←back to thread

837 points turrini | 1 comments | | HN request time: 1.73s | source
Show context
titzer ◴[] No.43971962[source]
I like to point out that since ~1980, computing power has increased about 1000X.

If dynamic array bounds checking cost 5% (narrator: it is far less than that), and we turned it on everywhere, we could have computers that are just a mere 950X faster.

If you went back in time to 1980 and offered the following choice:

I'll give you a computer that runs 950X faster and doesn't have a huge class of memory safety vulnerabilities, and you can debug your programs orders of magnitude more easily, or you can have a computer that runs 1000X faster and software will be just as buggy, or worse, and debugging will be even more of a nightmare.

People would have their minds blown at 950X. You wouldn't even have to offer 1000X. But guess what we chose...

Personally I think the 1000Xers kinda ruined things for the rest of us.

replies(20): >>43971976 #>>43971990 #>>43972050 #>>43972107 #>>43972135 #>>43972158 #>>43972246 #>>43972469 #>>43972619 #>>43972675 #>>43972888 #>>43972915 #>>43973104 #>>43973584 #>>43973716 #>>43974422 #>>43976383 #>>43977351 #>>43978286 #>>43978303 #
_aavaa_ ◴[] No.43972050[source]
Except we've squandered that 1000x not on bounds checking but on countless layers of abstractions and inefficiency.
replies(6): >>43972103 #>>43972130 #>>43972215 #>>43974876 #>>43976159 #>>43983438 #
Gigachad ◴[] No.43972215[source]
Am I taking crazy pills or are programs not nearly as slow as HN comments make them out to be? Almost everything loads instantly on my 2021 MacBook and 2020 iPhone. Every program is incredibly responsive. 5 year old mobile CPUs load modern SPA web apps with no problems.

The only thing I can think of that’s slow is Autodesk Fusion starting up. Not really sure how they made that so bad but everything else seems super snappy.

replies(40): >>43972245 #>>43972248 #>>43972259 #>>43972269 #>>43972273 #>>43972292 #>>43972294 #>>43972349 #>>43972354 #>>43972450 #>>43972466 #>>43972520 #>>43972548 #>>43972605 #>>43972640 #>>43972676 #>>43972867 #>>43972937 #>>43973040 #>>43973065 #>>43973220 #>>43973431 #>>43973492 #>>43973705 #>>43973897 #>>43974192 #>>43974413 #>>43975741 #>>43975999 #>>43976270 #>>43976554 #>>43978315 #>>43978579 #>>43981119 #>>43981143 #>>43981157 #>>43981178 #>>43981196 #>>43983337 #>>43984465 #
sorcerer-mar ◴[] No.43972248[source]
I think it's a very theoretical argument: we could of course theoretically make everything even faster. It's nowhere near the most optimal use of the available hardware. All we'd have to give up is squishy hard-to-measure things like "feature sets" and "engineering velocity."
replies(2): >>43973093 #>>43973523 #
CyberDildonics ◴[] No.43973523[source]
we could of course theoretically make everything even faster. It's nowhere near the most optimal use of the available hardware. All we'd have to give up is squishy hard-to-measure things like "feature sets" and "engineering velocity."

Says who? Who are these experienced people that know how to write fast software that think it is such a huge sacrifice?

The reality is that people who say things like this don't actually know much about writing fast software because it really isn't that difficult. You just can't grab electron and the lastest javascript react framework craze.

These kinds of myths get perpetuated by people who repeat it without having experienced the side of just writing native software. I think mostly it is people rationalizing not learning C++ and sticking to javascript or python because that's what they learned first.

replies(2): >>43973895 #>>43975467 #
sorcerer-mar ◴[] No.43973895[source]
> These kinds of myths get perpetuated by people who repeat it without having experienced the side of just writing native software. I think mostly it is people rationalizing not learning assembly and sticking to C++ or PERL because that's what they learned first.

Why stop at C++? Is that what you happen to be comfortable with? Couldn't you create even faster software if you went down another level? Why don't you?

replies(2): >>43974060 #>>44001898 #
const_cast ◴[] No.44001898[source]
> Couldn't you create even faster software if you went down another level? Why don't you?

No, actually, C++ is pretty much as low as you can go.

Well, I mean, you can go lower but you're not going to get performance benefits. You could go down to C. But C is going to be more of the same or, more likely, slower. You're going to be swapping Templates for things like void *.

You could go to assembly, but let's be honest - who can write better assembly than a C++ compiler?

replies(1): >>44004851 #
1. sorcerer-mar ◴[] No.44004851[source]
> You could go to assembly, but let's be honest - who can write better assembly than a C++ compiler?

In other words, yes you can eek out more performance at lower levels. Then again at the silicon level. No, it's not worth it in 99.9999% of scenarios (because there are tradeoffs).