Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Changing intobject to use int rather than long

Reply
Thread Tools

Changing intobject to use int rather than long

 
 
Clarence
Guest
Posts: n/a
 
      12-18-2007
Does anyone think (or know) that it might cause any internal problems
if the ival member of the struct defining an intobject were to be
changed from its current "long int" to just "int"?

When you move your application to a 64-bit system in order to get a
bigger address space to store your millions/billions of integers in
RAM, but they get twice as big, you don't gain very much.

Thanks.
 
Reply With Quote
 
 
 
 
Chris Mellon
Guest
Posts: n/a
 
      12-18-2007
On Dec 18, 2007 11:59 AM, Clarence <(E-Mail Removed)> wrote:
> Does anyone think (or know) that it might cause any internal problems
> if the ival member of the struct defining an intobject were to be
> changed from its current "long int" to just "int"?
>
> When you move your application to a 64-bit system in order to get a
> bigger address space to store your millions/billions of integers in
> RAM, but they get twice as big, you don't gain very much.
>


Your int objects get twice as large, but you get 4294967296 times more
address space.

(They don't always get twice as large, and you don't actually get that
much address space, and there's lots of other things wrong with this
answer, but the core truth - that your available address space grows
at a greater rate than the size of your ints - is correct).

> Thanks.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

 
Reply With Quote
 
 
 
 
Clarence
Guest
Posts: n/a
 
      12-18-2007
On Dec 18, 6:24 pm, "Chris Mellon" <(E-Mail Removed)> wrote:
>
> Your int objects get twice as large, but you get 4294967296 times more
> address space.
>
> (They don't always get twice as large, and you don't actually get that
> much address space, and there's lots of other things wrong with this
> answer, but the core truth - that your available address space grows
> at a greater rate than the size of your ints - is correct).


Technically true, but in my real world, I deal with physical RAM in
the machine. I went from a 2GB machine that was using half its memory
to an 8GB machine that is using one quarter its memory. Yes, it's
better,
but I still want that factor of two!
 
Reply With Quote
 
Hrvoje Niksic
Guest
Posts: n/a
 
      12-18-2007
Clarence <(E-Mail Removed)> writes:

> When you move your application to a 64-bit system in order to get a
> bigger address space to store your millions/billions of integers in
> RAM, but they get twice as big, you don't gain very much.


I don't think changing the underlying type will help at all. The
layout of the int object is as follows:

typedef struct {
// PyObject_HEAD
Py_ssize_t ob_refcnt;
struct _typeobject *ob_type;
// the actual value
long ob_ival;
} PyIntObject;

On a 64-bit machine, that's 16 bytes for PyObject_HEAD and 8 more
bytes for the value, 24 bytes total. Changing long to int won't
decrease the struct size to 20 because the compiler will pad it to 24,
the nearest multiple of 8. (Forcing the compiler to pack the struct
won't help because malloc will still pad it for you.)

If you need to store millions of integers compactly, maybe
array.array('i') can help.
 
Reply With Quote
 
Clarence
Guest
Posts: n/a
 
      12-18-2007
On Dec 18, 6:58 pm, Hrvoje Niksic <(E-Mail Removed)> wrote:

> I don't think changing the underlying type will help at all. The


>
> On a 64-bit machine, that's 16 bytes for PyObject_HEAD and 8 more
> bytes for the value, 24 bytes total. Changing long to int won't
> decrease the struct size to 20 because the compiler will pad it to 24,
> the nearest multiple of 8. (Forcing the compiler to pack the struct
> won't help because malloc will still pad it for you.)


That's an excellent point. And true, too. Thanks, that will lay the
issue
to rest.

> If you need to store millions of integers compactly, maybe
> array.array('i') can help.


 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      12-18-2007

"Clarence" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
| That's an excellent point. And true, too. Thanks, that will lay the
| issue to rest.

Good idea. I think people who moved to 64 bits to get 64 bits would be
upset if they did not .





 
Reply With Quote
 
Martin v. Lwis
Guest
Posts: n/a
 
      12-18-2007
>> On a 64-bit machine, that's 16 bytes for PyObject_HEAD and 8 more
>> bytes for the value, 24 bytes total. Changing long to int won't
>> decrease the struct size to 20 because the compiler will pad it to
>> 24, the nearest multiple of 8. (Forcing the compiler to pack the
>> struct won't help because malloc will still pad it for you.)

>
> That's an excellent point. And true, too. Thanks, that will lay the
> issue to rest.


As a side observation, notice how the increase in memory consumption
does not primarily originate from the increase in the size of a long.
Instead, all pointers double their sizes. In an OO language (like
Python), you have lots of pointers, so you will often find that the
application uses more memory when run in 64-bit mode.

If that is a concern to you, let me rephrase Terry's observation:
just try running a 32-bit Python interpreter on your 64-bit system,
and you may find that it actually runs better because it uses less
memory.

Regards,
Martin
 
Reply With Quote
 
Christian Heimes
Guest
Posts: n/a
 
      12-19-2007
Terry Reedy wrote:
> Good idea. I think people who moved to 64 bits to get 64 bits would be
> upset if they did not .


Windows X64 users still get 32bit ints. The long datatype is 32bit even
on the 64bit version of Windows.

Christian

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      12-19-2007

"Christian Heimes" <(E-Mail Removed)> wrote in message
news:fkainq$61f$(E-Mail Removed)...
| Terry Reedy wrote:
| > Good idea. I think people who moved to 64 bits to get 64 bits would be
| > upset if they did not .
|
| Windows X64 users still get 32bit ints. The long datatype is 32bit even
| on the 64bit version of Windows.

Yes, anyone expecting to get 64 bit ints from Windows would be upset. And
those who are getting 64 bit ints from real 64 bit OSes would be upset if
the OPs suggestion were implemented.



 
Reply With Quote
 
Hrvoje Niksic
Guest
Posts: n/a
 
      12-22-2007
"Terry Reedy" <(E-Mail Removed)> writes:

> "Christian Heimes" <(E-Mail Removed)> wrote in message
> news:fkainq$61f$(E-Mail Removed)...
> | Terry Reedy wrote:
> | > Good idea. I think people who moved to 64 bits to get 64 bits would be
> | > upset if they did not .
> |
> | Windows X64 users still get 32bit ints. The long datatype is 32bit even
> | on the 64bit version of Windows.
>
> Yes, anyone expecting to get 64 bit ints from Windows would be
> upset.


Why? Using only 32 bits doesn't make the structure any smaller
because of pointer alignment.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Promoting unsigned long int to long int pereges C Programming 112 07-28-2008 05:00 AM
Having compilation error: no match for call to (const __gnu_cxx::hash<long long int>) (const long long int&) veryhotsausage C++ 1 07-04-2008 05:41 PM
unsigned long long int to long double Daniel Rudy C Programming 5 09-20-2005 02:37 AM
int main(int argc, char *argv[] ) vs int main(int argc, char **argv ) Hal Styli C Programming 14 01-20-2004 10:00 PM
dirty stuff: f(int,int) cast to f(struct{int,int}) Schnoffos C Programming 2 06-27-2003 03:13 AM



Advertisments