[Patches] [ python-Patches-601369 ] obmalloc,structmodule: 64bit, big endian

[noreply@sourceforge.net]

Patches item #601369, was opened at 2002-08-28 18:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470

Category: Modules
Group: Python 2.2.x
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Guido van Rossum (gvanrossum)
Summary: obmalloc,structmodule: 64bit, big endian

Initial Comment:
Issue 1: in Objects/obmalloc.c, SYSTEM_PAGE_SIZE 
is assumed to be 4K.  I corrected (#if _MIPS_ABI>=4) 
the page size at least for 64bit SGI Irix machines.

Issue 2: in Modules/structmodule.c, most of the 
un/packing functions assumed that the char *p 
argument (destination or source for un/packing) is 
correctly aligned for the concerned type.  It is no 
problem for x86 processors (2 cycle access instead of 1 
if unaligned), but it is a problem for 64bit MIPS 
processors (where an int is 64bit and it must be at least 
on a 4-byte boundary).
All the functions handling types larger than 1 byte use 
memcpy now, taking care of endianess with an 
intermediate variable y wherever needed.
The sparse comments stating "p may not be properly 
aligned" are removed, and a more thorough comment is 
inserted before the definitions of the un/packing 
functions.
The patched module passes test_struct fine in 64-bit 
and 32-bit builds on an SGI Octane with MIPS cc; so it 
does on a Pentium Linux with gcc.  I have no way to 
make a Windows build.  Pack formats prefixed with '!' 
or '>' produce the same sizes everywhere.

----------------------------------------------------------------------

>Comment By: Christos Georgiou (tzot)
Date: 2002-09-04 17:23

Message:
Logged In: YES 
user_id=539787

Tim is probably right.

Compiled obmalloc.c with PYMALLOC_DEBUG and running
test.testall with PYTHONMALLOCSTATS, here are some
statistics results:

4K maximum numbers:
# bytes in allocated blocks        =           33,964,192
# bytes in available blocks        =               63,056
# bytes lost to pool headers       =              405,216
# bytes lost to quantization       =              145,968
# bytes lost to arena alignment    =              548,864

16K maximum numbers:
# bytes in allocated blocks        =           33,970,384
# bytes in available blocks        =              289,824
# bytes lost to pool headers       =              100,800
# bytes lost to quantization       =               45,392
# bytes lost to arena alignment    =            2,293,760

The overall size of the python process remained in both
cases at 223MB the most.
I don't think I should research more into it.  I will try to
make a patch for the current 2.2 branch too.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-09-03 21:43

Message:
Logged In: YES 
user_id=6380

Tim sez, the obmalloc.c patch should not go in unless
supported by measurements.

I do like the structmodule.c patch, and have check it in.
Thanks!

PS the structmodule patch might apply to Python 2.2.x too.
Somebody should backport it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470