Basic Python Questions - Oct. 31, 2013

[Chris Angelico]

On Fri, Nov 1, 2013 at 1:18 AM, Alain Ketterlin
<alain at dpt-info.u-strasbg.fr> wrote:
> Well, sure, yes, I agree with you and hope they are left to the FP
> engine (still, fp ops are often multi-cycle, but that's a minor point).
>
> But what I meant was: a (bytecode) interpreted program will always be
> slower than a compiled program, probably by an order of magnitude when
> doing number crunching.

Yeah, but it depends on what your number crunching actually involves.

If you're implementing crypto in Python, then yes, there's a lot of
actual Python number crunching, and it's going to be slow. But
calculating the cosine of 1.23456 is going to take very close to the
same amount of time in each - the work isn't being done in Python.

But yes, Python code does tend to be a lot slower than equivalent C.
The goal of Python is not to lick (or even challenge) C for raw speed,
but to be "fast enough", and to be easy to write and clear to read. It
does a fairly good job at that.

ChrisA