News for hackers. Stuff that matters.
Re:“Clean” Code, Horrible Performance by Taniwha on Tuesday February 28, 2023 @05:48PM (#34976033)
Occasional CPU architect here .... probably the worst thing you can do in your code is to load something from memory (the core of method dispatch) and then jump to it, it sort of breaks many of the things we do to optimise our hardware - it causes CPU stalls, branch prediction failures, etc etc

There is one thing worse you can do (and I caught a C++ compiler doing it when we were profiling code while building an x86 clone years ago) instead of loading the address and jumping to it push the address then return to it, that not only breaks pipelines but also return stack optimisations

Re:“Clean” Code, Horrible Performance by saagarjha on Tuesday February 28, 2023 @06:35PM (#34976501)
Most people do neither, but call into something that may do these things.
Re:“Clean” Code, Horrible Performance by badsectoracula on Tuesday February 28, 2023 @06:26PM (#34976424)
> instead of loading the address and jumping to it push the address then return to it

I remember doing that in a code generator ages ago because it was easier than calculating the jump offset :-P

Re:“Clean” Code, Horrible Performance by Taniwha on Wednesday March 01, 2023 @02:24PM (#34987010)
every subroutine return after that would be miss-predicted
Re:“Clean” Code, Horrible Performance by badsectoracula on Thursday March 02, 2023 @04:05AM (#34993621)
FWIW i wasn't trying to make an optimizing compiler, i was experimenting with replacing an interpreter for a scripting language with a JIT, so even bad native code was still faster than the interpreter :-).

It wasn't really used anywhere, eventually i decided to keep the interpreter and move any complex logic in C which ultimately was the simpler approach (and which has been my take on scripting languages for years now: use scripting languages for the "what" and native code for the "how").