In this video I discuss Ubuntu's decision to switch to using rust implementations of the core utilities (mkdir, ls, cat, etc...) and what it could mean for the broader Linux ecosystem. My merch is ...
Look, I wrote plenty of assembly. A human knows how the code will flow. A compiler knows how everything is linked together, but it does not know how exactly the code will flow. In higher level languages, like C, we don’t always think about things like what branch is more likely (often many times more likely).
Memory is the real performance winner, and yes registers play a big role in that. While cache is more important it depends on data layout and how it is processed. That is practically the same in C and asm.
C compilers don’t even use every GP register on amd64. And you know exactly what you need when you go into some procedure.
And when you get called / call outside of your… object file in C (or C ABI), you have to:
“Functions preserve the registers rbx, rsp, rbp, r12, r13, r14, and r15; while rax, rdi, rsi, rdx, rcx, r8, r9, r10, r11 are scratch registers.”
put those on the stack. So libraries have calling overhead (granted there is LTO).
In assembly you can even use the SSE registers as your scratchpad, pulling and putting arbitrary data in them (even pointers). The compilers never do that. (SSE registers can hold much more then GP)
In asm you have to know exactly how memory is handled, while C is a bit abstracted.
If you want to propagate such claims, read the “Hellо, I am a compiler” poorly informed… poem ?
But it’s easy to see how much a compiler doesn’t optimize by comparing compilers and compiler flags. GCC vs LLVM, O3 vs Os and even O2. What performs best is random, LLVM Os could be the fastest depending on the program. Differences are over 10% sometimes.
Biggest problem with writing in asm is that you have to plan a lot. It’s annoying, so that’s why I write higher level languages now.
Edit: Oh, I didn’t talk about instructions not in C, nor the FLAGS register.
Look, I wrote plenty of assembly. A human knows how the code will flow. A compiler knows how everything is linked together, but it does not know how exactly the code will flow. In higher level languages, like C, we don’t always think about things like what branch is more likely (often many times more likely).
Memory is the real performance winner, and yes registers play a big role in that. While cache is more important it depends on data layout and how it is processed. That is practically the same in C and asm.
C compilers don’t even use every GP register on amd64. And you know exactly what you need when you go into some procedure. And when you get called / call outside of your… object file in C (or C ABI), you have to: “Functions preserve the registers rbx, rsp, rbp, r12, r13, r14, and r15; while rax, rdi, rsi, rdx, rcx, r8, r9, r10, r11 are scratch registers.” put those on the stack. So libraries have calling overhead (granted there is LTO). In assembly you can even use the SSE registers as your scratchpad, pulling and putting arbitrary data in them (even pointers). The compilers never do that. (SSE registers can hold much more then GP)
In asm you have to know exactly how memory is handled, while C is a bit abstracted.
If you want to propagate such claims, read the “Hellо, I am a compiler” poorly informed… poem ? But it’s easy to see how much a compiler doesn’t optimize by comparing compilers and compiler flags. GCC vs LLVM, O3 vs Os and even O2. What performs best is random, LLVM Os could be the fastest depending on the program. Differences are over 10% sometimes.
Biggest problem with writing in asm is that you have to plan a lot. It’s annoying, so that’s why I write higher level languages now.
Edit: Oh, I didn’t talk about instructions not in C, nor the FLAGS register.