The paradox.
The hand written assembly language programs are faster and use less memory than the programs with the same features, but written in high level languages (HLL).
I will give below some examples from the real life. In addition I have made several artificial experiments that show the same.
This looks like a paradox, because the HLL compilers are very effective these days and for big programs generate more optimal code, than the hand written assembly language.
Yes, it can be formally proven the following theorem:
The hand written assembly language code, is always more optimal or equal to the compiler generated code.
This statement is easily proved by the fact, that the programmer can always read the compiler output and optimize it further, while the compiler can't do the same with the programmers code.
But this theorem is not very helpful in the real life. Simply because the compilers generate huge amount of code, that can not be manually read, analyzed and optimized by a human.
Fortunately, the assembly language programmer, does not need to compete with the compiler in the platform specific optimizations, in order to beat it.
The fastest assembler today is FlatAssembler. It is written in assembly language and is "optimized" for 80386 CPU, if this can be qualified as optimization at all. The competitors are written in C/C++ and are slower, despite of the more optimal code generated by the C/C++ compiler.
The fastest OS I know is KolibriOS written in assembly language. It boots for less than 2 seconds to the GUI desktop. Even the BIOS startup is slower. And the GUI is instantly responsive even on very slow and old machines.
The fastest web server is RWASA and it is the only of the above examples that is really optimized for speed. But it still uses less memory than its competitors. (I mean, the speed optimizations in HLL, often leads to increased memory use)
Actually, in most cases, writing programs in assembly language, the programmers put more effort in writing smaller and readable code, than in writing faster code. But as a result, these programs always perform faster than their HLL counterparts.
Why?
Let see the so called "Jevons paradox". This is an economics paradox, but actually it can be applied to the programming as well.
In economics, the Jevons paradox occurs when technological progress increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand.
If we apply this definition to the programming, we can see, the direct analogy. The compilers actually increases the efficiency with which the computer resources are used by the programmers. With one line of code in HLL the programmer can use more resources than with one line of code in assembly language.
The same way more efficient car have greater mileage with a liter of fuel.
As a result, the use of the computer resources CPU and RAM increases. Because of increased demand.
The same way the traveled kilometers and the total fuel consumption increases with more efficient cars.
Notice, that the increased efficiency of the compilers is not the only increased efficiency in the IT. The efficiency of the hardware also increases with the time. Now the RAM is faster and bigger than ever, the CPUs are also pretty efficient.
But all these improvements, lead only to increased consumption of the resources. In full accordance with Jevons paradox.
As simple as that.
How to counteract?
In economics, there are tools to counteract the Jevons paradox. For example, the increased taxes can stop the demand raise and neutralize the effect if the goal is to reduce the resource consumption.
All other possible countermeasures are always related to some forced restrictions.
But there is no taxes or other regulations for "CPU cycles" or "RAM usage".
The only way for the programmers is to consciously limit themselves from using this increased effectiveness of the HLL compilers and hardware improvements.
Someone will probably ask here "Why we should limit the resource use? The RAM is cheap and the CPU is fast."
The answer is simple and straightforward: Because we will need these resources in order to develop our programs further.
In addition, the programmers time is of course important, but the programmers often forget that the program is written once, but executed sometimes millions of times. One saved second by writing faster program, can result in millions of saved seconds for the users of the program.
Yes, the program needs maintenance and further development, but who said, more optimal program needs more effort for the maintenance?
Мy experience with the development of assembly language projects clearly shows that maintenance efforts practically do not depend on the programming language.
For example, the mentioned above FlatAssembler is developed and maintained for almost 20 years by a single person. I didn't noticed some enormously great effort for this program to be maintained, regardless of the fact it is written entirely in assembly language. Sometimes the reported bugs are fixed for hours or even minutes.
Of course, the programs in HLL also can be written in efficient manner. There are many examples of C/C++ projects written this way and really performing excellent.
But the higher is the level of the language, it is harder to write efficient code. For me, languages like C++, Pascal or Fortran are the higher level language that allows somehow to counteract the Jevons paradox.
Languages like Java, C# or Python are totally affected by the paradox and it seems that any counteract is impossible by design.
The future
Fortunately or not, but the overgrowth of the computer performance, actually ended. There will be no exponential growth anymore. Nor even close. We can expect some slow linear growth, or even some decline (the mobile devices, lower energy consumption, recently revealed CPU and DRAM bugs) of the computers performance and resources.
So, now the programmers have the time to put their code in order and to start to pay this giant technological debt they accumulated during the big bang of the hardware.
If during the exponential growth the technical progress provided the RAM and CPU for the next program version, now this time ended.
If someone have a program that uses all resources of the computer and want to implement new features, he will be forced first to optimize the existing features to use less memory and CPU and to use the released resources for the new features of the program.
And I have some strong suspicions that this process is already silently (and probably unconsciously) running in most of the software companies and big open source projects.
But for the new projects, the economical use of the resources from the day one, seems to be better strategy, simply because it is easier to write resource friendly code from the beginning, than to rewrite it later.
BTW, more and more people start to call for more resource friendly code. I am reading such articles every day on different blogs and social networks.
So, interesting times are coming. The era of deep software optimization.
Top comments (4)
My first interaction with assembly language was when I was doing a hobby project with microcontrollers. It was a RICS processor, and I really fell in love. These days I am trying to write an Operation System for x86 processor. It is much joy to write assembly language. But I do think, that it is the job of the developer to not write cryptic codes.
Can the operation system you wrote for x86 processor run in Intel Core i5?
@mozart91784563 If the computer supports legacy BIOS (not just purely UEFI), then yes it will run on i5 processors.
When you use assembly languages to write a program, does it need to be CPU type specific which means a program written for Intel Core i9 can not run on Intel Core i5?