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

491–500 of 819 posts

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

#491

Post by drewtato »

rl3 wrote: post #452
d110af5ccf wrote: post #434

Earlier quoted context omitted.

Nope. All physical effects are bounded by the speed of light. (As far as anyone knows, anyway.) The only weird one is quantum entanglement, but even then information transfer doesn't travel faster than light and that's about all I know on that subject.

> The only weird one is quantum entanglement, but even then information transfer doesn't travel faster than light ... For anyone wondering why that is, I found this explanation super interesting: https://www.forbes.com/sites/startswithabang/2020/01/02/no-w...

I also liked this explanation: https://www.youtube.com/watch?v=v7jctqKsUMA

In short, the only information you gain is about the outcome of the other side's measurement. They cannot introduce information into the particle, and thus can't transmit information. The only thing you learn is what you already knew: the other particle had a 50% chance of being in one state or another, with the added fact that it's now correlated to your particle with a 75% (depending on experiment) chance. This is information that didn't exist until that moment, so it couldn't have been sent out and reach you before you measure your particle, which would inform you with 75% certainty how your particle would act and break causality.

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

#492

Post by hnick »

Guest19023892 wrote: post #26
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 upgraded a desktop machine the last time I visited my family. It was a Windows 7 computer that was at least 10 years old with 4GB of ram. They wanted to use it online for basic web browsing, so I thought I'd install Windows 10 for security reasons and drop in a modern SSD to upgrade the old 7200rpm drive to make it more snappy. Well, it felt slower after the "upgrade". Clicking the start menu and opening something…

Try Win-R and type "notepad", at a reasonably fast programmer's pace. It consistently loses "no" for me, sometimes more if it's feeling particularly slow.

This should involve absolutely zero disk reads or anything of the sort, it's a window that runs a command. And it used to work reliably in past years. It feels like keyboard input simply isn't buffered like it used to be. Calculator it even worse as it loses input if you start typing the formula too soon. It used to be very easy for casual calculations now I have to wait for the computer.

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

#493

Post by RaoulP »

Scalene2 wrote: post #428
scarmig wrote: post #266

Earlier quoted context omitted.

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

So, there's actually a proposal for "real-time" communication between galaxies. Just upload your consciousness to a computer and run it slow enough that a few hundred million years feels like a couple seconds.

I don’t really see the benefit. But running that slow, you might experience the heat death of the universe in your lifetime!

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

#494

Post by ben_w »

aneeshnl wrote: post #410
bombcar wrote: post #327

Earlier quoted context omitted.

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

Its still just 1 m/s improvement. Not worth it.

Only in metric units. If you’re using natural units, it’s twice as fast as c.

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

#495

Post by hnick »

kossTKR wrote: post #132
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 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.…

For me, there is far more latency on typical operations, but far less waiting for longer intensive operations like opening a program/tab or saving a file (bloat aside, some are guilty here).

I'd also prefer the sluggishness gone if I had my choice between the two.

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

#496

Post by ben_w »

_dain_ wrote: post #358
scarmig wrote: post #266

Earlier quoted context omitted.

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

Bay Area, 1960s: "Soon we will have computers the size of a single room" Bay Area, 2020s: "Soon we will have rooms the size of a single computer"

"Vertical sleep pod, extra large (room for iPad on ceiling!), $3500/month"

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

#497

Post by skohan »

flohofwoe wrote: post #485
ano88888 wrote: post #462

Earlier quoted context omitted.

Why can't we have a language easy to read and maintain but also have the speed of C?

It's not "the C part" that makes code run fast, but memory access patterns. C just happens to not get in the way between the coder and the machine when it comes to explicit control over memory layout. In the late 60's and early 70's this was probably an "accidential feature", but with the widening CPU/memory performance gap it turned out that later languages (from the late 90's and early 00's) had bet on the wrong ho…

Doesn't Rust mostly abstract the memory management away as well? It tends to be low overhead, and has sensible defaults with respect to memory management, but it's built around RAII and for instance if you use a lot of reference types as far as I know there's nothing keeping you from having fragmented memory the same way you would with another high level language.

I know Rust also offers arenas and other purpose built tools for more optimized allocation strategies, but Rust doesn't seem like the language you would reach for if your number one priority is memory performance.

It seems like there is a necessary trade-off between truly top-end memory performance and memory safety.

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

#498

Post by vishnugupta »

skohan wrote: post #453

I remember the moment I realized how fast computers are at uni. I was in an algorithms course, and one of our projects was to make a program which would read in the entire dataset from IMDB of films and actors, and calculate the shortest path between any actor and Kevin Bacon using actors and movies as nodes and roles as edges. I was working in C, and looking back I came up with a quite performant solution mostly by…

For most of my work CPUs form the last decade will work just fine. It’s the memory and, especially, disk IO that kills the performance. SSDs have helped big time.

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

#499

Post by flohofwoe »

skohan wrote: post #497
flohofwoe wrote: post #485

Earlier quoted context omitted.

It's not "the C part" that makes code run fast, but memory access patterns. C just happens to not get in the way between the coder and the machine when it comes to explicit control over memory layout. In the late 60's and early 70's this was probably an "accidential feature", but with the widening CPU/memory performance gap it turned out that later languages (from the late 90's and early 00's) had bet on the wrong ho…

Doesn't Rust mostly abstract the memory management away as well? It tends to be low overhead, and has sensible defaults with respect to memory management, but it's built around RAII and for instance if you use a lot of reference types as far as I know there's nothing keeping you from having fragmented memory the same way you would with another high level language. I know Rust also offers arenas and other purpose buil…

Well yeah, you can write slow code in any language if you don't think about memory layout ;) I see Rust roughly in the same bucket as C++. You can abstract the details of memory management away - which mostly also means giving up control over how things are arranged in memory - but if needed the low level explicit memory management features are there.

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

#500

Post by mcbuilder »

ano88888 wrote: post #462
skohan wrote: post #453

I remember the moment I realized how fast computers are at uni. I was in an algorithms course, and one of our projects was to make a program which would read in the entire dataset from IMDB of films and actors, and calculate the shortest path between any actor and Kevin Bacon using actors and movies as nodes and roles as edges. I was working in C, and looking back I came up with a quite performant solution mostly by…

Why can't we have a language easy to read and maintain but also have the speed of C?

Haskell has an elegance, and can be written as simply as C. Usually fast enough, and can be optimized as well. The downside is that you will be sucked into a rabbit hole of academic type theory and wonder how best to express your system as a Free Monad instead of bashing it out like any sane C programmer. Just kidding, someone already figured out those hard parts for you, you just forgot to browse for it on Hackage.
Post reply on HN