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

691–700 of 819 posts

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

#691

Post by pkolaczk »

skohan wrote: post #504
flohofwoe wrote: post #499

Earlier quoted context omitted.

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.

I guess the difference is that C++ still gives you pretty much direct access to memory (i.e. pointer arithmetic). Rust tries very hard to keep you at arms length from the actual memory as a rule, and forces you to work through a safe abstraction unless you use an escape hatch.

If by "escape hatch" you mean unsafe blocks, then whole C++ is an escape hatch.

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

#692

Post by munificent »

wruza wrote: post #482
kllrnohj wrote: post #436

Earlier quoted context omitted.

They are. They've just chosen to spend all their speed gains on more optimization passes and static analysis, to produce ever faster outputs than to produce an output faster.

Their fundamental model is one translation unit per time, while developers decided that writing all library code in headers is a good idea. Which makes them parse and DCE literally kilometers of mostly irrelevant code again and again. You’re not wrong, but it’s not the complete point. C++ development is slow as a whole, and compilers/standards do nothing to fix that. It’s a kind of F1 engine in a tractor situation.

> while developers decided that writing all library code in headers is a good idea.

It wasn't developers who designed C++'s template model which requires generic code to be fully defined in header files.

Inheriting C's textual include file based "module" system and then bolting compile-time specialized generics is a choice the C++ committee made, not C++ users. It was probably the right choice given C++'s many very difficult constraints, but that's what directly leads to huge compile times, not dumb C++ users.

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

#693

Post by munificent »

zozbot234 wrote: post #192
skybrian wrote: post #178

Earlier quoted context omitted.

I mean, he just explained that after rewriting his program in Dart, it was fast enough? That's not really the point here. On the other hand, I tried writing a Wren interpreter in Go and it was considerably slower than the C version. Even programming languages that are usually pretty fast aren't always fast, and interpreter inner loops are a weak spot for Go.

> I mean, he just explained that after rewriting his program in Dart, it was fast enough? Yes, and that makes his C advocacy even less sensible. Dart is a perfectly fine language, even though it seems to be a bit underused compared to others.

I didn't advocate that anyone ship production code written in C.

I advocated that people write programs in C and run them to see how fast executables can startup and run.

(Dart isn't great for that because while its runtime performance is pretty fantastic, it does still take a hit on startup because it's a VM with a fairly large core library and runtime system.)

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

#694

Post by knorker »

corrral wrote: post #682
knorker wrote: post #54

Earlier quoted context omitted.

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…

We shouldn't let people obtain CS degrees until they've had to write at least one fairly-complex program on a platform with little enough RAM that the amount of code in the program starts to be something they have to optimize (because the program itself takes up space in memory, not just the data it uses, which is something we hopefully all know but rarely think about in practice on modern machines). Tens or low hund…

It's not far fetched. Microcontroller programming should not be seen as magic.

And microcontrollers will never get abundant capacity because smaller and more efficient means less battery, no matter the tech level.

So it's not like "everyone should know the history of the PDP-11" which I would disagree with.

During my schooling we built traffic lights and stuff on tiny machines, and even in VHDL, even though desktop machines were hundreds of MHz. They both have a place still.

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

#695

Post by edbaskerville »

aeonik wrote: post #235
edbaskerville wrote: post #121

Earlier quoted context omitted.

The thing that did for me is realizing that people on opposite sides of the United States can't play music together if it requires any rhythmic coordination, even with a true speed-of-light signal with no other sources of latency.

jamtaba and ninjam are an open source solutions to this problem. They allow you to buffer everyone's playing, at a user specified interval, then replays the last measure of music to everyone. It's definitely not the same as live playing, but it's still pretty fun, and actually forces you to get creative on different ways. https://jamtaba-music-web-site.appspot.com/

Interesting! Presumably last 12 measures if you're playing a 12-bar blues, etc.

Big downside is you're stuck playing to a metronome, which would be enough for me to skip it, but it depends on the kind of music you're playing.

I could imagine that if the music is rhythmically slow and vague and improvised, big latencies are OK, and actually might yield some pretty interesting creative results.

Another model I've thought about is to structure players in a rooted DAG, and players can hear only people upstream of them.

E.g., you could build an orchestra by having a conductor and section leaders in a room together (or at within very low latency of each other). Other players could hear the leaders and play along, and then an audience could hear everyone. You could also do something more complicated like build things out in linear or power-of-2 layers, where each layer can hear everything upstream of it, and therefore many players would get a partial sense of the orchestral effect.

This could work nicely for improvised music, too, with causality preserved.

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

#696

Post by munificent »

latenightcoding wrote: post #172
munificent wrote: post #68

Earlier quoted context omitted.

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…

off topic but I initially didn't notice your username but the second I read "I wrote my own template language in Dart" I knew who it was.

Haha, yes, I definitely realized I was doing some extremely on-brand yak shaving when I did it.

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

#697

Post by diroussel »

2143 wrote: post #579
reacharavindh wrote: post #440

Earlier quoted context omitted.

This reminds me of that “todo” I wrote for myself a long time ago. These days processors come with bigger L1,L2, and L3 caches. Would it be possible for a program that works on a tiny bit of data(few KB) to load it all up in the cache and provide ultimate response times?! Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”?

> Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”? I'm probably the worst person to explain this. Long long ago, I took a parallel programming class in grad school. It turns out the conventional way to do matrix multiplication results in plenty of cache misses. However, if you carefully tweak the order of the loops and do certain minor modifica…

There is a data access strategy called cache oblivious algorithms which aim to make it more likely to utilise this property without knowing the actual cache size.

I used that approach once on a batch job that read two multi megabytes files to produce a multigigabyte output file. It gave a massive speed up on at 32-bit intel machine.

https://en.wikipedia.org/wiki/Cache-oblivious_algorithm

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

#698

Post by winternett »

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…

I was working at my UNI library around 97 when a fresh t3 (~45MBPS) line was just installed... We also got brand new top of the line Micron computers as well there. I was the first person to test the connection and after years of working on 56k modems I couldn't believe how everything I clicked suddenly worked at the speed of light. Videos I clicked on (on MTVs web site back then) loaded instantly, almost felt as if they loaded before I clicked on links... I have never had anything load as quickly since, even on my home Internet, which is directly connected to my router & 250MBPS plan.

I blame all the ads, tracking, and bloatware that is prevalent now most of all.

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

#699

Post by Sinidir »

pclmulqdq wrote: post #649
kaba0 wrote: post #604

Earlier quoted context omitted.

But then why go? You can also implement that logic in a likely much more readable way in Python (as at that point performance doesn’t matter), or just write the whole thing in Java/C#/Scala/Kotlin whatever, which in my opinion are more expressive for business logic.

In my experience, Python is far less readable than languages like go. The information density and semantic whitespace of Python really hurts readability.

How does the whitespace hurt readability when basically every styleguide and linter in other languages indents code blocks?

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

#700

Post by sparker72678 »

winternett wrote: post #698
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…

I was working at my UNI library around 97 when a fresh t3 (~45MBPS) line was just installed... We also got brand new top of the line Micron computers as well there. I was the first person to test the connection and after years of working on 56k modems I couldn't believe how everything I clicked suddenly worked at the speed of light. Videos I clicked on (on MTVs web site back then) loaded instantly, almost felt as if…

Gosh, yes, this. There was a brief era where websites loaded instantly on those fast network connections, and it was glorious.

It's bananas how slow the web is today on average when you're on a symmetric gigabit connection.

Post reply on HN