Hacker News Reader

Comment by huhtenberg | Hacker News Reader

This somehow reminds me of an old gamedev trick when at the start of the development cycle you'd declare a huge static array somewhere in the code to "reserve" some memory. You'd then "rediscover" and reclaim it a year later when the game needs to ship but no longer can fit in a memory.

That is, any sort of astonishing improvements is often a sign of the original version being crappy, so it's also a red flag even if it's ultimately the good news.

View on HN

Your comment somehow reminds me how about 20 years ago me with my friend tried to came up with a stupidest possible conspiracy theory ever, and what we settled on was an idea that all possible hardware features are already implemented, and when you install a new CPU for example, it's actually just a heating element and a collection of jumpers to tell motherboard to adjust a performance of the real CPU hidden in it accordingly.

Funnily enough that seems very similar to "cpu binning" in which sections of a cpu are disabled based on stress testing so you end up with different models but the same underlaying hardware.

So of course a pointy-haired boss found out about it and you end up with stupid stuff like this: https://en.m.wikipedia.org/wiki/Intel_Upgrade_Service

Well, your conspiracy was somewhat true for AMD PHENOM X2 550, a 2-core cpu which was the same as the 4-core model, but had 2 cores deactivated. Users were able to unlock the cores with BIOS tricks (and some future mobos would do it automatically though it depended on the quality of the chip. AMD even played along and released an optimized for overclocking version (since users had to bump voltage to unlock the cores in the first place)).

But also the user you are quoting, the "gamedev trick" is actually somewhat of a true story as well. But it wasn't an optimization trick. It was just different teams that each acted as if they are working on the most important thing, competing for limited old-hardware resources! Some coders, pre-version control, would just pre-allocate ram even if they didn't really need it, just so they don't have to go through the dance of asking other teams to release some. As you can imagine, when the project ended up going beyond the hardware limits causing chaos and stress to the devs, those people would descend as heroes and say "Here I was able to free 512kb!" (from their unnecessary preallocation calls)

Ah, to be old on the internet... :)

I've heard the same conspiracy theory doing the rounds, that CPUs can in fact be much faster already than they really are (like, generations ahead), but because They want to make money they're intentionally slowing things down with incremental releases.

Joke's on them, software gets slower faster than hardware gets faster.

this wasn't that far off. for a while you could upgrade celeron to pentium soldering a connection, the r5 are r7 with cores disabled, the athlon II did the same but was easier to unlock as the extra core are turned off not from yeld but to follow market demand.

Or unlock a processor to be able to overclock it by using a pencil

https://forum.overclock3d.net/showthread.php?t=3671

I unlocked an Athlon in 2000 using pencil graphite and used it to heat my apartment all winter long.

> That is, any sort of astonishing improvements is often a sign of the original version being crappy, so it's also a red flag even if it's ultimately the good news.

Actually, I'd argue they are fixing other people's mistakes with some of this.

A great example are the changes around devirtualization and/or removing certain branches, be it in the code level or at the CLR (.NET VM) level. 5-10 years ago, these changes would likely provide far less benefit, possibly not even worth the effort.

But thanks to Spectre/Meltdown/etc, getting rid of such things (especially near the IO layer) has become more important.

In this case, it's rather that consistent work toward transformative goals has unlocked optimisations that have been deliberately and consciously been worked towards for the last several years and versions.

> That is, any sort of astonishing improvements is often a sign of the original version being crappy, so it's also a red flag even if it's ultimately the good news.

How is it a red flag? I don't quite understand your comment.

He's assuming that one of the most widely used runtimes in the world had easy optimizations to do, about 20 years after it was first launched.

Something like: a Microsoft programmer uncommented

// PERFORMANCE_MODE = true

to make .NET fast.

His comment is just silly :-)

> assuming that one of the most widely used runtimes in the world had easy optimizations to do, about 20 years after it was first launched.

Perhaps not trivial, but it did have easy optimizations - within hours of it being open sourced, external people who had not worked on the codebase were making pull requests with straightforward (and in some cases substantial) optimizations. Matt Warren (author of Benchmark.NET) has tracked many of these.

When Microsoft worked on the .net framework. Performance was not a metric they used. The only performance goal they had was basically “it can’t be slower than it is now”. So performance can’t regress.

Since open sourcing performance is one of the goals in mind. And it shows.

Yeah, but those happen in any code base. You can always find improvements, sometimes changes that seem trivial in hindsight. That doesn't make the original code base crap :-)

Yup - absolutely agree. Being open source and accepting contributions means that people can spend time on bits which otherwise will not get prioritised.

I think the author of the comment is saying that existence of low hanging fruits is evidence that people haven't gone out to pick fruit in a while. Where picking fruit really means "improving quality", and low hanging fruit means "quality issues".

I don't think I agree with this, but hopefully that makes it more clear what was meant.

Having followed the process and lots of improvements in .NET over the past year or so, there's not that many low-hanging fruit anymore and definitely not the kind where a quick 5-minute change brings considerable gains. Some of the things that have happened are reducing allocations aggressively, which _can_ a quick change by using newer language features where applicable, but a lot also have been things like vectorizing algorithms or adding additional optimizations either in the JIT or in other code that's generated (regular expressions). Those are rarely trivial.

It's more like there's been a few hundred small individual improvements and those provide a lot of improvement in total.

The term is speed-up loop[1].

[1] https://thedailywtf.com/articles/The-Speedup-Loop

> That is, any sort of astonishing improvements is often a sign of the original version being crappy, so it's also a red flag even if it's ultimately the good news.

That's a question that can't be answered by comparing one version of .Net to another version. Instead we'd need to compare the performance of .Net to a rival system like the JVM. edit Or rather, a JVM.

How?

Reply on news.ycombinator.com