This sort of analysis is great.

Now why can't compilers do this sort of thing automatically?

Almost any problem seems to be possible to speed up 1000x in AVX512+days of thought compared to the naive version written in a python loop. If we could automate that whole process for big codebases the performance gains could be huge.

▲

cmovq 4 hours ago | parent | next [-]

Compilers can’t really, in a meaningful way, change the layout of your data in memory. And you do need to think about your memory layout to get any benefit from SIMD. You’ll notice a lot of compiler auto vectorization insert many instructions just to shuffle data around to get to a usable layout, which negates much of the benefit.

▲

motoboi 28 minutes ago | parent | next [-]

This is actually a very nice question and the answer is that interpreted languages with a JIT benefit from this.

One example is Java, which will happily vectorize your code into AVX or SSE where possible.

Python just got a JIT compiler and we’ll start seeing the same thing soon.

But as someone else said here, some constructs don’t translate well and adding transformations to show vectorization would negate the perfomance gains.

Sad that the compiler (even Java) can’t explain you this and warn about it, but now with LLM, maybe they’ll start doing things like that soon.

▲

fulafel 3 hours ago | parent | prev [-]

Depends on the programming language. A good question is why we don't have more optimizable languages in mainstream use.

▲

inigyou an hour ago | parent | next [-]

FORTRAN is used for a lot of numerical algorithms - today! installed on your computer right now in some library! - because it optimizes better than C because it doesn't have pointers.

	▲	fc417fc802 an hour ago \| parent [-]
		As I understand it most of the difference can be made up by adding the restrict qualifier to everything in C.

▲

flohofwoe 3 hours ago | parent | prev [-]

Are there any programming languages which change the data layout beyond naively sorting struct members by alignment? (which at best helps with reducing padding bytes but can be either good or bad for performance, depending on the code which accesses the data).

▲

londons_explore an hour ago | parent | next [-]

One simple optimization is to change arrays of struts into struts of arrays. To my knowledge, nothing even makes those changes, despite them being safe and having a huge potential performance benefit.

	▲	flohofwoe an hour ago \| parent [-]
		Now that you mention it... :) Zig has MultiArrayList in the stdlib which does the SoA transform via comptime: https://ziglang.org/documentation/master/std/#std.multi_arra... Zig also sorts struct members by size/alignment, but has two escape hatches ('extern struct' which is for C compatibility, and 'packed struct' which offers an explicit bit-by-bit memory layout). AFAIK Odin and Jai offer the SoA transform as specialized language features, e.g. in Odin: https://odin-lang.org/docs/overview/#soa-data-types I'd still always want such data layout transforms as an explicit language feature though, not the compiler making this decision for me.

▲

pillmillipedes 39 minutes ago | parent | prev [-]

various SQLs and APLs come to mind :) the industry still has a lot to learn from them both

▲

flohofwoe 3 hours ago | parent | prev | next [-]

> 1000x in AVX512+days of thought compared to the naive version written in a python loop

Out of this 1000x speedup you get 100x by just not using python though ;)

Also IIRC the main problem specifically with AVX512 was that mainstream CPUs simply didn't have it, so a smart compiler won't be of much use when the output code only runs on a handful devices.

▲

diamondlovesyou 4 hours ago | parent | prev | next [-]

> Now why can't compilers do this sort of thing automatically?

They do - they just can't assume GFNI instructions are present unless you explicitly say so: https://godbolt.org/z/eYasbKsse

▲

lifthrasiir 3 hours ago | parent | prev [-]

Intents matter. Compilers can't see through your skull to infer your intents and thus behave very conservatively unless you override that behavior somehow. This inference, alas, also takes (much) time, so compilers have to balance the compilation time with quality of intents guessed as well. (This is why we can't exactly use LLMs in mainstream compilers, by the way.) So go and make a programming language that preserves your intents by every means; but making it practical would be very difficult.