Article:
  Why Learning Assembly Language Is Still a Good Idea
Subject:   Modern Programmers Should Write Code in Assembly
Date:   2004-05-08 09:35:57
From:   kain
Response to: Modern Programmers Should Write Code in Assembly


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.

Full Threads Oldest First

Showing messages 1 through 7 of 7.

  • 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 ;)