The compiler will optimize that away • Hacker News Board

Re: The compiler will optimize that away

#301

Post by chromanoid » Mon, May 03, 2021, 10:30 PM UTC

mort96 wrote: post #299

chromanoid wrote: post #247

Earlier quoted context omitted.

C++ is an issue for games. Most game engines implement a garbage collected script language (e.g. Lua, CLR, JavaScript...) to implement huge parts of game logic.

They’re not implementing game logic in those languages for performance reasons though. The question, as I interpret it, is about why C++‘s performance isn’t an issue for games. Using those languages for scripting/game logic is a trade-off where performance is sacrificed for developer productivity.

You are right. I misunderstood the question.

I thought it was about the language as efficient tool not about performance. The Unreal engine is not even using data oriented design (at least for most parts), so I was assuming C++ sufficient efficiency was out of question. I agree with your argument, that the games would probably be faster. Game object processing is probably not the most pressing issue in games regarding performance, so I guess the impact would be not that visible (when talking about the stuff that is implemented in C++ in game engines).

Re: The compiler will optimize that away

#302

Post by jupp0r » Mon, May 03, 2021, 10:52 PM UTC

toss1 wrote: post #217

jupp0r wrote: post #125

Earlier quoted context omitted.

Do you use browsers? Browser makers spend billions of dollars in engineering time making them "fast", with great results.

>"Browsers... "fast", with great results." Are you joking? I have seen progressively worse performance from even the best browsers, and page load times that should be instant often literally take minutes or never load unless I completely kill the browser process and return. The slowdown is nearly inexorable, with occasional improvements in some versions before resuming the dismal trend. Simple word processing and spr…

Maybe you should visit better websites? Try http://www.quakejs.com/

Re: The compiler will optimize that away

#303

Post by jupp0r » Mon, May 03, 2021, 10:57 PM UTC

krapp wrote: post #204

29athrowaway wrote: post #130

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.

>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. All of which are Electron apps, apart from "Webmail" which is, well, what one might call a "distributed Electron app" (a website.) Maybe, just maybe, Electron is the problem.

Spotify is not an Electron app, they are using Chromium Embedded Framework.

Re: The compiler will optimize that away

#304

Post by [deleted] » Mon, May 03, 2021, 11:08 PM UTC

dragonwriter wrote: post #120

beagle3 wrote: post #119

Earlier quoted context omitted.

I should have added "in C / C++ / C#". Everything OOP works well in Smalltalk (and most of it does in Python), but you pay dearly for that in efficiency - which is what this article as about.

> I should have added "in C / C++ / C#". The only part of my response that would have effected was the aside about Smalltalk-style “become”, not the main point about the problem being one of constructing an inheritance heirarchy based on relations of immutable entity and using it for mutable entities with mutation contracts that don’t observe the same is-a heirarchy.

[deleted]

Re: The compiler will optimize that away

#305

Post by beagle3 » Mon, May 03, 2021, 11:12 PM UTC

dragonwriter wrote: post #120

beagle3 wrote: post #119

Earlier quoted context omitted.

I should have added "in C / C++ / C#". Everything OOP works well in Smalltalk (and most of it does in Python), but you pay dearly for that in efficiency - which is what this article as about.

> I should have added "in C / C++ / C#". The only part of my response that would have effected was the aside about Smalltalk-style “become”, not the main point about the problem being one of constructing an inheritance heirarchy based on relations of immutable entity and using it for mutable entities with mutation contracts that don’t observe the same is-a heirarchy.

I agree, but that's the thing: It is non idomatic to write immutable Shape-style classes in C++. Possible, yes. Idiomatic, no.

IIRC in Stroustroup's book (the one I read a decade ago, anyway), he concludes that Rect:Square and Circle:Ellipse can not inherit from each other in either direction, and did not suggest switching to immutable everything.

Re: The compiler will optimize that away

#306

Post by kgr » Mon, May 03, 2021, 11:16 PM UTC

The article seems to claim that if we did as he says and rewrote all of our code to be data-oriented instead of object-oriented, then our code would run ~2X faster and all of our performance problems would be solved. However, I got my first 64 thread server CPU 15 years ago and my first 64 thread desktop CPU six years ago, so I could get a much larger increase by instead keeping my OO code and making it concurrent (64X > 2X). Also, if being 2X faster would make everything better, we could just wait 18 months and let Moore's law take care of the 2X savings, rather than the much longer period of time it would take to redesign our languages and rewrite all of our code.

Re: The compiler will optimize that away

#307

Post by dahart » Mon, May 03, 2021, 11:46 PM UTC

kaba0 wrote: post #292

dahart wrote: post #284

Earlier quoted context omitted.

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

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 all, allocation is basically free

No, definitely not true. You're claiming that memory allocation in a tight loop is not a bottleneck. I completely disagree, having written several high performance web apps with thousands to millions of users, the single most important performance "best practices" strategy in any tight-loop Javascript is to avoid memory allocation in the hot spot. Also true in Python, true in C++, true in every language I've ever used, and has been true for decades and is still true despite significant performance improvements in V8 and other engines. This is the whole reason there are high performance libraries in JavaScript like https://glmatrix.net/ that specifically structure the API so that the user has complete control over allocations, precisely because batching and re-using allocations is faster than not.

Re: The compiler will optimize that away

#308

Post by smusamashah » Mon, May 03, 2021, 11:58 PM UTC

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…

Character interacts with the 'world' or another local context object which contains all characters it can interact with.

Re: The compiler will optimize that away

#309

Post by 29athrowaway » Tue, May 04, 2021, 1:28 AM UTC

kaba0 wrote: post #277

29athrowaway wrote: post #151

Earlier quoted context omitted.

Similarly, SNES games were more responsive than modern games and have zero loading screens.

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.

Re: The compiler will optimize that away

#310

Post by blakehaswell » Tue, May 04, 2021, 6:37 AM UTC

xiaodai wrote: post #192

Something I genuinely don't understand "buttery smooth 3D game"s are created with C++ too but why isn't C++ an issue for games? Seems to contradict the premise which is that programming languages were designed in the past and hence not efficient for modern computers.

C++ provides programmer control over memory layout, which is something managed languages don't provide. So although C++ is an older language and it isn't designed for modern machines, it does allow you the control to make performant programs for modern machines.