News for hackers. Stuff that matters.
Re:Please restore our registers when you’re done with them by matthews2 on Tuesday November 22, 2022 @11:38AM (#33707656)
Maybe we need some kind of higher level language that gets boiled down into assembly.
Re:Please restore our registers when you’re done with them by pencilguin on Tuesday November 22, 2022 @02:46PM (#33710378)
And, a compiler that knows custom SIMD optimizations for every algorithm anyone might ever need, and can recognize when you have coded one of them so it can substitute its SIMD version.
Re:Please restore our registers when you’re done with them by astrange on Wednesday November 23, 2022 @12:00AM (#33715411)
C does have official intrinsics for SIMD on Intel platforms, but the people who are good at writing video codecs don't like to use them because Wintel culture has such bad taste at naming functions (thanks to Hungarian notation) that using them is near-unreadable and it's easier to write everything in asm.
Re:Please restore our registers when you’re done with them by Iwan-Zotow on Wednesday November 23, 2022 @09:54PM (#33727361)
You're wrong. Intrinsics for SIMD are not named by Windows people. They were named by Intel engineers and supported now by all other compilers. Naming is actually in the C/C++ style - __simd_do_something_here() and such
Re:Please restore our registers when you’re done with them by astrange on Thursday November 24, 2022 @12:53AM (#33728156)
I am not wrong and I'm not talking about those.

The Intel platform intrinsics have names like `_mm512_4dpwssd_epi32()`. The standardized SIMD intrinsics with `simd` in the name are much newer than any of the code I'm talking about in ffmpeg/x264/dav1d. These are okay, but not being platform-specific of course means you don't get platform-specific features, which you might want when you're doing this level of optimization.

The other problem is compilers (esp. gcc) were traditionally very bad at code generation for them, although these days they're okay at it.