OSDev.org

Hi,

I was just wondering, for a particular application, lets say a HelloWorld, how faster is an assembly kernel in comparaison to Linux ?
Do you any link to any benchmark or just a rough idea of the speed ratio ?

Thanks for your replies,

In general, assembly is faster than most other programming languages and more compact as well. You have many examples. Compare KolibriOS and Linux, for example. KolibriOS is written entirely in assembly language.
This also applies for user mode programs; programs written in assembly language are usually faster than those written in C and other languages.

No meaningful comparison can be made.

Overall OS performance is about features and how those features are implemented and how programs interact or contend for those features.

A cooperative multi-tasking operating system allows a program to decide when to task-switch so enables programs to hog the CPU and do more work between task switches, for example, but a file system without a cache will slow down that same program if its doing predictable IO. Swings and roundabouts.

Hi,



Note: It's hard not to be biased. You should know I've been programming in assembly for over 20 years, mostly writing OS related code (boot code, kernels, etc), and am currently writing the next version of my boot code and kernel in assembly.

The exact speedup from hand crafted assembly depends far too much on what the code actually does, how skilled the programmers is, how well a compiler would've optimised, what the target CPU/s are, etc. It can range from nothing to maybe 100% in extreme/rare cases (but on average it's generally more like 5%).

However, the problem with assembly is that the more you optimise the harder it is to maintain; and for most code most of the time maintenance is far more important than squeezing a trivial performance increase out of it. What this means is that (assuming a project is 100% assembly) a good assembly language programmer won't even try optimise most of the code and a compiler will beat a good assembly language programmer almost all of the time.

More often than not; people claiming that assembly is faster in practice are not doing a fair comparison. For example they'll compare something like Menuet (with very minimal features) to something like Linux (that supports a massive number of features). In this case you can expect the former to be faster because it has less features, not because it's written in assembly. This happens frequently, simply because it takes longer to write code in assembly and therefore you end up with less features in the same amount of time.


Cheers,

Brendan

You have to compare like with like, i.e. an assembler-only kernel that does all that the Linux kernel does with Linux itself.

The assembler-only kernel will take far longer to execute, mainly because you have to factor in the time to actually develop such a kernel. This means that a simple program executing under the Linux kernel will take a few seconds at most. I'd guess it would be a few decades, at best, for an assembler-only kernel. (By that time, of course, the Linux kernel will have advanced further. )

It's a bit like asking "Which spacecraft will get to the moon first - Apollo 11 or a faster-than-light drive powered spacecraft?".

And again an assembly-vs-other-languages thread. Waiting for "real programmers" to rush in.

Actually, is it the time needed for writing the actual code, i.e. implementing the design, the bottleneck at all? If you have a good design and you know what you are doing, you would get an impressive amount of features, code, everything, after a few years of coding your project in assembly. As always, it is not that simple. In practice, I agree that high-level languages are much more productive.

I used to think that assembly was faster than, say, C. But now I have realized that it matters little in new and fast microprocessor with advanced optimization and parallel execution techniques, and in new highly optimized compilers.

The proof of the pudding is in the eating. The simple fact is that no-one has produced a kernel written only in assembler that has a fraction of the capabilities of the Linux kernel, the FreeBSD kernel, the Windows kernel, .... And, let's face it, they never will.

I believe implementing complex logics and algorithms with plain assembly draw programmer's focus, which could otherwise be used to pay more attention on the design itself.

How many of us can write quick sort in assembly that beat code generated by gcc? and with sane/usable interface?

Bottom line, assembly is cool in some situation, but use all the tools you know, which is not limited to assembly.

I think this question needs to be narrowed in scope. It is an inalienable fact that object code generated by any means is as fast as any other, the only potential assembled code has is to be more compact. As an example.This snipped extracts the 12 character processor ident, constructs an ASCIIZ string and displays it. Extrapolate upon this, it's not unreasonable to think code designed in assembly would be 1/2 the size of HLL.

I'm a vehement proponent of assembly and it is because of its simplicity. Therefore I can focus on the instruction set rather than linker scripts, compiler switches etc. However, if my mandate was beyond hobbyist, assembly wouldn't even be in contention. Inarguably, the fewer instructions, the faster the throughput.

I believe notwithstanding all other considerations and the simple answer to the question is, a well designed assembler kernel could be considerably faster than otherwise.

@TightCoderEx: Linker scripts are related to binary formats. It is no way related to languages. With assembly scripts can also be needed. And you don't need to bother with compiler switches, you can just set them once in your build script.

Nope. That's not true at all; modern CPUs have very complex, non-obvious performance characteristics. Your hand-crafted assembly with the minimum possible number of instructions could very easily be slower than a longer, more complex set of instructions produced by a compiler.

For an incredibly simple example, consider that on x86 most CPUs, the "LOOP" instruction is slower than a "DEC, JNZ" pair. For a more complex example, consider that the fastest way to copy a large block of memory on a modern x86 CPU is with a fairly complex SSE-based algorithm; which outperforms the shortest possible algorithm by an order of magnitude.

These days, CPU performance is complex and equally complex modern compilers are often better at producing fast code than all but the very best assembly-language programmers. Not only that, but if the compiler is doing the optimisation, the higher level source code can be kept simpler and easier to maintain, unlike hand-written assembly. Also, if a new optimisation technique is discovered, updating a compiler to take advantage of it is far easier than re-writing assembly.

While writing optimised assembly can be a fun and rewarding exercise, and a great way of learning about the low-level operation of the CPU, in terms of real-world performance it's often harmful.

I did compare KolibriOS disk cache and Linux disk cache. I'm not an expert at reading assembly but it seems that the KolibriOS disk cache uses a linear search for finding disk blocks. Linux uses a page cache that is integrated into its mmap facility. The page cache is indexed by red-black trees. I conclude that either KolibriOS has a tiny cache and will be 'slower' than Linux or that KolibriOS has a large cache and will be 'slower' than Linux.

Therefore assembly is slower.

That sort of a conclusion is dangerous, as you're comparing different algorithms in different languages. Even though the argument is somewhat flawed, your point is correct: hand-crafted assembly is often not better than one in a language like C, due to extremely simplified maintenance.

The only methods that I would do in assembly are the ones you have to do in assembly (LGDT/LIDT/LTR, ISRs etc.) + some libc functions, where optimizing can be extremely profitable (I'd say that for some functions a speedup by 100x is possible). For a correctly and thoroughly tested written libc function, maintenance shouldn't be a thing.

Talking about such a topic is relatively useless, as it is highly biased and heavily depends on the ability of the programmer to write/maintain assembly.