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

631–640 of 819 posts

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

#631

Post by dahfizz »

pjmlp wrote: post #525
bruce343434 wrote: post #483

Earlier quoted context omitted.

You can't just "transpile to C" to get "C speed". C speed comes from low overhead. Naive transpilations will just include that overhead, like garbage collection or many layers of pointer indirection, but written in C. The unsavory answer is that you must use less abstractions if you want fast code. Compilers just aren't good enough to compile all the abstractions away.

That includes C versus modern CPUs.

The CPU is the CPU regardless of what language you are running on it. C will still give you the best performance on a modern CPU.

If anything, C has an even bigger advantage on modern CPUs because it has easier access to things like vectorize/SIMD intrinsics. It is also easier to tweak your data dependencies to help the branch predictor.

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

#632

Post by skohan »

kaba0 wrote: post #619
paskozdilar wrote: post #615

Earlier quoted context omitted.

Go is much faster than Python, uses less memory, and compiles down to a statically-linked native binary, making containerization trivial. And (IMHO) it's even more readable than Python - nowdays Python code is as easily turned into an unreadable mess as Java or C# code. Just try reading Python standard library and Go standard library - the difference is monumental.

We are talking about business logic. The infrastructure is already in a lower level language, so the performance is not a concern. And we will have to disagree on C#/Java/Python being unreadable mess. In my experience all 3 can be written in a really well maintainable way. I don’t have much experience with Go, but out of these, I would vote for it as the least maintainable (as just because each line is trivial to und…

Performance is always a concern. For instance, if running a python interpreter introduces latency for each request, that can add up to perceptively worse performance when applied throughout a product.

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

#633

Post by dizhn »

Aeolun wrote: post #415
aeonik wrote: post #235

Earlier quoted context omitted.

jamtaba and ninjam are an open source solutions to this problem. They allow you to buffer everyone's playing, at a user specified interval, then replays the last measure of music to everyone. It's definitely not the same as live playing, but it's still pretty fun, and actually forces you to get creative on different ways. https://jamtaba-music-web-site.appspot.com/

How does that work for the one playing ahead of everyone else? He just doesn’t hear anything? Or he hears his own music from 1 second ago? Or worse, other people’s music from 1 second ago.

You have to think in bars not seconds.I believe you hear your own playing in near real time and is overlayed on the bars coming from others.

It works pretty well with well structured music like the blues. You probably couldn't play well if the piece was changing tempo or key all the time.

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

#634

Post by crabmusket »

carlmr wrote: post #577
soco wrote: post #574

Earlier quoted context omitted.

I program Java to earn my living and any hierarchy deeper than two is a bad smell for me. Not that it cannot have its place, but most of the time you're right, some find so fascinating to inherit everything from everything...

I remember sitting in these lectures thinking, why not just use a function without all the boilerplate? And a decade later the programming world finally came back to some semblance of sanity.

Because for some reason most OO learning material seems to be focused on syntax and language features, not design. It's a real shame.

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

#635

Post by matthias509 »

2143 wrote: post #579
reacharavindh wrote: post #440

Earlier quoted context omitted.

This reminds me of that “todo” I wrote for myself a long time ago. These days processors come with bigger L1,L2, and L3 caches. Would it be possible for a program that works on a tiny bit of data(few KB) to load it all up in the cache and provide ultimate response times?! Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”?

> Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”? I'm probably the worst person to explain this. Long long ago, I took a parallel programming class in grad school. It turns out the conventional way to do matrix multiplication results in plenty of cache misses. However, if you carefully tweak the order of the loops and do certain minor modifica…

I’m guessing you are thinking of cache lines where CPUs will read/write data in 64 byte chunks from memory to/from cache.

As you said, being aware of this lets you optimize away cache misses by controlling the memory access pattern.

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

#636

Post by loup-vaillant »

knorker wrote: post #475
pjvsvsrtrxc wrote: post #333

Earlier quoted context omitted.

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

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

Casey Muratori said it best: there are 3 philosophies of optimisation. You're talking about the first: actual optimisation where you measure and decide what to tackle. It's rarely used, and with good reason.

The second philosophy however is very different: it's non-pessimisation. That is, avoid having the CPU do useless work all the time. That one should be applied in a fairly systematic basis, and it's not. To apply it in practice you need to have an idea of how much time your algorithm requires. Count how many bytes are processed, how many operations are made… this should give a nice upper bound on performance. If you're within an order of magnitude of this theoretical maximum, you're probably good. Otherwise you probably missed something.

The third philosophy is fake optimisation: heuristics misapplied out of context. This one should never be used, but is more frequent than we care to admit.

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

#637

Post by Aeolun »

jiggawatts wrote: post #587
Aeolun wrote: post #416

Earlier quoted context omitted.

Millions of multiplications in the time it takes me to open the ‘calc’ app.

Billions. Your estimate is off by 3 orders of magnitude.

You underestimate the speed at which I open the app ;)

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

#638

Post by modo_mario »

journey_16162 wrote: post #514

As a front-end developer, I can't help but notice how much useless computation is going on in a fairly popular library - Redux. It's a store of items, if just one tiny items change in the whole store, every subscriber of every item gets notified and a compare function is ran to check if it changes. Perhaps I'm misunderstanding something and not to bash on Redux - I'm sure there are well-deserved reasons it got popula…

>I don't use a high-end laptop and I'm not eager to upgrade is because I can relate to the average user of the software I develop.

Thank you so so much. It's insane how it feels like the speed of much of our software hasn't improved or even regressed despite the gigantic advancements made over the years. People really don't seem to care about this.

I had an argument about it with a senior colleague regarding some industry software. He figured it wasn't worthwhile to improve the speed of some table fetching and calculations that people actually had to wait on since it would only amount to a bit more than a second or so on top of the regular slowness of it all.

A second that had been multiplied on at least 20 pc's each going trough it at least a 100 times a day of more than 260 times each year over at least 10 years so far. Turns out more than 5 million seconds is a lot of man-hours which whilst cheaper than ours amount to manyfold what it would have taken to fix it.

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

#639

Post by khalladay »

von_lohengramm wrote: post #603
vishnugupta wrote: post #498

Earlier quoted context omitted.

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…

Ah yes game engine development, where we herd all the lazy folks who hate efficient solutions to problems.
Post reply on HN