4 ms·

I think this feels like an underestimate of the performance difference? I generally keep in my head that C/CPP is roughly 100x faster than python, and the compu

I think this feels like an underestimate of the performance difference? I generally keep in my head that C/CPP is roughly 100x faster than python, and the computer language benchmarks game seems to support this (I admit that the solutions on there are uncharacteristic of idiomatic code in many cases but hopefully the python and CPP solutions are equally horrible there). https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I wonder how you can characterize the difference in speed between the two languages. I think I read somewhere that in the reference implementation of ruby, calling a method in the general case can require several hash table lookups to find the implementation associated with the name of the method. Is that mostly the same in python as well?

steerablesafe 6y ago
I expect a lot of time being wasted in `sqrt`, which is probably similar in the two languages.
- contravariant 6y ago
  Yeah it's probably better to use something like k*k < n as a stopping condition. Though that one uses requires some additional calculation per step. I've once tried to fix that part by using the (usually discarded) result of `n div k` to determine when k < sqrt(n). I couldn't get it to work (faster) but it was fun to try.
  - steerablesafe 6y ago
    Interesting. In principle that idea does look better, but the data dependency on the loop condition could be the bottleneck. CPUs probably have plenty of pipelining capacity to calculate `k*k` parallel to `n div k`, so effectively free as it's much faster than division.
Rochus 6y ago
> I generally keep in my head that C/CPP is roughly 100x faster than python Right; here is a recent scientific publication which confirms about factor 50 speed-down from C++ to Python for the given micro benchmarks: https://authors.elsevier.com/a/1cP%7ELc7X4-XPM; https://authors.elsevier.com/a/1cP%7ELc7X4-XPM; see table 4. The more time Python spends in native procedures, the more favorable the ratio is for Python; this is probably the reason why only around factor ten was measured here.

steerablesafe 6y ago

I expect a lot of time being wasted in `sqrt`, which is probably similar in the two languages.

contravariant 6y ago
Yeah it's probably better to use something like k*k < n as a stopping condition. Though that one uses requires some additional calculation per step. I've once tried to fix that part by using the (usually discarded) result of `n div k` to determine when k < sqrt(n). I couldn't get it to work (faster) but it was fun to try.
- steerablesafe 6y ago
  Interesting. In principle that idea does look better, but the data dependency on the loop condition could be the bottleneck. CPUs probably have plenty of pipelining capacity to calculate `k*k` parallel to `n div k`, so effectively free as it's much faster than division.

Rochus 6y ago

> I generally keep in my head that C/CPP is roughly 100x faster than python Right; here is a recent scientific publication which confirms about factor 50 speed-down from C++ to Python for the given micro benchmarks: https://authors.elsevier.com/a/1cP%7ELc7X4-XPM; https://authors.elsevier.com/a/1cP%7ELc7X4-XPM; see table 4. The more time Python spends in native procedures, the more favorable the ratio is for Python; this is probably the reason why only around factor ten was measured here.