Hacker News Reader

Comment by Karrot_Kream | Hacker News Reader

I'm normally a fan of Dan Luu's posts but I felt this one missed the mark. The LCP/CPU table is a good one, but from there the article turns into a bit on armchair psychology. From some random comments coming from Discourse's founder, readers are asked to build up an idea of what attitudes software engineers supposedly have. Even Knuth gets dragged into the mud based on comments he made about single vs multi-core performance and comments about the Itanium (which is a long standing point of academic contention.)

This article just felt too soft, too couched in internet fights, to really stand up.

View on HN

> readers are asked to build up an idea of what attitudes software engineers supposedly have.

But they do, don't they. Discourse's founder's words are just very illustrative. Have you used the web recently? I have. It's bloated beyond any imagination to the point that Google now says that 2.4 seconds to Largest Contentful Paint is fast now: https://blog.chromium.org/2020/05/the-science-behind-web-vit... (this is from 4 years ago, it's probably worse now).

You don't have to go far to see either Youtube loading 2.5 megabytes of CSS on desktop to the founder of Vercel boasting its super fast sites that take 20 seconds to load the moment you throttle it just a tiny bit: https://x.com/dmitriid/status/1735338533303259571

You're making the same mistake the post did. It depends on the reader already having sympathy for the idea that bloat is bad in order to make its case. I can read nerd site comments all day that lament bloat. For an article to stand on its own on this point it has to make the case to people who don't already believe this.

Dan's articles have usually been very good at that. The keyboard latency one for example makes few assumptions and mostly relies on data to tell its story. My point is that this article is different. It's an elevated rant. It relies on an audience that already agrees to land its point, hence my criticism that it's too couched in internet fights.

State your case that bloat is good. I currently have a client who will do literally anything except delete a single javascript library so I'd like to understand them better.

Joel Spolsky on Excel bloat, 2001: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

The latest version of Excel loads faster on my laptop than most websites do. I’ve timed this.

I can load the entire MS Office suite and open a Visual Studio 2022 project in less time then it takes to open a blank Jira web form.

What’s your point?

My point is to reply to "State your case that bloat is good" with a famous blog stating a case that bloat is good. Bloat makes the company more money by allowing them to develop and ship faster, bloat makes the company more money by being able to offer more features to more customers (including the advertisers and marketers and etc. side of things), and - well, read the article.

I, too, dislike slow websites and web apps, but I don't think they are some mystery - natural selection isn't selecting for idiot developers, market selection is selecting for tickbox features and with first-mover-advantage they are selecting against "fast but not available for another year and has fewer features and cost more to develop".

Due to prevalence of native apps in the macOS world, the difference are often stark. I use Things and Bear, and it’s fast, then try to load gmail (dump account, so it’s not in Mail) and it’s so slow. Youtube too. Fastmail, in comparison, loads like it’s on localhost.

You block JavaScript and the amount of sites that is broken is ridiculous, some you would not expect (websites, not fullblown interactive apps).

The web doesn't scale like desktops - not even close.

Furthermore - this philosophy has made Windows worse and less responsive in all cases.

I understand that this "pays the bills" but my charge is (currently) to make things faster so I am against slowness.

That was 2001.

Core frequencies aren't going up at 2001 rates anymore. (And although Moore's law has continued, it is only just. Core freqs have all but topped out, it feels like.) Memory prices seem to have stalled, and even non-volatile storage feels like it's stalled.

My computer in 1998, compared to it's predecessor, storage was going up in size at ~43% YoY. It was an amazing time to be alive; the 128 MiB thumbdrive I bought the next decade is laughable now, but it was an upgrade from a 1.44 "MB" diskette. Today, I'm not sure I'd put more storage in a new machine than what I put in a 2011 build. E.g., 1 TiB seems to be ~$50; cheaper, yet. Using the late 90s growth rates, it should be 17 TiB… so even though it's about half the price, we can see we've fallen off the curve.

> "And although Moore's law has continued, it is only just."

https://en.wikipedia.org/wiki/Transistor_count has a table of transistor count over time. 2001 was Intel Pentium III with 45 million transistors and nVidia NV2A GPU with 60 million. 2023 has Apple M2 Ultra with 134 billion transistors and AMD Instinct CPU with 146 billion, and AMD Aqua Vanjaram CDNA3 GPU with 153 billion. That's some ~3,000x more, about a doubling every two years.

Core frequencies aren't going up, but amount of work per clock cycle is - SIMD instructions are up, memory access and peripheral access bandwidth is up, cache sizes are up, branch predictors are better, multi-core is better.

> "E.g., 1 TiB seems to be ~$50"

You can get a 12TB HDD from NewEgg for $99.99, Joel's blog said $0.0071 per megabyte and this is $0.0000083 per megabyte, ten thousand times cheaper in 23 years. Even after switching to more expensive SSDs 1TB for $50 is $0.00005 per megabyte, a hundred times cheaper than Joel mentioned - and that switch to SSDs likely reduced the investment in HDD tech. And as you say "I'm not sure I'd put more storage in a new machine than what I put in a 2011 build" few people need more storage unless they are video or gaming enthusiasts, or companies.

> has a table of transistor count over time

My comment explicitly notes this, and that I am not debating that transistor counts have continued to follow Moore's Law. They have. That's not the point.

> Core frequencies aren't going up, but amount of work per clock cycle is

[Citation needed]; this absolutely doesn't match my experience at all.

> You can get a 12TB HDD from NewEgg for $99.99

I looked at NewEgg specifically before I made that comment. (But for the pricing for 1 TiB, as that was comparable.) 12 TiB runs $250–400, with the absolute lowest priced¹ 12 TiB (internal desktop form factor) HDD being $201. So no, you cannot.

¹and the "features" of this "12 TB" HDD include "14TB per drive for 40% more petabytes per rack" (wat) "Highest 14TB hard drive performance" (wat)

The reason we have bloat is it's easier to satisfy stakeholders if you don't give a damn. There's really no reason to discuss this at all once you realize this.

But of course, ranting and reading rants is satisfying in its own right. What's the problem?

The article you diss has actual benchmarks in it. The article I linked has actual numbers in it.

At this point you're willingly ignoring it because you dislike that this is additionally illustrated by quotes from specific people.

I think the article makes a pretty good case for bloat being bad for low-end users actually. His analysis demonstrates how many websites become genuinely unusable on cheaper devices, not just to techie standards, but for anyone trying to actually interact with the page at all.

Usually the directive "don't worry about bloat" comes from above, or outside, the software engineering team. I'm a software engineer and I would love to fix performance problems so that everything runs Amiga smooth. But that takes time and effort to find, analyze, and fix performance issues... and once The Business sees something in more or less working order, implementing the next feature takes priority over removing bloat. "Premature optimization is the root of all evil" and that. I know that's not what Knuth meant, he meant don't be penny-wise and pound-foolish when you do optimize. But much like "GO TO considered harmful", something approaching the stupidest possible interpretation of the maxim has become the canonical interpretation.

And that's before getting into when The Business wants that sweet, sweet analytics data, or those sweet, sweet ad dollars.

> what attitudes software engineers supposedly have

I don’t think I’ve ever seen a company take performance seriously. No one scoffs when a simple API service for frontend has 500ms response time! How many engineers even know or care how much their cloud bill is?

I'm sure Google invests a lot of resources in making Google Search load fast. AFAIK they serve a specialized version for each user agent out there.

One the best counter examples to the rule. I tried running Lighthouse on a few Google services that are less prominent and had a few good laughs.

Knuth is kinda right imo - parallelism as we have it now is unused by 90% of software outside of specialist use cases and running the same single-threaded program on multiple data items.

Programming languages and hardware both offer poor support for fine-grained parallelism and it's very hard to speed up classical software using parallel approaches.

This felt more true a decade ago but there’s been a lot of improvement in both languages (e.g. Rust) and libraries - I routinely see most of the cores on my Macs fully loaded for things like working with media files which used to be single-threaded.

Languages are getting there but based on how much heartburn Rust's async causes, I still find it to be a very hard problem to give programmers a real multicore abstraction. And it starts from the ground up with operating systems designed around single core ideas.

When I first read about the multi core vs single core debate in college, I thought it was silly and that multi core would be just fine. But over the years I've developed a more nuanced view. The average user is mostly doing things that involve IO, so that makes multi core useful in that you can use multiple cores to wait for IO, but for actual computation single core performance continues to be the bottleneck.

async isn’t the only option: threading scales well and is often much easier to write and make production-ready (e.g. reasoning about peak memory usage can be hard in an async model).

> ...which is a long standing point of academic contention.

What contention? If anything, Luu is being rather generous–Knuth was just whining that the decades-long free lunch program was being cancelled.

VLIW (Itanium is a VLIW arch) is what's contentious, not multiprocessing.

OK I missed that. Thanks. But it looks like Itanium was only tangential to this discussion, in that Knuth thinks multicore programming may be an even worse mistake than Itanium.

I thought he summarised it pretty well. Jeff Atwood was only picked as example. But there are LOTS of high profile, huge followers web developments thought leaders constantly pump out similar views. And a lot of their followers just blindly accept what they were told.

Reply on news.ycombinator.com