| HN Mirror

$ time python -c '0' python -c '0' 0,03s user 0,01s system 7% cpu 0,467 total $ time python -c '0' python -c '0' 0,03s user 0,00s system 98% cpu 0,030 total $ time python -c 'import numpy' python -c 'import numpy' 0,17s user 0,05s system 9% cpu 2,401 total $ time python -c 'import numpy' python -c 'import numpy' 0,11s user 0,01s system 99% cpu 0,118 total $ time julia -e 0 julia -e 0 0,25s user 0,27s system 17% cpu 2,868 total $ time julia -e 0 julia -e 0 0,09s user 0,05s system 92% cpu 0,155 total

$ time python -c 'import numpy; numpy.random.rand(10,10)' python -c 'import numpy; numpy.random.rand(10,10)' 0,10s user 0,01s system 99% cpu 0,116 total $ time julia -e 'rand(10,10)' julia -e 'rand(10,10)' 0,35s user 0,23s system 209% cpu 0,277 total $ time julia -e 'rand(10,10)' julia -e 'rand(10,10)' 0,36s user 0,22s system 209% cpu 0,278 total

We got approximately the same numbers (your clock speed is likely to be much higher). User/system time is quasi-bogus, since it’s a high core count system (although still a bit concerning). I accounted for possible cache effect by running each a number of times and reporting the last. I’m not really trying to make an absolute time comparison here, just pointing out that if 100ms is unacceptable, numpy would just miss that bar too. Once you’re past the bar of “this needs to be kept running”, I don’t think a constant factor of 100ms vs 1s makes much difference in QoL, and now we’re just comparing apples and oranges. A constant factor gain on the rest of the time can make a huge difference on the rate of results per second. But I actually hope both will improve!