The fault in high level programming languages
Just sharing another thought from the programming world. Lattely I've been forced to look into assembly programming. And with awe and surprise I was struck! I came to appreciate the processor and what it goes through. More importantly I came to appreciate the connection of what happens in the processor and what is stored in memory. I was especially struck with the hoops the processor has to go through in order to fetch data from data structures in memory which are as a result of high level programming language features. I will take a simple case of data alignment. Those in the Java world are probably in a worse of case because they cannot choose the alignment for data allocated in memory (or may be Java does it for simple cases). The processor loves when the memory address of the data it fetches is aligned to a memory address value that is a multiple of the size of the data type. For example an integer is 4 bytes in size therefore an interger data should be in a memory address value that's a multiple of 4. For data structures then the alignment is according to the size of the data structure and this is where a high level programming language might screw up. Due to inheritance and polymophism a virtual table for function mapping is created in memory and the programmer has no control of that therefore the class data structure might not be aligned. High level languages seem to be created for the purpose of making modelling of real world concepts easier for the programmer, thus OOP. They seem to ignore the other world, the processor world. However compilers attempt to optimize the code for the processor but not always archieving the optimizations. Above is just a simple case. It's not completely explained but it introduces the idea. It probably won't make sense to someone who doesn't know C++ and processor stuff but atleast it's information for those willing to go under the hood! This doesn't matter for applications that are not concerned about performance. O_O.
I wouldn't call it a fault per se. You must also acknowledge that the lower the level of abstraction the more work the programmer has to do, and the more details the programmer must manage e.g. big endian vs little endian ordering, 64 bit vs 32 bit development, etc, functions & libraries vs first principle code. I think an analogy that fits this scenario is you don't have to know how an engine works to drive a car. Although if you do know how an engine works, you'll probably be a better driver. On Wed, Jul 8, 2009 at 8:52 AM, wesley kiriinya <kiriinya2000@yahoo.com>wrote:
Just sharing another thought from the programming world.
Lattely I've been forced to look into assembly programming. And with awe and surprise I was struck! I came to appreciate the processor and what it goes through.
More importantly I came to appreciate the connection of what happens in the processor and what is stored in memory. I was especially struck with the hoops the processor has to go through in order to fetch data from data structures in memory which are as a result of high level programming language features.
I will take a simple case of data alignment. Those in the Java world are probably in a worse of case because they cannot choose the alignment for data allocated in memory (or may be Java does it for simple cases). The processor loves when the memory address of the data it fetches is aligned to a memory address value that is a multiple of the size of the data type. For example an integer is 4 bytes in size therefore an interger data should be in a memory address value that's a multiple of 4. For data structures then the alignment is according to the size of the data structure and this is where a high level programming language might screw up. Due to inheritance and polymophism a virtual table for function mapping is created in memory and the programmer has no control of that therefore the class data structure might not be aligned.
High level languages seem to be created for the purpose of making modelling of real world concepts easier for the programmer, thus OOP. They seem to ignore the other world, the processor world. However compilers attempt to optimize the code for the processor but not always archieving the optimizations.
Above is just a simple case. It's not completely explained but it introduces the idea. It probably won't make sense to someone who doesn't know C++ and processor stuff but atleast it's information for those willing to go under the hood!
This doesn't matter for applications that are not concerned about performance.
O_O.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Skunkworks announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science - http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi - http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general
On Wed, Jul 8, 2009 at 8:52 AM, wesley kiriinya<kiriinya2000@yahoo.com> wrote:
High level languages seem to be created for the purpose of making modelling of real world concepts easier for the programmer, thus OOP. They seem to ignore the other world, the processor world.
Apart from easier and practical real-world modelling ...cross-platform portability is the other major requirement that has made direct-memory access languages cumbersome to use ....as opposed to higher level memory sandboxed programming languages... ashok
@Wesley tis very true. Until you go down there, you may never understand what running full blast is all about!! Here's a thot, if you can make libaries in assembly, then use these in C and C++ via asm, I think things can get pretty fast (Kinda what java does to C using native). On Wed, Jul 8, 2009 at 12:56 PM, <ashok+skunkworks@parliaments.info<ashok%2Bskunkworks@parliaments.info>
wrote:
On Wed, Jul 8, 2009 at 8:52 AM, wesley kiriinya<kiriinya2000@yahoo.com> wrote:
High level languages seem to be created for the purpose of making modelling of real world concepts easier for the programmer, thus OOP. They seem to ignore the other world, the processor world.
Apart from easier and practical real-world modelling ...cross-platform portability is the other major requirement that has made direct-memory access languages cumbersome to use ....as opposed to higher level memory sandboxed programming languages...
ashok _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Skunkworks announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science - http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi - http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general
-- www.dealcent.com - Your electronics shop www.golavish.com - The travel and leisure www.raccuddasys.com - code Development issues
Depending on what you are trying to achieve, it could or could not be regarded as fault. Personally I learnt Assembly before learning C/C++ and true, that understanding assembly takes you to another level as a programmer. It gives you a greater understanding of how hardware works with your code and that knowledge can be invaluable when push comes to shove. Though not portable like high level languages for the obvious reason it is architecture specific... although there programs called assemblers that can do this translation into other architectures. Anyway. Here's the thing. a lot of the current crop of developers fear languages with low level features like the dreaded C/C++ so going into Assembly is just pushing it too far for them. Not that its wrong to use high level languages, i also write code in other languages based on my needs for the day. Now for those familiar with low level workings of the processor, memory, storage; will be able to attest that using Assembly can get you those tight optimizations you re looking for to boost program performance. With today's processor speeds and modern hardware, it may not be necessary to have those optimizations as far as software applications apply. Now for game development esp those that need lightening fast responses, Assembly can be an gem. Other places where Assembly can give a serious performance boost if when dealing with processor intensive tasks like encryption algorithms, loops. For those that want to go into certain real time precise systems like simulators, flight and sea navigation, embedded systems, medical monitoring equipment. Compilers themselves... coding the Bios... boot loaders, graphic acceleration.. etc. With a dissasembler in hand, It would also be probably fun for many people on this list to learn assembly as can it can give you the ability to reverse engineer, crack etc etc Software or games. and you wouldn't need to keep googling around looking for cracked software or asking for keys and stuff. (Disclaimer: Nobody ask me for help coz i wont help you). Personally i no longer write anything in assembly directly mainly coz like most coders today, i don't have any direct practical application that would need me to hand code it, then also Visual Studio (that's what i mainly use in addition to others) does a great job of generating highly optimized Assembly code from the C/C++ i write. Steve Obbayi, Tel: +1 202 470 0575 cell: +254 722 627691 _____ From: skunkworks-bounces@lists.my.co.ke [mailto:skunkworks-bounces@lists.my.co.ke] On Behalf Of wesley kiriinya Sent: Wednesday, July 08, 2009 8:52 AM To: Skunk Works Subject: [Skunkworks] The fault in high level programming languages Just sharing another thought from the programming world. Lattely I've been forced to look into assembly programming. And with awe and surprise I was struck! I came to appreciate the processor and what it goes through. More importantly I came to appreciate the connection of what happens in the processor and what is stored in memory. I was especially struck with the hoops the processor has to go through in order to fetch data from data structures in memory which are as a result of high level programming language features. I will take a simple case of data alignment. Those in the Java world are probably in a worse of case because they cannot choose the alignment for data allocated in memory (or may be Java does it for simple cases). The processor loves when the memory address of the data it fetches is aligned to a memory address value that is a multiple of the size of the data type. For example an integer is 4 bytes in size therefore an interger data should be in a memory address value that's a multiple of 4. For data structures then the alignment is according to the size of the data structure and this is where a high level programming language might screw up. Due to inheritance and polymophism a virtual table for function mapping is created in memory and the programmer has no control of that therefore the class data structure might not be aligned. High level languages seem to be created for the purpose of making modelling of real world concepts easier for the programmer, thus OOP. They seem to ignore the other world, the processor world. However compilers attempt to optimize the code for the processor but not always archieving the optimizations. Above is just a simple case. It's not completely explained but it introduces the idea. It probably won't make sense to someone who doesn't know C++ and processor stuff but atleast it's information for those willing to go under the hood! This doesn't matter for applications that are not concerned about performance. O_O.
Think http://www.amazon.com/Expert-NET-2-0-IL-Assembler/dp/1590596463 might interest some of you. Be sure to read the comments. http://www.bitwisemag.com/2/Expert-NET-2-IL-Assembler On Thu, Jul 9, 2009 at 8:06 AM, Steve Obbayi <steve@sobbayi.com> wrote:
Depending on what you are trying to achieve, it could or could not be regarded as fault. Personally I learnt Assembly before learning C/C++ and true, that understanding assembly takes you to another level as a programmer. It gives you a greater understanding of how hardware works with your code and that knowledge can be invaluable when push comes to shove.
Though not portable like high level languages for the obvious reason it is architecture specific... although there programs called assemblers that can do this translation into other architectures.
Anyway. Here’s the thing. a lot of the current crop of developers fear languages with low level features like the dreaded C/C++ so going into Assembly is just pushing it too far for them. Not that its wrong to use high level languages, i also write code in other languages based on my needs for the day.
Now for those familiar with low level workings of the processor, memory, storage; will be able to attest that using Assembly can get you those tight optimizations you re looking for to boost program performance.
With today’s processor speeds and modern hardware, it may not be necessary to have those optimizations as far as software applications apply. Now for game development esp those that need lightening fast responses, Assembly can be an gem. Other places where Assembly can give a serious performance boost if when dealing with processor intensive tasks like encryption algorithms, loops.
For those that want to go into certain real time precise systems like simulators, flight and sea navigation, embedded systems, medical monitoring equipment. Compilers themselves... coding the Bios... boot loaders, graphic acceleration.. etc.
With a dissasembler in hand, It would also be probably fun for many people on this list to learn assembly as can it can give you the ability to reverse engineer, crack etc etc Software or games. and you wouldn’t need to keep googling around looking for cracked software or asking for keys and stuff. (Disclaimer: Nobody ask me for help coz i wont help you).
Personally i no longer write anything in assembly directly mainly coz like most coders today, i don’t have any direct practical application that would need me to hand code it, then also Visual Studio (that’s what i mainly use in addition to others) does a great job of generating highly optimized Assembly code from the C/C++ i write.
Steve Obbayi,
Tel: +1 202 470 0575 cell: +254 722 627691
------------------------------ *From:* skunkworks-bounces@lists.my.co.ke [mailto: skunkworks-bounces@lists.my.co.ke] *On Behalf Of *wesley kiriinya *Sent:* Wednesday, July 08, 2009 8:52 AM *To:* Skunk Works *Subject:* [Skunkworks] The fault in high level programming languages
Just sharing another thought from the programming world.
Lattely I've been forced to look into assembly programming. And with awe and surprise I was struck! I came to appreciate the processor and what it goes through.
More importantly I came to appreciate the connection of what happens in the processor and what is stored in memory. I was especially struck with the hoops the processor has to go through in order to fetch data from data structures in memory which are as a result of high level programming language features.
I will take a simple case of data alignment. Those in the Java world are probably in a worse of case because they cannot choose the alignment for data allocated in memory (or may be Java does it for simple cases). The processor loves when the memory address of the data it fetches is aligned to a memory address value that is a multiple of the size of the data type. For example an integer is 4 bytes in size therefore an interger data should be in a memory address value that's a multiple of 4. For data structures then the alignment is according to the size of the data structure and this is where a high level programming language might screw up. Due to inheritance and polymophism a virtual table for function mapping is created in memory and the programmer has no control of that therefore the class data structure might not be aligned.
High level languages seem to be created for the purpose of making modelling of real world concepts easier for the programmer, thus OOP. They seem to ignore the other world, the processor world. However compilers attempt to optimize the code for the processor but not always archieving the optimizations.
Above is just a simple case. It's not completely explained but it introduces the idea. It probably won't make sense to someone who doesn't know C++ and processor stuff but atleast it's information for those willing to go under the hood!
This doesn't matter for applications that are not concerned about performance.
O_O.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Skunkworks announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science - http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi - http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general
participants (6)
-
ashok+skunkworks＠parliaments.info -
Frankline Chitwa -
Murigi Muraya -
Rad! -
Steve Obbayi -
wesley kiriinya