Why Learning Assembly Language Is Still a Good Idea
Pages: 1, 2
Assembly Isn't Dead
Assembly language, of course, developed a very bad reputation throughout the 1990s. Advances in compiler technology, improved CPU performance, and the "software crisis" all conspired to suggest that assembly language was a "dead" language that was no longer needed. As assembly language was a bit more difficult to learn than traditional high-level programming languages, students (and instructors!) gladly embraced this brave new high-level world, abandoning difficult-to-learn assembly in favor of higher and higher level languages.
The only problem with the demise of assembly language is that as its popularity waned, so did the percentage of programmers who understood the low-level ramifications of the code they were writing. Those programmers who were claiming that assembly language was dead already knew how to think in assembly language and how to apply that low-level thinking to their high-level code; in effect, enjoying the benefits of assembly language while writing high-level language code. However, as new programmers worked their way into the system, without the benefits of having written several applications in assembly, the efficiency of software applications began to decline.
Though it would be foolish to start claiming that programmers should begin writing commercial applications in assembly language, it is clear today that the demise of assembly language's popularity has had a big impact on the efficiency of modern software. To reverse this trend, one of two things must happen: programmers must once again begin studying assembly language, or they must somehow pick up this low-level programming knowledge some other way.
Learning assembly language still remains the best way to learn the basic organization of the underlying machine. Those programmers who take the effort to master assembly language become some of the very best high-level language programmers around. Their ability to choose appropriate high-level constructs to produce efficient code, their ability to read disassembled high-level language code and detect heinous bugs in a system, and their understanding of how the whole system operates elevates them to near legendary status among their peers. These are the programmers everyone goes to when they have questions how to implement something. These are the engineers who garner the respect of everyone around them. They are the ones other programmers want to emulate. These are the programmers who write great code.
If knowing assembly language helps make programmers great, a obvious question is "Why don't more programmers learn assembly language?" Part of the problem is prejudice: many college and university instructors that teach assembly programming begin their course with a statement like, "No one really needs to know this stuff, and you'll never use it, but it is required by this program so we've got to struggle through the next several weeks studying this material." After four years of this type of attitude from their instructors, it's no surprise that students really want nothing whatsoever at all to do with assembly language programming.
Still, once it becomes obvious to a coder that the truly great programmers are the ones who've mastered assembly language programming, you might ask why more programmers don't pick up this valuable knowledge. The only problem is that, traditionally, most programmers have found it difficult to master assembly language. Assembly is radically different than most high-level languages, so learning assembly language is almost as much work as learning programming from scratch.
To someone attempting to learn assembly, it often seems as though none of their past programming experience is of any help. All too often, an engineer learning assembly becomes frustrated with the fact that they know how to achieve a goal in a high-level language but they cannot figure out how to achieve the same thing in assembly. For many programmers, switching from "thinking in a high-level language" to "thinking in an assembly language" becomes an insurmountable problem.
As an instructor teaching assembly language for over a decade at the University of California, I was quite aware of the problems students have making the transition from the high- level programming paradigm to the low-level programming paradigm.
In the early 1990s, Microsoft provided a solution with the introduction of the Microsoft Macro Assembler (MASM) v6.0 -- the inclusion of high-level control structures in an assembly language translator. While these new statements are definitely not true assembly language, they do provide a nice transition path from traditional, imperative, high-level programming languages to assembly. A programmer can continue to use statements like IF, WHILE, and FOR while learning other aspects of assembly language programs. This lets the programmer learn assembly language programming in graduated steps rather than having to make the plunge all at once.
Master Low-Level Statements
Of course, a programmer cannot truly call themselves an assembly language programmer until they've mastered the equivalent low-level statements. Nevertheless, these high-level control structures provide an excellent bridge between high-level languages and assembly language, allowing the student to leverage their existing high-level programming knowledge to learn assembly language. Alas, there are few, if any, appropriate textbooks that teach assembly language programming using this high-level to low-level approach using the high-level control structures that MASM provides.
Another problem with the high-level to low-level transition is that most high-level languages provide large libraries of routines to handle mundane tasks such as input/output, numeric conversions, and string operations. A big problem that beginning assembly programmers face is that they typically need the ability to input and output numeric quantities or do numeric-to-string conversions (and vice versa) in order to write and test very simple programs. Unfortunately, most assembly language development systems leave it up to the programmer to provide this functionality for their applications. This presents a Catch-22 situation: it is difficult to learn assembly language without these functions, but you can't really write such functions until you learn assembly language.
These roadblocks effectively prevent all but the most determined programmers from mastering assembly language. As such, throughout the 1990s and early 2000s the use of assembly language continued to wane. Seeing the decline in software efficiency and quality that seemed to track the decline of the use of assembly language, I set out on a crusade in the mid-1990s to encourage programmers to learn assembly language programming.
The first milestone I achieved was the release in the mid-1990s of the electronic edition of The Art of Assembly Language. This book, along with the use of the accompanying UCR Standard Library for 80x86 Language Programmers, reduced the effort needed to learn assembly language programming. Tens of thousands of programmers have learned assembly language programming using this textbook and the complementary set of library routines.
The only problem with the electronic edition of The Art of Assembly Language and the UCR Standard Library for 80x86 Assembly Language Programmers is that they were almost obsolete as soon as they appeared on the Internet because they taught the reader how to create 16-bit DOS applications (their release almost corresponded with the release of Windows 95, which was one of the last nails in the 16-bit programming coffin).
Still on the crusade, I started to work on a brand-new, high-level assembler (HLA, the High-Level Assembler), a new version of The Art of Assembly Language, and a new, 32-bit, HLA-based set of library routines. This effort culminated with the release of the published edition of The Art of Assembly (AoA) in 2003. To date, thousands and thousands of programmers have enthusiastically embraced this new way of learning assembly language using AoA, HLA, and the HLA Standard Library.
Though The Art of Assembly Language and HLA are increasing the ranks of assembly language programmers every day, the solution they provide is for the next generation of programmers.
What about current programmers who've missed the opportunity to learn assembly language while in school and master the concepts of machine organization before the realities of project schedules rob them of the time needed to develop the necessary expertise to write great code? The question is, "Can machine organization be effectively taught to professional programmers without simultaneously teaching assembly language?"
While it is fairly clear that learning assembly language is the best advice I can give anyone who is interested in writing great, efficient code, I am also convinced that someone can study the subject of machine organization sans assembly and still learn how to write better code. Perhaps their code won't be quite as good as the programmer who has mastered assembly language, but it will be better than the software they've written devoid of this knowledge.
Most importantly, while it is difficult to sell the idea of learning assembly language to the current generation of programmers (two decades of anti-assembly propaganda have assured this), most programmers realize that if they just "learned a little more about how the underlying hardware works" they would be able to write better code. So what is needed is a set of materials that teach data representation, memory organization, elements of computer architecture, how input/output operates, and the correspondence between high-level programming language statements.
That is, teach them all the things that they'd have to learn when learning assembly language, with the single exception of mastering the assembly language programming paradigm. Recently, I've begun to focus on this group, working on books like Write Great Code, Volume One: Understanding the Machine, a book on machine organization that doesn't specifically teach assembly language programming. While someone studying machine organization might not write code as great as someone who takes the time to master assembly language, my hope is that those who would never consider learning assembly language might be willing to pick up a book like Write Great Code and learn to write better code, if not totally great code.
Conclusion
To write great code requires one to write efficient code. Writing efficient code requires good algorithm choices and a good implementation of those algorithms. The best implementations are going to be written by those who've mastered assembly language or fully understand the low-level implementation of the high-level language statements they're choosing. This doesn't mean that we'll return to the days when major commercial applications were written entirely in assembly language. However, to reverse the trend of software running slower and slower even though CPUs are running faster and faster is going to require programmers to begin considering the low-level implications of the code that they write.
So, even if you never intend to write a single line of assembly language code again, learning assembly language, and learning to think in assembly language, is one of the best things you can do to learn how to write better assembly code.
[1] Moore's Law states that semiconductor technology doubles in capacity or performance at a given price point about every 18 months.
Randall Hyde is the author of the recently released "Write Great Code" and "The Art of Assembly Language" (both from No Starch Press), one of the most highly recommended resources on assembly.
Return to ONLamp.com.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 35 of 35.
-
Where's the information?
2005-01-18 08:51:45 MaCo [Reply | View]
As machines goes more advanced, they are too more complicated to understand.
Today's programmers have little chance to get the machine's structure.
Of course, a processor is still based on it's old predecessors, but there are little information about them.
Thanks, for remembering assembly, my very first programming language.
-
Where???
2004-11-09 18:25:05 jbellew [Reply | View]
Where can I find information about learning Assembly for my PowerMac G4. Apple has info but I'm looking for something that teaches assembly for the PowerMac??
If you go any ideas let me know...
-
My views on asm
2004-10-05 01:00:13 Al_Leitch [Reply | View]
In my view, I feel the most important reason to learn asm is to get a deeper understanding of the machine and to be able to speed up your algorithms when you find that even the best optimization options along with your best source code optimization attempts don't quite live up to what you want. It would be frustrating to be stuck at this point because you didn't know assembly. Granted you need to know what your doing, ESPECIALLY if you are coding on a RISC machine. One person on this board had described being able to code at the compiler level after one year of coding. I'm curious how long it would take to do so on a RISC machine.
Personally I have yet to beat a compiler, but I have the understanding that a non-asm programmer wouldn't have. One great example is the subject of pointers. This subject is one of the most difficult for many beginning C programmers to grasp, yet I had absolutely no trouble. All I'm trying to do is grasp the syntax.
Another cool thing about knowing assembly is that many people will think your pretty cool.
I wonder if anybody has obtained any good degree of optimization when coding in MS IL (.net asm) or Java assembler. Any input here?
-
rather teach c as "portable assembler"
2004-06-13 02:07:55 evan_summers [Reply | View]
i agree that learning a language more closer
tied to the machine is useful learning exercise
(in addition to the "real" development languages java and c#)
but i would recommend c be taught, rather than asm, in addition to java
from this exercise the learner will understand
performance/optimisation issues, memory management issues, etcetera
another approach is to teach embedded c programming, which is fun for the learner
and requires optimum use of limited resources
eg. 8052 microcontroller with 256 bytes RAM
-
Don't rush over to your assembly handbook just yet!
2004-06-12 15:27:42 Prutser [Reply | View]
Compiled Code
I think the author is missing some important things. When he reasons that a programmer can gain efficiency by rearranging machine instructions manually, it seems a bit as if he failed to keep pace with the scientific work done in the field of compiler construction over the last 20 years or so.
Today's compilers (especially the mature C compilers) contain amazingly impressive algorithms in the code-generating back-end that are fully optimized for the target language. Using mechanisms such as BURS (bottom-up rewrite systems), together with a built-in, up-to-date set of machine instructions for the CPU at hand (including relative costs), these backends are guaranteed to find the optimal arrangements of instructions.
Important here also is that most humans aren't fully aware of the specialized instruction sets of modern CPU's. Compilers are.
This may have been different 20, 30 or 40 years ago, but like the author's programming skills, compilers too have come of age.
Interpreted Code
The author must realize that more and more software is written in higher level languages. Some of these don't even produce executable code (java for example). When the author claims that one should think assembly, but write high-level code (to choose language constructs that translate to better machine code), it's unclear which instruction set to follow. Either that of the intermediate code, or that of the real hardware. Also, interpreted code often runs on a multitude of platforms, each having their own specialities. The quality of the interpreter (and possibly JIT stages) and runtime system is critical.
Conclusion
Profound knowledge of assembler is definately still crucial. However, these efforts are far more lucrative when writing a compiler than when writing a program that is still to be fed to a compiler.
Probably the gradual shift to higher languages with highly optimized interpreters/compilers isn't as bad as the author suggests.
regards,
Erik
-
Why learning HTML is Still a Good Idea
2004-06-12 12:28:29 mangalasss [Reply | View]
http://webster.cs.ucr.edu/
A tragically atrocious site that inhibits access to, and comprehension of, what seems to be a lot of excellent information.
-
From C to assembly
2004-06-12 00:07:54 sigsoftware [Reply | View]
A good way to begin learning assembly language is to take a small piece of time-critical C code, perhaps 20-30 lines, then disassemble it and work out how the C maps to the assembly. Draw a picture with registers, pointers and arrows, and really get to the bottom of what is going on.
Then you can start making the implementation more efficient by finding superfluous calculations and rewriting the C in a series of iterations to reduce the number of branches and instructions.
With the exception of a few operations such as rotate, C has all you need to write assembly code, with the advantages of being cross-platform and more readable. Every high-level C construct (for, while, array dereference) has a fairly obvious breakdown in terms of branches, gotos and adds.
By applying this technique for important parts of my code, I regularly get a speedup of 2-4x over gcc with its highest level of optimization.
-
A couple of bits to pick with the premise...
2004-06-11 20:45:32 MaxHeck [Reply | View]
If I may respectfully disagree with some of the ideas in the article:
I don't agree with the implied premise that knowing assembly makes you a better programmer. It's entirely possible to write complete garbage in assembly as it is in the latest language from Redmond, You just have to hit the reset button more often.
A better expression of the idea might be "Writing code on a dinky 2kb machine with a 1Mhz processor will teach you how to truly code efficiently, whatever language you use."
I know, I've been there! When Intel's chips opened up the flat memory space and got rid of the 64k segmented model, well... An entire new world opened up for me, at least.
And please don't get me wrong... I love assembly. My favorite technique (when it's useful, for anything I want to move fast) is to prototype in my own stripped-down version of C++ and then once I have the bugs worked out then re-write in assembler.
At the same time, sometimes it's not worth it. Put it this way... I'll not write my own RDBMS when I can just write a select statement in someone else's version of SQL. Perhaps I could write something faster, but A) that's doubtful at best, and B) I'd spend more time in writing it than I'd likely save in executing it within my expected lifespan. Nuts to that!
What I *DO* agree with is that understanding the underlying code does make you think about optimization, although I wonder how much so with current languages.
A Q-sort is a Q-sort, no matter what it's written in. I don't know that being able to write it in assembler is going to make that much difference if you're bound to writing it in say... Java.
Max
-
Why learning assembly language is useful in like 1 case out of tens of thousands
2004-05-18 07:48:14 Betelgeuse [Reply | View]
I learned assembly language back in the 8 bit microcomputer era. I started on a Commodore 64 learning the 6502 processor and eventually graduated to an IBM PC learning 80x86 assembly. I retain a significant amount of information from this era. This has come handy a few times during my career when looking at mixed source/assembly. While at Microsoft (yes I spent time there) I had occasion to identify a bug in the Visual Studio debugger which would not have been possible without my previous experience. Debug points are set in the Intel 80x86 through an INT 9 software interrupt. The debugger needs to replace values in a code segment and when it ultimately handles the breakpoint needs to put back the values it overwrite. I had some C++ template code where clearly this was not happening.
Nevertheless assembly language knowledge has become extremely niche. Unless you are working on embedded devices it has become mostly irrelevant. And with virtual machines (Java's and Microsoft's CLR) becoming accepted due to the high computing power afforded people's code people are that much further removed from having visibility into this layer of computing.
I could say, "Yeah, you should learn hardware digital design and Karnaugh maps since it will improve your understanding." Yes I suppose learning hardware design will give you even MORE insight into computing but assembly language is starting to go in this direction - diminishing returns.
Hey, I'm all for expanding my horizons through learning but in this time of dozens upon dozens of APIs that software people have to worry about, specialization is key and assembly language has become mostly irrelevant given its very low priority to get the job done.
Sure there are certain instances where it can be handy but those times have been very few and very far between. -
Why learning assembly language is useful in like 1 case out of tens of thousands
2004-05-27 11:17:49 belze [Reply | View]
Based on my experience I believe there are lots of instances where the knowledge of assembler is very helpful (certainly a lot more than just "very few and very far between"). For example I often see horribly inefficient C++ programs written by people who don't understand when passing parameters by value is slower than passing by reference and when not. Without any basic understanding of the way passing arguments to a function is actually implemented it is probably quite difficult to write a good C++ program. This was just one example but I can provide a lot more.
It is true that these days virtual machines are becoming more and pore popular. But this doesn't remove the need to know how the computer operates. Virtual machine can be thought of as a type of a computer with its own assembler (called "bytecode" in JVM, i don't know how it is called in .NET). So for example failure to understand how JVM operates will result in bad Java code (many Java programmers don't know how to use a proper object allocation strategy to greatly improve the speed of Java programs and its memory usage, etc, etc.).
-
Assembler is a compiler on steroids!
2004-05-13 03:20:59 SubEvil [Reply | View]
I am a professional assembler (former C/C++) programmer and an active member and contributor to the assembler community.
I started learning assembler about 3 years ago in my spare time. My first step, after learning the basic instruction set, was to co-write a small project in both assembler and C/C++. Using the disassemblies of my C/C++ program to help me program certain functions if/when I got stuck. My first program written in assembler was a chess game. To my enjoyment, I found assembler helped me make more optimizations in my C/C++ code (mainly the AI), than my C/C++ code helped me learn assembler. Among other things, by reading the disassembled C/C++ (VC6) code I found by simply moving several instructions around in my project, the compiler was able to generate smaller and faster executing output. At first, my assembler AI code was not performing as well as the C/C++ code, and I became aware of some nice optimizations made by the compiler. I implemented some in my Assembler program. I continued to optimize and eventually reached the/my limits of optimization in my C/C++ code. So, as the reason for the project was to learn assembler, I continued on my assembler project, satisfied with the C/C++ project. As time went by, and I learnt new/more assembler instructions (my assembler vocabulary grew) I began reaching, and exceeding the speed of execution of my C/C++ project. At the end of the day (3 weeks later), I was happy that the project allowed me such an in-depth look into what type of code the VC6 compiler produces.
During but mainly after this project, I disassembled many common Windows API and C/C++ library calls. I tried my hand at improving their speed/efficiency. My first achievement, almost 3 years ago was a 15% speed increase on the common itoa() (exported by msvcrt??.dll) function used to convert an int to it's ascii string representation (this function written by the assembler community is up to 20x faster). A while ago I had the need to improve the speed of the API call GetPixel(), the result was a 25x improvement that no C/C++ compiler would beat! And my most recent is an estimated 3x increase in speed of the lstrlen() (exported by kernel32.dll) function used to determine the length of an ascii string. I have found that the longer and more complex the algorithm, generally the greater the increase in speed. For study purposes, I have read disassemblies of many common functions used by C/C++ and API programmers (formerly like myself). I can now, comfortably say, that a compiler is hard pressed to beat my standard, un-optimized assembler code. Worst case scenario is that they (my un-optimized code and C/C++ release code) perform equally well.
About 1 year ago, I was commissioned to complete a database validation program, I had 3 days to get a basic working model complete. 6 users would use my program, which would display an image, and they would have to validate OCR entries. They would be validating for 6 months. Due to the extremely tight deadline (1 weekend), I chose to develop in Borland C++ Builder 6, with it's RAD interface (using VCL), taking only a few minutes to do the front end design (I had no time for a fancy front end and couldn't waste the time). I used Borland's library for JPEG images and database connectivity. The users started using my application, and I continued to add features to improve productivity. The biggest complaint, especially on the slower (pII/pIII) PC's, was speed. I profiled and improved algorithms and response times, but still, they were unhappy. I disassembled critical parts of code, moved and removed code and checks. It became apparent that we weren't going to meet our 6 month validation deadline at the current pace of validation. My boss had thoughts of increasing the user count. I decided to re-write critical and non-critical parts of my code in assembler. Non critical included populating thousands of entries in a list box (which rapidly increased in speed with assembler), as the user interface and more critical sections became faster, our validation speed (along with user familiarity with the system) increased. Response times increased and users complained less. Critical image retrieval, viewing and manipulation became more responsive, database connectivity, retieval and connectivity increased (I re-wrote many ODBC functions/features in assembler) and the older PC's were as responsive as the pIV's we had.
If nothing else, I would honestly have to agree that knowledge of assembler, has made me an all round better C/C++ programmer. It took me about 1 year of assembler studies to reach 'compiler' level. After 2 years, I was thinking and coding like a compiler. After 3 years, compilers are left in the dust.
One thing I would like to make clear about this 'transition' from C/C++ to assembler I was able to make. Is that the abundance of C/C++ source code and resources out there, is astronomical. Libraries, functions, snipets, help files and documentation. I initially found these resources difficult to come-bye in the assembler community. When I wrote C/C++ programs, I had my 'frameworks', my templates. I could write a project in 3 days. I have CD's full of C/C++ source code, example code on everything imaginable. I have years of the stuff. But I had very few for assembler. What I could do, of course was compile and disassemble. So that's what I did to get my assembler source code. But I'm happy with my assembler library now. I have assembler code to achieve everything and anything I want and need in assembler now. If I don't have it, I'll disassemble it.
My Pro Assembler comments
"You don't know the power of the dark side": Darth Vader. You don't know the power of assembler, till you learn. Have respect for it. Have respect for those that code in it. All languages have pros and cons, assembler included. All languages have a purpose and a reason for being there. Assembler will never die. By it's nature, it cannot die. Without assembler, there's no true performance. Sucking everything out of the CPU can only be done in assembler. When new CPU's and instructions come out, assembler is normally the first and only language to support them. C/C++ has no real native/built in support for MMX/SSE/SSE2 instructions. How else can you utilize these instruction sets? Maybe inline assembler but then you loose the 'benefit' of compiler optimizations.
I'm not the best assembler programmer, but I don't consider myself a newbie. I can say I consistently beat compiler output and my project deadlines are met, without 'buggy' code as some would argue and without complaint from users on performance. But I do consider myself lucky!
How much can this line in C/C++ be optimized?
for (int i = 0; i < count; i++)
<some code here>
In assembler you can optimize to your hearts content. For Intel/AMD CPU's for example.
Sorry for the long post guys.
For the love of programming, Assembler is king!
But it's a long dark road, with few to guide you!
Final words: YES, assembler made me a much better C/C++ programmer.
Regards!
-
Why has assembler re-emerged ?
2004-05-12 19:38:39 hutch-- [Reply | View]
Computer languages are diverse in response to the diversity of the tasks they are used for and in this context, assembler programming is one of the tools that has a very useful place in software development. Over many years students have been told that you no longer need assembler, compilers are so good now that there is no point. Then you have the folklore that you cannot write reliable assembler and it is impossible to debug yet with this particular dogma, the area in question is the knowledge base of the person saying it.
When pioneers like Bob Boyer and L Moore published their famous pattern matching algorithms back in the late 70s, it was in PDP10 assembler, not a soft and easy high level language. Any who remember the DOS modem program QMODEM may remember when it was converted from C to assembler where its size dropped by half, its performance improved dramatically and its functionality increased.
Nothing stings like the sheer brutal performance of well written assembler and for the sum total of opinion, size, speed and functionality laugh at them all as it is an objective test.
Someone sprouting nonsense from their recollections of assembler programming in the 80s is doing their students a disservice when no-one programs in the style that was still being used back then.
C, Pascal and basic were all available that long ago yet few would want to go back to pre 1990 C to program in when they have the best and latest tools available. Assembler programming is no different here, when you have so many powerful capacities at your disposal with the full range of Windows API functions, structures, unions, direct addressing and the very high powered macro capacity of a modern assembler, you don't write pre-1990 style code either.
Where assembler used to be hard with DOS segemented addressing, flat memory model made this far more powerful and far easier to use and the choice of instructions is wider and more flexible.
Those who have been tarred with the brush of soft easy high level languages may never make the transition to true low level programming but for the younger programmers who are seduced by the sheer performance of a modern assembler, the sky is the limit and you don't need a compiler writer to hold your hand when you write high performance code.
-
Assembly isn't dead.
2004-05-12 16:43:01 NoDot [Reply | View]
Assembly isn't dead.
Most people have problems believing assembly isn't a dead language. Anti-assembly types like most of the people posting here don't get the fact that, if you write bad code, then your teaching others and yourself to write bad code.
If assembly was a dead language, then I wouldn't be programming in it, places like www.masmforum.com wouldn't be around, bogdanontanu would be writing Hostile Encounter in C, ect.
I wish I could understand why you people don't like assembly language. It doesn't make any sense. Assembly is not dead.
Besides, this book isn't about teaching assembly. It's about learning about the machine. Optimizing compilers can only do so much. They have a limit.
Prepackaged routines are only useful to a degree. If you need something not provided for by the routines, then you have to write it yourself.
You anti-assembly people had best hope you never work for me, because if you do, you will be learning assembly language. I will demand that the best possible code be written, but still following good programming practices, of course.
I won't sacrifice most Sortware Engineering standards for preformance. I'm not dumb.
Stop the "blah, blah" and wakeup for the coffee. Assembly is still alive. Let the bells ring out.
-
Its about caring about your work
2004-05-12 01:29:24 menglis3 [Reply | View]
My value to my user, customer, audience is NOT about how fast my programs go. It is a balance between :
timely delivery of the functionality,
correctness of the functionality,
documentation of the functionality,
usability,
efficiency,
dollars,
customers priorities,
and a bunch of other stuff.
Because of libraries and interfaces supplied by operating systems and language environments, we don't have to exercise the degree of control and detail that Assembly programming requires. This is a "good thing(tm)" in many circumstances - I don't want to write a new video driver every time I get a new monitor. It means I can use high-level languages to add value to someone else's data - such as implementing a Data Warehouse.
The corollary is that the further I am abstracted from the hardware, the less control I have. So I have to be careful about how I code my high-level statements (be it COBOL, C. Java or my image definition for HTML) if I want them to be efficient. And that takes time. Bear in mind that the other attributes of a good program or task still have to be met, and that time is not a finite resource. The trade-off that most people make is calendar time v 'good' (not just efficient code) programming in general (see the list above). In many cases, once the program or code or functionality is working and documented, work stops on it (until the next change).
But that paragraph assumed that I had the choice in the first place, that I COULD code efficiently for the platform that I'm using. And the only way that will happen is if I know the environment, the tools and the platform. But how do I learn to code efficiently ?
It's more than just knowing Assembly coding. For example, if you define a set of type java.lang.String constants in one java class, and then you update the class to change the value of any of these constants, you must remember to recompile all other classes that use the changed constants (p44 of O'Reilly Hardcore Java Ch2 The Final Story - I'm NOT a java guru, but its a referenceable example I was looking at on the weekend).
So, by trying to write efficient maintainable code (in this case, by using constants), the unwary programmer can cause more problems than they solve. Even if you know what you're doing, will the person who maintains your code ?
The nett effect is that the learning curve can be very expensive, and this (along with the other pressures on a programmer) mean that it can be a difficult decision for an individual programmer to take. It is easier to say "yes, i know its inefficient, but so's 90% of ALL xyz code".
Take this personally if you like, but if you say that, then you're not a professional. Even when it comes to playpen stuff, learn to code efficiently, learn to document (so that you remember why you did it this way), and learn to give a damn about your work.
This way you'll have the confidence to say "yes, I know that part is inefficient, but it is efficient where it matters".
-
Question about O(n^2)
2004-05-11 21:52:29 rhyde [Reply | View]
O(n^2) means Big-Oh, n-squared.
O(n^lg^n) is a typo and should read O(nlgn)
(that is, n times log(n))
Both are rough descriptions of the running time of a program. With n inputs, the running time of an O(n^2) program increases by approximately four times whenever you double the value for n. For O(nLgn) the running time increases much more slowly.
-
O(n^2)? & powerpc learning material?
2004-05-11 15:26:10 __b__e__n__ [Reply | View]
"going from an algorithm with O(n^2) performance to one with O(n^lg^n) performance"
could anyone explain what O(n^2) and O(n^lg^n) means, preferably in a very simple down to earth way please? i've seen O(n^2), or something very similar, in many things i've read and never known what it means. any explenation much appreciated.
xtra question: anyone know of any good powerpc assembly books / tutorials?
thanks. -
O(n^2)? & powerpc learning material?
2004-05-14 04:06:42 CraigRinger [Reply | View]
http://www.nist.gov/dads/HTML/bigOnotation.html
and
http://en.wikipedia.org/wiki/Big_O_notation
may help.
It's really very simple once someone explains it. My understanding is that, for typical uses in terms of computing algorithms, it is typically used to represent "scaling" efficiency of algorithms.
O(n^2) is _fine_ for small values of n (usually data set size / number of items/records ), but quickly becomes a problem as n grows.
Here's an example from an app I'm currently working on. There's a function that runs in O(n^2) time, and I need to use it with large data sets. As it's not a super-fast operation anyway, the result is it's just too slow for me to be able to use.
I have to options to fix it.
(a) find a way to improve it in a constant way, and improve it enough that for my data sets the completion time is OK. I then have to hope my data sets don't grow.
(b) Improve it so that the increase in run time grows more slowly as n increases.
Currently:
Num rows Completion time
1000 3.7s
2000 11s
3000 25s
4000 46s
100000 ???
Not cool for web document delivery ;-) Note that the completion time is growing (roughly) in proportion to the square of number of rows:
1000**2 / 3.7 == 270270
2000**2 / 11 == 363636
3000**2 / 25 == 360000
4000**2 / 46 == 347826
I've been able to make some changes that allow the function to complete in O(n) time. Now (yeah, I know the row counts tested with are different):
4000 : 5s
8000 : 10s
20,000 : 24s
100,000: 131s
or:
4000/5 == 800
8000/10 == 800
20000/24 == 833
100000/131 == 763
make sense? The function used to process the data (n) times, meaning that it'd be procssing twice the data twice as many times when the data size was doubled. O(n^2). The revised function only processes the data once, and is able to complete in O(n) time.
The article comments on people being obsessed with improving algorihmic efficiency in terms of logical completion times - taking an O(n^2) algorithm to an O(n) one, for example. While I agree there are times that you can say "instead, I'm better off getting a 100-fold linear improvement in speed on my O(n^2) algorithm, that'll be good enough for the data set size I expect to use" there are also times when you need to say "O(n^2) is not OK; we need large data sets and I don't think we'll be getting the ten-million-fold linear speed improvement we'd need."
Both have value.
-
Its in the knowledge
2004-05-11 07:49:00 tlaurenzo1 [Reply | View]
I haven't written anything in assembly in a decade. However, back when I did it, I did some pretty cool stuff that FORCED me to learn not just the way the machine does things but the order in which all of the software layers interact. By integrating my assembly systems with high-level OO languages, I had to learn exactly how OO was implemented, and what the benefits and drawbacks to all of those compiler options are.
This has made me a better programmer at all levels. To this day, I am the only one in the office who can explain and fix the really bizarre COM/DCOM problems people run into periodically or intelligently explain why DCL (in Java) is what it is.
Did assembly language do all of this for me? Absolutely not. But I would say that the in-depth experience that I had with assembly was the most valuable part of my development as a programmer. Who knows, there may have been other (even better) ways to get to the same place in my development, but personally, I wouldn't trade the lessons learned from assembly development for anything.
As an aside, I didn't really cut my teath on MASM. I found the path of least resistance was to start with the old Borland Pascal or C compilers which had good support for inline assembly. At the beginning, this let you step down to assembly without giving up all of the built-in stuff (and having to learn the calling conventions up front was good background). It wasn't long before I was using Turbo Assembler and building stand-alone modules.
I personally find no use for assembly coding in my present job. And I think most jobs are like that. It still needs to be taught better in schools, though. We need more people who can "see through the layers" of software and easily translate their high level actions into how all of the moving parts interoperate.
-
Low level programming ?
2004-05-08 19:17:34 hutch-- [Reply | View]
Just think back a while when we used to have people saying "I have a blazingly fast 16 megahertz 286 with 4 mem of memory, you don't need to write great code with all of this computing power.". The proponent of this view today has the same problem as it had back then, the scale of the task changes with the capacity of the hardware and absorbing the capacity of the hardware with bloated sloppily written code limits the size and complexity of the task that can be performed.
Much of what passes for programming these days is little better than manipulating someone elses pre-packed software in much the same way as the ever maligned "end user" is supposed to do. The difference between the end user and the programmmer is the capacity to do things that can't be taken out of a box ready to run and somewhere along the line, it means actually knowing how to code an algorithm and do all of those messy complicated things like manage memory, handle pointers and the like.
There is an old joke that does make the point about learning something useful instead of treading the wide easy path to oblivion.
Q. What does a C programmer say to an ADA[tm] programmer ?
A. I will have onions with my french fries please.
Programmer who learn the hard stuff like assembler, C, Pascal or any of the well known languages have a skill they can adapt to a changing market over time. When the alternative is standing in a qeue trying to get a job pumping gas, is treading down the wide easy path worth the effort ?
-
Understanding architecture
2004-05-08 02:23:24 m_keightley [Reply | View]
While I agree that an understanding of a machines architecture is for some types of programming useful, for the ordinary application programmer it is of little use. If the writer of the under laying operating system have done there job well, the system libraries will contain tight and lean code that ‘understands’ the architecture and uses it to it’s fullest extent. This may or may not be true of certain modern operating systems!
In addition any thing more than a basic understanding of a modern 32 bit processor which may not even run directly the machine code you write is requires a completely new (and large) area of expertise. One which probably to wide and deep for an application programmer to learn along side what he or she already needs to know.
-
Is good code going to make my boss happy?
2004-05-07 16:09:36 rstens [Reply | View]
Not if I miss my deadlines and leave something behind that can only be maintained by myself.
The reason for higher level languages is that they do increase productivity. Assembler is notoriously unproductive.
System Performance was mentioned as a benefit. Most high level languages have optimizing compilers which crank out excellent code.
Good code typically is not a guarantee for great system performance. A great and solid architecture is.
As much as I like to have developers who do understand the consequences of their code, I do think that the author is flogging this horse to death.
The rant index on this article is pretty high.
I am a c++ programmer , interested in system programming.
First of all , I want to give thanks for providing such a valuable book.
All the examples in the book is for Intel. I am having AMD processor although the code work fine. But I need to know the Internals of 64 bit AMD processor.
I hope you will not stuck to Intel only and release a book for 64 bit programming with AMD.
Pralay