4 ms·

Notably, it should be mentioned that writing idiomatic Python and Ruby results in much slower code than that used here. Ranges bad. While loops good.

Notably, it should be mentioned that writing idiomatic Python and Ruby results in much slower code than that used here. Ranges bad. While loops good. I get 33% shorter times when I change the while loops to for-in-range and a list comprehension. But unless you're doing computationally expensive operations, I don't see the benefit of these speed tests except to provide ammunition for flame wars. What good is it for your code to run 50% faster if you spend 300% more time creating, debugging, and maintaining it?

deleted 11y ago
[deleted]
caf 11y ago
What good is it for your code to run 50% faster if you spend 300% more time creating, debugging, and maintaining it? That question illustrates an important trade-off. The implication is that if your code currently spends more than 8 times as much time running as you spend creating, debugging and maintaining it, then the trade-off would be worth it. (Adjusted as necessary if there is not a one-to-one value correspondence between minutes spent running the program and minutes spent building it).
alialkhatib 11y ago
I'm glad you brought this up, because I was thinking about it but felt like my relative unfamiliarity with C(++) and a handful of other languages in this "shoot-out" made my understanding here flawed (or at least partially naive). I'm also going to piggyback a bit because another thought I had seems related. There's also the issue that among languages like Python, standard libraries (like multiprocessing[0]) make parallelizing code trivial (even with/despite the dreaded global interpreter lock). I rewrote some of the code the author uses and on a smaller number (6710886 instead of 67108864) I'm seeing ~1/3 the time to run compared to his baseline with 4 worker processes (27.469517s vs 1:25.373176). I haven't looked into what might be keeping it from being a full 4x faster, but my hunch is that it's a combination of other things going on in my laptop and the undeniable difference in execution speed in cPython (specifically, cPython3.4). One might make the argument that this is a wildly unfair comparison, but my bigger-picture argument is that a language that abstracts things like parallelization to the point that one can invoke such features in a line or two of added & changed code is probably worth factoring into an analysis, if we're even interested in analyzing languages in this way. If we're going to write C-like code and run it as Python, should we be surprised when it doesn't live up to those expectations? [0]: https://docs.python.org/3.4/library/multiprocessing.html https://docs.python.org/3.4/library/multiprocessing.html
- stelund 11y ago
  Maybe too low chunksize value for map_async call?

deleted 11y ago

[deleted]

caf 11y ago

What good is it for your code to run 50% faster if you spend 300% more time creating, debugging, and maintaining it? That question illustrates an important trade-off. The implication is that if your code currently spends more than 8 times as much time running as you spend creating, debugging and maintaining it, then the trade-off would be worth it. (Adjusted as necessary if there is not a one-to-one value correspondence between minutes spent running the program and minutes spent building it).

alialkhatib 11y ago

I'm glad you brought this up, because I was thinking about it but felt like my relative unfamiliarity with C(++) and a handful of other languages in this "shoot-out" made my understanding here flawed (or at least partially naive). I'm also going to piggyback a bit because another thought I had seems related. There's also the issue that among languages like Python, standard libraries (like multiprocessing[0]) make parallelizing code trivial (even with/despite the dreaded global interpreter lock). I rewrote some of the code the author uses and on a smaller number (6710886 instead of 67108864) I'm seeing ~1/3 the time to run compared to his baseline with 4 worker processes (27.469517s vs 1:25.373176). I haven't looked into what might be keeping it from being a full 4x faster, but my hunch is that it's a combination of other things going on in my laptop and the undeniable difference in execution speed in cPython (specifically, cPython3.4). One might make the argument that this is a wildly unfair comparison, but my bigger-picture argument is that a language that abstracts things like parallelization to the point that one can invoke such features in a line or two of added & changed code is probably worth factoring into an analysis, if we're even interested in analyzing languages in this way. If we're going to write C-like code and run it as Python, should we be surprised when it doesn't live up to those expectations? [0]: https://docs.python.org/3.4/library/multiprocessing.html https://docs.python.org/3.4/library/multiprocessing.html

stelund 11y ago
Maybe too low chunksize value for map_async call?