Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #102407 > unrolled thread

Why Python is slow

Back to article view | Back to comp.lang.c

Contents

  Why Python is slow thunderbirdmember@gmail.com - 2017-01-24 10:22 -0800
    Re: Why Python is slow Richard Heathfield <rjh@cpax.org.uk> - 2017-01-24 18:33 +0000
    Re: Why Python is slow Richard Heathfield <rjh@cpax.org.uk> - 2017-01-24 20:14 +0000
      Re: Why Python is slow luser droog <luser.droog@gmail.com> - 2017-01-26 10:13 -0800
      Re: Why Python is slow Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 05:50 -0800
    Re: Why Python is slow bart4858@gmail.com - 2017-01-24 13:21 -0800
    Re: Why Python is slow BartC <bc@freeuk.com> - 2017-01-24 22:23 +0000
    Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-24 17:11 -0800
      Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-24 19:26 -0800
      Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-25 12:50 -0800
        Re: Why Python is slow BartC <bc@freeuk.com> - 2017-01-25 21:52 +0000
          Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-25 14:30 -0800
            Re: Why Python is slow BartC <bc@freeuk.com> - 2017-01-25 22:59 +0000
              Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-27 13:20 -0800
        Re: Why Python is slow DFS <nospam@dfs.com> - 2017-01-25 19:22 -0500
          Re: Why Python is slow "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-01-26 13:40 -0800
    Re: Why Python is slow David Brown <david.brown@hesbynett.no> - 2017-01-25 10:29 +0100
      Re: Why Python is slow gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-25 10:38 +0000
      Re: Why Python is slow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-26 06:44 -0800
        Re: Why Python is slow Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 15:00 +0000
          Re: Why Python is slow Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-26 17:23 +0000
            Re: Why Python is slow supercat@casperkitty.com - 2017-01-26 09:42 -0800
              Re: Why Python is slow Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-26 18:24 +0000
        Re: Why Python is slow David Brown <david.brown@hesbynett.no> - 2017-01-26 16:14 +0100
          Re: Why Python is slow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-26 12:49 -0800
            Re: Why Python is slow Robert Wessel <robertwessel2@yahoo.com> - 2017-01-26 15:11 -0600
            Re: Why Python is slow David Brown <david.brown@hesbynett.no> - 2017-01-26 23:56 +0100
          Re: Why Python is slow Keith Thompson <kst-u@mib.org> - 2017-01-26 15:20 -0800
            Re: Why Python is slow David Brown <david.brown@hesbynett.no> - 2017-01-27 09:31 +0100
        Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 07:24 -0800
          Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 07:57 -0800
            Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 08:46 -0800
          Re: Why Python is slow supercat@casperkitty.com - 2017-01-27 08:06 -0800
            Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 08:39 -0800
              Re: Why Python is slow fir <profesor.fir@gmail.com> - 2017-01-27 13:29 -0800
    Re: 3**3**3**3 Noob <root@127.0.0.1> - 2017-01-27 14:33 +0100

Page 2 of 2 — ← Prev page 1 [2]

#102477

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 26/01/17 14:44, Malcolm McLean wrote:
>
> <snip>
>
>> The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
>> in under just-noticeable time on my machine.
>
> That's actually quite a reasonable answer.

It's much further from the correct answer than, say, zero.  Even
-DBL_MAX is a better estimate! :-)

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102478

On Thursday, January 26, 2017 at 11:24:05 AM UTC-6, Ben Bacarisse wrote:
> >> The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> >> in under just-noticeable time on my machine.
> >
> > That's actually quite a reasonable answer.
> 
> It's much further from the correct answer than, say, zero.  Even
> -DBL_MAX is a better estimate! :-)

That depends whether "inf" is taken to mean "infinity" or "some value that
exceeds DBL_MAX by an unknown amount".  I think the latter interpretation
is more consistent with the behavior of the type.  The only place the latter
definition would cause trouble is that after:

    float f1 = 1.0e38f, f2=f1*f1;
    double d1=f2;

the value of f2 would be, correctly, "some value that exceeds FLT_MAX by an
unknown amount", but the assignment to d1 would cause it to incorrectly be
regarded as "some value that exceeds DBL_MAX by an unknown amount".

[toc] | [prev] | [next] | [standalone]

#102481

supercat@casperkitty.com writes:

> On Thursday, January 26, 2017 at 11:24:05 AM UTC-6, Ben Bacarisse wrote:
>> >> The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
>> >> in under just-noticeable time on my machine.
>> >
>> > That's actually quite a reasonable answer.
>> 
>> It's much further from the correct answer than, say, zero.  Even
>> -DBL_MAX is a better estimate! :-)
>
> That depends whether "inf" is taken to mean "infinity" or "some value that
> exceeds DBL_MAX by an unknown amount".  I think the latter interpretation
> is more consistent with the behavior of the type.

... but not more consistent with the smiley.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102468

On 26/01/17 15:44, Malcolm McLean wrote:
> On Wednesday, January 25, 2017 at 9:29:15 AM UTC, David Brown wrote:
>>
>> Of course, Python is not /really/ twice as fast as C - the run-time
>> python libraries that do the integer calculations are written in C (for
>> normal Python).  But it shows that for some purposes, Python is faster
>> than C in practice - because "in practice" covers the effort involved in
>> writing the code.  With good enough algorithms and good enough
>> implementations, C will be faster than Python - but you would have to
>> spend an inordinate effort to write C code that is faster than the
>> highly optimised C code in the Python runtime libraries.
>>
> The Python source code has generally been stolen from reference
> implementations which have been floating around in cyberspace for
> ages.

By "stolen", can I assume you are accusing the Python implementation
developers of making illegal unlicensed copies of other people's code,
breaking their licences, copyrights, or in some other way offending the
original authors' rights?  Obviously you can't really mean "stolen",
because that does not make sense for something like source code.

And you are certainly accusing the Python implementation developers of
being extraordinarily lax in just "pulling some code off the net",
rather than either spending time and effort developing it themselves,
spending time and effort researching the quality of available libraries,
or starting with existing software and spending time and effort getting
it up to a suitable quality.

And you make this as a general statement about "Python source code" -
not even just about the big integer handling.

However you expect that accusation to be interpreted, it is quite an
astonishingly derogative way to describe the efforts involved in writing
the Python runtime libraries.


It would not surprise me to find that at least parts of Python's big
integer handling is based on existing arbitrary precision libraries -
that's part of the beauty of open source development.  But that is a
very, very different thing from what you wrote.

> Then they add a Python interface layer. So you don't work from
> scratch, you nick the Python C sources and peel off the interface layer,
> it's some effort but not equivalent to reinventing the FFT.

Again, you don't "nick" anything.

And no, if you want to have an efficient implementation of big integer
multiplication in C you do /not/ start from the Python source code and
"peel off the Python bits".  You'll find there is no "interface layer"
in most of the Python library source code - it is much more integrated
to give the balance more of an emphasis on run-time speed than ease of
development.

And if you really wanted to solve this particular problem as fast as
possible, you would aim for specialised algorithms rather than general
multiplication algorithms.

But however you did it, the development work would be vastly greater in
C than in Python, especially if you want to compete with Python in speed
here.

> 
> The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> in under just-noticeable time on my machine.
> 

That uses double-precision floating point, and it has already been
established that the result is well outside the range of doubles - as
well as completely missing the point of the test.

[toc] | [prev] | [next] | [standalone]

#102492

On Thursday, January 26, 2017 at 3:14:26 PM UTC, David Brown wrote:
>
> And no, if you want to have an efficient implementation of big integer
> multiplication in C you do /not/ start from the Python source code and
> "peel off the Python bits".  You'll find there is no "interface layer"
> in most of the Python library source code - it is much more integrated
> to give the balance more of an emphasis on run-time speed than ease of
> development.
> 
A few years ago, someone decided to test a physics sim of a protein by
asking two computational biochemistry labs to run it independently.
They had supposedly separate programs. It emerged that 95% of the
source code was in fact in common.

That's the way it goes in scientific computing. Very few people have
both the skills and the inclination to implement something from
scratch when there is perfectly functional solution a short web
search away.

[toc] | [prev] | [next] | [standalone]

#102495

On Thu, 26 Jan 2017 12:49:33 -0800 (PST), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:

>On Thursday, January 26, 2017 at 3:14:26 PM UTC, David Brown wrote:
>>
>> And no, if you want to have an efficient implementation of big integer
>> multiplication in C you do /not/ start from the Python source code and
>> "peel off the Python bits".  You'll find there is no "interface layer"
>> in most of the Python library source code - it is much more integrated
>> to give the balance more of an emphasis on run-time speed than ease of
>> development.
>> 
>A few years ago, someone decided to test a physics sim of a protein by
>asking two computational biochemistry labs to run it independently.
>They had supposedly separate programs. It emerged that 95% of the
>source code was in fact in common.
>
>That's the way it goes in scientific computing. Very few people have
>both the skills and the inclination to implement something from
>scratch when there is perfectly functional solution a short web
>search away.


It's worse than that - people solving the same problem often come up
with very similar solutions.

When NASA was designing the avionics for the Space Shuttle, they built
it with five computers, four of which would run identical copies of
the mission software (and could thus survive two hardware failures).
The fifth, while running on identical hardware, used independently
developed software providing the minimal functions needed to get the
Shuttle back on the ground.  Despite near clean-room conditions, there
were repeated cases of the same bugs being found in both
implementations, and only a subset of those could be attributed to
flaws in the (common) specifications.  Which is why nobody does it
that way that anymore.

[toc] | [prev] | [next] | [standalone]

#102504

On 26/01/17 21:49, Malcolm McLean wrote:
> On Thursday, January 26, 2017 at 3:14:26 PM UTC, David Brown wrote:
>>
>> And no, if you want to have an efficient implementation of big integer
>> multiplication in C you do /not/ start from the Python source code and
>> "peel off the Python bits".  You'll find there is no "interface layer"
>> in most of the Python library source code - it is much more integrated
>> to give the balance more of an emphasis on run-time speed than ease of
>> development.
>>
> A few years ago, someone decided to test a physics sim of a protein by
> asking two computational biochemistry labs to run it independently.
> They had supposedly separate programs. It emerged that 95% of the
> source code was in fact in common.
>
> That's the way it goes in scientific computing. Very few people have
> both the skills and the inclination to implement something from
> scratch when there is perfectly functional solution a short web
> search away.
>

That is true - but totally irrelevant to your accusations about the 
Python implementers.  In the case of the folks writing the Python 
run-time libraries, they /do/ have the skills and inclination to 
implement good code.  They were not trying to make two separate 
implementations.  And it is perfectly reasonable if they choose to make 
appropriate and legal use of existing libraries - which is not "stealing 
random code off the internet".

[toc] | [prev] | [next] | [standalone]

#102507

David Brown <david.brown@hesbynett.no> writes:
> On 26/01/17 15:44, Malcolm McLean wrote:
[...]
>> The Python source code has generally been stolen from reference
>> implementations which have been floating around in cyberspace for
>> ages.
>
> By "stolen", can I assume you are accusing the Python implementation
> developers of making illegal unlicensed copies of other people's code,
> breaking their licences, copyrights, or in some other way offending the
> original authors' rights?  Obviously you can't really mean "stolen",
> because that does not make sense for something like source code.
[...]

David, sometimes the word "stolen" is used facetiously to refer to
reusing existing code, even if such reuse is perfectly legitimate.
I've used the word that way myself on occasion.  It's possible,
but by no means certain, that Malcolm meant it that way.

Malcolm, please clarify either that you are, or that you are not,
accusing the Python developers of doing something illegal and/or
illegitimate.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#102514

On 27/01/17 00:20, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 26/01/17 15:44, Malcolm McLean wrote:
> [...]
>>> The Python source code has generally been stolen from reference
>>> implementations which have been floating around in cyberspace for
>>> ages.
>>
>> By "stolen", can I assume you are accusing the Python implementation
>> developers of making illegal unlicensed copies of other people's code,
>> breaking their licences, copyrights, or in some other way offending the
>> original authors' rights?  Obviously you can't really mean "stolen",
>> because that does not make sense for something like source code.
> [...]
> 
> David, sometimes the word "stolen" is used facetiously to refer to
> reusing existing code, even if such reuse is perfectly legitimate.
> I've used the word that way myself on occasion.  It's possible,
> but by no means certain, that Malcolm meant it that way.

Yes, I realise that - and I expect that is the usage Malcolm meant.  And
that's fine in an appropriate context - we have all "stolen" sample code
from the net in that manner.

My objection with Malcolm's writing is that he is blatantly accusing the
Python library implementers of just grabbing whatever code they found
lying about, without consideration for quality, suitability, copyrights,
licenses, or anything else, then slapping on a "Python wrapper".  Now, I
know some people /do/ work like that, and I have not examined the Python
source code to look at how it was made - but I think Malcolm's comments
are way out of line unless he can provide justification for them.

> 
> Malcolm, please clarify either that you are, or that you are not,
> accusing the Python developers of doing something illegal and/or
> illegitimate.
> 

[toc] | [prev] | [next] | [standalone]

#102532

W dniu czwartek, 26 stycznia 2017 15:44:22 UTC+1 użytkownik Malcolm McLean napisał:
> 
> The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> in under just-noticeable time on my machine.

that could mean that double (this  IEEE 754 ) is not neccessary well defined - some scheme for growing exponent could be maybe used 

not sure if using a numbers larger than 1e1024 (where this 1024 is dot shift in binary afaik) would be really usable,
usable only for fun, or not usable at all (though it seem 
it could be usable, for exampling when calculating mandelbrot it is quite possible to zoom in till it will
stop working - afaik this is a problem with this 10 bit exponent, when resizable scheme would be implemented it could maybe work longer 

if someone has nothing better to do thinking in details on
own/possible double encoding scheme could be somewhat good  (fun) topic 

[toc] | [prev] | [next] | [standalone]

#102539

W dniu piątek, 27 stycznia 2017 16:24:30 UTC+1 użytkownik fir napisał:
> W dniu czwartek, 26 stycznia 2017 15:44:22 UTC+1 użytkownik Malcolm McLean napisał:
> > 
> > The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> > in under just-noticeable time on my machine.
> 
> that could mean that double (this  IEEE 754 ) is not neccessary well defined - some scheme for growing exponent could be maybe used 
> 
> not sure if using a numbers larger than 1e1024 (where this 1024 is dot shift in binary afaik) would be really usable,
> usable only for fun, or not usable at all (though it seem 
> it could be usable, for exampling when calculating mandelbrot it is quite possible to zoom in till it will
> stop working - afaik this is a problem with this 10 bit exponent, when resizable scheme would be implemented it could maybe work longer 
> 
> if someone has nothing better to do thinking in details on
> own/possible double encoding scheme could be somewhat good  (fun) topic

note btw besides double how much usefull/needed would be builtin type of pixel/color

so many operations could be done on that , like mixing,
diming, upsaturating, blending, gamma_corection and more

[toc] | [prev] | [next] | [standalone]

#102553

W dniu piątek, 27 stycznia 2017 16:57:13 UTC+1 użytkownik fir napisał:
> W dniu piątek, 27 stycznia 2017 16:24:30 UTC+1 użytkownik fir napisał:
> > W dniu czwartek, 26 stycznia 2017 15:44:22 UTC+1 użytkownik Malcolm McLean napisał:
> > > 
> > > The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> > > in under just-noticeable time on my machine.
> > 
> > that could mean that double (this  IEEE 754 ) is not neccessary well defined - some scheme for growing exponent could be maybe used 
> > 
> > not sure if using a numbers larger than 1e1024 (where this 1024 is dot shift in binary afaik) would be really usable,
> > usable only for fun, or not usable at all (though it seem 
> > it could be usable, for exampling when calculating mandelbrot it is quite possible to zoom in till it will
> > stop working - afaik this is a problem with this 10 bit exponent, when resizable scheme would be implemented it could maybe work longer 
> > 
> > if someone has nothing better to do thinking in details on
> > own/possible double encoding scheme could be somewhat good  (fun) topic
> 
> note btw besides double how much usefull/needed would be builtin type of pixel/color
> 
> so many operations could be done on that , like mixing,
> diming, upsaturating, blending, gamma_corection and more

i presently mentioned support for this could be usable in asm and c but only recently i seen that it makes quite wieder set of opperations (this makes it would be yet more usable) (some could say that gpu is for working on pixels not cpu but i personally like doing graphics on cpu and
would very much like it)

[toc] | [prev] | [next] | [standalone]

#102541

On Friday, January 27, 2017 at 9:24:30 AM UTC-6, fir wrote:
> W dniu czwartek, 26 stycznia 2017 15:44:22 UTC+1 użytkownik Malcolm McLean napisał:
> > 
> > The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> > in under just-noticeable time on my machine.
> 
> that could mean that double (this  IEEE 754 ) is not neccessary well defined - some scheme for growing exponent could be maybe used 
> 
> not sure if using a numbers larger than 1e1024 (where this 1024 is dot shift in binary afaik) would be really usable,

While modern floating-point hardware isn't equipped to handle it,
processors without floating-point hardware can process the IEEE-754
80-bit extended type more efficiently than 64-bit doubles.  During
the 1980s, many compilers would perform all floating-point computations
by converting operands to that type, doing the necessary computations,
and then converting the result back to "double" or "float" as needed.
The only problem with such a type--but it was a killer--is that C was
designed with the presumption that default argument promotion would
convert *all* floating-point values to the *same* type, but the only
way compilers could uphold that was to make "long double" a synonym for
"double".

[toc] | [prev] | [next] | [standalone]

#102551

W dniu piątek, 27 stycznia 2017 17:07:12 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Friday, January 27, 2017 at 9:24:30 AM UTC-6, fir wrote:
> > W dniu czwartek, 26 stycznia 2017 15:44:22 UTC+1 użytkownik Malcolm McLean napisał:
> > > 
> > > The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> > > in under just-noticeable time on my machine.
> > 
> > that could mean that double (this  IEEE 754 ) is not neccessary well defined - some scheme for growing exponent could be maybe used 
> > 
> > not sure if using a numbers larger than 1e1024 (where this 1024 is dot shift in binary afaik) would be really usable,
> 
> While modern floating-point hardware isn't equipped to handle it,
> processors without floating-point hardware can process the IEEE-754
> 80-bit extended type more efficiently than 64-bit doubles.  During
> the 1980s, many compilers would perform all floating-point computations
> by converting operands to that type, doing the necessary computations,
> and then converting the result back to "double" or "float" as needed.
> The only problem with such a type--but it was a killer--is that C was
> designed with the presumption that default argument promotion would
> convert *all* floating-point values to the *same* type, but the only
> way compilers could uphold that was to make "long double" a synonym for
> "double".

ye i liked this QWORD type, one piece i wrote in old assembly in x86 was mandelbrot viewer/explorer working on this QWORDS

as to "long doubles" i vaguelly remember MS compilers was supporting that, gcc i vaguelly remember no (bad and sad maybe)

[toc] | [prev] | [next] | [standalone]

#102605

W dniu piątek, 27 stycznia 2017 17:39:09 UTC+1 użytkownik fir napisał:
> W dniu piątek, 27 stycznia 2017 17:07:12 UTC+1 użytkownik supe...@casperkitty.com napisał:
> > On Friday, January 27, 2017 at 9:24:30 AM UTC-6, fir wrote:
> > > W dniu czwartek, 26 stycznia 2017 15:44:22 UTC+1 użytkownik Malcolm McLean napisał:
> > > > 
> > > > The C expression pow(3, pow(3, pow(3, 3)) just comes back with "inf"
> > > > in under just-noticeable time on my machine.
> > > 
> > > that could mean that double (this  IEEE 754 ) is not neccessary well defined - some scheme for growing exponent could be maybe used 
> > > 
> > > not sure if using a numbers larger than 1e1024 (where this 1024 is dot shift in binary afaik) would be really usable,
> > 
> > While modern floating-point hardware isn't equipped to handle it,
> > processors without floating-point hardware can process the IEEE-754
> > 80-bit extended type more efficiently than 64-bit doubles.  During
> > the 1980s, many compilers would perform all floating-point computations
> > by converting operands to that type, doing the necessary computations,
> > and then converting the result back to "double" or "float" as needed.
> > The only problem with such a type--but it was a killer--is that C was
> > designed with the presumption that default argument promotion would
> > convert *all* floating-point values to the *same* type, but the only
> > way compilers could uphold that was to make "long double" a synonym for
> > "double".
> 
> ye i liked this QWORD type, one piece i wrote in old assembly in x86 was mandelbrot viewer/explorer working on this QWORDS
> 
> as to "long doubles" i vaguelly remember MS compilers was supporting that, gcc i vaguelly remember no (bad and sad maybe)

maybe this was OWORDS (i dont quite remember the word, qwords should be 64 bit so it would have some other name,
i forgot how it was called, i used tasm or masm dont remember)

[toc] | [prev] | [next] | [standalone]

#102522 — Re: 3**3**3**3

On 24/01/2017 20:45, Stefan Ram wrote:

>   Just a few days ago, I wrote my first Python expression
>   and fed it to an interpreter. It was
> 
> 3**3**3**3

I do have the answer, but it's too large to fit in this margin.

Literally.

(If I am not mistaken, the answer is a 12 Tbit number.)

Related topics:
https://en.wikipedia.org/wiki/Exponentiation#Repeated_exponentiation
https://en.wikipedia.org/wiki/Tetration

Regards.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web