this post was submitted on 17 Oct 2024
1378 points (98.9% liked)
RetroGaming
19568 readers
641 users here now
Vintage gaming community.
Rules:
- Be kind.
- No spam or soliciting for money.
- No racism or other bigotry allowed.
- Obviously nothing illegal.
If you see these please report them.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think they meant the other way around, that if you wanted to use it in C/C++, you'd have to either use assembly or some specific SSE construct otherwise the compiler wouldn't bother.
That probably was the case at one point, but I'd be surprised if it's still the case. Though maybe that's part of the reason why the Intel compiler can generate faster code. But I suspect it's more of a case of better optimization by people who have a better understanding of how it works under the hood, and maybe better utilization of newer instruction set extensions.
SSE has been around for a long time and is present in most (all?) x86 chips these days and I'd be very surprised if gcc and other popular compilers don't use it effectively today. Some of the other extensions might be different though.
If you want to use instructions from an extension (for example SIMD), you either: provide 2 versions of the function, or just won't run in some CPUs. It would be weird for someone that doesn't know about that to compile it for x86 and then have it not run on another x86 machine. I don't think compilers use those instructions if you don't tell them too.
Anyway, the SIMD the compilers will do is nowhere near the amount that it's possible. If you manually use SIMD intrinsics/inline SIMD assembly, chances are that it will be faster than what the compiler would do. Especially because you are reducing the % of CPUs your program can run on.
Oh I see your point. Yeah, I think they meant that. And yes, there was a time you’d have to do trickery in C to force the use of SSE or whatever extensions you wanted to use.