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

601–610 of 819 posts

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

#601

Post by knorker »

gpderetta wrote: post #573
knorker wrote: post #287

Earlier quoted context omitted.

It depends. Run the lifetime cost of a CPU, and compare it to what you pay your engineers. It's shocking how much RAM and CPU you can get for the price of an hour of engineer time. And that's not even all! Next time someone reads the code, if it's "clever" (but much much faster) then that's more human time spent. And if it has a bug because it sacrificed some simplicity? That's human hours or days. And that's not eve…

> Next time someone reads the code, if it's "clever" (but much much faster) then that's more human time spent. yet piles and piles of abstractions are considered acceptable and even desirable while having significant negative effects on code readability.

Yeah, it doesn't have a simple answer that works for all cases.

Say you need to do some data processing from format A to B. There's already a maintained codebase for converting from A to C, C to D, and a service that converts individual elements from D to A. All steps require storing back onto disk.

For a one-time thing it'll be MUCH cheaper to do it the naive way reusing existing high level blocks, and going to lunch (or vacation), and let it run.

For a recurring thing, or a pipeline with latency requirements, maybe it's worth building a converter from A to B.

Or… it could be cheaper to just shard A and run it on 20 CPUs.

Let's say you have the expensive piles of abstraction, and creating huge waste. At my company one HOUR of engineer time costs about the same as 20 CPUs running for A YEAR.

This means that if you reduce CPU use by 20 cores, forever, then ROI takes a full year. Including debugging, productionizing, and maintenance you pretty much can't do anything in 1h.

Likely your A-to-B converter could take 1h of human time just in ongoing costs like release management.

And to your point about code readability: Sometimes the ugly solution (A-C-D-B) is the one with less code. If you needed the A->C, C->D, D->A components anyway, then writing an A->B converter is just more code, with its potential readability problems.

On the flip side of this: It's been a trend for a long time in web development to just add layers of frameworks and it's now "perfectly normal" for a website to take 10s to load. Like what the fuck, blogspot, how do you even get to the point where you realize you need a "loading" animation, and instead of fixing the problem you actually do add one.

Human lifetimes have been spent looking at just blogspot's cogs spinning.

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

#602

Post by Tomis02 »

grishka wrote: post #77
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.

I remember a video of a guy running an old version of Visual C++ on an equally old version of Windows, in a VM on modern hardware, to try Windows development "the old way". It took about one frame to launch. One. Frame. By the way, Apple isn't much better. Xcode takes around 15 seconds to launch on an M1 Max. edit: probably this video https://youtu.be/j_4iTovYJtc?t=282

Just based on memory, Visual C++ 6 was written using the good old Win32 API, which is just plain C code. Without access to the source code, I can assume that the object-oriented craze and XML fad had not corrupted that codebase. Superb software.

Visual C++ 7 was rewritten to use another SDK, likely based on .Net, and it was noticeably slower. The problem, as I see it, is people don't understand the cost of abstractions and intermediate layers, and add them gratuitously. This has been a trend ever since.

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

#603

Post by von_lohengramm »

vishnugupta wrote: post #498
skohan wrote: 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…

For most of my work CPUs form the last decade will work just fine. It’s the memory and, especially, disk IO that kills the performance. SSDs have helped big time.

I'd argue that SSDs have done more harm than good. Since the worst-case is now far superior that it used to be (HDDs), most developers see no need to optimize any further. For example, plenty of video game engines will stream copious amounts of data from disk instead of optimizing memory usage, asset size, and in general more creative solutions (i.e. shader effects instead of GBs of redundant assets). If hitting the disk slowed everything to a crawl, then maybe software would've been designed in much more efficient ways. Good (enough) is the enemy of great.

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

#604

Post by kaba0 »

skohan wrote: post #596
kaba0 wrote: post #569

Earlier quoted context omitted.

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: htt…

Isn't a lot of server code these days small programs that just pull data out of a database and feed it to an HHTPS response? It seems like it's a pretty good option to have your infrastructure code implemented in a systems programming language like C or Rust (probably AWS or GCP is doing this for you), and just implement your business logic in Go as the type of small, well-defined programs you're talking about.

But then why go? You can also implement that logic in a likely much more readable way in Python (as at that point performance doesn’t matter), or just write the whole thing in Java/C#/Scala/Kotlin whatever, which in my opinion are more expressive for business logic.

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

#605

Post by fennecfoxy »

onion2k wrote: post #422
bouke wrote: post #403

Earlier quoted context omitted.

And things are slow as we waste all that processing power on running javascript one way or another. And everything requires a slow blocking connection to the mainframe. Nowadays the “always connected” mindset is really slowing us down.

That explains why Electron apps and Web pages are slow but the post you're replying to is about games...

Games do use JS, some UIs actually render using a webview (Unity etc is capable of this)

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

#606

Post by fennecfoxy »

bouke wrote: post #403
jiggawatts wrote: post #273

Earlier quoted context omitted.

Back in the days, an integer division took something like 46 clocks (original Pentium), and now on Ice Lake it's just 12 with a reciprocal throughput of 6. Multiply that by the clock speed increase and a modern CPU can "do division" about 300-400 times faster than a Pentium could. Then multiply that by the number of cores available now versus just one core, and that increases to about 2000 times faster! I used to pla…

And things are slow as we waste all that processing power on running javascript one way or another. And everything requires a slow blocking connection to the mainframe. Nowadays the “always connected” mindset is really slowing us down.

Afaik much JS these days is optimised, see things like V8's turbofan https://v8.dev/blog/turbofan-jit

However there is definitely still less intrinsic optimisation from a dev perspective I think - people will iterate over the same array multiple times in different places rather than do it once.

I guess our industry has decided moving faster is better than running faster for a lot of stuff.

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

#607

Post by kaba0 »

zinodaur wrote: post #599
kaba0 wrote: post #569

Earlier quoted context omitted.

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: htt…

Wow, I had no idea that java was so fast. One thing I like about go is that you can cram many thousands of concurrent requests into the same process. But it looks like java has some pretty robust async tools... So I bet you could do something similar

The JVM is a real beast, which makes sense as a good chunk of the whole internet runs on top of it (almost every big corp has plenty of infrastructure running Java), so it had plenty of engineering time poured into it.

Regarding concurrency, I wouldn’t choose existing reactive frameworks and what not for a new system. Java will soon get Project Loom, which will introduce Go-like virtual threads - so that one can write a web server that spawns a new thread for each request as well. Since the Java ecosystem is very purely written almost exclusively in Java itself (no FFI), basically everything will turn automagically non-blocking.

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

#608

Post by gpderetta »

jnordwick wrote: post #561
gpderetta wrote: post #472

Earlier quoted context omitted.

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…

> Sorry, I dropped all the 1s in that message when i typed it

It makes sense now! :D

> You're not getting a result in less than 20 cycles basically

But the end of the pipeline is an arbitrary point. It will take a few more cycles to get to L1 (when it makes it out of the write buffer), a few tens more to traverse the L2 and L3 and hundreds to get to RAM (if it gets there at all). If it has to get to an human it will take thousands of cycles to get through the various busses to a screen or similar.

The only reasonably useful latency measure is what it takes for the value to be ready to be consumed by the next instruction, which is indeed 3-5 cycles depending to the specific microarchitecture.

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

#609

Post by tpoacher »

The point about pandas resonates with me.

Don't get me wrong, pandas is a nice library ... but the odd thing is, numpy already has, like, 99% of that functionality built in in the form of structured arrays and records, is super-optimised under the hood, and it's just that nobody uses it or knows anything about it. Most people will have never heard of it.

To me pandas seems to be the sort of library that because popular because it mimics the interface of a popular library from another language that people wanted to migrate to (namely dataframes from R), but that's about it.

Compounding this, is that, it is now becoming an effective library to do things, even if backward, because the network effect means that people are building stuff to work on top of pandas, rather than on top of numpy.

The only times I've had to use pandas in my personal projects was either:

a) when I needed a library that 'used pandas rather than numpy' to hijack a function I couldn't care writing by myself (most recently seaborn heatmaps, and exponentially weighted averages - both relatively trivial things to do with pure numpy, and probably faster, but, eh. Leftpad mentality etc ...)

b) when I knew I'd have to share the code with people who would then be looking for the pandas stuff.

I'm probably wrong, but ...

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

#610

Post by avianes »

When I have to explain the speed of a processor to a neophyte I always begin by avoiding using GHz unit which has the weakness of hiding the magnitude of the number, so I explain things in terms of billions of cycles each second.

As an example, with an ILP ~4 instruction/cycle at 5GHz we get 20 billion instructions executed each second in a single core. This number is not really tangible but it shocks

Post reply on HN