All that extra push and popping to slower memory (using ram instead of register) must make it more expensive to call a function in Go than in C right? Even without adding the extra complexity of Defer.
From my perspective CPUs truly are magical beasts. Speculative branching and execution, pseudo register that mimics memory addresses with zero latency.
Every layer adds so much optimization, the compiler inlines functions, removes static loops and what not, so that the assembly don’t look like the written code, and then the cpu execute the opcodes as it sees fit. Truly, the code that I write is not what is running on the silicon. 😀 That all this cleverness don’t break the programs! (Well, we did have specter and meltdown recently)
Truly, the code that I write is not what is running on the silicon. 😀 That all this cleverness don’t break the programs
This is what ‘compilation’ means!
It’s the translation from some language (the ‘source’) to some other language (the ‘target’) in a manner that correctly expresses the semantics of the former according to those of the latter.
There’s no fundamental difference between the architectures and compilers of today and those of the 70s; there are just more and bigger translations.
Did not see any references for the statement that Go exclusively pass arguments in the stack. Quick search found this: https://programmer.group/go-function-calls-stack-and-register-perspectives.html
All that extra push and popping to slower memory (using ram instead of register) must make it more expensive to call a function in Go than in C right? Even without adding the extra complexity of Defer.
In compiler class, I “accidentally” forgot to implement passing arguments in registers, and I think it was not even 10% slower. Cache lines are good.
How long ago was this? Newer CPUs have memory renamers which allow zero-latency access to memory; but they didn’t back when sysv was designed.
From my perspective CPUs truly are magical beasts. Speculative branching and execution, pseudo register that mimics memory addresses with zero latency.
Every layer adds so much optimization, the compiler inlines functions, removes static loops and what not, so that the assembly don’t look like the written code, and then the cpu execute the opcodes as it sees fit. Truly, the code that I write is not what is running on the silicon. 😀 That all this cleverness don’t break the programs! (Well, we did have specter and meltdown recently)
This is what ‘compilation’ means!
It’s the translation from some language (the ‘source’) to some other language (the ‘target’) in a manner that correctly expresses the semantics of the former according to those of the latter.
There’s no fundamental difference between the architectures and compilers of today and those of the 70s; there are just more and bigger translations.
In 2013.
CPUs have a thing called load store forwarding that helps I think.
https://easyperf.net/blog/2018/03/09/Store-forwarding