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

141–150 of 819 posts

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

#141

Post by grishka »

MiddleEndian wrote: post #125
grishka wrote: post #77

Earlier quoted context omitted.

I remember a video of a guy running an old version of Visual C++ on an equally old version of Windows, in a VM on modern hardware, to try Windows development "the old way". It took about one frame to launch. One. Frame. By the way, Apple isn't much better. Xcode takes around 15 seconds to launch on an M1 Max. edit: probably this video https://youtu.be/j_4iTovYJtc?t=282

But imagine if Visual C++ was written entirely in Electron instead! Wouldn't THAT be sweet?

Should be called Visual React then!

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

#142

Post by cgriswald »

pjvsvsrtrxc wrote: post #99
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…

> 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 would take less than 4 days to make up for the employee's time. That $800 would save about $80,000 per year.

Obviously, this is a contrived example, but I think it's a conservative one. I'm overpaying the engineer (on average) and probably under-estimating time wasted and user cost.

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

#143

Post by dataflow »

radicalbyte wrote: post #124
dataflow wrote: post #97

Earlier quoted context omitted.

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

If you're using an IDE (Rider or Visual Studio) and avoid the Enterprise frameworks, then it's much easier to use than Python. Tooling makes a huge difference, no more digging through the sometimes flakey Python documentation and cursing compatibility issues with random dependencies not supporting Apple Silicon.

I agree tooling makes a huge difference but I specifically said this with the understanding that you're using C# with Visual Studio. Some stuff will be easier in C#, but a lot of other stuff just isn't as easy as in Python.

At the risk of setting up a strawman for people to punch down, try comparing how easy it is to do the equivalent of something like this in C#, and feel free to use as much IDE magic as you'd like:

  x = [t[1] for t in enumerate(range(1, 50, 4)) if t[0] % 3 == 0][2:]
Was it actually easier?

There's a million other examples I could write here, but I'm hoping that one-liner will be sufficient for illustration purposes.

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

#144

Post by pjvsvsrtrxc »

etaioinshrdlu wrote: post #17

My entire career, we never optimize code as well as we can, we optimize as well as we need to. Obviously the result is that computer performance is only "just okay" despite the hardware being capable of much more. This pattern repeats itself across the industry over decades without changing much.

The problem is that performance for most common tasks that people do (f.e. browsing the web, opening a word processor, hell even opening an IM app) has gone from "just okay" to "bad" over the past couple of decades despite our computers getting many times more powerful across every possible dimension (from instructions-per-clock to clock-rate to cache-size to memory-speed to memory-size to ...)

For all this decreased performance, what new features do we have to show for it? Oh great, I can search my Start menu and my taskbar had a shiny gradient for a decade.

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

#145

Post by eterm »

geph2021 wrote: post #20
eterm wrote: post #14

It's hard to evaluate this article without seeing the detail of the "algorithm_wizardry", there's no detail here just where it would be interesting.

The author says: "The function looks something like this:" And then shows some grouping and sorting functions using pandas. Then he says: "I replaced Pandas with simple python lists and implemented the algorithm manually to do the group-by and sort." I think the point of the first optimization is you can do the relatively expenseive group/sort operations without pandas, and improve performance. For the rest of the ar…

We never get a good sense of how much time was actually saved with that change not least because the original function calls "initialise weights" inside every loop, the new function does not. It would have been interesting to see what difference that alone made.

The takeaway of the article, that computers are blindingly fast and we make them do unecessary work (and often sit around waiting on I/O) with most their time is true of course.

I'm currently writing a utility to do a basic benchmark of data structures and I/O and it's been a real learning experience for me in just how fast computers can be, but also just how slow a little bit of overhead or contention can cause things, but that's better left for a full write up another day.

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

#146

Post by physicsguy »

The return value on the function in C++ is of the wrong type :)

I agree though. I used these tricks a lot in scientific computing. Go to the world outside and people are just unaware. With that said - there is a cost to introducing those tricks. Either in needing your team to learn new tools and techniques, maintaining the build process across different operating systems, etc. - Python extension modules on Windows for e.g. are still a PITA if you’re not able to use Conda.

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

#147

Post by jcelerier »

tester756 wrote: post #93
jcelerier wrote: post #73

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. Conversely when 99.9% of the software you use in your daily life is blazing fast C / C++, having to do anything in other stacks is a complete exer…

Is performance inversely proportional to dev experience? because what you wrote could be said about using C++ in the context of dev experience 10 compilers, IDEs, debuggers, package managers and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware I don't believe that this is the best we can get.

> and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware

I mean, that's the initial build.

Here's my compile-edit-run cycle in https://ossia.io which is nearing 400kloc, with a free example of performance profiling, I haven't found anything like this whenever I had to profile python. It's not LLVM-sized of course, but it's not a small project either, maybe in the medium-low C++ project size: https://streamable.com/o8p22f ; pretty much a couple seconds at most from keystroke to result, for a complete DAW which links against Qt, FFMPEG, LLVM, Boost and a few others. Notice also how my IDE kindly informs me of memory leaks and other funsies.

    C/C++ Header                      2212          29523          17227         200382
    C++                               1381          34060          13503         199259
Here's some additional tooling I'm developing - build times can be made as low as a few dozen milliseconds when one puts some work into making the correct API and using the tools correctly: https://www.youtube.com/watch?v=fMQvsqTDm3k

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

#148

Post by antisthenes »

moffkalast wrote: post #36
Guest19023892 wrote: post #26

Earlier quoted context omitted.

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…

That's interesting, I cloned a Win10 installation on a HDD to a sata SSD a year or two back and the speed difference was considerable. Especially something like Atom that took minutes to open before was ready to go in like 10 seconds afterwards. A lot of things remained slow though.

The bigger question is why does a glorified text editor take 10 seconds to open on any system?

Is it loading 2000 plugins?

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

#149

Post by SV_BubbleTime »

agumonkey wrote: post #79
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…

Remember when people were counting cpu cycles and instruction size to ensure performance ?

I program for embedded… still do that.

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

#150

Post by fatnoah »

Gibbon1 wrote: post #74
mrtranscendence wrote: post #42

Earlier quoted context omitted.

> And in the end, the code seems to run "fast enough" and nobody involved really notices that what is running in 750ms really ought to run in something more like 200us. Nobody has created a language that is both thousands of times faster than Python and nearly as straightforward to learn and to use. The closest thing I know of might be Julia, but that has its own performance problems and is tied closely to its AI/ML…

C# is faster than python and as easy to use.

As a long-time C# user who started life with coding for embedded systems with C, graduated to C++ business tiers, and then on to C#, my personal crusade has always been to show that it's very possible to make things go pretty fast with C#.

One of my favorite moments happened after my C#-based back-end company was acquired by an all-[FASTER LANGUAGE] company. We had to connect our platforms and hit a shared performance goal of supporting 1 billion events/month, which amounted to something like (IIRC) 380 per second. Our platform hit that mark running on 3 server setup w/2 Amazon Medium FE servers and a SQL backend. The other company's bits choked at 10 per second, running on roughly 50x the infra.

Poorly written and architected code is a bigger drag than the specific language in many cases.

Post reply on HN