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

751–760 of 819 posts

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

#751

Post by loup-vaillant »

kllrnohj wrote: post #745
loup-vaillant wrote: post #668

Earlier quoted context omitted.

I'm sorry, C++ ?!? Granted, C is underpowered and I would like namespaces and generics. But from a safety standpoint nowadays, C++ is just as bad. Not only is is monstrously complex, it still has all the pitfalls of C. C++ may have been "more strongly typed" back in the day, but now compiler warnings made up for that small difference. Granted, C++ can be noticeably safer if you go RAII pointer fest, but then you're e…

> I'm sorry, C++?!? C++ had a defined multithreaded memory model and 2's compliment behavior before C did. Since you're all about UB, that kinda matters. A lot.

Well, I'll check who gets rid of all undefined overflows first. 2's complement is nice and dandy, but if overflow is still undefined that doesn't buy me much.

Point taken about multi threading.

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

#752

Post by rufus_foreman »

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…

>> The first time I ran the program, it finished in a couple seconds. I was sure something must have failed

At one of my first jobs I was a DBA supporting a CRUD app in the finance industry. The app had one report that took forever and usually timed out, I was told to take a look at it. The DB query was just missing a couple indexes so I added those.

After I added them, my boss told one of the users of the app to try out the report and she said it was still broken. He asked what she meant and she said she clicked the button and the page with the results came up right away. She thought it was broken because it didn't take forever.

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

#753

Post by corford »

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?

We do. It's called D

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

#754

Post by nyanpasu64 »

kaba0 wrote: post #731
acoard wrote: post #661

Earlier quoted context omitted.

Right it’s basically just developer convenience. So from your post it follows that if a developer can reason about the state changes of their app without redux, they should do so if there are performance concerns. Right? I say this as a webdev who has written pure vanilla Js SPAs a decade ago, and someone who often uses Redux now on most projects today. So I know it’s totally possible to have performant mutable state…

I would say that the tool should reason about it at compile time, a la SolidJS.

Can SolidJS reason about collections of items being added and removed? My pseudo-reactive Qt apps do well with structs, but I often resort to recomputing the entire list of items when elements are added or removed (because QAbstractItemModel is hell to work with, and because my "move items" commands are not exposed to the GUI layer). Perhaps even diffing the item list would be faster than telling the GUI that all data was changed. (Though with I don't know how item lists are handled by GTK3, GTK4 (which is supposedly a lot better: https://blogs.gnome.org/antoniof/2022/06/15/the-tree-view-is...), Svelte, Solid, or the C# GUI frameworks.

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

#755

Post by jussij »

ben0x539 wrote: post #746
jussij wrote: post #372

Earlier quoted context omitted.

The phrase "goes downhill" means things only get worse. The OP is suggesting that since the ping is already slow, a function that does something is going to be much worse.

But as performance gets worse, the ping being slow matters less, relatively, right?

But for most system you don't want performance to get worse. You want to make performance get better.

The ping is just being used to measure of the foundations of the system and the OP is pointing out don't expect to see a 'high performing' system when the ping has identified the foundations are broken.

If you fix the ping and then system is automatically fixed.

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

#756

Post by throwaway894345 »

jcelerier wrote: post #735
throwaway894345 wrote: post #720

Earlier quoted context omitted.

You need to provide all of the libraries referenced by the core dump (at the specific versions and compiled with debug symbols) to get gdb to produce a useful backtrace. It's been a decade since I've done professional C++ development, so I'm a bit foggy on the particulars.

we're in 2022, gdb asks me "can i download missing symbols from the internet" when it loads a binary and does it

Glad to hear the 2022 C++ ecosystem is finally catching up on some regards, but how does it know which version of those dependencies to download, and how does it download closed source symbols?

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

#757

Post by deterministic »

kaba0 wrote: post #296
bayindirh wrote: post #113

Earlier quoted context omitted.

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.

You clearly have strong opinions about things you don’t understand or have any experience with.

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

#758

Post by gilbetron »

necovek wrote: post #748
gilbetron wrote: post #653

Earlier quoted context omitted.

If I travel 25 miles in 1 hour, my speed was 25mph. If I go 100% faster, I'm going 50mph and get there in 30 minutes. If I go 200% faster, I'm going 75mph and get there in 20 minutes. However, the original statement of "We have reduced the time for the computation by ~119%!" is still wrong-seeming, I agree. It should be "We have increased the speed for the computation by 119%" or "We have reduced the time for the com…

Language is, as you nicely point out, very tricky. Yeah, when talking of speed, you can clearly go more than 100% faster. But when talking of something taking a certain amount of time, like done in most benchmarks, it can't be made more than 100% faster.

You can because when you say 100% faster, it is referring to speed, and so you convert to speed than calculate time from that. Language matters :)

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

#759

Post by Balgair »

rufus_foreman wrote: post #752
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…

>> The first time I ran the program, it finished in a couple seconds. I was sure something must have failed At one of my first jobs I was a DBA supporting a CRUD app in the finance industry. The app had one report that took forever and usually timed out, I was told to take a look at it. The DB query was just missing a couple indexes so I added those. After I added them, my boss told one of the users of the app to try…

If I recall correctly, the first few ATMs near Wall Street had the same issue. They were too fast and people were suspicious. They had to add in a delay so folks would feel alright using them.

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

#760

Post by dr_zoidberg »

dr_zoidberg wrote: post #681
xaedes wrote: post #559

Earlier quoted context omitted.

> I think developer speed is more important than optimising clock cycles unnecessarily. Developer time is spent once. Users will always have to pay the price of additional run time. For. Each. Single. User. Always. It scales! Due to the scale of, e.g. slow front-ends, with millions of users, this takes a HUGE amount of time. Only to save a few hours or days to develop it better. Having 1 million users each wait a sin…

> Having 1 million users each wait a single second is already 11 days. This will sound like a nitpick, but it's actually worse. 1 million users waiting a single second is 11,000,000 seconds, right? A day has 86,400 seconds. 11 million divided by 86k is 127.31. That means million users combined just spent 127 days and 8 hours because of the "just one second" delay.

Ah that's what happens when I don't have my cup of coffee in the morning. I went from 1 to 11 million in a typo and didn't even reason. So yeah, it was 12,7 days, not 127. Guess I'll double check having my coffee next time I'm doing back-of-the-napkin math /facepalm
Post reply on HN