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

721–730 of 819 posts

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

#721

Post by m1el »

acoard wrote: post #661
m1el wrote: post #538

Earlier quoted context omitted.

Hi, I believe I understand you. If you look at immutable data structures implemented using JS primitives, it will surely look terrible. However, there's a lot of benefit to using a FP approach like Redux. It's much easier to reason about state updates if all you have is pure functions. It allows you avoid very annoying and hard to catch bugs. I've seen this personally, when replacing a spaghetti component with a stra…

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…

> if a developer can reason about the state changes of their app without redux, they should do so if there are performance concerns. Right?

That is correct :)

However, I'm not sure how many developers will be able to maintain the project and keep the invariants implicitly ingrained in the codebase by the smart developer who can reason about mutable state changes.

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

#722

Post by Shorel »

p1esk wrote: post #140
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.

Which “accelerated” libraries for matrix operations are you talking about? Try writing a matmul operation in C++ and profile it against the same thing done in Numpy/Pytorch/TensorFlow/Jax. You’ll be surprised.

The canonical answer would be uBLAS.

https://www.boost.org/doc/libs/1_75_0/libs/numeric/ublas/doc...

I think BLAS (a C version, not the boost one) is also the library numpy is using, as numpy is not written in python. That's why it is fast, it is C.

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

#723

Post by dragonwriter »

gpm wrote: post #719
necovek wrote: post #582

Earlier quoted context omitted.

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 initia…

> 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).

Sounds like a Numba use case.

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

#724

Post by gpm »

dragonwriter wrote: post #723
gpm wrote: post #719

Earlier quoted context omitted.

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 initia…

> 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). Sounds like a Numba use case.

Huh, I didn't know that was a thing. At a super high level glance I suspect yes.

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

#725

Post by Schroedingersat »

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…

Jai has this as an explicit goal.

Zig has closely aligned goals.

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

#726

Post by Shorel »

Dylan16807 wrote: post #456
babypuncher wrote: post #111

Earlier quoted context omitted.

Throw in more RAM and Windows 10 will likely feel snappier than Windows 7 did. It's probable the old Windows 7 install was 32-bit while your fresh install of 10 would have defaulted to 64-bit. That combined with 10's naturally higher memory requirements means the system has less overhead to work with.

If it was 32-bit, then it's probable the windows 7 install wasn't using all the memory, so there shouldn't have been a big difference. And 4GB is enough for a blank windows 10 install doing some OS things and browsing. I don't think more memory helps that scenario.

In my experience, also with some older hardware: Windows 10 is not happy with just 8 GB of RAM, much less 4 GB.

I mean, everyone uses a browser, even if they use nothing else, and browsers gobble up RAM like crazy.

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

#728

Post by throwaway894345 »

necovek wrote: post #677
throwaway894345 wrote: post #642

Earlier quoted context omitted.

> even though there are workarounds to make that 1-10x slower rather than 100-1000X (eg. C-based implementations, including all the itertools stuff). These only apply for specific problems, and very few applications are purely CSV parsing or purely matrix math operations. In the real world, you often spend more time marshaling your Python data to C than you save by doing your computation in C. > But as you note, bott…

> The bottleneck in a static site generator is I/O. The fact that Python, Ruby, etc based implementations take tens of seconds or more while Go and Rust finish instantly for an I/O bound problem is pretty damning. My point was that if this was the case, your Python code is probably suboptimal. Sure, you are comparing against naive implementation as well, but if performance is a concern, don't do naive Python :) > I g…

> My point was that if this was the case, your Python code is probably suboptimal. Sure, you are comparing against naive implementation as well, but if performance is a concern, don't do naive Python :)

I agree, and I'll go further: if performance could be a concern and you aren't certain that even optimized Python is up for the task, don't do Python. :)

I don't know how optimized these SSGs are, but given how frequently this complaint occurs and how popular they are, I would expect that someone would have tried to optimize them a bit. Even assuming naive implementations, tens of seconds versus tens of milliseconds for an I/O-bound task is pretty concerning.

> Yes, it's easy and sometimes even idiomatic to write non-performant Python code. Getting the most out of pure Python is hard and it means avoiding some common patterns.

It probably shouldn't be easy for someone to write non-performant Python code when they're trying desperately to write performant Python code. :)

> Getting the most out of pure Python is hard and it means avoiding some common patterns.

And even then, you're probably going to be coming in 10-100X slower than naive Go/Java/C#/etc unless your application happens to be a good candidate for C-extensions (e.g., matrix math) or if it really is I/O bound (a CRUD webapp). It honestly just seems better to avoid Python altogether than try to write Python without using "common patterns" (especially absent guidance about which patterns to avoid or how to avoid them).

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

#729

Post by OOPMan »

carlmr wrote: post #532
moffkalast wrote: post #529

Earlier quoted context omitted.

> that results in more education time for programers, which no company is willing to pay for That's why you finally stop teaching Java in high schools.

I was going to say OOP aside from the basic animals and calls example, takes years of indoctrination for people to find it the simple default way to do things. Functional programming is much simpler, but we don't spend years hammering the concept into people's brains.

Ah yes, functional programming is indeed so much simpler.

I'll just use a Kleisli

XD

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

#730

Post by kaba0 »

xaedes wrote: post #559
korla wrote: post #517

Earlier quoted context omitted.

I think developer speed is more important than optimising clock cycles unnecessarily. Generally writing to dom is much much slower than evaluting a few thousand expressions. For the cases when it's not, use memo.

> 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…

I’m not claiming that we should not improve that single second, but summing it is a meaningless operation. It doesn’t matter for a user how many other user spent time on it as well.
Post reply on HN