August 17, 2021

Is Assembly language more efficient over C?

 

Some Linux newbies are often surprise why after an installation the system will need so much discpace on the hard drive and will occupy 2 GB of RAM. Even minimalist Window manager like LXDE will need 700 MB of RAM without starting a single application. The answer to this problem is not located in Linux itself but is has to with the C programming language.
In contrast to a common myth, the c language is not the fastest and most efficient programming language in the world but it is only a language used everywhere. C compilers are optimized for compatibility reasons and will in a direct comparison with handcrafted assembly language. To understand how big the gap is we have to focus on some operating systems which were written entirely in Assembly. These systems for example MenuetOS will need only 70 MB of RAM and are providing network functionality and a GUI. In contrast, the Debian system will need 10x more RAM.
With improved programming techniques for example storing Assembly instructions as bytecode it is possible to reduce the RAM consumption further. So it is possible to compress an entire operating system into 20 MB of RAM. It will use the latest graphics modes and is ultrafast.
The only problem is, that the sourcecode is difficult to maintain. At least for c programmers. Only Forth programmers and assembly specialist find it easy to maintain such a minimalist operating system. Bascially spoken, technically it is possible to program a linux like OS which needs only 10% of the RAM of a normal Linux system, the problem is, that somebody has to write the sourcecode first and this is the bottleneck.
The reason why the C language is used so much in the reality is, because it has simplified the programming. Even larger programs which contains of many modules can be created in C easily. The additional advantage is, that the same code can be compiled for different hardware architecture. The disadvantage of this flexciblity is, that the RAM Conspumption is high, the and the runtime speed low. But in the reality this is not a big problem, because modern computers have large amount of RAM. So we can say, that programming in the now works different from programming in the 1980s in which every byte of the RAM was expensive. In the 1980s most programmers have tried to reduce the amount of occupied RAM to a minimum. It was common to write programs which were running with 200 kb RAM and less. For today's ears this sounds like overengineering. Because a single PNG image which is rendered in Firefox will occupy this amount of RAM easily. It simply makes no sense to reduce the needed amount of RAM For executable binary files.
Perhaps it makes sense to explain what programming in general is. Let us investigate the similarity of some larger apps which are gnuplot and lyx. The shared feature is, that both applications are containing a large amount of codelines. In these codelines all the features are implemented. Each submenu in Lyx was realized with complicated C functions. So we can say, that the reason why these programs are big is not because of the programming style itself, but it has to do with the requirements how the application is working. That means, if somebody writes a gnuplot program from scratch which has all the same features and all the fancy graphics and buttons, he will need the same amount of codelines like the original gnuplot needs today. The only choice for creating smaller programs is to reduce the amount of features. For example if the idea is to program a simple command line based texteditor which has no features at all it is possible to compress the binary file in less than 50 kb of RAM. The problem is that modern normal users have such high expectations in the software. They wouldn't be satisfied by a simple 50kb large texteditor but they have a need for a lyx-like all in one system.