How to make Python run as fast (or faster) than Julia

[Chris Angelico]

On Sat, Feb 24, 2018 at 3:39 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Fri, 23 Feb 2018 23:41:44 +1100, Chris Angelico wrote:
>
> [...]
>>>  Integer pixel values
>>
>> Maybe in 64 bits for the time being, but 32 certainly won't be enough.
>> As soon as you do any sort of high DPI image manipulation, you will
>> exceed 2**32 total pixels in an image (that's just 65536x65536, or
>> 46341x46341 if you're using signed integers);
>
> I don't think there's any sensible reason to use signed ints for pixel
> offsets.

How about "my language's default integer type is signed"? That's what
gave us all manner of problems, like the way a whole lot of old (and
some not even all THAT old) programs have trouble if you have more
than 2GB of free space - because they query disk free space as a
32-bit number, then interpret that number as signed. (If, as on many
modern systems, you have hundreds or thousands of gig free, it depends
whether that number modulo 4GB is more than 2GB, which is a very fun
thing to manage.)

>> and it wouldn't surprise
>> me if some image manipulation needs that many on a single side - if not
>> today, then tomorrow. So 64 bits might not be enough once you start
>> counting total pixels.
>
> 64-bit int will limit your image size to a maximum of 4294967296 x
> 4294967296.
>
> If you stitched the images from, let's say, the Hubble Space Telescope
> together into one panoramic image of the entire sky, you'd surely exceed
> that by a couple of orders of magnitude. There's a lot of sky and the
> resolution of the Hubble is very fine.
>
> Or made a collage of all the duck-face photos on Facebook *wink*
>
> But you wouldn't be able to open such a file on your computer. Not until
> we get a 128-bit OS :-)

Hmm, yeah, I didn't actually do the math on that, heh.

> While all of this is very interesting, let's remember that listing all
> the many things which can be counted in 64 bits (or 128 bits, or 1024
> bits...) doesn't disprove the need for bignums. The argument Bart makes
> is to list all the things that don't need refrigerating:
>
> - tinned beans
> - nuts and bolts
> - DVDs
> - books
> - spoons
>
> as evidence that we don't need refrigerators. Yeah, I get it, there are
> approximately a hundred thousand million billion trillion things that
> don't need bignums. There are so many things that don't need bignums, you
> need a bignum to count them all!

Touche!

> And I don't give a rat's arse that this means that adding 1 to 10 to get
> 11 in Python takes thirty nanoseconds instead of ten nanoseconds as a
> consequence. If I cared about that, I wouldn't be using Python.

Which is why you don't do crypto in Python - because you DO care about
whether it takes thirty sometimes and ten sometimes, and various other
things.

So there *are* situations where you specifically do not want bignums;
but they're a lot rarer than situations where you don't care what the
underlying implementation is, and it's incredibly freeing to not have
to take integer magnitude limitations into account.

ChrisA