The compiler will optimize that away • Hacker News Board

Re: The compiler will optimize that away

#281

Post by kaba0 » Mon, May 03, 2021, 5:30 PM UTC

dnautics wrote: post #168

beagle3 wrote: post #45

Earlier quoted context omitted.

> 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.

It is pretty much an MVC separation that was mainstream in OOP-based GUI frameworks since the 90s at least.

But instead of “state”, you have a model, which uses the Observable pattern to notify the view of changes.

Re: The compiler will optimize that away

#282

Post by kaba0 » Mon, May 03, 2021, 5:36 PM UTC

Tomte wrote: post #176

lordnacho wrote: post #13

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…

> as opposed to OO where you have the data declared next to the functions that mutate it. In the popular OO languages. As usual, the Common Lisp Object System is always worth a look. You have classes that encapsulate data, and then you have "free" generic functions (well, methods that implement those generic functions) that operate on that data.

How does that enforce class invariants?

Re: The compiler will optimize that away

#283

Post by uhhhhhhhhhhhhhh » Mon, May 03, 2021, 5:46 PM UTC

29athrowaway wrote: post #130

esailija wrote: post #87

Earlier quoted context omitted.

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…

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.

VLC has pretty good startup time. VScode plugins (generally) dont take down the whole program or BSOD any more. I do feel that its not as snappy, which is sometimes physically unpleasant, but it is possible that we now wait less because we're not rebooting or ctrl+alt+del'ing our way out of some nullptr deref

Re: The compiler will optimize that away

#284

Post by dahart » Mon, May 03, 2021, 6:05 PM UTC

kaba0 wrote: post #279

dahart wrote: post #254

Earlier quoted context omitted.

> All the languages mentioned in the article are still around because it doesn’t matter how performant 99% of code is. It’s worth challenging this assumption and asking whether it’s really true, or whether this belief is old and outdated like the old languages. I’m certain that providers of compute infrastructure like Amazon, Microsoft, Google and others completely disagree that performance doesn’t matter. Letting sl…

Feel free to profile a high-profile application. It is almost always a few hotspots that “suck”. There are rare cases where there is no one point that is slow, that’s a bad situation to find oneself in — it usually means that the base architecture/abstraction sucks and needs a big refactor. But even in so low-level code as the linux kernel, you see the use of linked lists all the time. Because it simply doesn’t matte…

FWIW, I profile intensive applications all the time, it's my job. You're right about the existence of hot spots, but that's not particularly relevant to my point or the author's. Just because one spot is hot doesn't mean you should rationalize using lazy or bad-practices programming on the rest. Just because you don't see a bottleneck somewhere when you profile doesn't mean it'll stay that way when other processes want the same resources at the same time. Knuth's famous quote was not intended to be a license to ignore using best practices in general for non-hot-spot code.

Use of linked lists in the linux kernel is also not very relevant, and somewhat of a red herring. Kernel-level (as well as games & embedded programming) linked lists are frequently allocated and used very differently from typical high level language linked lists. Scripting languages are allocating individual linked list nodes by default. Linux uses linked lists for the memory allocator itself, for example, and allocates nodes at a lower level in blocks. There are no particularly good alternatives, and no great ways for the allocator itself to be cache aware, though that is ongoing research. The main perf problem with using linked lists in high level languages is not the fact that they cause cache-incoherent access, it's worse, it's the fact that they allocate and deallocate memory constantly which is much much slower. This is one reason why linked lists don't get used as much as arrays in high level languages, when arrays are a reasonable alternative.

Anyway, it's somewhat of a straw man to bring up linked lists when the author's valid point was SoAs are better than AoSs from a cache perspective, and that our languages aren't yet doing much to help us code that way, but they could in the future if we decide to want them to.

Re: The compiler will optimize that away

#285

Post by ric2b » Mon, May 03, 2021, 6:10 PM UTC

TeMPOraL wrote: post #206

beagle3 wrote: post #45

Earlier quoted context omitted.

> 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 - and I think it is not a coincidence that OO popularity exploded together with the the coming-of-age of GUIs. Yeah, and I think the reason has nothing to do with objects per se. I've recently been coming to conclusion that the one thing that makes OOP last is that it's neatly packaging an important feature that other programming paradigms strug…

> But say I want to change the system so that, in some cases, it calls Baz instead of Bar - but I don't want to rip the system apart and change every call site. With OOP, I just make a class Quux inheriting from Foo, have it override Bar(stuffs) to do Baz code, and shove a Quux object into the system. Done. Dynamic linking ensure that my new implementation gets called for Quux objects.

Functional programming does this with pattern matching, it is just as easy and avoids the dangers of sub-classing.

Re: The compiler will optimize that away

#286

Post by lostmsu » Mon, May 03, 2021, 6:45 PM UTC

Blikkentrekker wrote: post #90

gpderetta wrote: post #50

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.

Which sections of the standard are you referring to?

Re: The compiler will optimize that away

#287

Post by toast0 » Mon, May 03, 2021, 7:28 PM UTC

kaba0 wrote: post #272

edenhyacinth wrote: post #224

Earlier quoted context omitted.

The article presents the case that writing code with a specific style - OOP compared to Data Oriented - is responsible for slowing down performance. That code architecture is primarily the cause, regardless of the actual implementation, because some architectures will never work well with the compiler. I get that like the major parts of picking algorithms that are N over N^2 is always going to be more important, but…

But only a strict subset of problems are heavily data oriented. For your 3 button GUI app whether you use a tightly packed AoS, even SoA doesn’t matter over a slow linked list of pointers for that 3 element list implementation doesn’t matter. And OOP is simply not contradictory to DOD.

(Agreeing) The 3 button GUI app is much more likely to be/feel slow because the UI framework used makes it difficult to get the widgets on the screen quickly than because of data processing.

Maybe it insists on a deep heirarchy of widget inheritence as many do. Maybe the framework wants to load and configure all the possible widgets, even though the application only uses a few. Maybe theres a bunch of images loaded from disk even though they're not used. Maybe it's just the fantastic default compositing system that puts everything a frame behind adding up with everything else.

There certainly are applications where data structures matter, and time spent processing data is significant to user experience, but that's not why the whole computing experience feels slower (although maybe prettier) than 25 years ago, despite capability being so much more for most things (as pointed out in the article, ram is better than years ago, and we certainly have more of it, but ram access takes a lot more cpu cycles now)

Re: The compiler will optimize that away

#288

Post by kaba0 » Mon, May 03, 2021, 8:17 PM UTC

fiddlerwoaroof wrote: post #278

kaba0 wrote: post #277

Earlier quoted context omitted.

And didn’t render millions of polygons at 60+ fps, while having many GBs of assets like textures, so I don’t see how is it relevant. One could write those programs in a truly inefficient manner in a not too performant language and it would run without problem. Today’s computers are really fast.

The problem is that, instead of the speed of modern computers translating to perceptible performance improvements for normal users, it translates to applications that use more resources. Whether or not the new features make up for the general perceptual slowness of modern computers is a somewhat open question.

I would agree with you, but in terms of games it is simply not a great example. It may be questionable why would we want photorealistic games when 2D, visible pixels are good enough, but games are not known for being inefficient.

Re: The compiler will optimize that away

#289

Post by lowercase1 » Mon, May 03, 2021, 8:28 PM UTC

TeMPOraL wrote: post #206

beagle3 wrote: post #45

Earlier quoted context omitted.

> 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 - and I think it is not a coincidence that OO popularity exploded together with the the coming-of-age of GUIs. Yeah, and I think the reason has nothing to do with objects per se. I've recently been coming to conclusion that the one thing that makes OOP last is that it's neatly packaging an important feature that other programming paradigms strug…

The source of this capability is hidden in that you had to pass in a Foo to the call site.

If you had done similarly in the struct example by passing in the function Bar to the caller then you could achieve similar functionality by shoving in a Baz function instead.

Re: The compiler will optimize that away

#290

Post by TeMPOraL » Mon, May 03, 2021, 8:31 PM UTC

tonyarkles wrote: post #235

jayd16 wrote: post #183

Earlier quoted context omitted.

Winamp didn't stream all music in existence over the internet. How is it really comparable?

Lol arguably Winamp + Napster did :D But really, 99% of the value-add of Spotify over Winamp is stuff that happens server-side. Your Spotify client doesn’t have a database of all the songs, nor the ML models for computing recommendations. As far as playing streaming music goes, Winamp would happily play an m3u (mmmm soma.fm). Don’t get me wrong, the discovery and search features in Spotify have brought me a ton of va…

And the kicker is, the music client is a completely separate concern from a song database, or a recommendation engine.

This is actually a point in favor of directly comparing WinAMP and Spotify - the important "value-add" bits of Spotify all happen server side, so they should have exactly zero impact on client performance.