Python is darn fast (was: How fast is Python)
ghowland at lupineNO.SPAMgames.com
Sun Aug 24 03:55:51 CEST 2003
On 24 Aug 2003 00:31:15 +0100, jjl at pobox.com (John J. Lee) wrote:
>Irmen de Jong <irmen at -NOSPAM-REMOVETHIS-xs4all.nl> writes:
>> P at draigBrady.com wrote:
>> > try a 3.x series gcc with the appropriate -march=pentium3
>> > You'll be pleasently surprised.
>> In my other reply I mentioned that I still get a Python+Psyco
>> advantage of 30% over a gcc 3.2.2 compiled version.
>> My gcc is doing a lot better than Michele's reported 50% difference,
>> but Python+Psyco still wins :-)
>So, the interesting part is: why?
I showed this to a more low-level friend and he said it's all down to
exp(). He says it's an awfully slow C call, and if you were to take
it out you would see a real change. Since youre measuring ALU type
things anyway, it's better to keep them to real ALUs. Otherwise
picking a different problem to solve, or not using exp() would make
the test more valid.
He also stated that just linking the library might take some
non-trivial amount of time out of the C implementation.
I'm fluent in C, but not into doing these kinds of things so I didn't
investigate myself, just mouthpiecing it on in case it's useful for
you in your question.
Though since you're just running time on it, I would assume the same
is true for launching the Python interpretter. Seems to me that maybe
time from the command prompt isnt the best measuring tool because of
those loading issues . Checking start/stop time once the program is
initiated would rule those out.
More information about the Python-list