Article:
  Why Learning Assembly Language Is Still a Good Idea
Subject:   Modern Programmers Should Write Code in Assembly
Date:   2004-05-06 17:17:57
From:   Trackback from http://www.alpha-geek.com/2004/05/06/modern_programmers_should_write_code_in_assembly.html anonymous2
I agree with almost nothing in Why Learning Assembly Language is Still a Good Idea, and I believe, I can generate a valid (if not unnecessarily contrived) counterpoint to each of his points. However, it did make me wish I...
Full Threads Oldest First

Showing messages 1 through 10 of 10.

  • Modern Programmers Should Write Code in Assembly
    2004-05-07 04:40:07  archdev [View]

    Agreed. A large part of the article borders on being useless rant. The worst part is how he used the example of word processor speed not following Moore's law as an argument for programmers not writing good code. While I can say that MS Word and the like are bloatware, buggy, proprietary etc., I find no need for it to increase in speed by a factor of 10000x+.

    Probably the only valid point in the entire article: implementation is the main weakness of most code. And don't blame the programmers in such a casual and irresponsible manner unless you're desperate to be flamed.
    • Modern Programmers Should Write Code in Assembly
      2004-05-11 04:50:25  jwenting [View]

      Maybe that word processor doesn't need to be 10.000 times faster to be efficient, but in a multi-threaded or multi-CPU system those other applications running in the background would benefit a lot if it were.

      Just an example of poorly written code that could easily have been a lot better:
      The drivers for my printer block my entire machine for as long as the printjob lasts.

      In your world such is perfectly OK, after all the printer doesn't need the machine to be available for other things while printing so why make the driver such that it does not block the machine?

      But maybe the user (me!) wants to do something else while his printer chugs away on that 100 page printjob in the background. Why didn't you think of that?

      And yes, I've learned assembly in uni. And there too it was abandoned because OO languages were all the rave at the time.
      We used to learn Assembly and Pascal, then along came C++ and every single curiculum was changed to that in the blink of an eye.

      I'd wish I had time to keep up my assembly skills but I don't...

      Instead I continue to keep the lessons learned in mind. Which operation will yield the smallest possible number of CPU cycles or OS calls, what memory structure is the most efficient, etc.

      Every programmer should be forced to run his tests on the absolute minimal hardware the program is to run on (as determined by marketing, not himself).
      Until he is no longer swearing under his breath because the application is unworkable because of performance or user interface design (another area where major improvements can be made, and I don't mean skinnable applications which are a cheap "solution" that does nothing) he's not allowed to pass it on to the test team (you do have testers in-house don't you?).

      One of the things I was asked to do as a contractor was to improve the performance of a small (about 1MB source) C++ application.
      It was beautifully architectured, applying every design pattern known to Man and adhering strictly to the rule that everything is a class and every bit of code that's used more than once should be a method.
      In fact, that beauty was its disaster. All the object creation, method callstacks, etc. etc. etc. caused so much performance overhead that the application needed 36 hours to run a relatively simple check over a logfile of approximately 1MB.
      I'd have rewritten it from scratch in C but that was not allowed, so I did the next best thing which was to optimise the heck out of existing code by things like unrolling loops and inlining one-liner methods (did I tell you the author had deemed it prudent to create a method to add 2 ints, adding a method callstack to "x=y+z"?
      In the end I was able to shave 20 hours (or roughly 60%) from the runtime with such simple optimisations, not a bad gain at all given that the application was supposed to run once a day which was now possible where in the past it had not been.

      Had the author of the application (who had left the company to write theoretical books on C++ application design and UML) had a grain of realism he'd have realised the performance penalties in his design and used some pragmatism, thus saving the company a week of my time (at €100 an hour consultancy fees) and a lot f frustrated users.

      And there's the other big problem these days with performance:
      Many applications are designed by OO theorists who have no understanding of the implications of their theories on the performance of the code those designs dictate.
      Not every performance problem is because of a poor implementation of an algorithm.
      Many problems have to do with copious method calls, object creation and mandated errorchecking enforced by insistance on all kinds of frameworks, design patterns and best practices.

      While these may make for fantastically maintainable code (I beg to differ as overenginered code is as hard or harder to maintain than underengineered code), they also make for poor performance and code bloat.

      At one project (in which the same designer named earlier had a big impact) a relatively simple automated mailer and customer management program (booking of incoming documents, automated generation of reminder letters, etc.) took up 100MB of sourcecode which yielded roughly 50MB of executable and DLLs.
      A weekly printrun of roughly 500 pages of form letters would take over 24 hours to complete until we went in and created some hooks that allowed the printing system to be rewritten to bypass about 80% of the application framework (so 80% of the object creation and method calls generated by overdesign).
      After that the same printrun was limited in speed only by the speed of the printer and the underlying database calls...
    • Modern Programmers Should Write Code in Assembly
      2004-05-08 09:35:57  kain [View]


      Yes, with attitudes like these, it is easy to see why we the scale of inefficient and buggy
      programs are increasing at an alarming rate. People just don't care anymore. Just meet
      the deadline and worry about patching the bugs later. They only want to drive the car
      without bothering to learn the basics of automotive care.

      Pretty soon, even low level HLL's like C are going to disappear in favor of basic-like
      scripting languages. I can envision Microsoft heading this way.

      But that's okay... As long as people don't care that a 1+ MB bloatware can be coded to
      run faster and sleeker at less than 100k. But some of us *do* care. We are climbing out
      of the box that has been built around us. You don't have to conform to a standard to be
      successful. If everyone conformed to a standard, we would still be in caves rubbing two
      sticks together.

      Assembly language has gotten a bad rap. Mostly by those too ignorant or too lazy to
      bother learning it themselves. New advances make it easier to code and maintain.
      However, one doesn't have to code in assembly to reap its benefits. Just learning machine
      architecture is enough to produce cleaner and more efficient HLL code. Though you
      won't get anything close to a magnitude of 10000+, even a magnitude of 2-3x speed
      increase can make a big difference if the user is working on time-critical, large
      data-intensive projects.

      Also to consider: while many modern machines are blazingly fast, the majority of the
      world still runs on lower end machines where even small increases in speed can make a huge impact.
      • Modern Programmers Should Write Code in Assembly
        2004-05-09 00:38:43  archdev [View]

        If you'd really read the opinions "bashing" the article, you should find that the attitude problem does not lie with us. (Had the title of the article been "Modern programmers should include more assembly in their code", more people would have agreed wit him.)

        It appears that both the author and you do not understand the origin of all the problems you've mentioned (e.g. bloatware, bugs).

        They stem from:
        1. Reality. Programmers don't get to set deadlines and decide whether a software is in a state to be released or not. Managers do. And as a rule of thumb, the latter does not listen to the former.

        2. Poor/ lousy/ (add your negative adjective here) programming. If you can write a 1MB+ bloatware in C, Pascal, (add your language here), etc., chances are you will do so in assembly too (or maybe you won't be able to get it working at all). The "bloat" part of the software is not added by the compiler, it's added by the programmer. Same for bugs.

        Assembly language has such a bad rep not because people are lazy or ignorant, but because it's not efficient to the *programmer*. No amount of advances can make it as easy to code and maintain as a higher-level language. C (or C++) is often considered to be the lower limit, because at this level, it maintains "human readability" even in large projects and yet I can be reasonably sure that the compiler will do a good job if I write my code properly. Why learn assembly if I can spend half the time and effort in C and the compiler can then do a better job than if I had written in assembly? OK, so even the best compilers have their blind spots but overall they shouldn't be worse than the average programmer in churning out code. (BTW, I used to learn assembly, and have learnt quite a bit about optimizing assembly code by playing around with compilers.)

        In fact, the same argument can be applied to learning about machine architectures, since there are so many different models in use (you said so yourself) and the compilers are likely to be just as capable (or incapable) of optimizing code across so many platforms. Be aware that there are more than just performance to be considered here, there are other things like portability, security, compatibility. In addition, external influence is not limited to the CPU, the operating system and settings, HDD speed, multi-tasking/multi-threading can all affect your software in good and bad ways. If you'd really tried, you'll find that it's much harder than you think to attain a speed increase of "even" 2-3x in large projects by simply switching to and optimizing code in assembly.

        (And BTW, you're not implying that MS Word is an example of "time-critical, large data-intensive projects", are you?)
        • Modern Programmers Should Write Code in Assembly
          2004-05-09 18:17:33  mlarson [View]

          "They stem from:
          1. Reality. Programmers don't get to set deadlines and decide whether a software is in a state to be released or not. Managers do. And as a rule of thumb, the latter does not listen to the former."

          Not all the time. It just depends on your manager. For instance, my manager listens to me. I actually program in assembly for a living, and I have no problems meeting my deadline. The source code we have runs in the 10MB-11MB range. I have no problems updating and maintaining that code.


          "2. Poor/ lousy/ (add your negative adjective here) programming. If you can write a 1MB+ bloatware in C, Pascal, (add your language here), etc., chances are you will do so in assembly too (or maybe you won't be able to get it working at all). The "bloat" part of the software is not added by the compiler, it's added by the programmer. Same for bugs."

          Well anyone can be stupid and write bloatware. What the assembler programmers are saying is that if you really want to make your code run fast and efficient, knowing how the processor works can really help you write effective code. That doesn't necessarily mean you have to write in assembler to learn that. However, after learning assembler I write faster C code now, because I really understand how the processor works and what C commands get turned into what assembler commands. So it really lets me take advantage of that. For instance did you know that on the P4 shifts are slow? So using shifts in C or any other language is slow. So if I know my program is going to be running on P4's I try and avoid shifts in the code if possible. C<<4.

          "Assembly language has such a bad rep not because people are lazy or ignorant, but because it's not efficient to the *programmer*. No amount of advances can make it as easy to code and maintain as a higher-level language. C (or C++) is often considered to be the lower limit, because at this level, it maintains "human readability" even in large projects and yet I can be reasonably sure that the compiler will do a good job if I write my code properly. Why learn assembly if I can spend half the time and effort in C and the compiler can then do a better job than if I had written in assembly? OK, so even the best compilers have their blind spots but overall they shouldn't be worse than the average programmer in churning out code. (BTW, I used to learn assembly, and have learnt quite a bit about optimizing assembly code by playing around with compilers.)"

          I already answered this above. We maintain our project which is is 10-11MB of assembler code. It is easy to maintain and add new features. The code is well documented, and we have several levels of quality control that we use. Second, assemblers are now starting to be more C like. Check out the masm32 project or the GoAsm project ( you can do a search on the web for either). It is closer to programming in C. Third, there are a lot of tricks you learn about optimizing in assembler. I used to write slower assembler code than what the C compiler could generate. Now, I have yet to see a compiler generate faster code than I can in assembler. Also you made the comment about large projects being hard to speed up 2-3x. I also disagree with that. Profiling your code is important. I like to download open source projects on the net and speed them up using assembler. The last one I downloaded and sped up, I got a 10x increase in speed over their C implementation. And he was saying that MS Word is just an example of bloatware/poor programming. Writing a super fast MS Word isn't the point he was making. He was saying it should have been done in a more efficient manner.


          • Modern Programmers Should Write Code in Assembly
            2004-05-16 11:15:27  isharkey [View]

            Ok, I have to respond to this.

            "I have no problems updating and maintaining that code."

            Emphasis on the "I". Who is going to maintain that code when you're gone? Documentation and code control is a great start, don't get me wrong, but I would hope you agree that it's easier to hire developers in C/C++/Java than Intel Asm these days.

            "I like to download open source projects on the net and speed them up using assembler. The last one I downloaded and sped up, I got a 10x increase in speed over their C implementation."

            Great, you got a 10x speed increase from the C implementation, with the tradeoff of limiting the application to Intel 686 only. Perhaps I'm making an assumption about your assembly skills, perhaps that should have read Sparc or PowerPC or Z80 assembly. Whatever. Properly written C is probably one of the most portable languages out there, and that is an undeniable advantage in the open source community..

            To cap this argument, here's my thoughts on the subject: There are 2 classes of software, CPU-bound and IO-bound. CPU-bound apps are all processing, and could definitely help from knowledge of low-level techniques, be that assembly or just general optimization strategies. IO-bound apps, however, spend most of their time waiting for input or causing output. These apps could probably make the tradeoff of slightly less efficient code for quicker, better amd safer development. Determine which components of your system are which, and optimize accordingly.
          • Modern Programmers Should Write Code in Assembly
            2004-05-10 09:19:43  nitroburn [View]

            I am just now learning different forms of programming and scripting(web stuff). Some of the previous replies that flamed him for reasons like, takes to long to write assembly, not maintainable, etc.; He is just saying that modern programmers should learn/write assembler so that you can apply better techniques to your own code in you own language. Also, he said that it would help you decide what to use for your projects, I agree. If you know how the underlying system works you will be better informed of what language to use when designing your higher level application.

            He is not saying that higher level languages are bad he is just saying that you should learn it so that you can apply programming techniques better.

            Don't just make your application "work and work now", make it work "better, faster, cheaper". Always find better ways of accomplishing your task. Sometimes you can actually make much more simple code by using different functions, methods ,etc.
            • Modern Programmers Should Write Code in Assembly
              2004-05-11 08:44:23  dscotson [View]

              "Don't just make your application "work and work now", make it work "better, faster, cheaper"."

              I think most programmers have trouble 'just' making their applications work and the conventional wisdom seems to be that "Premature optimization is the root of all evil in programming", as originally stated by C.A.R Hoare long before we had the plentiful supplies of memory, processsor cycles and network bandwidth we enjoy today.

              Where did this movement for assembler fundamentalism spring from?
              • Modern Programmers Should Write Code in Assembly
                2004-05-12 09:24:28  kain [View]

                "Where did this movement for assembler fundamentalism spring from?"

                Are you sure the fundamentalism is from the assembly/HLL crowd who are willing to try new and different approaches or from the HLL-only crowd who are unwilling to consider change?

                • Modern Programmers Should Write Code in Assembly
                  2004-05-12 14:30:49  maiku41 [View]

                  I think it's a matter of perspective, with a perhaps a bit of C-programmer conceit thrown in.

                  C's strong point was primarily that it was a 'high level assembler language'. It let one manipulate the underlying hardware while not having to bother with some of the details of a native assembler and not being tied to a particular instruction set. Understanding the hardware is, indeed, an important part of writing in assember or other languages which map closely to a particular hardware instruction set.

                  One still needs to understand the constraints of the execution environment in higher level languages. These days, however, that is often a virtual machine rather than a physical one.

                  Java programmers, for instance, have little need to understand the hardware they're running on, but can benefit from knowledge of the Java Runtime Environment. The JRE is to Java what the hardware is to C.

                  Programmers using a functional language have almost no need to understand the underlying hardware except in general terms.

                  Most commercial quality compilers are quite good optimizing code for their target, whether virtual or real. As long as the code is reasonable well structured, the compiler will take care of best use of the target resources (e.g. register vs. memory ops on hardware, load/store sequencing, etc). Modern CISC processors will also reorder instructions in the pipeline.

                  So... I guess the point of all this is to say that, yes, it can be helpful to understand your target environment when using certain languages, but it's more important to understand the problem at hand and the tools (languages, algorithms, non-computer solutions) available to solve it.

                  And yes, Premature Optimization is t3h 3vil ;)