Live data from Hacker News

The compiler will optimize that away

blog.royalsloth.eu

161–170 of 329 posts

Re: The compiler will optimize that away

#161
post #79

The implicit premise of the article seems to be that all software has to be heavily optimized. This is completely wrong. All the languages mentioned in the article are still around because it doesn’t matter how performant 99% of code is. For the 1%, we can think about cache misses, SIMD and data parallel approaches. In my experience this is totally possible and not too hard, but has the enormous downside of making th…

I disagree. Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity. I have ssd, fast internet, 64gb ddr4 etc, almost everything I do should be impercetibly instant but instead takes seconds and even minutes. Yeah of course most of that slowness is not even because of ignorance of the low level stuff but complete disregard of performance aspect…

> I disagree. Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity.

This is absolutely true, but the problem is usually a lack of due care about performance at higher levels, rather than low level optimization. Things are usually slow because they do entirely too much of the wrong things, than because nobody optimized the things, or the wrong registers were used or what not.

Re: The compiler will optimize that away

#162

Earlier quoted context omitted.

It is technically also possible in C as long as the program can't tell the difference (thanks to the as-if rule). This is hard to prove though and in practice requires whole program compilation.

The C standard provides guarantees about data layout even if the compiler can prove it will never be used internally, for the sake of, say, external debugging.

It doesn't require this as long as the program has the same side effects - the contents of memory are not a side effect necessarily.

The problem is that there are lots of operations which imply the existence of part of an object, like passing around pointers or allocating single objects at a time, and that would disable these layout optimizations. An optimization that's easy to break isn't useful even if it would help a lot; you want them to be predictable more than anything.

Re: The compiler will optimize that away

#163

Why aren’t hardware designers designing hardware for the languages and methods we have?

They are (through prediction, reordering, etc in the CPU), but manual approaches like hinting or VLIW have always turned out to fail, and the automatic approaches we're using now turn out to have security issues like Spectre.

Re: The compiler will optimize that away

#164
post #57

Why wouldn't a new programming language like python nowadays decide to use a Gil? I thought the point was to make the interpreter easier to write.

A global interpreter lock made sense in the 1990s when multiple cpus was rare, and when it happened, it was usually two.

Now, it's hard to find a system with just one cpu. Maybe something really embedded; but IoT stuff sometimes is multiprocessor these days. Anything intended for regular computers needs to be prepared for 1-16 cpus, and more isn't hard to find if you need it. Building a new programming language with a big constraint preventing it from using modern computing seems like a mistake. That doesn't mean an early version wouldn't start with a big lock, but fine grained locking is probably needed before release.

Re: The compiler will optimize that away

#165
post #51

> The programming languages listed above are all over 20 years old and their initial design decisions, like Python’s global interpreter lock or Java’s everything is an object mindset, no longer make any sense today I wonder what general purpose languages (as the mentioned Jai is meant for games primarily) will be the best fit for modern architectures, besides obvious things like doing it in C and just doing everythin…

It's the APL/J/K/Fortran model. It fits modern CPU and memory architectures, it fits GPUs, and slow external storage. And rather surprisingly, it always has, even when memory latency was 1 cycle and there was no prefetch (for which you have to go back to the late 70s). The first APL implementation is from 1962 or so, first Fortran is 1955 or so. R and Numpy use it to deliver their speed while still providing high lev…

I too suspect "data oriented programming" is just array programming rebranding itself.

Re: The compiler will optimize that away

#166

Earlier quoted context omitted.

Shit is slower than it was in the 90s. Spotify is slower than Winamp, Slack is slower than IRC, Webmail is slower than my e-mail client, VS Code is slower than Visual C++ 6.0.

Slack is definitely faster than my IRC client since it's not running over ssh to a host. You can't actually run IRC locally or you'll miss all the chat from when you're not signed in.

You can use a bouncer so that's not true

Re: The compiler will optimize that away

#167
> So far, the only programming language I know of that supports this type of crazy data transformations is JAI

I believe zig supports this too, and it's very encouraging that the creator has recently done a refactoring of the language parser taking a data-oriented approach, so that has surfaced pain points to be repaired for folks who would like to do things that way.

Re: The compiler will optimize that away

#168
post #45

Good article. My own thinking when coding performance is also towards data oriented approaches. For example Bevy in Rust. If stuff needs to be fast, it needs to be in cache. To do that, have everything nicely packed so you only ask for a chunk as often as you need. Then when you need it, it's already there. Thing about old fashioned OO is it's often fine enough for your run-of-the-mill CRUD app. If you look at the la…

> Somehow over the years I've found that the animals/cars analogies given in OO tutorials are one of the few places that fit well with the model. Yes, and I've never actually needed to implement a cat or a cow in any project :) The other thing for which OO works much better than plain data is GUIs - and I think it is not a coincidence that OO popularity exploded together with the the coming-of-age of GUIs. The other…

> The other thing for which OO works much better than plain data is GUIs

I think the absolute dominance of React and its functional style (especially among juniors) is pretty good evidence against this belief.

Re: The compiler will optimize that away

#169

Earlier quoted context omitted.

Haskell uses linked lists everywhere, so any transformation like this likely does nothing for speed.

Haskell uses linked lists as a metaphor for generators (since it's a lazy language), which is a strange decision since linked lists are a bad data structure, so you have to write the program to avoid accidentally ever doing what it says it does.

> linked lists are a bad data structure

Why is that? They're perfectly fine for most purposes, and have the advantage that when you pass one across a function boundary the callee can play with it or modify it or do whatever the hell they want and when the callee returns, the caller's linked list is untouched. That's an incredibly valuable feature for correctness and safety.

Re: The compiler will optimize that away

#170

> The programming languages listed above are all over 20 years old and their initial design decisions, like Python’s global interpreter lock or Java’s everything is an object mindset, no longer make any sense today I wonder what general purpose languages (as the mentioned Jai is meant for games primarily) will be the best fit for modern architectures, besides obvious things like doing it in C and just doing everythin…

> I wonder what general purpose languages

I'm looking forward to zig. The author is taking a lot of care and effort to make sure the content works on legacy systems as well as modern systems, so I think the level of flexibility that entails will also mean the flexibility to adapt to the future.

Also, IIRC zig has an AOS to SOA transformation in its stdlib? In any case, they have been refactoring the language parser to use SOA to great effect:

https://github.com/ziglang/zig/pull/7920

Post reply on HN