The computers are fast, but you don't know it • Hacker News Board

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

#711

Post by igouy » Fri, Jun 17, 2022, 5:41 PM UTC

kaba0 wrote: post #289

spatley wrote: post #63

Earlier quoted context omitted.

Agreed that switching to lower level languages give the potential of many orders of magnitude. But the thing that was most enlightening was that removing pandas made a 9900% increase in speed without even a change to language. 20 minutes down to 12 seconds is a very big deal, and I still don't have to remember how to manage pointers.

I don’t believe orders of magnitude is achievable in general. Even python, which is perhaps the slowest mainstream language clocks in at around 10x that of C. Sure, there will be some specialized program where keeping the cache manually small you can achieve big improvements, but most mainstream managed languages have very great performance. The slowdown is caused by the frameworks and whatnot, not the language itsel…

Guess it depends what you mean by "achievable in general".

Guess we don't have a way to measure "in general" so we are left with tiny tiny benchmarks programs.

    simple

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

    cpu secs Python 3 versus C gcc

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#712

Post by charlie0 » Fri, Jun 17, 2022, 5:41 PM UTC

blub wrote: post #524

charlie0 wrote: post #69

I've always been tempted to make things fast, but for what I personally do on a day to day basis, it all lands under the category of premature optimization. I suspect this is the case for 90% of development out there. I will optimize, but only after the problem presents itself. Unfortunately, as devs, we need to provide "value to the business". This means cranking out features quickly rather than as performant as pos…

Performance is something that needs to be considered throughout the development cycle. If optimization happens at the end then it’s either a rewrite or a minor concern anyway because the building blocks like frameworks and libraries were already optimized. Or the software is just slow but still sells for other reasons.

Totally depends in the business. Most businesses just don't need ultra low ms response times.

Rewriting an app because is too slow is a rather extreme approach. Most of the times it's just a small part of the application that needs optimization and not the entire app.

I'd argue that if the app experiences huge growth, then that's a good problem to have and a rewrite is in order.

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

#713

Post by Zetaphor » Fri, Jun 17, 2022, 5:47 PM UTC

For some reason my employer is blocking this site as malware using Cisco's OpenDNS service

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

#714

Post by hinkley » Fri, Jun 17, 2022, 5:48 PM UTC

Too wrote: post #400

hinkley wrote: post #345

Earlier quoted context omitted.

Developers are genuinely bad at watching themselves work. I've had any number of conversations with people who are being slowed down by things and just don't see it. If you take the roadblock away, a lot of them will start to notice, but most won't notice when it comes back, so recruiting people to help you keep things working is a challenge, and guard dogging things can be a significant time suck. The thing I usuall…

You also have some mental thresholds that multiply this effect even more. The difference between 5 min build and 30 min build isn’t just 25 mins. It’s the difference between I will only run this over lunch break, vs I will run this while fetching coffee. Add many other thresholds like short enough to still stare at progress bar vs alt-tab into Facebook and loose attention and waste another 10mins there, slow enough t…

Agreed. But I’ll add another phenomenon here. A five minute build takes ten minutes, because once you start something else you’ve estimated will take five minutes, you quickly discover that it takes ten, or you forget that you were doing that other thing. So taking four minutes off of a build actually takes 8 minutes off of the expected round trip time.

And that’s not even counting the “what if it fails the first time” tax which can double it again. Especially if it fails 30 seconds in and you don’t check until the end of the expected time. That four minutes can go to fifteen minutes on a really bad day, and that bad day might be a production issue or just trying to get out the door for your anniversary dinner. These are the situations when the light bulb goes on for people.

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

#715

Post by Shorel » Fri, Jun 17, 2022, 6:08 PM UTC

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?

For many things, I have found this easy language is C++.

I use JavaScript and C++ for different things, sometimes in the same day. (And python and PHP and others, but this is not relevant.)

Believe me, JavaScript can be a real head scratcher compared to C++.

And now for the purists: No, I don't use all features of C++, only the minimal necessary ones for the problem I have to solve. This ridiculous idea that you are not using C++ if you are not using every single language feature is what makes programs difficult to write and maintain.

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

#716

Post by Shorel » Fri, Jun 17, 2022, 6:11 PM UTC

qikInNdOutReply wrote: post #509

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…

So a good language, should not abstract that memory pyramid away, but instead make you painfully aware of it, while developing. Rewarding DOD, punishing OO, but that results in more education time for programers, which no company is willing to pay for. What instead is needed is a intermediate language, that takes the constructs of object orientation and the instruction flow and allows to rearrange them for maximum me…

Just allocate the objects in the stack, RAII style.

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

#717

Post by morelisp » Fri, Jun 17, 2022, 6:12 PM UTC

igouy wrote: post #708

gilbetron wrote: post #643

Earlier quoted context omitted.

You picked binary trees, which has java better than Go, I'm guessing something about the implementation. If you look at other examples on that site, Go and Java are roughly the same, but with some variance: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> … guessing something about the implementation. The source code is shown — binary-trees Java #7 program https://benchmarksgame-team.pages.debian.net/benchmarksgame/... binary-trees Go #2 program https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Alright, I guess I'll admit this just sniped me.

Having read the rules it's difficult to know what's considered "fair" for this test - all GC tuning is off the table, sure. But what's bugging me is "Leaf nodes must be the same as interior nodes - the same memory allocation." So what constitutes "the same memory allocation" - literally the exact same call to some opaque internal allocator? If so, shouldn't Java also have to disable JIT to be fair?

Let me offer an alternate interpretation: I will do the same memory allocation if I need to allocate a node, but if my language lets me not allocate a node yet still use that node why should I? Or an alternate argument if you don't like that one: Why must my "node" be `Tree`, rather than `*Tree`?

A central idiom of Go is that zero-values of a type can be useful; a two-line change, no new special-cases, no pooling or such gauche hacks:

    // Count the nodes in the given complete binary tree.
    func (t *Tree) Count() int {
     if t == nil {
      return 1
     }
     return 1 + t.Right.Count() + t.Left.Count()
    }

    // Create a complete binary tree of `depth` and return it as a pointer.
    func NewTree(depth int) *Tree {
     if depth > 0 {
      return &Tree{Left: NewTree(depth - 1), Right: NewTree(depth - 1)}
     } else {
      return nil
     }
    }

I'm sure someone will tell me I "optimized away the work" - but in the end I believe I'm making exactly the same number of method calls on the same type of receiver. If that's not the work, what is?

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

#718

Post by LtdJorge » Fri, Jun 17, 2022, 6:28 PM UTC

von_lohengramm wrote: post #603

vishnugupta wrote: post #498

Earlier quoted context omitted.

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.

I'd argue that SSDs have done more harm than good. Since the worst-case is now far superior that it used to be (HDDs), most developers see no need to optimize any further. For example, plenty of video game engines will stream copious amounts of data from disk instead of optimizing memory usage, asset size, and in general more creative solutions (i.e. shader effects instead of GBs of redundant assets). If hitting the…

Games are a bad choice as an example. (Some) Games are always trying to squeeze the most out the latest hardware. You can't have a massive world with 4K textures and no loading screens using an HDD and 8GB of RAM without performance degradation.

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

#719

Post by gpm » Fri, Jun 17, 2022, 6:33 PM UTC

necovek wrote: post #582

gpm wrote: post #161

Earlier quoted context omitted.

This is because numpy and friends are really good at matmul's. As soon as you step out of the happy path and need to do any calculation that isn't at least n^2 work for every single python call you are looking at order of magnitude speed differences. Years ago now (so I'm a bit fuzzy on the details) a friend asked me to help optimize some python code that took a few days to do one job. I got something like a 10x spee…

That's definitely quite curious: I am sure pure Python could have been heavily optimized to reach 2 minutes as well, though. Random number generation in Python is C-based, so while the pseudo-random generators from Python's random module might be slow, it's not because of Python itself ( https://docs.python.org/3/library/random.html is a different implementation from https://man7.org/linux/man-pages/man3/random.3.htm…

I'm reasonably sure the PRNG being used in the python version came from numpy and was implemented in C (or other native code, not python). The problem was that the necessary control flow and varying parameters around it meant you had to call it once per value from python (and you had to generate a lot of values).

And if I recall correctly there was no allocation in the hot loop, with a single large array being initialized via numpy to store the values before hand. Certainly that's one of the first things I would think to fix.

I was strongly convinced at the time that there was no significant improvement left in python. With >99% of the time being spent in this one function, and no way to move the loop into native code given the primitives available from numpy. Admittedly I could have been wrong, and I'm not about to revisit the code now, since it has been years and it is no longer in use - so everything I'm saying is based off of years old memories.

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

#720

Post by throwaway894345 » Fri, Jun 17, 2022, 6:41 PM UTC

gpderetta wrote: post #667

throwaway894345 wrote: post #663

Earlier quoted context omitted.

Nah man, I've spent way too much time trying to piece together libraries to turn core dumps into a useful stack trace. Similarly, as miserable as Python package management is, at least it has a package manager that works with virtually every project in the ecosystem. I actually really like writing C++, but there are certain obstacles that slow a developer down tremendously--I could forgive them if they were interesti…

I won't spend any positive words on cmake (I'm a plain make fan), but... > or try to get debug information for a segfault what's the problem with opening the core dump with gdb and looking at the backtrace?

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.