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

321–330 of 819 posts

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

#321

Post by kllrnohj »

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…

Rather than bare C something like C++, Rust, or even Haskell would be better. C isn't the fastest, especially not with normal code. C++ templates get a bad rep, but if you want to go fast they are extremely hard to beat.

Also those languages show you don't actually have to give up modern features or even that much convenience in order to get blazing fast speeds.

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

#322

Post by doliveira »

pelorat wrote: post #262
dataflow wrote: post #97

Earlier quoted context omitted.

As nice as it is, C# is definitely not as easy to use as Python.

But who compares Python with C#, they are not even in the same league? Python is a glorified bash scripting replacement with a mediocre JIT engine. Modern C# is faster than Go which is what it is competing against.

Does Python even have JIT?

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

#323

Post by doliveira »

pjvsvsrtrxc wrote: post #112
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 yet, even with all the evidence that modern, heavily-bloated software development is AWFUL (constant bugs and breakage because no one writing code understands any of the software sitting between them and the machine, much less understands the machine; Rowhammer, Spectre, Meltdown, and now Hertzbleed; sitting there waiting multiple seconds for something to launch up another copy of the web browser you already have…

During work I'm constantly reminded of how much better and snappier MSN Messenger was when compared to Teams.

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

#324

Post by drpyser22 »

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…

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.

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

#325

Post by kllrnohj »

rot13xor wrote: post #280
bayindirh wrote: post #170

Earlier quoted context omitted.

As a person who wrote Java and loved it (and I still love it), I understand where you're coming from, however all programming languages thrive in certain circumstances. I'm no hater of any programming language, but a strong proponent of using the right one for the job at hand. I write a lot of Python these days, because I neither need the speed, nor have the time to write a small utility which will help a user with C…

The biggest weakness of C++ (and C) is non-localized behavior of bugs due to undefined behavior. Once you have undefined behavior, you can no longer reason about your program in a logically consistent way. A language like Python or Java has no undefined behavior so for example if you have an integer overflow, you can debug knowing that only data touched by that integer overflow is affected by the bug whereas in C++ y…

That is a radically gross misunderstanding of what undefined behavior is and how it can (and mostly how it cannot) propagate.

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

#326

Post by taeric »

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…

Being fair, for many of the things that it is worth using a microservice for, you should already have some sort of dominant factor to the call that would more than justify the added latency of the remote call. Be it a database read/write or some other heavy calculation.

Granted, this is exacerbated when architectures don't make a good division between control/compute/data planes.

Control plane, which is exposed to users, should almost certainly be limited to a single (or handful, at most) microservice calls. Preferably to the fastest storage mechanism that you have, such that what latency it does add is minimized entirely.

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

#327

Post by bombcar »

ineedasername wrote: post #230
generalizations wrote: post #108

Earlier quoted context omitted.

I ran across an animation once that showed graphically the time it takes light to travel between the planets and the sun. It's weird, but light doesn't seem that fast anymore.

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.

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

#328

Post by kllrnohj »

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.

That's what's preached against in theory. But in practice any performance discussion is immediately met with that answer. The standing recommendation is build it fully ignorant of all things performance, and then hope you can somehow profile and fix it later. But you probably can't, because your architecture and APIs are fundamentally wrong now. Or you've been so pervasively infested with slow patterns you can't reasonably dig out of it after the fact. Like, say, if you went all in on Java Streams and stopped using for loops entirely, which is something I've seen more than a few times. Or another example would be if you actually listen to all the lint warnings yelling at you to use List everywhere instead of the concrete type. That pattern doesn't meaningfully improve flexibility, but it does cost you performance everywhere.

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

#329

Post by bombcar »

jiggawatts wrote: post #283
diroussel wrote: post #62

Earlier quoted context omitted.

That is quite an amazing way to put it. So the processor in my hand can compute a multiplication fast than light can cross the room?

It can complete many multiplications in that time, especially if you factor in parallelism. An 8-core machine using AVX-512 could do a few thousand 32-bit multiplications in that time. Your GPU can do tens of thousands, maybe hundreds of thousands depending on the model.

Or another way to look at it - the computer can do an absolute insane amount of math in the time it takes to roundtrip a single byte to the datacenter in US-West.

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

#330

Post by ineedasername »

scarmig wrote: post #266
orzig wrote: post #256

Earlier quoted context omitted.

Another consequence of our society’s reduced investment in fundamental physics - instead we go ether.

Perhaps the solution is more on the bioengineering side of things: make smaller people so they can fit in smaller rooms.

That would have a nice side benefit or making space exploration much more economical. Faster too if you can bioengineer higher G resistance at the same time. Maybe someday the outer planets will be colonized by tiny humans measured in millimeters, with 125mm humans darting around the various moons shot out of repurposed tank canons, all laughing at the slow giants stuck down the gravity well on Earth.
Post reply on HN