Live data from Hacker News

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

shvbsle.in

471–480 of 819 posts

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

#471
post #53

Earlier quoted context omitted.

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.

Problem with Ubuntu is it doesn’t auto update and it’s very hard to get it to do that. Not sure it’s even possible to auto update major releases as well.

Every time I have installed Ubuntu for someone, I have come back years later and it’s still on the same version.

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

#472

Earlier quoted context omitted.

> The latency on multiplication (register input to register output) is 5-clock ticks 3 https://www.agner.org/optimize/instruction_tables.pdf

Those insrtruction latencies are in addition to the pipeline created latency. (They are actually the number of cycles added to the dependency chain specifically). The mult port has a small pipeline itself of 3 stages (that why 3 cycles latency). Intel has a 5 stage pipeline so the minimum latency is going to be 8 for just those two things.

I don't understand what you are trying to say. The dependency chain length is what is normally intended as instruction latency.

Also the pipeline length is certainly not 5 stages but more like 20-30.

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

#473

Earlier quoted context omitted.

My guess is that few people have stopped to compare them. I've never knowingly seen a 100+hz screen in person, so I stopped by a local store. Sure enough, I could tell that the motion was smoother. Bought 2. After using those, I can feel my older monitors that I'm using to write this are choppy.

But do you notice the smoothness in the day to day basis or have you, in a way, crippled yourself, because now the majority of monitors feel choppy to you? Sounds a bit like the, 'Never meet your heroes', thingy.

I 100% notice it but interestingly it doesn’t affect me on my laptop/desktop much since I use a mouse and scrolling is already not smooth. While mobile has smooth scrolling and a lot more animations/swipes.

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

#475

Earlier quoted context omitted.

If humans wait, yes. If you can just buy another server: no. I 100% agree on saving human time. Human time is expensive. CPU time is absolutely not.

Servers are expensive, too. Humans waiting on servers to process something is even more expensive. No software runs in a vacuum; someone is waiting on it somewhere. Adding more servers doesn't generally make things faster (latency). It only raises capacity (bandwidth). It does, however, generally cost quite a bit on development. Just about the only thing worse than designing a complex system is designing a complex di…

I'm of course aware of all this.

If you don't want to take the advise of running the numbers that's up to you.

E.g. if end user latency is 10ms (and it's not voip or VR or something) then that's fast enough. Doesn't matter if it's optimizable to 10 us.

If this is code running on your million CPU farm 24/7, then yeah. But always run the numbers first.

Like I said, the vast majority of code optimization opportunities are not worth taking. Some are, but only after running the numbers.

On the flip side optimizing for human time is almost always worth it, be it end users or other developers.

But run the numbers for your company. How much does a CPU core cost per hour of it's lifetime? Your developers cost maybe $100, but maybe $1000 in opportunity cost.

Depending on what you do a server may cost you as much as one day of developer opportunity time. And then you have the server for years. (Subject to electricity)

Latency and throughput may be better solved by adding machines.

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

#476

Earlier quoted context omitted.

But do you notice the smoothness in the day to day basis or have you, in a way, crippled yourself, because now the majority of monitors feel choppy to you? Sounds a bit like the, 'Never meet your heroes', thingy.

I 100% notice it but interestingly it doesn’t affect me on my laptop/desktop much since I use a mouse and scrolling is already not smooth. While mobile has smooth scrolling and a lot more animations/swipes.

Do you think that besides gaming there really any need to move to higher then 60Hz on desktops and laptops?

My phone (POCO X3 PRO) allowed me to turn on 120Hz but when I do I don't notice any change except if I really look at it, like scrolling up and down very quickly while looking behind the phone I notice a difference, but otherwise I don't notice it, so I just have it turned off, should give more battery life.

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

#477
post #433

Earlier quoted context omitted.

Doesn't numpy use a natively compiled Fortran or c library for that? https://github.com/numpy/numpy/blob/main/numpy/core/src/mult...

Why should I care what Numpy is written in? All I see is Python.

Because it is like saying you use a bash script to configure and launch a c++ application and saying it is a bash script. Python is not a high performance language, it isn't meant to be and it's strengths lie elsewhere. One of it's great strengths is interop with c libs.

Your assertion was that numpy etc will be faster than something else despite being python:

> Try writing a matmul operation in C++ and profile it against the same thing done in Numpy/Pytorch/TensorFlow/Jax. You’ll be surprised.

I mean TensorFlow is c++/cuda!

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

#478
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're using a normal monitor, the bottleneck would be transferring the results of the calculation to the monitor, which commonly have a latency of 3ms or more. So when the monitor displays the calculations, the CPU has already moved on to other things :)

It takes 10-20ms for the pixels to transition on an LCD display. And on 60Hz, it's 8+/-8ms for the monitor to actually address the row with your information. Luckily, the CPU doesn't need to wait for the monitor. And the slowest part of the chain will almost always be getting it from your eyes to your hands (250ms+).

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

#479
post #453

I remember the moment I realized how fast computers are at uni. I was in an algorithms course, and one of our projects was to make a program which would read in the entire dataset from IMDB of films and actors, and calculate the shortest path between any actor and Kevin Bacon using actors and movies as nodes and roles as edges. I was working in C, and looking back I came up with a quite performant solution mostly by…

Why can't we have a language easy to read and maintain but also have the speed of C?

[deleted]

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

#480

I've always been tempted to make things fast, but for what I personally do on a day to day basis, it all lands under the category of premature optimization. I suspect this is the case for 90% of development out there. I will optimize, but only after the problem presents itself. Unfortunately, as devs, we need to provide "value to the business". This means cranking out features quickly rather than as performant as pos…

I agree... for a business "fast" means shipping a feature quickly. I have personally seen the convos from upper management where they handwave away or even justify making the application slower or unusable for certain users (usually people in developing countries with crappy devices). Oh it will cost +500KB per page load, but we can ship it in 2 weeks? Sounds good!

Lots of businesses have nearly zero engineering in them and cobble together libraries and frameworks that they sell or rent as software.

On the other end of the spectrum you have companies hiring specialists at all points of the stack to squeeze out the last drops of performance, dedicated perf teams, etc. The latter also typically produce the tools that enable the former to function.

Post reply on HN