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

581–590 of 819 posts

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

#581

Post by TremendousJudge »

throwaway894345 wrote: post #173
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 was a C++ dev in a past life and I have no particular fondness for Python (having used it for a couple of decades), and "friendliness" is a lot more than code golf. It's also "being able to understand all of the features you encounter and their interactions" as well as "sane, standard build tooling" and "good debugability" and many other things that C++ lacks (unless something has changed recently).

>unless something has changed recently

No, it's even worse -- there are even MORE ways of doing the same thing now.

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

#582

Post by necovek »

gpm wrote: post #161
p1esk wrote: post #140

Earlier quoted context omitted.

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.

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

Call overhead and loop overhead is pretty big in Python though. The way to work around that in Python is to use C-based "primitives", like the stuff from itertools and all the builtins for set/list/hash processing (thus avoiding the n^2 case in pure Python). And when memory is an issue (preallocating large data structures can be slow as well), iterators! (Eg. compare use of range() in newer Python with use of list(range())).

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

#583

Post by [deleted] »

Gigachad wrote: post #471
nequo wrote: post #53

Earlier quoted context omitted.

I wonder if you'd have any more luck with that hardware putting Ubuntu Mate on it. For basic web browsing, it probably wouldn't matter much to your family whether it's running Windows or Linux.

Problem with Ubuntu is it doesn’t auto update and it’s very hard to get it to do that. Not sure it’s even possible to auto update major releases as well. Every time I have installed Ubuntu for someone, I have come back years later and it’s still on the same version.

[deleted]

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

#584

Post by necovek »

easytiger wrote: post #548
p1esk wrote: post #502

Earlier quoted context omitted.

I mean TensorFlow is c++/cuda! No. When I write Tensorflow code I write Python. I don’t care what TF does under the hood just like I don’t care that Python itself might be implemented in C. Though I got to say TF is quite ugly and not a good example of Python’s user friendliness. But that’s another topic.

As long as you know python is doing little to no computational work.

That's a known and widely publicised trait of Python.

In the early days, Python tutorial warned against adding to strings by doing "+" even though it works because that performed a new allocation and string copy.

What you were asked to do was use fast, optimized C-based primitives like "\n".join(list_of_strings) etc.

Basically, Python is an "ergonomic" language built in C. Saying how something is implemented in C at the lower level is pointless, because all of Python is.

Yes, doing loops over large data sets in Python is slow. Which is why it provides itertools (again, C-based functions) in stdlib.

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

#585

Post by wruza »

diroussel wrote: post #62
forinti wrote: post #22

On a 3GHz CPU, one clock cycle is enough time for light to travel only 10cm. If you hold up a sign with, say, a multiplication, a CPU will produce the result before light reaches a person a few metres away.

That is quite an amazing way to put it. So the processor in my hand can compute a multiplication fast than light can cross the room?

Not so extraordinary if you take into account that CPU is essentially a thumb-sized labyrinth for light.

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

#586

Post by necovek »

bayindirh wrote: post #457
l33t2328 wrote: post #454

Earlier quoted context omitted.

> 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’m gonna need an example because I do not believe this whatsoever.

I'd rather open the code and show what I'm talking about, however I can not. Let's say I'm making a lot of numerical calculations which are fed from a lockless queue with atomic operations to any number of cores you want, where your performance is limited by the CPU cores' FPU performance and the memory bandwidth (in terms of both transfer speed and queries that bus can handle per second). As I noted below, that code…

There are definitely operations you cannot speed up in Python as much as in other languages, unless you implement it in one of those other languages and interface it in Python.

That much is obvious from Python providing a bunch of C-based primitives in stdlib (otherwise they'd just be written in pure Python).

In many cases, you can make use of the existing primitives to get huge improvements even with pure Python, but you are not beating optimized C++ code (which almost has direct access to CPU vector operations as well).

Python's advantage is in speed of development, not in speed of execution. And I say that as a firm believer that majority of the Python code in existence today could be much faster only if written with the understanding of Python's internal structures.

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

#587

Post by jiggawatts »

Aeolun wrote: post #416
bombcar wrote: post #329

Earlier quoted context omitted.

Or another way to look at it - the computer can do an absolute insane amount of math in the time it takes to roundtrip a single byte to the datacenter in US-West.

Millions of multiplications in the time it takes me to open the ‘calc’ app.

Billions.

Your estimate is off by 3 orders of magnitude.

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

#588

Post by jiggawatts »

wruza wrote: post #465
bouke wrote: post #424

Earlier quoted context omitted.

Ok fair enough, but the mindset is spreading: json (javascript) parsing is what caused GTA Online loading times to balloon and I dread playing Call of Duty online as it wants to download and install dozens of GBs every time I launch it.

It wasn’t json parsing per se, but a buggy roll-your-own implementation that used a function (sscanf iirc) with a surprising nontrivial complexity on a long string. Fun part is, if they just outsourced that load to javascript and its JSON.parse, they’d never encounter that exponential slowdown. Javascript is a nice target to blame, but it isn’t the problem. CPUs got hundreds of times faster, javascript only divides i…

You may be thinking of GTA Online, but the point is still valid.

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

#590

Post by FeepingCreature »

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?

D as well, though only (like Rust) if you keep the traits and template stuff low.

The nice thing about D for me is that you can generally banish the unreadable metaprogramming code to a library.

Post reply on HN