News for hackers. Stuff that matters.
Re:“Clean” Code, Horrible Performance by rerdavies on Tuesday February 28, 2023 @10:57PM (#34978595)
It's not really possible to write hand-coded assembler that's faster anymore. C/C++ compilers have deep knowledge of architecture-specific instruction pipelines that allow them to schedule instructions more accurately than any human could.

My most recent misadventure: trying to write hand-coded ARM Neon assembler, and/or C++ code with neon intrinsics to optimize a piece of real-time audio effect code. The clear performance winner: plain C++ with no intrinsics, but tweaked to allow auto-vectorization (plus judicious use of the __restrict modifier for a small but significant boost). GCC produced code that had better instruction scheduling than I could (but not for the NEON intrinsics, oddly). And as an added bonus, the same plain-old C++ code generates AVX vectorization on MSVC without modifications! (MSVC also supports __restrict until the C++ standards committee gets their act together to adopt the eminently necessary C99 restrict keyword).

Re:“Clean” Code, Horrible Performance by DeathArrow on Wednesday March 01, 2023 @05:14AM (#34980690)
It is. I witnessed it many times on Code Golf substack.
Re:“Clean” Code, Horrible Performance by pg314 on Wednesday March 01, 2023 @06:25AM (#34981140)
>It's not really possible to write hand-coded assembler that's faster anymore.

That is wrong. Just because you didn’t succeed in writing faster code in one case, doesn’t mean it’s impossible. See e.g. [1] on why the Lua vm is written in assembly. It’s from 2011 but not much has changed in the meantime.

[1] http://lua-users.org/lists/lua-l/2011-02/msg00742.html