Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Jerry Pisk — Tue, 06 Apr 2004 23:56:00 GMT

That's all nice and good if you work as contractor - you get paid by the hour. I personally think that simple, readable (and therefore managable and less prone to bugs) code is more important than code that saves 20 bytes of memory and runs two milliseconds faster. Hardware is cheap compared to programmers, even those in India. But if your team writes code that's full of bugs because they're trying to play tricks with the compiler to make the code run a little bit faster and use a little less memory and then spends weeks trying to find those buggers you're just wasting money and time.

Remember people who were smart and used the top bit in memory pointers to hold their flags? That saved some memory but created code that needs to be completely re-written (to run in an environment that ca address more than 2GB of RAM). And there's tons of other examples...

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Mike Kozlowski — Wed, 07 Apr 2004 02:31:00 GMT

The problem with "knowing" what the assembly looks like is that your knowledge can get out of date.

Lots of Java programmers "know" that they shouldn't do String concatenation by writing x = a + b + c + d + e;, for instance -- that allocates all sorts of extra strings (as in your example above) and is just terribly inefficient.

Only, it doesn't: The compiler actually translates those concatenation into StringBuffer calls invisibly, and it all works just performantly delicious.

So for the past umpty-ump years, I've been dealing with code that's needlessly full of StringBuffer.append() operations, when the programmers could have used simple straightforward concatenation, because they "knew" the assembly that was generated, based on their experience with, I dunno, Java 1.1 or something.

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Larry Osterman — Wed, 07 Apr 2004 03:38:00 GMT

Jerry,
I'd almost want to agree with you. But I can't think of the number of times that I've been called in to debug someone elses performance problem because they didn't understand why their programming practices generated bad code. STL generates pretty good code (especially in VC.Net) but you still need to know what's going on under the covers.

It's only tricks with the compiler if you're being tricky using the compiler - and I include using templates or operator overloads as being tricky (more on that at a later date) :)

Mike, your point is valid, and it works IFF you have runtime support underneath. You will note that I didn't comment on the behavior of either managed code or Java, because there are other tricks that happen with those. The examples I used were all built with VC.NET 2K3, using the STL libraries that come with the compiler (I built a bunch of toy apps to verify the stuff I wrote above, just to make sure it still happened with the current compiler).

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Pontus — Wed, 07 Apr 2004 07:29:00 GMT

I kind of agree with Mike, except I think people should avoid C and C++ as much as possible. A very high percentage of those who write code are frankly bunglers (at least when it comes to handling pointers and memory), and _everybody_ makes mistakes.

Languages like C#, Java and Python allows us to write code with less faults (and as "someone else" deals with most of the hard and boring stuff, the programs are often faster than they would've been had we coded them ourselves).

Those languages, I could probably follow, but my fiancé could not, and she's still a competent coder in those languages, but then, we regulary use languages like Scheme, SML and Prolog, and those would probably be a hard to follow for me.

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Jerry Pisk — Wed, 07 Apr 2004 15:06:00 GMT

Larry, if somebody doesn't understand that their innocent line of code is going to create three unnecessary objects then the problem isn't knowing what assembly code gets generated. It's not know how the language you use works. If you knew C++ and how it works with objects you'd know when extra objects are created, without knowing what the actual assembly code is. I think you wanted to say - do not write code unless you know what you're doing. Unfortunatelly not many people do...

And I agree that operator overloads are playing tricks, most of the time they make the code very difficult to understand (and therefore maintain).

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

bg — Wed, 07 Apr 2004 19:31:00 GMT

whats the best way to start learning assembly language - books? can you recommend any.

ta

bg

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Larry Osterman — Wed, 07 Apr 2004 21:27:00 GMT

An interesting question bg. I'm actually not sure I know of any that are still in print, but the good news is that I don't think it really matters that much.

Jerry's comment above is actually spot-on. It's not so much the actual instructions (although they DO matter at some point), it's what code is being generated.

One thing that I might suggest doing is to use the compiler to generate a .COD file of your source code, then look up the instructions in the Intel processor reference (http://www.intel.com/design/pentium4/manuals/253665.htm).

The bottom line is that I'm not sure that it's necessary to know how to PROGRAM in assembly language any more (and I could put forward a very strong argument that it's a bad idea to program in assembly language at this point), but it IS important that you know how to READ assembly language.

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

josh — Thu, 08 Apr 2004 01:28:00 GMT

The problem with saying that hardware is cheap compared to programmers is that hardware costs scale linearly with your user base, while programmer costs don't. If you've got a sufficiently large user base then you'd have to have some pretty expensive programmers for this to be true.

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Michael Grier — Thu, 15 Apr 2004 04:58:00 GMT

I still claim that this comes down to two kinds of programmers. "Systems programmers" who have to know what the heck they're doing and "applications programmers".

"Applications programmers" are the ones with the massive application backlog and need to work through it. Frankly they don't have a real quality or performance problem for the most part because the ones who have a clue leave the heavy lifting to the "systems programmers" who are writing things like Exchange and SQL Server.

"Systems programmers" are building the components that everyone else leverages and they can't afford to play fast and loose.

If the top-level application chooses to write their code more quickly and sloppily and generates 20,000 extra copies of strings but the job still gets done in time, that's great.

If the component provider writes their code quickly and sloppily and generates 20,000 extra copies of strings, this is irresponsible and hopefully they will not remain being a shared component provider for long.

Shared component providers also have a massive backlog, but the absolute last thing in the world that we need for shared component providers is the ability for them to turn out more shared components more quickly. Quality stinks and it's not about buffer overruns and leak management - anyone who has problems designing for and addressing these issues isn't qualified to write a shared component in the first place.

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Hrvoje Zlatar — Fri, 23 Apr 2004 08:54:00 GMT

Why did you make the rule exclusive for assembly language? I would extend it to: Every engineer should understand at least the first layer below the one he's using. For example .NET programmers should understand the internals of CLR.
I dare to say that the quality of an engineer may be measured by the number of layers below the one he's working in, he trully understands.

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Alex Blewitt — Sun, 25 Apr 2004 11:11:00 GMT

The point re replacing a+b+c with stringbuffer is only valid in a single expression. If you are using (for example) a loop, then the compiler will *not* generate a stringbuffer for concatenation. Even different expressions using the same string aren't guaranteed to use an SB.

What really gets on my tits is people who are using some kind of output stream (e.g. to an ServletResponse's writer) and do:

write(a+b+c); // or println(a+b+c)

when you can get concatenation for free using

write(a);
write(b);
write(c);

You've got the rule backwards - as per your example...

Pat Niemeyer — Sun, 25 Apr 2004 18:37:00 GMT

Your example serves to demonstrate that developers should, under normal circumstances, *not* care about low level code or performance issues... They should just do the "right thing" where that is usually the simplest and most staightforward thing. If developers had followed this rule in Java all along then they woudln't have been bitten by all these stupid optimization rules that ended up being anti-optimizations when the VMs got smarter.

Trust the compiler people... trust the VM people and then when your code is working trust the profilers to tell you what is actually going on. People's intuition about performance issues is wrong more often thant it's right. You don't know anything unless you profile it - zip, nada, nothing. You may think you're a hotshot Java programmer (we all do) but you're wrong most of what you think about optimization. That's the real rule.

Pat Niemeyer
Author of Learning Java, O'Reilly & Associates

re: What's wrong with this code?

Larry Osterman's WebLog — Wed, 28 Apr 2004 17:02:00 GMT

Beating the

From Over the Long Hill — Thu, 20 May 2004 16:12:00 GMT

Beating the

Larry's rules of software engineering part 1, redux

Larry Osterman's WebLog — Sat, 12 Jun 2004 08:08:00 GMT

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Eric Newton — Mon, 02 Aug 2004 21:36:00 GMT

Pat Neimeyer: perhaps you've just proven Larrys point even better than he thought. You're stressing the importance of understanding optimizations, which is conceptually similar to understanding the assembly language (which itself is conceptually saying "Understand how your code works")

So many times I see code written without regard to "how it works" or even "how does this get optimized." To be honest, I see a lot of cut and paste, which is a prime reason why samples should illustrate good practices.

re: Larry's rules of software engineering, part 1: Every software engineer should know roughly what assembly language their code generates.

Norman Diamond — Wed, 04 Aug 2004 03:52:00 GMT

In the base note:

> foo = bar + baz + “abc”;
[...]
> The second is one that’s used to hold the
> intermediate result of baz + “abc” which
> is then added to bar to get the resulting
> foo.

OK, string concatenation is transitive, and a compiler might make use of this knowledge in performing some optimization. But I don't think a programmer should depend on observing that one version of some optimizing compiler used some trick once on one version of the programmer's work. One maintenance programmer later, the results might be different.

In this example, the programmer should start by assuming that bar + baz will generate a temporary, and the temporary "should" reuse itself in adding "abc" to the result. If the generated code is worse than this, complain to the makers of the compiler or the component, AND if performance is bad then temporarily find a workaround. If the generated code is better than this, be happy but do not depend on it.

(By the way, if these were numbers instead of strings, and subtraction operators instead of addition, I hope your compiler gets the sequence of operations correct.)

Hiding Complexity

Larry Osterman's WebLog — Wed, 01 Dec 2004 21:37:00 GMT

Another year, another post

Larry Osterman's WebLog — Wed, 15 Mar 2006 20:21:09 GMT

Well, this year I didn't miss the anniversary of my first blog post.
I still can't quite believe it's...

Software Information » Larry Osterman’s WebLog : Larry’s rules of software engineering part 1 …

Tue, 22 Jan 2008 15:32:23 GMT

PingBack from http://softwareinformation.247blogging.info/larry-ostermans-weblog-larrys-rules-of-software-engineering-part-1/

Generate Assembly From C++ Code in Visual Studio | Code Gem

Generate Assembly From C++ Code in Visual Studio | Code Gem — Fri, 03 Oct 2008 15:12:44 GMT

PingBack from http://codegem.org/2008/10/generate-assembly-from-c-code-in-visual-studio

Larry Osterman s WebLog Larry s rules of software engineering part 1 | debt consolidator

Fri, 19 Jun 2009 17:16:42 GMT

PingBack from http://mydebtconsolidator.info/story.php?id=15140

Larry Osterman s WebLog Larry s rules of software engineering part 1 | debt solutions

Fri, 19 Jun 2009 21:03:48 GMT

PingBack from http://debtsolutionsnow.info/story.php?id=11389