Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The compiler will optimize that away

blog.royalsloth.eu

Post reply on HN
Print view View original

311–320 of 329 posts

Re: The compiler will optimize that away

#311

Post by blakehaswell »

jolux wrote: post #117
jmull wrote: post #77

There’s a nice introduction to a data-oriented approach in here, but it’s buried in some junk. E.g., I don’t think a lot of developers believe compilers are magic optimizers. And programming languages, including the ones referenced, have changed quite a bit over the last 20 years. A strong enough case for general data-oriented features would cause at least some of them to support it. Also, a great amount of code shou…

To me, the goal of language implementations should be to make the most maintainable code also the fastest code. I shouldn't have to worry much about the performance characteristics of my software outside of general concerns about algorithmic complexity.

At the end of the day our software is going to run on real machines, sending data across real networks. I feel like we'll always be leaving performance on the table if we don't understand the characteristics of the hardware we're developing on.

I can build a cubby house in the backyard (low performance system) without understanding the the physical characteristics on the materials I'm using, but if I want to build a sky-scraper (high performance system) I need to understand the actual physical materials and how to use them effectively.

Re: The compiler will optimize that away

#312

Post by joshuamorton »

dragontamer wrote: post #268

While this article starts to discuss the low level details that underlie our code, I feel like its incomplete. * Latency hiding -- CPUs work extremely hard on latency hiding. A lot of those OOP-indirect calls will be branch predicted by the CPU in the simple cases (ex: if one object-type is more common than others, then those indirect branches will be branch predicted correctly in most situations). There are other bi…

> * Cache: L1, L2, and L3 caches can grossly mitigate a lot of the problems. While CPUs today are far faster than DDR4 RAM, L1 cache scales perfectly with the CPU. If you can keep your code+data under 64kB, you'll always be executing in L1 cache and basically get the full benefits.

I think even now you're underselling this. Depending on the types of transforms you're doing, an object-oriented (or row-oriented) instead of data-oriented (or column-oriented) approach can be faster due to caching. With OOP approaches, the object you're operating on will basically always be in L1 cache. On the other hand, if your ants name and age are in different columns and each column has 10000 things, you'll have to load both into L1 cache separately.

Stuff like vectorization can further complicate things, but it isn't' as simple as data-oriented is more performant.

Re: The compiler will optimize that away

#313

Post by kaba0 »

dahart wrote: post #307
kaba0 wrote: post #292

Earlier quoted context omitted.

I apologize for my cocky reply. I just meant to point out that SoA vs AoS or an even slower data structure is not necessarily relevant for all programs. > 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 not true though; at least…

> at least the JVM most definitely doesn’t do that, and I’m sure other state-of-the-art GCs neither, like V8. Which implementation are we talking about here? Do you mean JVM internal linked lists, or user allocations of linked list nodes? I was talking about implementations such as (first Google result for "Java linked list implementation") https://www.geeksforgeeks.org/implementing-a-linked-list-in-... > First of al…

What are the specific situation that we are talking about? Of course needless creation of non-single-use objects will have a cost, but object reuse via pools may be even worse than creating non-escaping objects in a tight loop. The “problem” with high level languages is the complexity of their runtimes - you can’t easily reason about what and how will get optimized. It can change from version to version so one should profile.

Not too familiar with JS vm internals, but OpenJDK has quite a good escape analysis.

Re: The compiler will optimize that away

#314

Post by kaba0 »

29athrowaway wrote: post #309
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.

Yet many of the games were more entertaining than many games today.

That’s completely orthogonal.

Re: The compiler will optimize that away

#315

Post by beagle3 »

ric2b wrote: post #285
TeMPOraL wrote: post #206

Earlier quoted context omitted.

> 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 thi…

There’s another side, which is that from a source code management perspective, modern pattern matching forces you to group implementation by operation (to get all the benefits), modern OO let’s you group by “class”.

There’s no right or wrong answer here. For GUIs, it appears grouping by class is more effective. But many other times, it’s not.

Re: The compiler will optimize that away

#316

Post by selfhoster11 »

goatinaboat wrote: post #245
selfhoster11 wrote: post #222

Earlier quoted context omitted.

> I dont know if you've noticed, but most programmers actually do care about performances. They just are bad at it. I disagree. Programmers may care about performance, but project managers certainly don't and they always have the final say.

Programmers may care about performance, but project managers certainly don't and they always have the final say LOL no. Offer a dev choice between a framework that is trending on Twitter, vs one that is 100x faster but "legacy" (meaning more than a year old) and she'll choose the first one every time, and the project manager won't know the difference, or care if he did.

If it's good to develop with, I don't care one whit whether a software framework is 2 months old or 20 years old. Besides, not everyone works on greenfield projects and can pick what framework they want.

Re: The compiler will optimize that away

#317

Post by moonchild »

vips7L wrote: post #231
moonchild wrote: post #26

Earlier quoted context omitted.

Actually... https://arxiv.org/pdf/1902.04738.pdf On a more serious note, most c programs I see don't do very much of that, preferring to allocate fixed-size buffers on the stack. Additionally, most GC'd languages that aren't java have crappy GCs, and those GC'd languages that are java lack value types. This harms spatial locality quite a bit, and compaction can't fully compensate for that. They are working on adding…

Doesn't D have value types via structs since by default they're stack allocated and copied? Though I'm not sure how well it's GC performs when you do allocate on the heap.

Oh yes, plenty of GCed languages have value types. But they're not java and their GCs are garbage. D's is particularly bad, probably 30 years out of date.

Re: The compiler will optimize that away

#318

Post by divs1210 »

BlueTemplar wrote: post #193
divs1210 wrote: post #69

Earlier quoted context omitted.

> The other thing for which OO works much better than plain data is GUIs This cannot be further from my experience. Switching from Java/AWT/Swing to ClojureScript/Reagent/Re-frame has been suoer liberating. Every GUI programmer must fiddle with reagent once: https://reagent-project.github.io/

But you're super limited if you're trying to make a GUI inside a browser, how is this a good example ?

The same technique can be used outside the browser with Clojure + JavaFX [0] and even at the terminal [1]!

[0] https://github.com/cljfx/cljfx

[1] https://github.com/eccentric-j/cljs-tui-template

Re: The compiler will optimize that away

#319

Post by prionassembly »

beagle3 wrote: post #45
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…

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

I have a word for you:

https://plato.stanford.edu/entries/mereology/

Re: The compiler will optimize that away

#320

Post by pwdisswordfish8 »

toss1 wrote: post #269
pwdisswordfish8 wrote: post #230

Earlier quoted context omitted.

> Are you joking? I have seen progressively worse performance from even the best browsers Where is the evidence that you're seeing poor performance from the browser itself and that the source of the problem does not lie in the difference between what the server is sending down the tubes today compared to what it was sending 10 years ago?

I agree that what the server is 'sending down the tubes' is a huge part of the problem. But this is the root cause we're discussing - programmers selecting tools for their convenience (and worse yet, cool factor), instead of FIRST considering the responsiveness of the system as they design and code. Optimization as an afterthought is about as good as security as an afterthought - anything from a complete waste of tim…

> this is the root cause we're discussing

It's not. Someone explained that browser makers spend billions on top talent to make browsers fast, and you posted a flippant comment — "are you joking?" — about your observations that performance of browsers is getting worse.

Now you're talking about stuff that web developers do on the pages that you visit.

Browsers are an example of software that is fast because companies have put effort into making them that way, instead of not caring. That's the claim made by the person you responded to. Dispute it, if you want, but don't make claims and then change the subject or shut down inquiry into the things that you're saying.

Post reply on HN