Basic Python Questions - Oct. 31, 2013

Chris Angelico rosuav at gmail.com
Thu Oct 31 10:49:46 EDT 2013


On Fri, Nov 1, 2013 at 1:41 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2013-10-31 14:05, Chris Angelico wrote:
>>
>> On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
>> <alain at dpt-info.u-strasbg.fr> wrote:
>>>
>>> "E.D.G." <edgrsprj at ix.netcom.com> writes:
>>>
>>>>        The calculation speed question just involves relatively simple
>>>> math such as multiplications and divisions and trig calculations such
>>>> as sin and tan etc.
>>>
>>>
>>> These are not "simple" computations.
>>>
>>> Any compiled language (Fortran, C, C++, typically) will probably go much
>>> faster than any interpreted/bytecode-based language (like python or
>>> perl, anything that does not use a jit).
>>
>>
>> Well, they may not be simple to do, but chances are you can push the
>> work down to the CPU/FPU on most modern hardware - that is, if you're
>> working with IEEE floating point, which I'm pretty sure CPython always
>> does; not sure about other Pythons. No need to actually calculate trig
>> functions unless you need arbitrary precision (and even then, I'd bet
>> the GMP libraries have that all sewn up for you). So the language
>> doesn't make a lot of difference.
>
>
> Sure it does. Python boxes floats into a PyObject structure. Both Python and
> C will ultimately implement the arithmetic of "a + b" with an FADD
> instruction, but Python will do a bunch of pointer dereferencing, hash
> lookups, and function calls before it gets down to that. All of that
> overhead typically outweighs the floating point computations down at the
> bottom, even for the more expensive trig functions.

Of course that's true, but that difference is just as much whether
you're working with addition or trig functions. That overhead is the
same. So if, as I said in the other post, you're doing some heavy
crypto work or something, then yes, all that boxing and unboxing is
expensive. Most programs aren't doing that, so the advantage is far
less (by proportion).

Plus, high level languages like Python make it a *LOT* easier to work
with arbitrary-precision integers than C does. In Python, you just
work with the default integer type and it's infinite-precision. In C,
you have to switch to explicitly using GMP (or equivalent). I'd much
rather pay the overhead and have the convenience of int being able to
store any integer.

ChrisA



More information about the Python-list mailing list