List Info

Thread: Regarding universal python framework....




Regarding universal python framework....
user name
2007-01-30 16:13:53
Hi all,

I had a question/comment from a numpy/Scipy developer that I
was asked 
to forward on:

> > To get the "definition" of
"universal" I went to
> > http:
//en.wikipedia.org/wiki/Universal_Binaries
> >
> > the last paragraph says:
> > Apple's Xcode 2.4 takes the concept of universal
binaries even
> > further, by allowing four-architecture binaries to
be created (32 and
> > 64 bit for both Intel and PowerPC), therefore
allowing a single
> > executable to take full advantage of the CPU
capabilities of any Mac
> > OS X machine

What are folk's thoughts on building "quad binary"
universal builds in 
the future? Is there much point? Are there any 64bit Intel
Macs? What 
difference might a 64bit build make on a G5?

For the app in mind, this is the issue:

I am interested in 64-bit because it is supposed to be able
to
open >4GB data files in memmap mode (that is, you could
treat any
large data set like a normal numpy array and
*instantaneously* access
sub-data without ever loading the entire file. Note that
this works
even with small amounts of physical memory, only the
(theoretical)
memory address space has to be 64bit.)

thoughts?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barkernoaa.gov
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: Regarding universal python framework....
user name
2007-01-30 16:21:30
On 1/30/07, Christopher Barker <Chris.Barkernoaa.gov> wrote:
> Hi all,
>
> I had a question/comment from a numpy/Scipy developer
that I was asked
> to forward on:
>
> > > To get the "definition" of
"universal" I went to
> > > http:
//en.wikipedia.org/wiki/Universal_Binaries
> > >
> > > the last paragraph says:
> > > Apple's Xcode 2.4 takes the concept of
universal binaries even
> > > further, by allowing four-architecture
binaries to be created (32 and
> > > 64 bit for both Intel and PowerPC), therefore
allowing a single
> > > executable to take full advantage of the CPU
capabilities of any Mac
> > > OS X machine
>
> What are folk's thoughts on building "quad
binary" universal builds in
> the future? Is there much point? Are there any 64bit
Intel Macs? What
> difference might a 64bit build make on a G5?

A 64-bit build would use more RAM, and it would let you
address more
RAM. That's pretty much it. It would also be only usable on
leopard. I
tried to build ppc64 on my G5 with tiger and it just crashed
(and I
didn't have enough reason to figure out exactly why).

For intel it's probably a bit different because there's more
registers
and whatnot in 64-bit mode... so it may actually be an
overall
performance win for machines that can do it.

I think all Core 2 Duo machines are x86-64 capable.

> For the app in mind, this is the issue:
>
> I am interested in 64-bit because it is supposed to be
able to
> open >4GB data files in memmap mode (that is, you
could treat any
> large data set like a normal numpy array and
*instantaneously* access
> sub-data without ever loading the entire file. Note
that this works
> even with small amounts of physical memory, only the
(theoretical)
> memory address space has to be 64bit.)

That is a good use case for having a 64-bit address space.

The problem with a quad binary build is that there's a lot
more
difference between 32-bit and 64-bit than there is from PPC
and Intel.
It would be a lot of work to make that happen. It would also
end up in
pain because I believe that a 64-bit machine would default
to using
the 64-bit version of the executable which wouldn't be
compatible with
any existing extensions.

It would make a lot of sense to have a 64-bit python
distribution that
was built for x86-64 and ppc64... but I don't think it would
be a good
idea to try and make python build quad.

-bob
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: Regarding universal python framework....
user name
2007-01-30 17:31:27
Thanks Bob,

We can always count on you for having useful ideas about all
sorts of stuff.

It does sound like a quad binary wouldn't be a good idea.

> For intel it's probably a bit different because there's
more registers
> and whatnot in 64-bit mode... so it may actually be an
overall
> performance win for machines that can do it.
> 
> I think all Core 2 Duo machines are x86-64 capable.

Isn't that all Intel Macs?

> The problem with a quad binary build is that there's a
lot more
> difference between 32-bit and 64-bit than there is from
PPC and Intel.

Wow! that's a surprise to me. I suppose there are a LOT of
32 bit 
assumptions built into  a lot of code.

> It would be a lot of work to make that happen. It would
also end up in
> pain because I believe that a 64-bit machine would
default to using
> the 64-bit version of the executable which wouldn't be
compatible with
> any existing extensions.

Would setup.py build Universal extensions right (if the
extension was 
written to support 64 bit)?

> It would make a lot of sense to have a 64-bit python
distribution that
> was built for x86-64 and ppc64...

Hmm. I like that idea. Now we just need a bunch of people to
find the 
time.....

-Chris





-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barkernoaa.gov
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: Regarding universal python framework....
user name
2007-01-30 17:36:32
On 1/30/07, Christopher Barker <Chris.Barkernoaa.gov> wrote:
>
> Thanks Bob,
>
> We can always count on you for having useful ideas
about all sorts of stuff.
>
> It does sound like a quad binary wouldn't be a good
idea.
>
> > For intel it's probably a bit different because
there's more registers
> > and whatnot in 64-bit mode... so it may actually
be an overall
> > performance win for machines that can do it.
> >
> > I think all Core 2 Duo machines are x86-64
capable.
>
> Isn't that all Intel Macs?

No. The first few revisions were Core Duo, not Core 2 Duo.
The MacBook
Pro I have definitely isn't 64-bit or 802.11n...

> > The problem with a quad binary build is that
there's a lot more
> > difference between 32-bit and 64-bit than there is
from PPC and Intel.
>
> Wow! that's a surprise to me. I suppose there are a LOT
of 32 bit
> assumptions built into  a lot of code.

It's not so much that there are 32-bit assumptions but that
there are
checks that do different things between 32-bit and 64-bit
code, and if
that check is done during configure or setup.py then it's
not
compatible with the way that universal binaries are
typically built.

> > It would be a lot of work to make that happen. It
would also end up in
> > pain because I believe that a 64-bit machine would
default to using
> > the 64-bit version of the executable which
wouldn't be compatible with
> > any existing extensions.
>
> Would setup.py build Universal extensions right (if the
extension was
> written to support 64 bit)?

Sure. Distutils builds things the same way that Python was
built
unless you tell it otherwise.

> > It would make a lot of sense to have a 64-bit
python distribution that
> > was built for x86-64 and ppc64...
>
> Hmm. I like that idea. Now we just need a bunch of
people to find the
> time.....

Good luck  Personally
I have neither the time, need, or the (intel) hardware.

-bob
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )