Hacker News Reader

Comment by gnuvince | Hacker News Reader

That line of reasoning reminds me of the fabled sufficiently smart compiler: one day, the sufficiently smart compiler will understand what we mean in our programs and generate code that is faster than what an expert could write in C or even assembly. Unfortunately, the sufficiently smart compiler still hasn't arrived.

And similarly, the performance potential of SwiftUI has not been unlocked. Maybe it will happen, but while we wait for the SwiftUI to implement those fabled optimizations, developers have to wrestle with—from what I gather from the article—a lot of extra accidental complexity so that they don't impose an unusably slow interface to their users.

View on HN

This is a fair point, but from what I've seen from Swift UI these optimisations are already happening.

Lists used to be backed by UITableViews in all contexts I believe. Now, if I remember rightly, they are backed by a mix of UICollectionView and raw combinations of views depending on various factors like the number of elements or whether that number changes.

These sorts of changes didn't go super smoothly, I think iOS 13.0 was the first one with SwiftUI, then 13.3 changed a lot of the under the hood details and broke some things (we had 13.2/3 specific hacks), but since iOS 14 things have been much more stable and there have been fewer breakages.

Optimizations have been happening in compilers for years, but they've never come close to the "sufficiently smart compiler" ideal.

IOW, you need more than an observation that optimization is happening.

> one day, the sufficiently smart compiler will understand what we mean in our programs and generate code that is faster than what an expert could write in C or even assembly.

Who is making this argument? Pretty sure I’ve heard most compilers (and transpilers maybe) will do a better job of the low level stuff than your average dev, but AFAIK no one notable is arguing a true expert couldn’t squeeze out some additional performance using say Assembly if and when it’s sensible to do so.

> That line of reasoning reminds me of the fabled sufficiently smart compiler: one day, the sufficiently smart compiler will understand what we mean in our programs and generate code that is faster than what an expert could write in C or even assembly. Unfortunately, the sufficiently smart compiler still hasn't arrived.

Hasn't it? Less and less gets written in C these days, even e.g. HFT or game engines tend to use higher-level languages.

It hasn't. It's possible for programmers to get massive speedups by re-architecting their code to make better use of the CPU caches or avoid branch mispredictions and that happens because the compiler was not sufficiently smart to do that transformation itself.

> It's possible for programmers to get massive speedups by re-architecting their code to make better use of the CPU caches or avoid branch mispredictions

Sure, but they can, and do, do that just as well in Java as they could in C or assembly.

Reply on news.ycombinator.com