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

361–370 of 819 posts

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

#361

Post by notriddle »

tylerchr wrote: post #320
geysersam wrote: post #189

Earlier quoted context omitted.

Shitty performance certainly is bad, but it is not an externality like emissions into the atmosphere. The fundamental difference is that the customer (and only the customer) is harmed by bad performance, while emissions harms everyone.

I'm not so sure. Emissions don't harm everyone instantly; they affect people disproportionately and only impact everyone over time as the effects accumulate. Sure, maybe bad performance only affects the customer initially, but can't you help but wonder what the cumulative opportunity cost of bad performance on civilization has been? The predominant perception among nontechnical people is that computers are fundamenta…

By this reasoning, though, there is no such thing as localized harm. The reason I can't abide by the idea that "there's no such thing as localized harm" is that, when you actually try to analyze nonlocal harms caused by personal decisions, you get swallowed up by the butterfly of doom.

It's the butterfly effect. For example, a lot of software that actually gets written is a net negative to society, even if it functions perfectly. So does making it more efficient actually benefit anybody? And a lot of other software is embedded in organizations that will add features to the software until it fails, expanding like an ideal gas to fill whatever space it's given, so even if you make it more efficient and less failure-prone, you're only really delaying the inevitable anyway. However, making a bureaucratic organization less efficient might not actually stop it; consider, for example, how the Social Security Card was originally engineered to be unusable as a national ID, but got used as one anyway, so now the United States not only has a national ID that most citizens didn't want, but we're stuck with a bad one. However, identity theft might actually be considered just another case of externalities, and if the bureaucrats had to eat the cost of easy-to-forge national IDs, this problem might have gotten fixed.

I think you can analyze nonlocal harms, but not using informal reasoning in a chatroom. There are too many possible interactions in the real world to fit them all in your head. You end up with an impossible-to-analyze infinite regress.

Instead, nonlocal harms should probably expect real-world measurements to prove that they actually exist and aren't entirely being washed out by the much larger effect sizes of unrelated phenomena.

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

#363

Post by nyanpasu64 »

fleddr wrote: post #340
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…

I think the issue isn't even individual developers, it's indeed the runtime itself. Anything you build on top of it is laggy. Take my simple example of reading a file, processing it in memory, writing output. A process that should be instant in almost any case. An implementation of such process that is commonly used in the front-end world would be CSS compilation, where a SCSS file (which is 90% CSS) is compiled into…

Hmm, I recently built a site on Zola, and rebuilding the whole blog (including a theme with around 10 files of Sass) compiles in a few dozen milliseconds, and around 1 second on a 15 year old Core 2 Duo. But then again this is compiled Rust camping into libsass, which (despite Rust's dependency auditing nightmare) compiles to low-overhead executables. And apparently libsass is now deprecated for Dart Sass which relies on JS or the Dart VM.

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

#364

Post by lvturner »

fendy3002 wrote: post #357
lumost wrote: post #352

Earlier quoted context omitted.

MicroServices are great, when your "app" is actually 500 different apps - and the user could be none the wiser that they are talking to 500 different one man applications. You probably need a few helper services in this world for common data access, authorization, sending notifications etc. in this environmen - but these things might also be standard libraries. When Microservices go awry, it's often because one "serv…

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

I almost prefer to just say "Services" -- though I feel this comment is already at risk of provoking a holy war

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

#365

Post by _ea1k »

nickjj wrote: post #348
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 per…

In my case, microservices are often asynchronous messaging applications serving hundreds, thousands, or _maybe_ tens of thousands of transactions per day. Message processing time matters much less to me than reliability and separation of concerns, generally. Kubernetes is great for this.

Its a different world if I have to deal with synchronous user response time.

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

#366

Post by nyanpasu64 »

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…

I wish C++ compilers written in C++ were blazing fast too.

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

#367

Post by rogerclark »

dylan604 wrote: post #269
grishka wrote: post #210

Earlier quoted context omitted.

Of video. Which probably was 30 fps. I mean, the splash screen just blinked for a barely noticeable split second before the main window appeared. You double click the shortcut, and it's already done launching before you realize anything. That's how fast modern computers are. (actually, some things on the M1 are fast enough that I'm now getting annoyed at networking taking what feels like ages)

Why would you assume video is at 30fps? Geographic location? People not in the US (and a handful of other countries) would assume video framerate of 25fps. Does the refresh rate of a computer monitor get referred to as frames? Usually, it's just the frequency like 120Hz type units. Sorry for the conversation break, but I've just never heard app start up times with a framerate reference. Was just an unusual enough thi…

I am the creator of this video. The screen capture was 60fps!

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

#368

Post by ben0x539 »

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…

> Performance only goes downhill from here if the function does more work,

Doesn't this mean it's less of a problem? Like, isn't that good?

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

#369

Post by throwaway894345 »

kaba0 wrote: post #299
throwaway894345 wrote: post #176

Earlier quoted context omitted.

I've written a whole bunch of all of those languages, and they each occupy a different order of magnitude of footguns. From fewest to most: Go (1X), Java (10X), Python (100X), and C++ (1000X).

Go has much more footguns in my opinion. Just look at the recent thread on the topic: https://news.ycombinator.com/item?id=31734110

Most of those aren’t “footguns” at all, but rather preferences (naming conventions, nominal vs structural subtyping) and many others are shared with Python (“magical behavior”, Go’s structural subtyping is strictly better for finding implementations than Python’s duck typing) or non-issues altogether (“the Go compiler won’t accept my invalid Go code”).

The “forget to check an error” one is valid, but rare (usually a function will return data and an error, and you can’t touch the data without handling the error)—moreover, once you use Go for a bit, you sort of expect errors by default (most things error). But yeah, a compilation failure would be better. Personally, the things that really chafe me are remembering to initialize maps, which is a rarer problem in Python because there’s no distinction between allocation and instantiating (at least not in practice). I do wish Go would ditch zero types and adopt sum types (use Option[T] where you need a nil-like type), but that ship has sailed.

I’ve operated services in both languages, and Python services would have tons of errors that Go wouldn’t have, including typos in identifiers, missing “await”s, “NoneType has no attribute ‘foo’”, etc but also considerably more serious issues like an async function accidentally making a sync call under the covers, blocking the event loop, causing health checks to fail, and ultimately bringing down the entire service (same deal with CPU intensive endpoints).

In Go, we would see the occasional nil pointer error, but again, Python has those too.

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

#370

Post by jerf »

Tade0 wrote: post #166
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…

> And in the end, the code seems to run "fast enough" and nobody involved really notices that what is running in 750ms really ought to run in something more like 200us. At least with Chrome's V8, the difference is not that big. Sure, it loses to C/C++, because it can't vectorize and uses orders of magnitude more memory, but at least in the Computer Language Benchmarks Game it's "just" 2-4x slower. I remember getting…

Languages top out at around 50x, and that's the extreme of pure CPython to C.

For as many factors of magnitude as I am talking about, you have to be screwing up algorithms, networks, and a whole bunch of other things too.

Python and similar languages like Ruby really do make it easy to accidentally pile things on top of each other, but you can screw up in pure assembler with enough work put into it. Assembler doesn't stop you from being accidentally quadratic or using networks in a silly way.

Post reply on HN