Live data from Hacker News

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

shvbsle.in

291–300 of 819 posts

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

#291
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.

In my experience, this wouldn't be needed if the rest of the app ran at native speed. There would already be a natural delay that would be noticed by the user.

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

#292

Earlier quoted context omitted.

> But here's the thing: it's cheaper to waste thousands of CPU cores on bad performance than to have an engineer spend a day optimizing it. No, it really isn't. It's only cheaper for the company making the software (and only if they don't use their software extensively, at that).

Exactly. Users are subsidizing the software provider with CPU cycles and employee time. Assume it costs $800 for an engineer-day. Assume your software has 10,000 daily users and that the wasted time cost is 20 seconds (assume this is actual wasted time when an employee is actively waiting and not completing some other task). Assume the employees using the software earn on average 1/8 of what the engineer makes. It wo…

If humans wait, yes. If you can just buy another server: no.

I 100% agree on saving human time. Human time is expensive. CPU time is absolutely not.

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

#294

Earlier quoted context omitted.

I hope one day latency in general will be "back to normal". I still remember how fast console based computing, an old gameboy or a 90's macintosh would be - click a button and stuff would show up instantly. There was a tactility present with computers that's gone today. Today everything feels sluggish - just writing this comment on my $3000 Macbook Pro and i can feel the latency, sometimes there's even small pauses.…

May I ask if you're using the M1 based MacBook or the Intel one? I'm asking because I've been thinking of getting a MacBook Air in the future with the intent to use it for writing.

Still on intel. And yes the newer M1's actually feels better for writing as far as i've tried..

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

#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 switch.

Remote call across a firewall and a load balancer.

Remote call across the above, but with HTTPS and JSON encoding.

Same as above, but across Availability Zones.

In my tests these scenarios have a performance range of about 1 million from the fastest to slowest. Languages like C++ and Rust will inline most local calls, but even when that's not possible overhead is typically less than 10 CPU clocks, or about 3 nanoseconds. Remote calls in the typical case start at around 1.5 milliseconds and HTTPS+JSON and intermediate hops like firewalls or layer-7 load balancers can blow this out to 3+ milliseconds surprisingly easily.

To put it another way, a synchronous/sequential stream of remote RPC calls in the typical case can only provide about 300-600 calls per second to a function that does nothing. Performance only goes downhill from here if the function does more work, or calls other remote functions.

Yet, every enterprise architecture you will ever see, without exception has layers and layers, hop upon hop, and everything is HTTPS and JSON as far as the eye can see.

I see K8s architectures growing side-cars, envoys, and proxies like mushrooms, and then having all of that go across external L7 proxies ("ingress"), multiple firewall hops, web application firewalls, etc...

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

#296
post #81

Earlier quoted context omitted.

Conversely when 99.9% of the software you use in your daily life is user friendly Python, having to do anything in C/C++ is a complete exercise in frustration, it feels like going back a few decades in time

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.

I call bullshit on that. You either don’t compare the same thing, but C++ is not that much faster than even Python.

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

#297

Earlier quoted context omitted.

I hope one day latency in general will be "back to normal". I still remember how fast console based computing, an old gameboy or a 90's macintosh would be - click a button and stuff would show up instantly. There was a tactility present with computers that's gone today. Today everything feels sluggish - just writing this comment on my $3000 Macbook Pro and i can feel the latency, sometimes there's even small pauses.…

>Hopefully the focus on 100hz+ screens in tech Come again? I think anything beyond 60hz still qualifies as niche. Vendors are still selling 720p laptops.

True, it's probably just bleeding edge, but i've noticed several flagship phones, have 90HZ, and the new iPad Pros have up to 120hz "smooth scrolling", so it seems something will be happening x years down the line.

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

#298
post #54

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.

Not that it invalidates anything you said, but it was 750ms vs 200 microseconds. But yeah. I agree. Why does Lightroom take forever to load, when I can query its backing SQLite in no time at all? And that's not even mentioning the RAM elephant in the room: chrome. Younglings today don't understand what a mindbogglingly large amount of data a GB is. But here's the thing: it's cheaper to waste thousands of CPU cores on…

Regarding chrome, browsers are basically operating systems nowadays. A standards compliant HTML5 parser is at the bare minimum millions of lines of code. Same for the renderer and Javascript engine.

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

#299
post #158

Earlier quoted context omitted.

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++.

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

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

#300
post #243

Earlier quoted context omitted.

> That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Many of the most highly credentialed, veteran C developers have said they can't write secure C code. Food for thought. > Go is a decent choice, because of a fairly shallow learning curve and not too much complexity, while having good lib…

> secure C code. There is unsecure code hidden in every project that uses any programming language ;) I get what you're saying here, you're specifically talking about security vulnerabilities from memory related errors. I honestly wonder how many of these security vulnerabilities are truly issues that never would have come up in a more "secure" language like Java, or if the vulnerabilities would have just surfaced in…

> I honestly wonder how many of these security vulnerabilities are truly issues that never would have come up in a more "secure" language like Java, or if the vulnerabilities would have just surfaced in a different manner.

Memory safety vulnerabilities basically boil down to following causes: null pointer dereferences, use-after-free (/dangling stack pointers), uninitialized memory, array out-of-bounds, and type confusion. Now, strictly speaking, in a memory-safe languages, you're guaranteed not to get uncontrollable behavior in any of these cases, but if the result is a thrown exception or panic or similar, your program is still crashing. And I think for your purposes, such a crash isn't meaningfully better than C's well-things-are-going-haywire.

That said, use-after-free and uninitialized memory vulnerabilities are completely impossible in a GC language--you're not going to even get a controlled crash. In a language like Rust or even C++ in some cases, these issues are effectively mitigated to the point where I'm able to trust that it's not the cause of anything I'm seeing. Null-pointer dereferences are not effectively mitigated against in Java, but in Rust (which has nullability as part of the type), it does end up being effectively mitigated. This does leave out-of-bounds and type confusion as two errors that are not effectively mitigated by even safe languages, although they might end up being safer in practice.

Post reply on HN