On 2013-10-31 14:49, Chris Angelico wrote:
On Fri, Nov 1, 2013 at 1:41 AM, Robert Kern <robert.k...@gmail.com> wrote:
On 2013-10-31 14:05, Chris Angelico wrote:
On Fri, Nov 1, 2013 at 12:17 AM, Alain Ketterlin
<al...@dpt-info.u-strasbg.fr> wrote:
"E.D.G." <edgrs...@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.
Yes, Alain was wrong to suggest that these are not "simple calculations" and
thus will benefit from a lower-level language. In fact, the relationship is
reversed. These are *such* simple operations that they do benefit from the
immediate surrounding code being done in C. The amount of time spent on overhead
doesn't change based on the operation itself but the immediate surrounding code,
the inner loops. That's where the language (implementation) matters.
> Most programs aren't doing that, so the advantage is far
> less (by proportion).
But we're not talking about most programs. We are talking about the OP's
programs, which apparently *do* involve lots of iterated floating point
calculations.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
https://mail.python.org/mailman/listinfo/python-list
