FreeBSD Has Been Working On AMD64 SIMD libc Optimizations - Coming For FreeBSD 14.1

[phoronix]

Phoronix: FreeBSD Has Been Working On AMD64 SIMD libc Optimizations - Coming For FreeBSD 14.1

The FreeBSD project today issued their Q4'2023 status report that highlights all of their interesting work accomplished last quarter on this open-source platform. Among the interesting achievements were the FreeBSD Foundation sponsoring AMD64 SIMD improvements for FreeBSD 15 that will also be back-ported to FreeBSD 14.1...

https://www.phoronix.com/news/FreeBSD-Q4-2023-Improvements

[Volta]

GNOME 45 is almost finished, except for GNOME Shell extensions. For this release I will focus on Wayland support (bug #258042 and bug #271836).

Good move on their part.

[bug77]

I don't get it. Is FreeBSD working on adding SIMD optimizations to libc? Or are they working on putting existing optimizations at work in FreeBSD?

[pabloski]

I don't get it. Is FreeBSD working on adding SIMD optimizations to libc? Or are they working on putting existing optimizations at work in FreeBSD?

Adding.

On other note, it looks to me that Intel's hand is starting to show. Let's remember that about one year ago or so decided to up its support of FreeBSD, from drivers to various optimizations and other bits. And it is clearly visible that FreeBSD is upping its game. I am a Linux user for choice and necessity ( I use a lot Stable Diffusion, so I need CUDA!! ), but I have an interest for BSDs, to the point of using FreeBSD on some spare machines and giving various BSD flavors a try. I remember my adventure playing with the low level bits of NomadBSD. But at the end of the day, I have been forced to crawl back to the Linux world.

I hope things will drastically change!!

[ddriver]

I'd rather see compilers auto vectorize to avx 512, Seems like most compilers still target 128 bit simd for auto vectorization.

[M.Bahr]

Can we at least limit avx support to the lowest common denominator please. Oh wait ... there is none! AVX versions are fragmented. This is probably the best thing about it.

[kozman]

I'd rather see compilers auto vectorize to avx 512, Seems like most compilers still target 128 bit simd for auto vectorization.

No. As someone who is still rocking Ivy Bridge on his home PC, I want to say that not everyone is ditching their perfectly working PC to have the latest and greatest rig. I would surmise a good majority of users out there don't have AVX512 capable CPUs running their boxes. Would be great if the compiler could query the CPU and-vectorize against what is present not what one wishes it was. Would be nice to have Linux have some kind of opt-in feature that reports your CPU gen to a public database to give a clearer picture of what actually is out there to make better code/compiler assumptions.

I like the way distros are now coming around to the idea of x64-v1, v2, v3, etc., releases to target certain generations of CPUs. A bit more work in terms of maintaining code and ISOs but it fills the void.

[ddriver]

No. As someone who is still rocking Ivy Bridge on his home PC, I want to say that not everyone is ditching their perfectly working PC to have the latest and greatest rig. I would surmise a good majority of users out there don't have AVX512 capable CPUs running their boxes. Would be great if the compiler could query the CPU and-vectorize against what is present not what one wishes it was. Would be nice to have Linux have some kind of opt-in feature that reports your CPU gen to a public database to give a clearer picture of what actually is out there to make better code/compiler assumptions.

I like the way distros are now coming around to the idea of x64-v1, v2, v3, etc., releases to target certain generations of CPUs. A bit more work in terms of maintaining code and ISOs but it fills the void.

There's nothing preventing the compiler from targeting older SIMD implementations if your cpu doesn't support the most recent.

Targeting what's essentially "SSE" in this day and age... quite backward.

[kozman]

There's nothing preventing the compiler from targeting older SIMD implementations if your cpu doesn't support the most recent.

Targeting what's essentially "SSE" in this day and age... quite backward.

I'm not a coder nor know anything about compilers. I'm sure I am not stating things right when I say things like above. I guess I am just seeing the trend where developers are leveraging AVX512 and it's newer variants because of the big perf gains I've read about here many times. There's probably not too much to gain from older instructions sets so I'd think developers and app makers would want to put efforts into where it'll make most difference. Still, the graphs show there is some good benefits to be had so I wonder why it took so long to squeeze out that much perf yield?

[bug77]

No. As someone who is still rocking Ivy Bridge on his home PC, I want to say that not everyone is ditching their perfectly working PC to have the latest and greatest rig. I would surmise a good majority of users out there don't have AVX512 capable CPUs running their boxes. Would be great if the compiler could query the CPU and-vectorize against what is present not what one wishes it was. Would be nice to have Linux have some kind of opt-in feature that reports your CPU gen to a public database to give a clearer picture of what actually is out there to make better code/compiler assumptions.

I like the way distros are now coming around to the idea of x64-v1, v2, v3, etc., releases to target certain generations of CPUs. A bit more work in terms of maintaining code and ISOs but it fills the void.

Package maintainers would like to have a word with you