Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

shvbsle.in

Post reply on HN
Print view View original

561–570 of 819 posts

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

#561

Post by jnordwick »

gpderetta wrote: post #472
jnordwick wrote: post #254

Earlier quoted context omitted.

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.

Sorry, I dropped all the 1s in that message when i typed it (laptop keyboard is a little sketchy right now). That should have been 15 and 18. I think the recent Intel microarchs take 14 plus howewever long at uopd decoding that minimum 1, so 15-20 or close to that.

> The dependency chain length is what is normally intended as instruction latency.

Yes, the way I read the original post and others was that you actually your response back in 3 cycles, which isn't correct. It doesn't get comitted for a while (but following instructions can use the result even if it hasn't been committed yet). You're not getting a result in less than 20 cycles basically.

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

#562

Post by Someone »

FTA: Note that the output of this function needs to be computed in less than 500ms for it to even make it to production. I was asked to optimize it.

[…]

Took ~8 seconds to do 1000 calls. Not good at all :(

Isn’t that 8ms per call, way faster than the target performance? Or should that “500ms” be “*500 μs”?

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

#563

Post by gpderetta »

throwaway894345 wrote: post #173
bayindirh wrote: post #113

Earlier quoted context omitted.

As a person who uses both languages for various needs, I disagree. Things which takes minutes in optimized C++ will probably take days in Python, even if I use the "accelerated" libraries for matrix operations and other math I implement in C++. Lastly, people think C++ is not user friendly. No, it certainly is. It needs being careful, yes, but a lot of things can be done in less lines then people expect.

I was a C++ dev in a past life and I have no particular fondness for Python (having used it for a couple of decades), and "friendliness" is a lot more than code golf. It's also "being able to understand all of the features you encounter and their interactions" as well as "sane, standard build tooling" and "good debugability" and many other things that C++ lacks (unless something has changed recently).

Python is a powerful yet beginner friendly language with a very gentle learning slope, but I would still take C++ tooling and debuggability any day over Python.

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

#564

Post by rieTohgh6 »

saberience wrote: post #516
d110af5ccf wrote: post #434

Earlier quoted context omitted.

Nope. All physical effects are bounded by the speed of light. (As far as anyone knows, anyway.) The only weird one is quantum entanglement, but even then information transfer doesn't travel faster than light and that's about all I know on that subject.

Why does gravity travel at the speed of light?

Well the other way to look at it is: gravity travels at maximum possible speed in this universe. Light in vacuum can also reach same maximum speed. I guess we would say the light travels with speed of gravity if we measured them in other order.

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

#565

Post by gpderetta »

p1esk wrote: post #502
easytiger wrote: post #477

Earlier quoted context omitted.

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 ag…

I mean TensorFlow is c++/cuda! No. When I write Tensorflow code I write Python. I don’t care what TF does under the hood just like I don’t care that Python itself might be implemented in C. Though I got to say TF is quite ugly and not a good example of Python’s user friendliness. But that’s another topic.

But as soon as you step out of the optimized path, the performance cliff is huge. Also you are forced to work in non idiomatic awkward meta-languages.

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

#566

Post by gpderetta »

wruza wrote: post #482
kllrnohj wrote: post #436

Earlier quoted context omitted.

They are. They've just chosen to spend all their speed gains on more optimization passes and static analysis, to produce ever faster outputs than to produce an output faster.

Their fundamental model is one translation unit per time, while developers decided that writing all library code in headers is a good idea. Which makes them parse and DCE literally kilometers of mostly irrelevant code again and again. You’re not wrong, but it’s not the complete point. C++ development is slow as a whole, and compilers/standards do nothing to fix that. It’s a kind of F1 engine in a tractor situation.

> and compilers/standards do nothing to fix that

C++20 finally standardized modules. Whether they will improve things significantly is still anyone guess.

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

#567

Post by Narishma »

Nihilartikel wrote: post #304
willis936 wrote: post #216

Earlier quoted context omitted.

This is a discussion about computers being slow. As in a person asks a computer to do something and the human waits while the computer does it. So python isn't the right tool for any job that involves human interaction.

Python _is_ slow, but even back in 2006 on a pentium 4 I had no problem using it with PyGame to build a smooth 60fps rtype style shooter for a coding challenge. One just has to not do anything dumb in the render loop and it's plenty responsive. Of course, if you're going to interactively process a 50mb csv or something... But even then pandas is faster.

That's because a Pentium 4 is way overkill for such a simple game.

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

#568

Post by inkblotuniverse »

RaoulP wrote: post #493
Scalene2 wrote: post #428

Earlier quoted context omitted.

So, there's actually a proposal for "real-time" communication between galaxies. Just upload your consciousness to a computer and run it slow enough that a few hundred million years feels like a couple seconds.

I don’t really see the benefit. But running that slow, you might experience the heat death of the universe in your lifetime!

The idea is that you've already dismantled the stars and stockpiled all the energy in the universe, to use at your leisure. (i.e. everyone lives around black holes they can throw mass into to reap the bawking radiation). Since you have control over the last non-entropic systems, you can tune how fast the candle burns.

And you're a mind running on a computer! You were already going to experience the heat death! This is just a scheme to get the most subjective time out of it as possible. (Running slower is more efficient.)

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

#569

Post by kaba0 »

bheadmaster wrote: post #557
kaba0 wrote: post #544

Earlier quoted context omitted.

> but it's performant enough to run circles around a lot of high level languages and dynamic languages It ain’t running circles around any managed language, with perhaps the exception of Python. C#, Java, JS all have comparably good performances, sometimes much better - e.g. when GC can’t be avoided.

Go is in my experience significantly faster than Java, and uses an order of magnitude less memory for equivalent functionality. If you have any data (or better yet, benchmarks I can run on my own machine), I'd very much like to see some hard numbers.

Go can be faster at small, specific programs where memory lifetimes are deterministic and you can use value types. Otherwise, Java will beat every other managed language by a huge margin when it comes to GC-related workflows. Sure, it does so at higher memory usage, but that is a good tradeoff for many use-cases (especially server).

Benchmarks are hard to do right but this one does actually measure GC quite well: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (For managed languages. It is not really a fair comparison between non-GC and GC-languages)

So all in all, for bigger programs it is hard to do a good comparison, but there is exactly where JIT compilers shine and the memory tradeoff and the like brings their return.

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

#570

Post by gpderetta »

knorker wrote: post #54
marcosdumay wrote: post #19

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.

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…

Why have an engineer spend a day optimizing the program when you can have it spend a month implementing features nobody asked for?
Post reply on HN