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

381–390 of 819 posts

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

#381

Post by throwaway14356 »

spatley wrote: post #63
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…

Agreed that switching to lower level languages give the potential of many orders of magnitude. But the thing that was most enlightening was that removing pandas made a 9900% increase in speed without even a change to language. 20 minutes down to 12 seconds is a very big deal, and I still don't have to remember how to manage pointers.

3 sec on 1 to 200 ms on 32 cores on the other hand smells like things could be better.

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

#382

Post by mark-r »

Tostino wrote: post #227
fleddr wrote: post #65

Earlier quoted context omitted.

I think it's even stronger than a habit. When you're exposed to the typical "performance" of the web and apps for a decade or so, you may have forgotten about raw performance entirely. Young people may have never experienced it at all. I once owned a small business server with a Xeon processor, Linux installed. Just for kicks I wrote a C program that would loop over many thousands of files, read their content, sort i…

In my SAAS app, we have a few artificial delays to ensure all "background tasks" that pop up a progress dialog take at least long enough to show that to the user.

I once did a progress dialog for a Windows app. It had a delay so it wouldn't even show until 0.5 seconds had elapsed - if the operation completed in that time, you never saw the pop-up. Once the dialog appeared it would stay on screen for at least a second so you wouldn't get freaked out by a sudden flash, even if the operation completed immediately after the 0.5 second delay.

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

#384

Post by astrange »

bb88 wrote: post #158
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.

Java and Go were both responses to how terrible C++ actually is. While there are footguns in python, java, and go, there are exponentially more in C++.

Java is largely based on Objective-C, not on C++. It's a bit hard to tell because they removed messaging though.

It is memory safe but otherwise I think it was an imitation, not a reaction, to ObjC features.

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

#385

Post by phillipcarter »

kllrnohj wrote: post #315
fleddr wrote: post #65

Earlier quoted context omitted.

I think it's even stronger than a habit. When you're exposed to the typical "performance" of the web and apps for a decade or so, you may have forgotten about raw performance entirely. Young people may have never experienced it at all. I once owned a small business server with a Xeon processor, Linux installed. Just for kicks I wrote a C program that would loop over many thousands of files, read their content, sort i…

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…

I mean, yeah, you should profile stuff. Your intuition only goes so far.

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

#386

Post by Aeolun »

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…

> can blow this out to 3+ milliseconds surprisingly easily

And then your actual function starts, and returns after roughly 10s.

I think you underestimate just how inefficient enterprise can be. The extra time taken in connections between layers is not even a consideration.

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

#387

Post by yen223 »

gpderetta wrote: post #339
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…

The best is "is IO bound anyway".

The thing that ticks me off with microservices is that things are already IO bound, and we decide to add more IO to the system!

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

#388

Post by pclmulqdq »

kaba0 wrote: post #289
spatley wrote: post #63

Earlier quoted context omitted.

Agreed that switching to lower level languages give the potential of many orders of magnitude. But the thing that was most enlightening was that removing pandas made a 9900% increase in speed without even a change to language. 20 minutes down to 12 seconds is a very big deal, and I still don't have to remember how to manage pointers.

I don’t believe orders of magnitude is achievable in general. Even python, which is perhaps the slowest mainstream language clocks in at around 10x that of C. Sure, there will be some specialized program where keeping the cache manually small you can achieve big improvements, but most mainstream managed languages have very great performance. The slowdown is caused by the frameworks and whatnot, not the language itsel…

Python programs often need to use a lot of optimized C and C++ libraries to get anywhere near reasonable performance. I would be shocked if a webserver written in Python was only 10x slower than one written in C (or Go or Rust for that matter).

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

#389

Post by Aeolun »

throwaway14356 wrote: post #381
spatley wrote: post #63

Earlier quoted context omitted.

Agreed that switching to lower level languages give the potential of many orders of magnitude. But the thing that was most enlightening was that removing pandas made a 9900% increase in speed without even a change to language. 20 minutes down to 12 seconds is a very big deal, and I still don't have to remember how to manage pointers.

3 sec on 1 to 200 ms on 32 cores on the other hand smells like things could be better.

That feels like fairly expected overhead for managing a bunch of threads?

I mean, you could potentially push another 2x speedup out of it, but you’re already at 10000x, is that really necessary?

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

#390

Post by closeparen »

judge2020 wrote: post #376
fendy3002 wrote: post #357

Earlier quoted context omitted.

I still don't get why MacroServices isn't getting popular as of today

I believe that's called a "monolith" and it's quite popular, especially in pretty much every traditional enterprising company.

Traditional enterprise companies are agglomerations of IT systems from a sprawling network of acquisitions, subsidiaries, and partners. They collect fad languages, architectures, and proprietary ecosystems from across decades of computing history. And then try to somehow make them all play with each other.

At least in our world we have the source code to all the services. They have explicit and intentional APIs. They're constructed from a small set of frameworks and speak an even smaller number of protocols. Our enterprise brothers have none of that. Screen scraping, retrofitting TCP/IP stacks onto things that never had them, patching binaries whose source is long gone, etc.

Post reply on HN