Live data from Hacker News

The computers are fast, but you don't know it

shvbsle.in

51–60 of 819 posts

Re: The computers are fast, but you don't know it

#52

NIM NIM should be part of the conversation. Typically, people trade slower compute time for faster development time. With NIM, you don’t need to make that trade-off. It allows you to develop in a high-level but get C like performance. I’m surprise its not more widely used.

It's written Nim, not NIM.

Re: The computers are fast, but you don't know it

#53
post #6

I've been lightly banging the drum the last few years that a lot of programmers don't seem to understand how fast computers are, and often ship code that is just miserably slower than it needs to be, like the code in this article, because they simply don't realize that their code ought to be much, much faster. There's still a lot of very early-2000s ideas of how fast computers are floating around. I've wondered how m…

I upgraded a desktop machine the last time I visited my family. It was a Windows 7 computer that was at least 10 years old with 4GB of ram. They wanted to use it online for basic web browsing, so I thought I'd install Windows 10 for security reasons and drop in a modern SSD to upgrade the old 7200rpm drive to make it more snappy. Well, it felt slower after the "upgrade". Clicking the start menu and opening something…

I wonder if you'd have any more luck with that hardware putting Ubuntu Mate on it. For basic web browsing, it probably wouldn't matter much to your family whether it's running Windows or Linux.

Re: The computers are fast, but you don't know it

#54
post #6

I've been lightly banging the drum the last few years that a lot of programmers don't seem to understand how fast computers are, and often ship code that is just miserably slower than it needs to be, like the code in this article, because they simply don't realize that their code ought to be much, much faster. There's still a lot of very early-2000s ideas of how fast computers are floating around. I've wondered how m…

It's not only a matter of 750ms instead of 200ms. I'm astonished every time I open some tool like Visual Studio, SAP Power Designer, or Libre Office that can stay for the most part of a minute on its loading screen. What do those tools even do for that long? They can read enough data from the disk to overflow my computer's main memory a few times during it.

Not that it invalidates anything you said, but it was 750ms vs 200 microseconds.

But yeah. I agree. Why does Lightroom take forever to load, when I can query its backing SQLite in no time at all?

And that's not even mentioning the RAM elephant in the room: chrome.

Younglings today don't understand what a mindbogglingly large amount of data a GB is.

But here's the thing: it's cheaper to waste thousands of CPU cores on bad performance than to have an engineer spend a day optimizing it.

Re: The computers are fast, but you don't know it

#55
post #6

I've been lightly banging the drum the last few years that a lot of programmers don't seem to understand how fast computers are, and often ship code that is just miserably slower than it needs to be, like the code in this article, because they simply don't realize that their code ought to be much, much faster. There's still a lot of very early-2000s ideas of how fast computers are floating around. I've wondered how m…

So much this.

I wonder what would be the software engineering landscape today if hardware specs were growing like 10% per year...

Re: The computers are fast, but you don't know it

#56
post #6

I've been lightly banging the drum the last few years that a lot of programmers don't seem to understand how fast computers are, and often ship code that is just miserably slower than it needs to be, like the code in this article, because they simply don't realize that their code ought to be much, much faster. There's still a lot of very early-2000s ideas of how fast computers are floating around. I've wondered how m…

Python allows one to save development time in exchange for execution time

Except as a developer I lose lots of time if I have to wait long for my code (esp. Unit tests) to run. Having said that larger projects in C/C++ are often very slow to build (esp. if dependencies are not well defined and certain header files affect huge numbers of source files - a problem that doesn't exist with higher level languages). But even if using a particular language and framework saves developer time, it rarely seems to translate into developers using that saved time to bother optimizing where it might really count.

Re: The computers are fast, but you don't know it

#57
post #6

I've been lightly banging the drum the last few years that a lot of programmers don't seem to understand how fast computers are, and often ship code that is just miserably slower than it needs to be, like the code in this article, because they simply don't realize that their code ought to be much, much faster. There's still a lot of very early-2000s ideas of how fast computers are floating around. I've wondered how m…

It's not only a matter of 750ms instead of 200ms. I'm astonished every time I open some tool like Visual Studio, SAP Power Designer, or Libre Office that can stay for the most part of a minute on its loading screen. What do those tools even do for that long? They can read enough data from the disk to overflow my computer's main memory a few times during it.

I've always assumed they are loading a bunch of stuff into caches and pre-computing things.

Re: The computers are fast, but you don't know it

#59
post #28

Earlier quoted context omitted.

It's not only a matter of 750ms instead of 200ms. I'm astonished every time I open some tool like Visual Studio, SAP Power Designer, or Libre Office that can stay for the most part of a minute on its loading screen. What do those tools even do for that long? They can read enough data from the disk to overflow my computer's main memory a few times during it.

Phone home. I suspect much of the lag is network latency.

I work at a BigCorp that ships desktop software (but none of the above products) and network latency is (usually) pretty easy to extract out of the boot critical path. Blocking UI with network calls is a big no-no, and I expect any sizeable organization to have similar guidelines.

Work like in the OP's article is probably the most difficult - it's work that is necessary, cannot be deferred, but is still slow. So it requires an expert to dig into it.

Re: The computers are fast, but you don't know it

#60
post #22

On a 3GHz CPU, one clock cycle is enough time for light to travel only 10cm. If you hold up a sign with, say, a multiplication, a CPU will produce the result before light reaches a person a few metres away.

> If you hold up a sign with, say, a multiplication, a CPU will produce the result before light reaches a person a few metres away.

The latency on multiplication (register input to register output) is 5-clock ticks, and many computers are 4GHz or 5GHz these days.

5-clock cycles at 5GHz is 1ns, which is 30-centimeters of light travel.

If we include L1 cache read and L1 cache write, IIRC its 4 clock cycles for read + 4 more for the write. So 13 clock ticks, which is almost 70 centimeters.

------------

DDR4 read and L1 cache write will add 50 nanoseconds (~250 cycles) of delay, and we're up to 13 meters.

And now you know why cache exists, otherwise computers will be waiting on DDR4 RAM all day, rather than doing work.

Post reply on HN