Using Python 32-bit (with Idle) in 64-bit System

[WWGD]

Hi,
I somehow carelessly installed Python 3.72, 32-bit in my 64-bit system. Is this a workable situation or will I pay a price eventually in a conflict between 32-bit software living in a 64-bit system? Should I uninstall and reinstall a 64-bit version?

 

[Mark44]

Hi,
I somehow carelessly installed Python 3.72, 32-bit in my 64-bit system. Is this a workable situation or will I pay a price eventually in a conflict between 32-bit software living in a 64-bit system? Should I uninstall and reinstall a 64-bit version?

The 32-bit version will work just fine in your 64-bit system. I think that the "price" you pay is not being able to use 64-bit types. Sort of related is that my VS compiler can generate either 32-bit or 64-bit executables, both of which run fine, within their limitations.

In your title, you have "Using Python 32-bit (with Idle) in 64-bit System." Was that a typo for IDE?

 

[PeterDonis]

I think that the "price" you pay is not being able to use 64-bit types.

For Python this doesn't really matter unless you are writing C extension modules. The Python 3 interpreter itself doesn't expose any Python types that are sensitive to whether the underlying OS is 32-bit or 64-bit. Python 2 did, because it had int and long as separate types, and the largest integer that int could represent was sensitive to the bit width. But Python 3's int, which is its only integer type, is the same as Python 2's long, and can represent arbitrarily large integers, and doesn't expose anything about the underlying OS bit width. There might be a small difference in speed for very heavy numeric computations, but that's an extremely specialized niche application.

 

[PeterDonis]

Is this a workable situation or will I pay a price eventually in a conflict between 32-bit software living in a 64-bit system?

Not from Python's standpoint. It might from your OS's standpoint, depending on which OS you are running. I have never heard of 64-bit Linux or Mac OS X having any problem running 32-bit executables; I can't say the same about Windows.

 

[WWGD]

The 32-bit version will work just fine in your 64-bit system. I think that the "price" you pay is not being able to use 64-bit types. Sort of related is that my VS compiler can generate either 32-bit or 64-bit executables, both of which run fine, within their limitations.

In your title, you have "Using Python 32-bit (with Idle) in 64-bit System." Was that a typo for IDE?

No, the IDE is called IDLE (Maybe for Eric, to continue the Python analogy)? https://duckduckgo.com/?q=idle+for+python&t=hk&ia=web

 

[WWGD]

Not from Python's standpoint. It might from your OS's standpoint, depending on which OS you are running. I have never heard of 64-bit Linux or Mac OS X having any problem running 32-bit executables; I can't say the same about Windows.

It is Win10 which has had good reviews , even from some (otherwise) skeptics.

 

[sysprog]

The main problem with 32-bit code on a 64-bit system is the 4GB limit that the smaller word size imposes on memory references. If you only need to use, say, 2GB at once, you may find that the 32-bit version is beneficially leaner. It wasn't so long ago that 4GB was a lot of memory for a PC, but these days, 8GB is common, and 16GB is not uncommon. Your 64-bit machine adapts well to running code in 32-bit x86-mode. If you look at your memory allocation, and find that what you're running in your python environment is going beyond 4GB and demanding a lot of swap-file IO, then it's definitely worth your effort to switch to the 64-bit version.

 

[willem2]

If you look at your memory allocation, and find that what you're running in your python environment is going beyond 4GB and demanding a lot of swap-file IO, then it's definitely worth your effort to switch to the 64-bit version.

If you run out of address space with a 32 bit program, you won't get swapping, it will simply run out of memory and produce an error. Swapping happens if you run out of physical memory. If that happens with 32 - bit programs, switching to 64 bit won't help. 64 bit programs use a bit more memory because all the pointers will be 64 bit (can be important if there are many small objects)

 

[PeterDonis]

If you look at your memory allocation, and find that what you're running in your python environment is going beyond 4GB and demanding a lot of swap-file IO

Swapping doesn't occur because a 32-bit program asks for more than 4 GB of memory. A 32-bit program can't ask for more than 4 GB of memory, because a 32-bit pointer can only address 4 GB worth of memory. A 32-bit program that needs to work on more than 4 GB worth of data needs to be explicitly written to only load part of the data into memory at a time.

Swapping occurs because multiple programs on a system are asking for an aggregate amount of memory that is more than is physically available on the machine. For example, you could have two 32-bit programs each asking for 3 GB of memory, on a machine that only has 4 GB of physical memory (the maximum a 32-bit machine can have). In that case, the operating system has to swap parts of each of the programs' requested memory out to disk. This is invisible to the programs except as a time delay in accessing memory addresses in their address space that were swapped (because the OS has to swap something else out to swap that data back in).

 

[sysprog]

If you run out of address space with a 32 bit program, you won't get swapping, it will simply run out of memory and produce an error. Swapping happens if you run out of physical memory. If that happens with 32 - bit programs, switching to 64 bit won't help. 64 bit programs use a bit more memory because all the pointers will be 64 bit (can be important if there are many small objects)

In a system with 4GB or more of physical memory, a 32-bit program will encounter a V=R (vitual-real) situation, and so will, as you pointed out, not cause the OS to do swap file IOs for purpose of allowing a larger virtual memory than real memory.

Even so, python memory management keeps a tally of how much storage is being used overall, and the python runtime environment will itself start swapping things around when the total is nearing its 4GB limit. That will cause an increase in IOs for the device that holds the things being swapped around.

If you find that your 32-bit python system is running close to 4GB, it might be better to switch to the 64-bit system, so that more programs and data can be simultaneously memory-resident.

 

[sysprog]

Swapping doesn't occur because a 32-bit program asks for more than 4 GB of memory. A 32-bit program can't ask for more than 4 GB of memory, because a 32-bit pointer can only address 4 GB worth of memory. A 32-bit program that needs to work on more than 4 GB worth of data needs to be explicitly written to only load part of the data into memory at a time.

Swapping occurs because multiple programs on a system are asking for an aggregate amount of memory that is more than is physically available on the machine. For example, you could have two 32-bit programs each asking for 3 GB of memory, on a machine that only has 4 GB of physical memory (the maximum a 32-bit machine can have). In that case, the operating system has to swap parts of each of the programs' requested memory out to disk. This is invisible to the programs except as a time delay in accessing memory addresses in their address space that were swapped (because the OS has to swap something else out to swap that data back in).

Agreed.