Assembly language programming vs Other programming languages

[fluidistic]

I was having a morning look into assembly language videos and stuff and I was wondering:
how much faster is assembly compared to some higher-level programming languages (like C or C++ or python)? And also why is it faster than those languages?
I mean a general C++ source code should be translated into machine code by the compiler right? So the actual performance of the C++ code would be the same as that of assembly's, even though assembly's just above the machine language.
PS : One point I found is the way a compiler can add unnecessary (compiler-dependant) stuff in the code, while writing immediately in Assembly you can emit them.
Thanks (specially to @phinds whose insight motivated me to look up for that language )

I'll give you one example because that's the only one I know of. Take Stockfish chess engine, it's the current strongest chess engine and it's open source. Several tens of people (mostly programmers) are contributing to it since a few years, and it's entirely written in C++ and is said to have a high quality standard of code. If you know C++, you can judge the code by yourself : https://github.com/official-stockfish/Stockfish.

Now, a single man from South Korea ported the code to assembly (see https://github.com/tthsqe12/asm). He said he could optimize several parameters that he had to manually pick. So without being close to be fully optimized, the gain in speed was about 25% compared to C++ (using GCC as a compiler).
Another single man ported Stockfish to C (Ronald de Man, who is also the creator of the Syzygy end game table bases) and he gained about 10% speed vs C++. See the code at https://github.com/syzygy1/Cfish.

And if you're interested, here's a hint on the performance of these engines : http://spcc.beepworld.de/.

 

[FactChecker]

Now, a single man from South Korea ported the code to assembly (see https://github.com/tthsqe12/asm). He said he could optimize several parameters that he had to manually pick. So without being close to be fully optimized, the gain in speed was about 25% compared to C++ (using GCC as a compiler).
Another single man ported Stockfish to C (Ronald de Man, who is also the creator of the Syzygy end game table bases) and he gained about 10% speed vs C++. See the code at https://github.com/syzygy1/Cfish.

That may be deceptive. A person who rewrites a large program in assembly language is really determined to optimize speed. I'm sure that the C++ programmers were also concerned in keeping the code understandable and maintainable. If they put the same effort into optimizing for speed as the assembler coders, they may have written faster code than they did. I also have seen benchmarks where C++ was slower than C.

 

[phinds]

I also have seen benchmarks where C++ was slower than C.

C++, when used to its full capacity with OOP techniques, is a whole different beast from C even thought the basic syntax is identical and it's not at all surprising that it would be slower. You can write programs in C++ with OOP that COULD be written in C with a bit more work and the overhead of the OOP constructs would make the C++ slower.

 

[FactChecker]

C++, when used to its full capacity with OOP techniques, is a whole different beast from C even thought the basic syntax is identical and it's not at all surprising that it would be slower. You can write programs in C++ with OOP that COULD be written in C with a bit more work and the overhead of the OOP constructs would make the C++ slower.

Yes, I agree. I have always assumed that you can do things in C++ as you would do them in C and get the same speed. But in the benchmarks that I have seen, I don't know if that is how the C++ was done, so my assumption might be wrong.

 

[hilbert2]

It isn't taught very much, as far as I know, but some universities teach it in their computer science/computer engineering or electrical engineering departments. If it is taught, it's usually in the context of computer architecture and system design.

One variant of assembly that appears fairly often is MIPS (https://en.wikipedia.org/wiki/MIPS_architecture), the assembly language used on MIPS processors.

If someone's trying to learn digital electronics and needs to understand grass root level things like how logic circuits are simplified with Karnaugh maps, it certainly doesn't hurt to learn Assembly language as well, even though it's not usually needed when writing actual programs.

 

[CMalcheski]

I write entire apps and drivers in all assembly (currently under Windows), and have done so for more than three decades. It continues today. Unless somebody else replying to this thread has done the same in the past, say, year, they are reciting their conditioning and they are not speaking from experience.

https://www.codeproject.com/Articles/1182724/Blowing-the-Doors-Off-D-Math-Part-I-Matrix-Multipl

The above link (yes it's the complete link) is an article I posted on April 17, 2017 (last updated April 19).

If the time frame involved in writing an all-assembly app were truly in the trillions of millennia, as represented, I could not not do what I do. However I do what I do, therefore it stands to reason that the time frame involved is just not that long.

I could write a novel on the benefits of using all-assembly. Things do what you tell them to do, when you tell them to do it. Just about everything is within reach. Nothing moves unless it's told to move. When one forgets that conditioning is just the emotional opinions of others, ASM becomes impossible. When one let's the task stand or fall on its own merit, the task becomes quite doable.

 

[Buffu]

I write entire apps and drivers in all assembly (currently under Windows), and have done so for more than three decades. It continues today. Unless somebody else replying to this thread has done the same in the past, say, year, they are reciting their conditioning and they are not speaking from experience.

https://www.codeproject.com/Articles/1182724/Blowing-the-Doors-Off-D-Math-Part-I-Matrix-Multipl

The above link (yes it's the complete link) is an article I posted on April 17, 2017 (last updated April 19).

If the time frame involved in writing an all-assembly app were truly in the trillions of millennia, as represented, I could not not do what I do. However I do what I do, therefore it stands to reason that the time frame involved is just not that long.

I could write a novel on the benefits of using all-assembly. Things do what you tell them to do, when you tell them to do it. Just about everything is within reach. Nothing moves unless it's told to move. When one forgets that conditioning is just the emotional opinions of others, ASM becomes impossible. When one let's the task stand or fall on its own merit, the task becomes quite doable.

If I tell you to program a software in ,say, Java and Assembly, how much more time will it take than Java ?

 

[CMalcheski]

It's really not feasible to give a comprehensive answer to such a question. First, how large is the app? Second, what is it doing? Third, who is doing the coding?

Having used ASM exclusively for decades, I have a very comprehensive personal library of common functions that I use - something a person writing their first app would not have access to. I've accumulated a lot of knowledge of Windows peculiarities that would take years and years to accumulate.

Every job listing online pushes experience and education - which, curiously, ranked 9th and dead last, respectively, in a list of factors that predict employee performance. The point is, the more you repeat something, the faster you're likely to get at it.

In writing the article I referenced, I tried running a timing test in VS2017. The most basic function, RDTSC(), crapped out (bugs) on the second call. It returned all 0's. The first time it was called, it worked fine. I could have sat there for half an hour fighting it, which only would have led me to tracing through it at the disassembly level anyway. But it failed to operate the way it should operate. There is no excuse for it. None. And it would have been a major ordeal to figure out why it wasn't behaving.
It was hardly unique. It was the norm among high level languages: didn't work as advertised, and the developer has to find a workaround. In ASM, I don't have such problems. I say RDTSC as an ASM instruction and it gives me the data I requested.

I calculated long ago that 95% of my time developing went to handling Windows bugs and missing or incorrect documentation. That number would only have gone higher if I had used anything but ASM.

You probably wouldn't compare the performance of two NASCAR cars by putting a newbie driver in one and an old pro in another. So there are many caveats and variables in answering the question directly.

 

[ChrisVer]

You probably wouldn't compare the performance of two NASCAR cars by putting a newbie driver in one and an old pro in another. So there are many caveats and variables in answering the question directly.

hm as far as I understood, you are put both in Assembly and Java... not like a Java-expert vs an assembly-newbie (or the other way around)...

Looking at your code for the matrix multiplication, I think the main problem would come by giving that code to someone else to inspect... of course I think everyone has admitted that assembly can outmatch the higher-level stuff in time performance, but I think it can become quiet terrible if for example you want to write a very complicated software - if you needed ~5 pages of code (repeatitive in most of its part) for a matrix multiplication... I think for a bigger project someone would need a book, which would make handling problems impossible? (just making thoughts here, I was fascinated by the anti-laziness, but maybe we shouldn't go to the other side and be impractical)

 

[SlowThinker]

Let me chime in
1. The PC is not all the programming that exists. I work in a company where programming is 90% for embedded systems. A colleague of mine wrote a multitasking OS for ARM, mostly for fun. Most of it is C++ but it would be impossible without some knowledge of ARM's assembly.
Also there are processors in sensors etc. that need to save power, or perform as many measurements as possible on a processor as cheap as possible. We use a lot of C but there are always a few assembly routines, mostly to control the processor's input, outputs and sleep modes, or add/multiply long numbers.

2. If you use C++ or C, you'll eventually end up in debugger's disassembly view. That is the most common place where a typical programmer will meet assembly. Obviously it can't happen if you work in Java or ActionScript or whatever.

3. Assembly is perfectly fine for small and time-critical tasks, but I wouldn't want to write a text editor or a spreadsheet in it. Render a letter on the screen? No problem.
This opinion may be a result of mental conditioning, but it's planted pretty firmly in me.

 

[FactChecker]

I write entire apps and drivers in all assembly (currently under Windows), and have done so for more than three decades. It continues today. Unless somebody else replying to this thread has done the same in the past, say, year, they are reciting their conditioning and they are not speaking from experience.

Most people here are speaking from experience. It's just a different kind of experience. You have over 3 decades of experience? Fine. I have over 4. Many people here have a lot more than me.

Many programs would be inconceivable to do in assembly code. They are not just hundreds of thousands of lines of high-level code -- they are hundreds of thousands of FILES of high level source code.

 

[FactChecker]

hm as far as I understood, you are put both in Assembly and Java... not like a Java-expert vs an assembly-newbie (or the other way around)...

Looking at your code for the matrix multiplication, I think the main problem would come by giving that code to someone else to inspect... of course I think everyone has admitted that assembly can outmatch the higher-level stuff in time performance, but I think it can become quiet terrible if for example you want to write a very complicated software - if you needed ~5 pages of code (repeatitive in most of its part) for a matrix multiplication... I think for a bigger project someone would need a book, which would make handling problems impossible? (just making thoughts here, I was fascinated by the anti-laziness, but maybe we shouldn't go to the other side and be impractical)

I agree, with one caveat. If speed is desired, any code would be significantly scrambled by a high level, global optimizing compiler. IMO, an assembly language programmer would find it practically impossible to compete on a large program.

 

[ProfChuck]

I used to write code for a radio telescope control system in machine language. The problem was that the program had to run synchronously with both the antenna pointing system and incoming data. And I mean synchronously not interrupt driven. That's hard to do with a compiled language. Compilers just don't give you that level of control over the process. However, modern compiler languages and high speed computers make this unnecessary except for the most basic of applications. Drivers and embedded systems are probably exceptions.

 

[CMalcheski]

Most people here are speaking from experience. It's just a different kind of experience. You have over 3 decades of experience? Fine. I have over 4. Many people here have a lot more than me.

Many programs would be inconceivable to do in assembly code. They are not just hundreds of thousands of lines of high-level code -- they are hundreds of thousands of FILES of high level source code.

Hundreds of thousands of files? I'd say there's some room serious for improvement there. I've noticed that hours to compile one app is not uncommon in high level languages. For anything I create to require more than ten seconds to compile is exceedingly rare.

As for experience ... writing all-assembly apps and nothing else? Who employs such people?

 

[CMalcheski]

I don't do Java. Never have, never will.

 

[CMalcheski]

Let me chime in
1. The PC is not all the programming that exists. I work in a company where programming is 90% for embedded systems. A colleague of mine wrote a multitasking OS for ARM, mostly for fun. Most of it is C++ but it would be impossible without some knowledge of ARM's assembly.
Also there are processors in sensors etc. that need to save power, or perform as many measurements as possible on a processor as cheap as possible. We use a lot of C but there are always a few assembly routines, mostly to control the processor's input, outputs and sleep modes, or add/multiply long numbers.

2. If you use C++ or C, you'll eventually end up in debugger's disassembly view. That is the most common place where a typical programmer will meet assembly. Obviously it can't happen if you work in Java or ActionScript or whatever.

3. Assembly is perfectly fine for small and time-critical tasks, but I wouldn't want to write a text editor or a spreadsheet in it. Render a letter on the screen? No problem.
This opinion may be a result of mental conditioning, but it's planted pretty firmly in me.

The impression I get (which may or may not be anywhere near correct) is that ARM processors have taken over the universe except for the PC and nothing else is used in any device except desktops and servers.

 

[lesaid]

I was at an interesting lecture quite a few years ago, where a very convincing case was made to say that on modern hardware, a well written optimising compiler designed to support that specific hardware, will generally produce faster code than all but the most skilled assembler programmers because of the knowledge built into to the compiler to take maximum advantage of specialist and proprietary hardware features - examples were given around caching and pipelining. Assuming of course that the high-level program is itself written in an efficient way!

Few assembler programmers would be likely to have that level of intimate awareness of their specific hardware - and of course, if they then ported their software onto different hardware, it may no longer run so efficiently - whereas being recompiled with a compiler appropriate to the new hardware would retain the performance.

I've never tested it - but seems plausible to me.

 

[CMalcheski]

I have never seen nor heard of an actual app ever being ported. I'm sure it happens; I just don't see where. And I view the entire process as the ultimate in shoddy shortcuts and laziness. Just my personal opinion; we all have one.

By the logic of "portability first, quality second," automobile engines should be made universal (be all things to all vehicles) because one might one day need to be ported over to the Space Shuttle and God forbid they should have to actually do some work and build a new engine suitable to the Shuttle. Oh wait, they use custom engines for the Shuttle too. Who'da thunk, the world keeps turning!

 

[FactChecker]

Hundreds of thousands of files? I'd say there's some room serious for improvement there. I've noticed that hours to compile one app is not uncommon in high level languages. For anything I create to require more than ten seconds to compile is exceedingly rare.

Ha! I admit that is not typical of programming. These were projects with hundreds of programmers, running on networks of computers. Even if they knew how to improve it, the refactoring and rewrite could never be funded. Although projects of that size are not frequent, I think they have a great influence on programming practices and state of the art.

As for experience ... writing all-assembly apps and nothing else? Who employs such people?

I have the same question.

 

[CMalcheski]

Actually the demand for such people is considerable, although still niche - as long as you have an active $20k security clearance, which no company will pay for because without fluffy credentials (5+ years of "experience" in each of 916 languages and a b.s. [we all know what b.s. stands for] degree), then a candidate obviously cannot program. Ability is irrelevant. How much education do you have? How much experience? To find a company that hasn't been seduced by this blind dogmatic addiction is to find pure gold.

One relatively recent study ranked experience and education ninth and dead last in a list of twelve factors that predict employee performance. And so the demand for experience and "education" becomes more and more deeply embedded each day. It's very similar to realtors receiving 90% of their business from referrals, and in response putting 90% of their ad budget into print advertising. Or very close to every major invention in history being attributable to a single individual, and so 100% of all charity, research, grant, etc. dollars go to large groups.

Looking for sanity in the human race might well be an exercise in futility. Isn't there an app for that?

 

[lesaid]

I have never seen nor heard of an actual app ever being ported

I have been out of the industry for a while, but early in my career I was coding commercial data processing applications in 100% IBM assembler! Seems surreal to think of it these days. This software was 'ported' every time there was an upgrade to a new processor version even if nominally the same kind of machine.

I imagine the same would be true of assembler components in more recent systems, unless all such are hardware-specific drivers and such. So not 'porting' as in moving from one manufacturer to another maybe - but porting from one hardware version to another more recent one with different behaviour? Seems likely?

 

[CMalcheski]

"Porting" to upgraded hardware ... absolutely. I just never thought of it as "porting," in the commonly-accepted sense of the word, but really that's exactly what it is.

Ultimately everybody finds their niche and does the work they are most drawn to doing. Some like me are wretched outcasts, condescendingly viewed as idiots who just don't get it, but I'm happy with what I write and that's what matters most to me.

 

[Khashishi]

Assembly language was useful in the past to squeeze every last bit of performance out of a single processor, strictly sequential system. Nowadays, it isn't as relevant since performance programming has moved on to multicore systems with parallel computing and perhaps GPU computing. Assembly language is basically a list of sequential instructions for a CPU, but in modern systems, instruction handling isn't sequential or necessarily synchronous.

 

[swordsman]

Assemble language could have been by far the best, but then C-code came along, which is a higher level language that was soon adopted. Unfortunately, it is (in my opinion) not the best since it is not as efficient as it should be due to the way it is designed. Assembly code directly addresses all computer machine processes, of which there are many combinations. Many years ago, I designed an assembly code "typewriter" for a newly introduced microcomputer that had keys labeled with the all of the assemble code values. The intent was to make coding highly efficient. This would probably not be feasible for C-code. Unfortunately, the microcomputer company discontinued their microcomputer production line.

 

[FactChecker]

I have never seen nor heard of an actual app ever being ported. I'm sure it happens; I just don't see where. And I view the entire process as the ultimate in shoddy shortcuts and laziness. Just my personal opinion; we all have one.

Code reuse is desirable. I wouldn't consider it shoddy or lazy.

 

[TheOldFart]

I would argue that assembly language is *not* faster in anything other than perhaps the smallest microcontrollers.

I've got 30+ years behind the keyboard, man and boy. I've written large to very large chunks of software in assembly a dozen different CPUs 68xx, 68000, 68020, 68360, 68HC11, tms34020, 8086, 286, 386, 486,, 8052 etc.

I spent a decade programming from schematics, today I work on highly scalable and fault tolerant Java server side stuff.

The first fact of modern life is that counting cycles doesn't work with modern processors since they have pipelines. The compiler has a better view of instruction scheduling than you do, and no one can pretend that they can juggle that viewpoint on any non-trivial assembly language app. So unless you're writing for some simple-minded microcontroller, you can't claim it's faster until you run them side by side - in which case why write the assembler version in the first place? Profilers will tell you if it's needed.

The second fact of modern life is that scalability matters more than throwing raw CPU at it. So what if your Java code runs 1/4 as fast as assembly code? You write some readable code using an understandable pattern, throw some more cores at it and then you go make progress on the *purpose* you wrote the code for. Sitting around admiring all the shiny bits is not solving problems, it's a sort of engineering masturbation practiced by engineers who haven't grown up. (and I say that as a software engineer who can gold plate requirements and be more anal about code than most so I'm definitely including myself in that group)

The code is not the goal. Solving problems is the goal. The readability, scalability, maintainability of the code all matter far more than the performance, for a lot of reasons.

Biggest reason is this: You know where your code spends most of its time? No you don't. If you don't have profiler output from your application running in a production environment then all you're doing is guessing and I'd guesstimate a 95% chance that you're wrong. I've done it on many projects, even when were absolutely confident where the problem would be, we were wrong until at least the third pass through the profiling process.

Second biggest reason is that if your code is modular, based on standard patterns, and readable then you can identify the tiny percentage of your code that actually *might* be a performance bottleneck using readily available high level tools. You can't go the other direction, there aren't any tools to reverse engineer a buttload of spaghetti code hacked out in the name of "efficiency" and turn it into something readable/valuable. Also if the code is readable and based on standard patterns then you can at least understand it and consider whether you can solve the problem simply using scalability rather than resorting to the brute force/blunt axe of assembly language to cover up your design mistake or incorrect choice of algorithms.

In Agile you have the concept of "last responsible moment" You put off defining or doing work until as late as you can because the later in the process you are, the less likely you are to be affected by changes. To start out a project writing assembly code is the ultimate in "first irresponsible moment" because you've made the decision to invest maximum effort at a time when you've also got maximum uncertainty. If you get down to the last possible straw and assembly language is the only way to solve the problem then you've done your due diligence and it really has to be that way. Otherwise you're just fondling your pocket protector.

The only valid reason I know of for writing assembly code from the start is a manufacturing cost one. If you're going to make a million devices and you can save $1 on each one if you can use a cheaper microcontroller or CPU, you _might_ have an argument...though I'd still argue that the company's reputation for producing reliable products is a big implicit cost that often gets left out of that discussion.

 

[Hellmut1956]

What was written in this thread about assembler code versus compiled code to my believe does not touch an equally critical argument for compiled programming. Modern processor architectures have multiple caches, do preprocess instructions, does pre-execute code based on assumption of the most probable branching of the code etcetera. To write assembler code that takes those issues into consideration is realistically seen very close to impossible for someone writing code in assembler. Compilers have so called "switches" that tell the compiler if the code it is going to generate is optimized for speed, for code density or a balance between those priorities. It then generates code that looks very different depending on the setting of such switches.

I did write the whole firmware for an NEC 7220 graphic controller to be used in a terminal and did write the assembler code for the MC6809. I guess none of you readers have ever heard about the NEC 7220 graphic controller that was very popular in the early 80's! Today, as it has been correctly stated in this thread neither memory nor CPU performance are really limiting factors and so today I use the language Python very much. This is an interpreted language which tends to be much slower than compiled code. tends to be is the term is used to express that languages are made of instructions and those are provided to a high extend as elements in libraries. The Python language, a scripting language can still be very efficient as the library elements can have been coded using C or C++, so that they are already present in machine language that can be executed directly from the processor or compiler. So a scripting language like Python can be just the tool to concatenate precompiled code of its library elements!

 

[phinds]

There's faster compiling languages than "C", we're talking about large factors faster.

https://brenocon.com/blog/2009/09/d...t-and-most-elegant-big-data-munging-language/

MAWK is one of the fastest languages out there and that makes a HUGE difference in transforming massive amounts of data where parallel computing becomes important.

As I understand it, that is NOT a general purpose language. It is "extremely specialized for processing delimited text files in a single pass"

 

[FactChecker]

I assume that modern assemblers have the same optimization options that higher level language compilers have.

 

[IDNeon]

As I understand it, that is NOT a general purpose language. It is "extremely specialized for processing delimited text files in a single pass"

Well it does quite a bit more though, and is good for number crunching. Which is why I thought it interesting to mention here.