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

341–350 of 819 posts

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

#341

Post by hinkley »

drpyser22 wrote: post #324
kllrnohj wrote: post #315

Earlier quoted context omitted.

Shit performance is what happens when every response to optimizations or overhead is immediately answered with "premature optimization is the root of all evil." Or the always fun "profile it!" or "the runtime will optimize it" when discussing new language features and systems. So often performance isn't just ignored, it's actively preached against. Don't question how that new runtime feature performs today or even da…

Well, performance is rarely the most important thing nowadays. What's preached against is not performance, but a performance-first attitude. I agree it would be nice to value performance a bit more, but not at all costs, and depending on the use case and context of the application not necessarily as the priority over security, maintainability, velocity, reliability, etc.

> What's preached against is not performance, but a performance-first attitude.

No, I can tell you this same record has been stuck on repeat since at least the mid 1990's. People want to shut down conversations or assign homework because it gets them out of having to think. Not because they're stupid (though occasionally...) but because you're harshing their buzz, taking away from something that's fun to think about.

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

#342

Post by fullstackchris »

And if you wrote your instructions in assembly, it would be even faster!

/s

Sorry for the rude sarcasm, but isn't this a post truly just about the efficiency pitfalls of Python? (or any language / framework choice for that matter)

Of course modern computers are lightning fast. The overhead of every language, framework, and tool will add significant additional compute however, reducing this lightning speed more and more with each complex abstraction level.

I don't know, I guess I'm just surprised this post is so popular, this stuff seems quite obvious.

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

#343

Post by fullstackchris »

munificent wrote: post #68
jerf wrote: 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 agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a native executable can start up and run. It is breathtaking if you're used to running scripting languages and VMs. Related anecdote: My blog used to be written using Jekyll with Pygments for syntax highlighting. As the number of posts increased, it got closer and…

While I'll take a bite at this, I think it's also fair to say how poorly portable C is. Can an mobile or web engineer quickly take some C code and use it in their stack somehow? I would guess not. While it's indeed an important lesson to see the speed of some of these 'close to the metal' languages, the question of how practical they are to use is a different question.

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

#344

Post by rasz »

marcosdumay wrote: post #19
jerf wrote: 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.

They read stuff off disk 1-4 bytes at a time and malloc() in a loop, then deserialize which calls its own malloc(). Its tiny malloc()s all the way down, and strlens for sure https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

The result is usually one CPU core running at 40% with sporadic disk access while you stare at Loading progress bar.

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

#345

Post by hinkley »

contravariant wrote: post #268
porcoda wrote: post #11

Yup. We have gotten into the habit of leaving a lot of potential performance on the floor in the interest of productivity/accessibility. What always amazes me is when I have to work with a person who only speaks Python or only speaks JS and is completely unaware of the actual performance potential of a system. I think a lot of people just accept the performance they get as normal even if they are doing things that ta…

While I would certainly welcome awareness when it comes to performance it's not always useful to make something 1000x faster if it takes even as little as 25% longer to develop. Taking an extra day to make something take 1s instead of an hour is just not always worth it. Though I will never understand webpages that use more code than you'd reasonably need to implement a performant lisp compiler and build the webpage…

Developers are genuinely bad at watching themselves work. I've had any number of conversations with people who are being slowed down by things and just don't see it. If you take the roadblock away, a lot of them will start to notice, but most won't notice when it comes back, so recruiting people to help you keep things working is a challenge, and guard dogging things can be a significant time suck.

The thing I usually end up saying in situations like this is that, if the application doesn't 'work' for the developers, then soon it won't work for anybody.

For the average user, speeding up some things by 10 seconds will affect their lives more than you think, but it's not going to be the secret to happiness. But for some of these same workflows, the developers are running them over, and over, and over in a day, and cutting a few seconds off each iteration can add up quick. I've fixed build issues that saved team members 45 minutes a day. That sounds nice, but not earth shattering, until you look at the work flow and see 45 minutes is the difference between 4 attempts at fixing a hard problem in one day versus 5. That's not just time that's stress. "I have one more try at this and then I'm done for the day, having accomplished nothing."

The XKCD math on whether you should implement a time saving tool is off by at least an order of magnitude for most real world problems, because it doesn't account for team dynamics. It's written for and about people who don't stop and ask for help. The sooner a person finds their own solution to a problem I'm knowledgeable in, the lower the likelihood that I will get preempted. The three minutes it takes to help them costs me half an hour. Even with tricks to salvage a silver lining from such interactions, that's still expensive.

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

#346

Post by 323 »

lynguist wrote: post #98
jerf wrote: 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 agree except for the Python bit, which is factually wrong. Python allows you to program as if you’re a jazz pianist. You can improvise, iterate and have fun. And when you found a solution you just refactor it and use numba. Boom, it runs the same speed as a compiled language. I once wrote one little program that ran in 24 min without numba and ca. 8 seconds with numba.

There is more to programming than iterating over number arrays, which is pretty much the only scenario where Numba shows impressive speedups.

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

#347

Post by gilbetron »

bombcar wrote: post #327
ineedasername wrote: post #230

Earlier quoted context omitted.

The speed of light has really not kept pace with Moore's Law. Engineers have focused overly much on clock speed and transistor density and completely ignored C, and it's really beginning to show.

People still using C as if C++ isn’t available for faster-than-light code.

dammit that took me a second to get

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

#348

Post by nickjj »

jiggawatts wrote: post #295

Something all architecture astronauts deploying microservices on Kubernetes should try is benchmarking the latency of function calls. E.g.: call a "ping" function that does no computation using different styles. In-process function call. In-process virtual ("abstract") function. Cross-process RPC call in the same operating system. Cross-VM call on the same box (2 VMs on the same host). Remote call across a network sw…

I think folks often make trade offs with their working requirements.

If you provide an end result response from your web app to a user's browser in 50ms-100ms (before external latency) then things like 200 microseconds vs 4 milliseconds have less of a meaningful difference. If your app makes a couple of internal service calls (over HTTP inside of the same Kubernetes cluster) it's not breaking the bank in terms of performance even if you're using "slow" frameworks like Rails and get a few million requests a month.

I'm not defending microservices and using Kubernetes for everything but I could see how people don't end up choosing raw performance over everything. Personally my preference is to keep things as a monolith until you can't and in a lot of cases the time never comes to break it up for a large class of web apps. I also really like the idea of getting performance wins when I can (creating good indexes, caching as needed, going the extra mile to ensure a hot code path is efficient, generally avoiding slow things when I have a hunch it'll be slow, etc.) but I wouldn't choose a different language based only on execution speed for most of the web apps I build.

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

#349

Post by xupybd »

pjvsvsrtrxc wrote: post #331
wbsss4412 wrote: post #313

Earlier quoted context omitted.

Nitpick: software optimization isn’t an example of an externality. Externalities are costs/benefits that accrue to parties not involved in a transaction.

Yes, it is. > ex·ter·nal·i·ty: a side effect or consequence of an industrial or commercial activity that affects other parties without this being reflected in the cost of the goods or services involved The buyer is an "other part[y]" from the seller's (edit: or better yet, developer, who might just be contracted by the ultimate seller...) perspective, and performance is basically impossible to quantify, therefore pri…

So would a less efficient engine in a car be an externality?

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

#350

Post by jeroenhd »

yoyohello13 wrote: post #128
jerf wrote: 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 felt this pretty viscerally recently. I did Advent of Code 2021 in python last year. My day job is programming in Python so I didn't really think about the execution speed of my solutions much. As a fun exercise this year I've been doing Advent of Code 2020 in C, and my god it's crazy how much faster my solutions seem to execute. These are just little toy problems, but even still the speed difference is night and d…

> Although, I still find Python much easier to read and maintain, but that may just be I'm more experienced with the language.

Python is definitely easier to read and maintain if you have loads of dependencies. C dependency management is a pain.

If you can read and write a little C, you should consider giving C#/Java/Kotlin/Swift a try. They're probably an order of magnitude slower than C if you write them in a maintainable style, but they're still much faster than Python. If you're doing stuff like web APIs then ASP.NET/Spring will perform very admirably without manually optimizing code, for example. You might find that these languages are C-like enough to understand and Python-like enough to be productive in. Or you might not, but it's worth a shot!

I personally believe that C is difficult if not impossible to properly to maintain long term, at least not as much as the faster alternatives. On the other hand my experience with Python is that it's one of the slowest mainstream languages out there, relying heavily on C libraries to get acceptable performance.

Post reply on HN