Linux 4.4 Continues Moving x86 Assembly Code Into C

[phoronix]

Phoronix: Linux 4.4 Continues Moving x86 Assembly Code Into C

The past few kernel cycles we've seen a fair amount of x86 Assembly changes with a goal of turning more Assembly into C code for the Linux kernel. That process has continued with the in-development Linux 4.4 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.4-x86-Assembly

[milkylainen]

C is fine. But how about the generated code? Syscalls can be quite sensitive. Modifying frequently called syscalls into something less optimal can cause quite a bit of performance hit. How do we know that the generated code is suitable from the vast array of GCC's? Do the developers check that normal GCC's generate reasonable code when doing this type of conversion? I mean.. they used to be asm for a reason...

[microcode]

C is fine. But how about the generated code? Syscalls can be quite sensitive. Modifying frequently called syscalls into something less optimal can cause quite a bit of performance hit. How do we know that the generated code is suitable from the vast array of GCC's? Do the developers check that normal GCC's generate reasonable code when doing this type of conversion? I mean.. they used to be asm for a reason...

From what I understand, so-far this effort has yielded better performance rather than worse.

[boxie]

C is fine. But how about the generated code? Syscalls can be quite sensitive. Modifying frequently called syscalls into something less optimal can cause quite a bit of performance hit. How do we know that the generated code is suitable from the vast array of GCC's? Do the developers check that normal GCC's generate reasonable code when doing this type of conversion? I mean.. they used to be asm for a reason...

Trust in the compiler!
Compiler tech has come a long way since in the last decade or two - so writing ASM now is more of a burden than it is worth.
Also, if you are compiling the kernel for a native CPU, it also has the benefit of being able to optimise for that CPU

[gens]

From what I understand, so-far this effort has yielded better performance rather than worse.

the assembly rewrite, yes
this to C rewrite should have no impact whatsoever

[gens]

Trust in the compiler!
Compiler tech has come a long way since in the last decade or two - so writing ASM now is more of a burden than it is worth.
Also, if you are compiling the kernel for a native CPU, it also has the benefit of being able to optimise for that CPU

more of a burden when GNU as is involved

in this case there is nothing to optimize

[profoundWHALE]

The burden of -maintaining assembly vs maintaining C- makes rewriting code worth it. It makes it more portable and shouldn't see any drops in performance.

[gens]

The burden of -maintaining assembly vs maintaining C- makes rewriting code worth it. It makes it more portable and shouldn't see any drops in performance.

in this case it doesn't matter
the kernel calling convention IS a set thing, there is nothing to maintain

it's not like the whole thing is written in assembly (not that assembly is that much harder to maintain)

if you go check the git logs for those files, you will find they were almost never changed

[F1esDgSdUTYpm0iy]

Maybe it's not so much about maintainability as it is about extensibility. What I mean is, in other OSS projects whose development I am interested in I see a recurring pattern -- a rewrite is met with some opposition but in the end, that same rewrite enables subsequent changes that were not possible before. What I mean to say is -- even if there is no direct performance improvement as a result of the ASM > C rewrite, as long as there is no performance regression either, it still is a worthwhile effort in my opinion.