3 ms·

New software optimizations is unlikely to stay a niche area where we only manage to eke out a bit of performance. Look at our popular languages today: pretty mu

New software optimizations is unlikely to stay a niche area where we only manage to eke out a bit of performance. Look at our popular languages today: pretty much none of them even do something as simple as combine a GC with true composition of data types (Go is the only one I can think of, and it makes up the difference elsewhere). This isn't about high level abstractions being bad, it's about our current arbitrary limits on high level abstractions being bad. The JIT languages are of course severely limited in the complexity of their optimizations due to time constraints. But most compiled languages experience the same because they either don't provide a good set of semantics for a compiler to reason about the code (e.g. C/C++), or use one that is so limited that you simply can't get the compiler to generate sufficiently efficient code in some instances (e.g. Haskell). On top of this, a programmer's input to the optimization process rarely extends past "inline/don't inline this function". Compilers have to make optimizations that are either strictly better or base it on a wild guess of the time, instead of using profiling to either automatically or manually (i.e. overridden by humans after they test the code) invoke optimizations. Many compilers offer profile-guided optimization but few projects use it, and the JVM just uses it to smooth over some of the performance loss from lacking things like value types or refined generics. In languages that provide sufficiently low level operations you can sometimes get what you want by altering the code, but that doesn't always work. I'm excited for us to stop using Moore's law as a crutch (which has stopped on desktop CPUs for a while now as far as performance if not price) and to look at things like improved tooling, improved languages, and hopefully even improved architectures. I find it hard to believe that "5nm transistors arranged into x86 processors running hand-optimized C code" is the epitome of feasible computing in our universe, and that's forgetting that most of our code isn't optimized anywhere near that much.

bogomipz 10y ago
>"combine a GC with true composition of data types" Could you elaborate on how combining a garbage collector with composition of data types works as an optimization? Is this distinctly different than GC with an inheritance object model?
- johncolanduoni 10y ago
  It's not about inheritance, it's about how to implement composition. In C++, B inheriting A is implemented to same as B containing a member variable of type A as far as memory layout: the form one allocation with space for A's fields as well as B. In Java or .NET, fields which are objects are pointers to a separate allocation, like they would be if they were pointed to in C++, even if you assign them once and never change them. This increases indirection, memory and GC overhead, and reduces locality. Since you can nest containment, the effect from this can be quite large. .NET has structs to offset this a bit, but they make you decide for each type instead of each variable and you can't really operate on references to them. Obviously there are cases where you need that indirection (e.g if you're swapping out pointers to different objects in that field) but there are plenty cases where you don't (this usage pattern is a big part of the reason why write barriers work okay for these languages). Also note that you don't need to use indirection if all you want to do is use/store a garbage collected pointer to the field's object elsewhere in your program; the .NET garbage collector already has the ability to deal with pointers within allocations. It's just that they've stuck to not discriminating between these within the language for simplicity (IIRC the .NET runtime can sort of use interior pointers to structs, but this isn't exposed in C#).
- imtringued 10y ago
  A GC needs to visit every pointer in live memory. The less pointers you have the quicker the GC can finish it's job.
imtringued 10y ago
Who has the luxury of having a CPU bound problem these days? The developers of games for handheld games consoles maybe. Most problems are memory or IO bound nowadays and in this era the latest crutch is the SSD. Since random access is faster than on an HDD the developers care less about optimizations. Heck even in the games with fast loading screens there is still low hanging fruit like "oh you are in a queue for map X? let me preload it for you in the background instead of waiting until the match starts and then loading it" for example.

bogomipz 10y ago

>"combine a GC with true composition of data types" Could you elaborate on how combining a garbage collector with composition of data types works as an optimization? Is this distinctly different than GC with an inheritance object model?

johncolanduoni 10y ago
It's not about inheritance, it's about how to implement composition. In C++, B inheriting A is implemented to same as B containing a member variable of type A as far as memory layout: the form one allocation with space for A's fields as well as B. In Java or .NET, fields which are objects are pointers to a separate allocation, like they would be if they were pointed to in C++, even if you assign them once and never change them. This increases indirection, memory and GC overhead, and reduces locality. Since you can nest containment, the effect from this can be quite large. .NET has structs to offset this a bit, but they make you decide for each type instead of each variable and you can't really operate on references to them. Obviously there are cases where you need that indirection (e.g if you're swapping out pointers to different objects in that field) but there are plenty cases where you don't (this usage pattern is a big part of the reason why write barriers work okay for these languages). Also note that you don't need to use indirection if all you want to do is use/store a garbage collected pointer to the field's object elsewhere in your program; the .NET garbage collector already has the ability to deal with pointers within allocations. It's just that they've stuck to not discriminating between these within the language for simplicity (IIRC the .NET runtime can sort of use interior pointers to structs, but this isn't exposed in C#).
imtringued 10y ago
A GC needs to visit every pointer in live memory. The less pointers you have the quicker the GC can finish it's job.

imtringued 10y ago

Who has the luxury of having a CPU bound problem these days? The developers of games for handheld games consoles maybe. Most problems are memory or IO bound nowadays and in this era the latest crutch is the SSD. Since random access is faster than on an HDD the developers care less about optimizations. Heck even in the games with fast loading screens there is still low hanging fruit like "oh you are in a queue for map X? let me preload it for you in the background instead of waiting until the match starts and then loading it" for example.