The compiler will optimize that away

#1

Post by 0-_-0 » Sat, May 01, 2021, 11:38 PM UTC

The compiler will optimize that away
blog.royalsloth.eu

Re: The compiler will optimize that away

#2

Post by theamk » Sun, May 02, 2021, 1:03 AM UTC

Summary: the computer has changed -- memory latency measured in CPU cycles has grown a lot. So we should not be using traditional struct/class-like programming model, where we put all properties of an object next to each other. Instead, we should be using game-style "data oriented programming" a.k.a. "column databases" for a much higher performance.

However, most modern languages (C, C++, Python, Java, etc..) are not making it easy, and this is bad! Meanwhile you can data into columns and enjoy faster programs.

Re: The compiler will optimize that away

#3

Post by conradludgate » Sun, May 02, 2021, 5:57 AM UTC

If you want to utilise this data oriented approach in rust, check out soa-derive[0]. SoA stands for struct of array, rather than the conventional array of struct.

[0]: https://crates.io/crates/soa_derive

Re: The compiler will optimize that away

#4

Post by aparsons » Sun, May 02, 2021, 6:29 AM UTC

theamk wrote: post #2

Summary: the computer has changed -- memory latency measured in CPU cycles has grown a lot. So we should not be using traditional struct/class-like programming model, where we put all properties of an object next to each other. Instead, we should be using game-style "data oriented programming" a.k.a. "column databases" for a much higher performance. However, most modern languages (C, C++, Python, Java, etc..) are not…

What do you mean by game-style here? I’m very intrigued. Any place to read more about these?

Re: The compiler will optimize that away

#5

Post by foota » Sun, May 02, 2021, 6:43 AM UTC

aparsons wrote: post #4

theamk wrote: post #2

Summary: the computer has changed -- memory latency measured in CPU cycles has grown a lot. So we should not be using traditional struct/class-like programming model, where we put all properties of an object next to each other. Instead, we should be using game-style "data oriented programming" a.k.a. "column databases" for a much higher performance. However, most modern languages (C, C++, Python, Java, etc..) are not…

What do you mean by game-style here? I’m very intrigued. Any place to read more about these?

The keywords here are things like data oriented or "structures of arrays". Some examples are unity ECS or amethyst and bevy in Rust language.

Re: The compiler will optimize that away

#6

Post by bvrmn » Sun, May 02, 2021, 7:06 AM UTC

> 4. Data oriented way of programming has its own set of problems.

This should be a top reason. Author is too shy to reveal the true cause.

Re: The compiler will optimize that away

#7

Post by mvanaltvorst » Sun, May 02, 2021, 7:11 AM UTC

“Programming languages are old, therefore they will never take advantage of our hardware.” Have you looked at how compilers have changed the past 30 years? How they take advantage of SIMD? AVX? The LLVM-revolution? It’s delusional to think compilers will never be smart enough to vectorise object-oriented code, which is the main gripe of this article.

Re: The compiler will optimize that away

#8

Post by speedplane » Sun, May 02, 2021, 7:14 AM UTC

theamk wrote: post #2

Summary: the computer has changed -- memory latency measured in CPU cycles has grown a lot. So we should not be using traditional struct/class-like programming model, where we put all properties of an object next to each other. Instead, we should be using game-style "data oriented programming" a.k.a. "column databases" for a much higher performance. However, most modern languages (C, C++, Python, Java, etc..) are not…

> Instead, we should be using game-style "data oriented programming" a.k.a. "column databases" for a much higher performance.

This makes logical sense, but I don’t buy it in practice. Most of the heavy data reads are handled by databases, which do optimize for this stuff. I just doubt that, in most software, a significant amount of software performance issues are a result of poor memory alignment of data structures.

Re: The compiler will optimize that away

#9

Post by gumby » Sun, May 02, 2021, 7:21 AM UTC

> What if a programming language would provide us with a structure that would act like an array of structs, but internally it would really behave like a struct of arrays?

I do this all the time (well, it’s not uncommon) in C++. The nice thing is I can mix the two with a bit of manual glue so callers don’t even have to know (though if you are doing this it’s often worth letting some callers know for the reasons described in this post.

Re: The compiler will optimize that away

#10

Post by gumby » Sun, May 02, 2021, 7:22 AM UTC

speedplane wrote: post #8

theamk wrote: post #2

Summary: the computer has changed -- memory latency measured in CPU cycles has grown a lot. So we should not be using traditional struct/class-like programming model, where we put all properties of an object next to each other. Instead, we should be using game-style "data oriented programming" a.k.a. "column databases" for a much higher performance. However, most modern languages (C, C++, Python, Java, etc..) are not…

> Instead, we should be using game-style "data oriented programming" a.k.a. "column databases" for a much higher performance. This makes logical sense, but I don’t buy it in practice. Most of the heavy data reads are handled by databases, which do optimize for this stuff. I just doubt that, in most software, a significant amount of software performance issues are a result of poor memory alignment of data structures.

When your datasets are quite large a sql database becomes an absurd bottleneck. Think of weather or aerodynamics simulations.