This thread is in response to several recent posts in the Programming forum opining that, given the (relative) portability of C/C++ and the advanced optimizations of compiled C/C++ code, there no longer exists any practical reason to write in assembly language. So I decided to run a couple tests on some code still written in GCC assembly language.

The assembly code tested is not trivial, consisting of over 3000 lines of code. Field use can sometimes generate tremendous looping, with a potential for millions or even billions of iterations of very simple code in a single ajax call. When i first wrote this code over 10 years ago, it had to run on my 32-bit home desktop as well as on the 32 bit linux server. I have since re-worked it to run both on 32-bit and 64-bit architectures, on both Linux and FreeBSD. I was willing to sweat the portability issue in order to achieve snappy response times. Thus my motive to listen to the aforementioned opinion and create a C version of the static routine, to see if i might be able to enjoy greater portability without sacrificing speed.

The test consists of two simplified mother C programs which call the static routine repeatedly with a mixture of arrays to be processed, mimicking normal field expectations of a mixture of intense and not-so-intense array looping. One program called the assembly routine repeatedly, the other program called the C routine. The C routine employed exactly the same logic as the assembly routine, written without resorting to non-portable machine-dependent code or compiler options.

Here are the test results:

Compiled and linked on my 10-year-old 32 bit system with gcc 3.3 (over 10 years old, i think), the binary executable linked with the C routine takes about 2 times longer to execute than that linked to the assembly routine, and is about 2.7 times larger on the hard disk. Examining the code generated by the C optimizer, it makes very little use of processor registers, perhaps accounting for the major performance penalty.

On the same 32 bit system with gcc 4.3 (4 or 5 years old?), the binary executable linked with the C routine takes about 1.7 times longer to execute than that linked to the assembly routine, and is about 1.7 times larger on the hard disk. This optimized C logic makes pretty good use of processor registers at critical points, but still results in slower execution.

On the up-to-date 64 bit FreeBSD server, the binary executable linked with the C routine consistently takes about 2.5 times longer to execute than that linked to the assembly routine, and is about 2.5 times larger on the hard disk. The optimized C logic seems to make pretty good use of processor registers, but much of the generated assembly (machine) code was incomprehensible to me, so I don't know to what to attribute the performance degradation. Is there a performance penalty in using 64 bit registers? My assembly routine, even on the 64 bit machine, still employs 32 bit processor registers within the intense loop simply because there is no need to use 64 bit registers.

Conclusion: I will NOT be converting this or other critical assembly language routines to C or C++. The fact that I can maintain greater control over the internal logic and flow means that as an assembly programmer I can still produce more efficient code. In those places where there is much looping or iteration, that means a significant performance difference.

I encourage others to continue to develop in assembly - and ask assembly questions here at LQ - when the situation calls for it.

for me it looks like it is a special case. I mean I believe you can write better/faster/smaller assembly code, but what you are doing is simply far from the general/usual programming. A "regular" programmer cannot do that, so a compiler is nowadays much better. Your skills are now not learned, not taught, almost forgotten....

No argument. The code I tested was quite special. The bulk of my programs are written in C, but special cases arise more often than you might think.

I fail to see why a 'regular' programmer cannot do assembly. Perhaps 'will not' would be more accurate?

which i lament. Even more I lament that programmers who post assembly language questions here at LQ are often discouraged by being told that assembly language is obsolete. The point of this thread is to say I believe there is still ample reason to program in assembly - when the situation warrants it.

That's something I'm curious about. Is there any performance differences between using %rax and the *q instructions over %eax and the *l instructions in a 64bit environment.

I agree. "Assembly code rocks!"

Well, it would be interesting to see comparisons if you did use processor-specific optimization settings and maximum optimization: how good can the compiler do?

In a performance-critical routine, "portability" ceases to be an issue. You want to squeeze the optimizer for all it's worth. You might specify a different subroutine-linkage for that module. And, yes, you might use asm{...}. That's why it's there.

Also many years ago, I found a few "hot spots" in a program that's near-and-dear to me, and I re-coded those sections in asm-blocks. I re-measured the program and determined that it did, indeed, make a "human noticeable" difference in execution time.

Remember that we live in a time where you are entitled to call yourself a "regular programmer" when all you do is copy&pasting Bootstrap and/or Python snippets from StackOverflow.

Professional programmer here.

I can't do assembly because most of the time I can't know on which platform my code will run, or it's requested that the code has some degree of portability.

On one particular real-time project I knew the hardware and knew said hardware was never going to change, so I wrote some of the code in assembler. After some time I noticed the code was becoming unmaintainable, so I converted it in C++ without any performance loss (I don't know if this was because my assembly was dreadful or compiler and C++ have done a great job...).

Since time is scarce and is money, I try write the higher level code I'm able write without sacrificing performance, unless there are some specifications to do otherwise.

That's because "regular programmers" are the ones who actually produce stuff and get things done. For some projects, that can mean writing a lot of assembly. For other projects, that does not. It depends on the needs of the project.

Deal with it.

How insecure are you, exactly?

Insecure of what?

I agree with you. But the truth is:
Being the devil's advocate I can add:

So your C++ code took twice as long to execute? In 18 months the hardware is 2 times faster. It might take longer to develop something in Assembler. In other words: the hardware speed develops faster than the software engineer can develop his Assembler program.

Professional cabinet making is done as much as possible by machines, glueing and nailing wood together so the product survives exactly one residence move. Even hobbyists live with machines, jigs and routers. Hand planing a board or hand cutting dovetails is looked strange upon.

And now we are even drifting to a situation were students cannot even do math and have to enter 6 / 3 = on a calculator.

I learned assembly on a PDP-11 and I am still grateful I put the effort in. In 2018 elegance is not appreciated. It is replaced with brute force.

jlinkels

Since I had no working magnetic tape or punch tape copy of the program. I had to program assembly a very very long time ago step by step into a Navy computer. You'd press lights and set address and then set lights and set code. All the documentation was in mov and such so you'd have to look up the bit meaning for most. Took me about 3 days almost non-stop When I got done they finally flew in a copy.

Anyone here ought to peek at the MenuetOS work.

Well, my C code was slower. Imagine C++ would be even slower.

For 10 years i didn't touch the 32-bit GCC assembly code. As noted in my original post, after 5 years, the performance went from 2.7 times difference to 1.7 times. When after 5 more years I re-wrote the assembly as 64-bit running on a new server, it went back to 2.5 times. I'll happily re-write code every 10 years to achieve those performance gains.

My original point is that elegance still matters, sometimes.