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

291–300 of 329 posts

Re: The compiler will optimize that away

#291

Post by GuB-42 »

8note wrote: post #159
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…

Most performance concerns that I run into are related to advertisements that need to load. The business model isn't right for performant experiences

Faster = more ad revenue. If your app/site is too slow, people will stop using it and won't see your ads. Also, search engines will detect that and downrank you, meaning even less ad impressions. It has been studied many times, and yet, developers don't do it.

Simply, performance is expensive and for most businesses, the additional revenue is not worth the additional expense.

Re: The compiler will optimize that away

#292

Post by kaba0 »

dahart wrote: post #284
kaba0 wrote: post #279

Earlier quoted context omitted.

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 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 the JVM most definitely doesn’t do that, and I’m sure other state-of-the-art GCs neither, like V8.

First of all, allocation is basically free, much faster than malloc and friends. It’s only a pointer bump. And the cost of deallocation is amortized/may not even happen. With plenty of memory available, GC doesn’t really happen, and for long-lived objects in case of a generational GC, they may not necessarily get checked at all after a time.

So the usual linked list gets appended a few times is close to optimal, iteration has the same cost as in lower level languages with pointer chasing (usually a bit more because objects usually have headers that take quite some space, less of them potentially fitting into cache). It even has some advantage in that a modern compacting GC may move the objects close to each other.

Re: The compiler will optimize that away

#293

Post by kaba0 »

mort96 wrote: post #211
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.

If you use C++ in the "default" object-oriented way, your program won't be as efficient as it could've been. Computers are fast, so you can still make games which run well, but not as well as they could've been. C++ can also be used in ways which are really fast on modern machines. You can, for example, write code in a data-oriented "struct of arrays" approach with C++. The argument is just that C++ isn't designed wi…

> If you use C++ in the "default" object-oriented way, your program won't be as efficient as it could've been

That’s way too general to hold any truth. C++’s classes are zero cost, SoA vs AoS is not always relevant. If I have three instances of my class, each doing something compute-intensive in a simple method, how is it different to dod?

Also, even virtual functions are not necessarily any more expensive than the alternative if one knows what he/she does.

Re: The compiler will optimize that away

#294

Post by CyberDildonics »

astrange wrote: post #275
CyberDildonics wrote: post #257

Earlier quoted context omitted.

This reads like a reply to a different comment. The person above was saying there haven't been any advancements in CPUs or GPUs which is obviously not true. No one said anything about battery powered devices and even those have had multiple cores for many years now - as a result of transistors still shrinking.

They're multicore devices but often only one core is free. Depending on how important you are, the rest are busy doing other things and you're not going to get scheduled.

This thread was someone saying there haven't been any advances in CPUs and GPUs in general.

You seem to be in a completely different goal post shifting context of some mythical mobile device that has only one core, but actually has multiple cores, but all them are pegged at 100% all the time. This doesn't make any sense in any context since it isn't even true, but it has nothing to do with what you are replying to.

Re: The compiler will optimize that away

#295

Post by kaba0 »

toast0 wrote: post #287
kaba0 wrote: post #272

Earlier quoted context omitted.

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

I am torn on the issue. On one hand, there is definitely useless technical debt, over-abstraction, no longer useful features slowing down our programs. But at the other hand, we are actually handling every language on Earth properly (or at least we very well should already), instead of just saying that yeah ascii is good enough, somewhat care about accessibility though far from enough, etc.

Also, actual native GUI apps are quite fast imo. Only electron apps are slow, but I really do think that it is mostly due to the web having a wrong abstraction for GUIs, not due to other reasons (of course there are shitty web apps, as well as shitty programs everywhere else)

Re: The compiler will optimize that away

#296

Post by TeMPOraL »

lowercase1 wrote: post #289
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…

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.

Yeah, but that's the thing: in case of dynamic dispatch in OOP, the function is tied to the argument you're passing. In a typical OOP language, your object carries an extra pointer that's hidden from your view - a pointer to a table of pointers to functions, specific for that object's class. Dynamic dispatch goes through that pointer on the object.

Doing what you describe with a struct would require at least keeping explicit function pointers on the structure; the OOP mechanism described above is a generalization of that.

(There are other, neater approach too, allowing late binding dispatched on the types of more than one argument - see e.g. methods in Common Lisp.)

Re: The compiler will optimize that away

#297

Post by desperate »

jupp0r wrote: 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…

Slightly off topic but I just realized that not only does optimized code = less processor cycles but less cycles = less power used.

This brings two rhetorical questions, How much more effective compute would we have if all code running today were perfectly optimized, and how much less energy would be needed under the same circumstances?

The computer gains could only be used in networks where unused compute can be scheduled / sold to other tasks. The energy gains could only be reaped if processors had proper low power modes they could fall into or some other method of conservation.

Re: The compiler will optimize that away

#298

Post by mort96 »

kaba0 wrote: post #293
mort96 wrote: post #211

Earlier quoted context omitted.

If you use C++ in the "default" object-oriented way, your program won't be as efficient as it could've been. Computers are fast, so you can still make games which run well, but not as well as they could've been. C++ can also be used in ways which are really fast on modern machines. You can, for example, write code in a data-oriented "struct of arrays" approach with C++. The argument is just that C++ isn't designed wi…

> If you use C++ in the "default" object-oriented way, your program won't be as efficient as it could've been That’s way too general to hold any truth. C++’s classes are zero cost, SoA vs AoS is not always relevant. If I have three instances of my class, each doing something compute-intensive in a simple method, how is it different to dod? Also, even virtual functions are not necessarily any more expensive than the a…

The context of the discussion is one where the difference between SoA and AoS is significant. It’s not always true in general that your program won’t be as efficient as possible, but it’s true in the context we’re discussing, where you have a lot of things (entities or whatever) and you’re iterating through them, which is what is being discussed.

I was writing a direct answer to the question of “how can it be true that C++ isn’t built for modern machines even though modern games with good performance on modern machines use C++”. I think the answer is entirely correct in context.

Re: The compiler will optimize that away

#299

Post by mort96 »

chromanoid wrote: post #247
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++ 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.

Re: The compiler will optimize that away

#300

Post by kaba0 »

mort96 wrote: post #298
kaba0 wrote: post #293

Earlier quoted context omitted.

> If you use C++ in the "default" object-oriented way, your program won't be as efficient as it could've been That’s way too general to hold any truth. C++’s classes are zero cost, SoA vs AoS is not always relevant. If I have three instances of my class, each doing something compute-intensive in a simple method, how is it different to dod? Also, even virtual functions are not necessarily any more expensive than the a…

The context of the discussion is one where the difference between SoA and AoS is significant. It’s not always true in general that your program won’t be as efficient as possible, but it’s true in the context we’re discussing, where you have a lot of things (entities or whatever) and you’re iterating through them, which is what is being discussed. I was writing a direct answer to the question of “how can it be true th…

Fair enough, sorry I misunderstood your point.
Post reply on HN