Live data from Hacker News

The compiler will optimize that away

blog.royalsloth.eu

221–230 of 329 posts

Re: The compiler will optimize that away

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

This attitude is very common and has clearly degraded software development particularly for users, and like most issues afflicting modern software it's not perceived by developers so it "doesn't exist" to them. As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about."

I have news for you, all code is difficult to reason about at some level. Sure, certain abstracts can be easier to reason about than others if you take certain examples that I can generally argue are reductionist, but any reasonably well developed piece of code (read, actual useful code) will require a certain level of sophistication and complexity that will eventually make it difficult to reason about.

I know this is a reach and a bit of a red-herring, but developers really really need to remember the allergy to "code being difficult to reason about" is a sometimes a useful intuition or heuristic to use, the heuristic being "easier to reason about is better," but it really is a heuristic at the end of the day. Abuse of this heuristic is often a motive behind all sorts of detrimental behaviors in tech, reinventing the wheel and NIH (I didn't write, it, so it's difficult to reason about!), rewrites from scratch (our "technical debt" is now hard to reason about, let's rewrite from scratch!) and the problem OP refers to (a solution that maps to the machine better is hard to reason about, let's use this less efficient solution instead!). And a big problem here is that these issues are often not issues to hackers because it just means more programming for them which they love! It just hurts users and customers.

Re: The compiler will optimize that away

#222

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…

I dont know if you've noticed, but most programmers actually do care about performances. They just are bad at it. Software are slow precisely because programmers dont get it: optimising all the code will make slow software. They spend their budget optimising 99% of the code and end up with no more money to make that last 1% fast. For real (game engine programmer speaking). Plus optimising all the code make all the co…

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

Re: The compiler will optimize that away

#223

Earlier quoted context omitted.

Related: when MacBooks switched to SSDs, the performance of my old spinning-disk MBP dropped noticeably basically overnight.

Same thing on Windows. It became incredibly slow on HDDs when SSDs started to become popular.

When I first bought an SSD and noticed the crazy speed-up, my next thought was that developers will get used to it as the "new normal" and stop caring about IOPS which would slow down SSDs (ruining my blink-of-an-eye super-speed fun) and make HDDs near-unusable. Two to four years later, here we were on Windows, and to some extent, on Linux too.

Re: The compiler will optimize that away

#224
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. 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. 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 it doesn't seem like the article is disagreeing with you at all, just another area where people need to consider their decisions.

Re: The compiler will optimize that away

#225
post #180

The real answer is you almost never need to solve this silly problem. If your data is static, why are you counting through arrays? If its dynamic, your n is probably low enough it doesn't matter or you're using some better data structure than an array. If you do hit this kind of problem its usually in games (lots of dynamic user generated content) and even then the n is usually negligible. The parts where this does m…

Would have to agree, common data structures like linked lists and maps can't really be easily composed into this sort of sequential layout as required, and the main advantages only come about when you're searching through the data for something.

The other data we process a lot of is strings which are commonly variable in length and scattered around in separate mem allocations.

Still, the performance difference between the 2 examples was eye-opening so I'll definitely spend a bit of time looking at Data-Oriented Design book for some ideas.

Re: The compiler will optimize that away

#226
post #148

Earlier quoted context omitted.

Windows Server 2019 has a much snappier UI then Windows 10 I've found (I recently spent a ton of time automating installs for both and boy did that become noticeable). Then you look at the Windows 10 list of crapware and it becomes a lot clearer.

Windows 10 is an abomination. It’s incredible how much grief Windows Vista got in comparison.

Vista was a worse abomination on 2 GB of RAM. It's likely that if I installed a build of Windows 10 from 2 years ago on the machine in question, it would be faster than a greased lightning in comparison.

Re: The compiler will optimize that away

#227
post #200
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.

It really did not for me by that standard. I have access to orders of magnitude more music now that I know I like than I did during the Winamp days and I was a pretty early and savvy user back then so I had more access than a lot of people.

If we're trading music player performance for the massive increase in availability I'll make that trade.

Re: The compiler will optimize that away

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

This attitude is very common and has clearly degraded software development particularly for users, and like most issues afflicting modern software it's not perceived by developers so it "doesn't exist" to them. As the top reply to this mentioned, anyone can easily tell how much slower software is today even when computers and devices are so fast now! All in the name of "making code easy to reason about." I have news…

I think other users in here are more on the right track about where the blame for this lies.

As you alluded to, a lot of programmers are happy to tweak and refine for ages so it's probably not that.

Is it just that programmers are lazy or need to care more or be better educated about optimization?

Honestly I really doubt it. I fully agree with the other takes that companies have incentives to ship working software quickly. Features sell subscriptions not performance. If it comes down to choosing between functionality and performance leaders will ship the slow feature every time.

I'm not even sure they're necessarily wrong most of the time. If you know where to look the internet is a graveyard of carefully engineered products that were beat to market and obliterated by three people with a shitty electron app.

Re: The compiler will optimize that away

#229

Earlier quoted context omitted.

> Sure developer time costs, but this cannot actually be the reason. It totally is because we've abstracted the cost of software engineering unto the hardware. Back in the 90s, people had to basically beg for memory when writing software while modern development is built on the theory of getting the fastest delivery speed at the cost of performance. We outsource the cost of software unto millions of customer's hardwa…

The point stands anyway. Why are all my dev tools super slow? If my time is important, shouldn’t those be fast and heavily optimized? And don’t try to tell me that 4 billion cycles a second across 16 cores operating on in-memory contiguous values isn’t enough to update a watch window more than 1 time per second.

> Why are all my dev tools super slow? If my time is important,

Quantify important into how much you spend on your tooling.

Aside from some key bits of development software at the IC / board layout, almost everything a software developer needs is free, open source or cheap. Noone pays $1000 for an IDE anymore.

Re: The compiler will optimize that away

#230
post #217
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…

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

Post reply on HN