5 ms·

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"

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.

MaxBarraclough 6y ago
> 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.
derision 6y ago
How?
reallydontask 6y ago
> 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.
- oblio 6y ago
  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 :-)
  - jen20 6y ago
    > 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.
    - oblio 6y ago
      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 :-)
      - jen20 6y ago
        Yup - absolutely agree. Being open source and accepting contributions means that people can spend time on bits which otherwise will not get prioritised.
    - philliphaydon 6y ago
      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.
- kqr 6y ago
  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.
  - ygra 6y ago
    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.
anonymfus 6y ago
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.
- maushu 6y ago
  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 https://en.m.wikipedia.org/wiki/Intel_Upgrade_Service
- LoSboccacc 6y ago
  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.
  - ktta 6y ago
    Or unlock a processor to be able to overclock it by using a pencil https://forum.overclock3d.net/showthread.php?t=3671 https://forum.overclock3d.net/showthread.php?t=3671
    - sevensor 6y ago
      I unlocked an Athlon in 2000 using pencil graphite and used it to heat my apartment all winter long.
- pantelisk 6y ago
  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... :)
mdpm 6y ago
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.
eCa 6y ago
The term is speed-up loop[1]. [1] https://thedailywtf.com/articles/The-Speedup-Loop https://thedailywtf.com/articles/The-Speedup-Loop
csharptwdec19 6y ago
> 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.

MaxBarraclough 6y ago

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

derision 6y ago

How?

reallydontask 6y ago

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

oblio 6y ago
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 :-)
- jen20 6y ago
  > 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.
  - oblio 6y ago
    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 :-)
    - jen20 6y ago
      Yup - absolutely agree. Being open source and accepting contributions means that people can spend time on bits which otherwise will not get prioritised.
  - philliphaydon 6y ago
    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.
kqr 6y ago
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.
- ygra 6y ago
  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.

anonymfus 6y ago

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.

maushu 6y ago
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 https://en.m.wikipedia.org/wiki/Intel_Upgrade_Service
LoSboccacc 6y ago
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.
- ktta 6y ago
  Or unlock a processor to be able to overclock it by using a pencil https://forum.overclock3d.net/showthread.php?t=3671 https://forum.overclock3d.net/showthread.php?t=3671
  - sevensor 6y ago
    I unlocked an Athlon in 2000 using pencil graphite and used it to heat my apartment all winter long.
pantelisk 6y ago
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... :)

mdpm 6y ago

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.

eCa 6y ago

The term is speed-up loop[1]. [1] https://thedailywtf.com/articles/The-Speedup-Loop https://thedailywtf.com/articles/The-Speedup-Loop

csharptwdec19 6y ago

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