LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 03-17-2018, 01:46 PM   #1
dogpatch
Member
 
Registered: Nov 2005
Location: Central America
Distribution: Mepis, Android
Posts: 302
Blog Entries: 1

Rep: Reputation: 79
Assembly code rocks!


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.
 
Old 03-18-2018, 03:47 AM   #2
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 11,141

Rep: Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329Reputation: 3329
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....
 
Old 03-18-2018, 09:53 AM   #3
dogpatch
Member
 
Registered: Nov 2005
Location: Central America
Distribution: Mepis, Android
Posts: 302
Blog Entries: 1

Original Poster
Rep: Reputation: 79
Quote:
Originally Posted by pan64 View Post
for me it looks like it is a special case.
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.

Quote:
Originally Posted by pan64 View Post
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.
I fail to see why a 'regular' programmer cannot do assembly. Perhaps 'will not' would be more accurate?

Quote:
Originally Posted by pan64 View Post
Your skills are now not learned, not taught, almost forgotten....
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.
 
Old 03-18-2018, 03:22 PM   #4
GazL
Senior Member
 
Registered: May 2008
Posts: 4,754
Blog Entries: 14

Rep: Reputation: Disabled
Quote:
Originally Posted by dogpatch View Post
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.
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.
 
Old 04-03-2018, 04:51 PM   #5
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: Slackware
Posts: 8,293

Rep: Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369
when not to use assembler
 
Old 04-03-2018, 05:05 PM   #6
jefro
Moderator
 
Registered: Mar 2008
Posts: 18,380

Rep: Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739
I agree. "Assembly code rocks!"
 
Old 04-03-2018, 05:28 PM   #7
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3169Reputation: 3169Reputation: 3169Reputation: 3169Reputation: 3169Reputation: 3169Reputation: 3169Reputation: 3169Reputation: 3169Reputation: 3169Reputation: 3169
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.

Last edited by sundialsvcs; 04-03-2018 at 05:30 PM.
 
Old 04-12-2018, 06:08 AM   #8
YesItsMe
Member
 
Registered: Oct 2014
Distribution: Gentoo
Posts: 372

Rep: Reputation: 112Reputation: 112
Quote:
Originally Posted by dogpatch View Post
I fail to see why a 'regular' programmer cannot do assembly.
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.
 
Old 04-12-2018, 08:04 AM   #9
Delcaran
LQ Newbie
 
Registered: Dec 2013
Location: ud.fvg.it
Distribution: Slackware64 14.2
Posts: 27

Rep: Reputation: 22
Quote:
Originally Posted by dogpatch View Post
I fail to see why a 'regular' programmer cannot do assembly. Perhaps 'will not' would be more accurate?
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.
 
Old 04-12-2018, 12:16 PM   #10
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: Slackware
Posts: 8,293

Rep: Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369
Quote:
Originally Posted by YesItsMe View Post
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.
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.

Last edited by dugan; 04-12-2018 at 12:18 PM.
 
Old 04-12-2018, 12:20 PM   #11
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: Slackware
Posts: 8,293

Rep: Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369Reputation: 3369
Quote:
Originally Posted by YesItsMe View Post
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.
How insecure are you, exactly?
 
Old 04-12-2018, 12:21 PM   #12
YesItsMe
Member
 
Registered: Oct 2014
Distribution: Gentoo
Posts: 372

Rep: Reputation: 112Reputation: 112
Insecure of what?
 
Old 04-12-2018, 12:42 PM   #13
jlinkels
LQ Guru
 
Registered: Oct 2003
Location: Bonaire, Leeuwarden
Distribution: Debian /Jessie/Stretch/Sid, Linux Mint DE
Posts: 5,161

Rep: Reputation: 992Reputation: 992Reputation: 992Reputation: 992Reputation: 992Reputation: 992Reputation: 992Reputation: 992
Quote:
Originally Posted by dogpatch View Post
I encourage others to continue to develop in assembly - and ask assembly questions here at LQ - when the situation calls for it.
I agree with you. But the truth is:
Quote:
Originally Posted by YesItsMe
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.
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
 
Old 04-12-2018, 07:41 PM   #14
jefro
Moderator
 
Registered: Mar 2008
Posts: 18,380

Rep: Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739Reputation: 2739
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.
 
Old 04-13-2018, 07:41 PM   #15
dogpatch
Member
 
Registered: Nov 2005
Location: Central America
Distribution: Mepis, Android
Posts: 302
Blog Entries: 1

Original Poster
Rep: Reputation: 79
Quote:
Originally Posted by jlinkels View Post
So your C++ code took twice as long to execute?
Well, my C code was slower. Imagine C++ would be even slower.

Quote:
Originally Posted by jlinkels View Post
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.
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.

Quote:
Originally Posted by jlinkels View Post
In 2018 elegance is not appreciated. It is replaced with brute force.
My original point is that elegance still matters, sometimes.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] assembly code ridoy Programming 3 03-29-2011 02:12 PM
LXer: Open Source rocks, learning from code by debugging LXer Syndicated Linux News 0 05-13-2009 01:40 PM
gcc/Assembly code gigantas1985 Programming 0 02-28-2006 05:52 AM
Command for getting assembly code aizkorri Programming 1 06-18-2002 05:04 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 07:06 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration