The compiler will optimize that away • Hacker News Board

Re: The compiler will optimize that away

#271

Post by kaba0 » Mon, May 03, 2021, 4:54 PM UTC

esailija wrote: post #87

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…

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 that everything would be slow. Yeah, there are websites with so many JS bloat that they can make the fans start up in my laptop, but otherwise, your computer does a shitton of things, most of which is essential complexity.

To-the-point software is actually really fast, like gcc/clang does tons of optimizations compared to what compilers did a few decades ago, and I doubt you could realistically optimize it by a significant percentage in the general case. Same for databases. Browsers themselves are also pushing the boundaries of hardware, they can display static HTML/CSS ridiculously fast even though it is not ideal for layouting. Pretty much only the top of the abstractions “suck” sometimes, but there are really fast JS apps as well.

Re: The compiler will optimize that away

#272

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

edenhyacinth wrote: post #224

toast0 wrote: post #161

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

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.

Re: The compiler will optimize that away

#273

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

kleiba wrote: post #200

jayd16 wrote: post #183

Earlier quoted context omitted.

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

It's comparable only on an abstract level - mostly because there's hardly anybody who really wants/needs "all music in existence over the internet", most people just want to "listen to music that I like". On that level, Winamp did the job just fine.

Is that why everyone uses a streaming service and no one collects music any more?

Re: The compiler will optimize that away

#274

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

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…

But the browser itself is plenty fast. Just open a huge static HTML file, or some well-optimized JS one like some simulation.

The problem is some websites

Re: The compiler will optimize that away

#275

Post by astrange » Mon, May 03, 2021, 5:11 PM UTC

CyberDildonics wrote: post #257

astrange wrote: post #158

Earlier quoted context omitted.

If you only have a single core (common on battery powered devices) then you should only run a single thread. Excess parallelism doesn't make things go faster and uses more memory. The important thing is avoiding unnecessary waits on non-CPU resources like I/O.

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.

Re: The compiler will optimize that away

#276

Post by jakear » Mon, May 03, 2021, 5:12 PM UTC

Article seems to suppose the entities will only ever exist in one collection. If that’s the case then sure remap the field layouts to behave better in cache. But the second you want to reference only a single element of that collection, or reference many elements of many different collections, you’re now dealing with managing N pointers for N fields, which of course all get invalidated when the collection is modified, and ha w lifetimes tied to the lifetime of the collection. As opposed to the single object with its own lifetime. And of course all the cache locality arguments go out the window.

The takeaway seems to be: if the entity in an atomic collection of items, represent that collection as the entity in as efficient manner as you see fit, rather than crating entities for each one. This makes sense, and is not out-of-line with OOP reasoning: each object corresponds to an atomic logical unit.

Re: The compiler will optimize that away

#277

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

29athrowaway wrote: post #151

fiddlerwoaroof wrote: post #136

Earlier quoted context omitted.

Yeah, this is the weirdest thing to me: Windows NT 3.51 on a Pentium was much snappier perceptibly than even my new M1 MBP (developers are already expanding to the new performance envelope).

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.

Re: The compiler will optimize that away

#278

Post by fiddlerwoaroof » Mon, May 03, 2021, 5:20 PM 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.

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.

Re: The compiler will optimize that away

#279

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

dahart wrote: post #254

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…

> 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 matter if you are not in a hot loop and iterate slowly over 3 elements.

Re: The compiler will optimize that away

#280

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

slifin wrote: post #58

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…

OO is a tree and html (UI) on a page is a tree The problem is when you want to go to page two and want to display the same data as page 1 but in a different configuration OO is suddenly terrible because the data is the wrong shape, you should hold your data as a graph then derive trees out of it to satisfy views OO is not good for UIs unless you have one page and the contents on that page is static and doesn't change…

OO can be a tree, as well as pretty arbitrary graphs. As has been said for over a decade, prefer composition over inheritance. There are cases where inheritance is really cool, but the main point of OOP is encapsulation. It can enforce class invariants.