32 vs 64 bit systems

Brogan

Is there any difference in coding PHP for 64 bit systems and for 32 bit systems.

Thanks
Brogan

bradgrafelman

Sure, there are some differences; approximately 32 of them. 😉

"Coding" is pretty general and vague... or, in a word, ambiguous. There's the obvious difference, of course; a 64-bit version of PHP can handle a 64-bit integer, for example.

cretaceous

for general intents and purposes the answer is 'no'

bradgrafelman

cretaceous;10993912 wrote:
for general intents and purposes

Again, that's ambiguous enough such that the answer could actually be 'yes.' For example, I would consider dates and the [man]date/man function pretty 'general', and yet that function has different limitations depending upon whether you're using a 32-bit PHP binary or a 64-bit binary.

As far as actual code execution, data structures, etc. (pretty much anything not related to a range/size of values), though, cretaceous is right; there isn't anything drastically different.

sneakyimp

cretaceous;10993912 wrote:
for general intents and purposes the answer is 'no'

Perhaps cretaceous is right -- for the vast majority of PHP operations, there is no difference at all. Then, one day, you will have a weird problem where you need to work with an integer value larger than 4,300,000,000 and the computer treats it as a float and you have a rounding error.

The biggest difference between 32-bit and 64-bit OS in my opinion is that a 32-bit OS usually cannot handle more than 3.2Gigabytes of memory.

In the opposite direction, one can run into problems with software that was written to run on a 32-bit OS which runs incorrectly (or not at all) on a 64-bit OS. AFAIK I have never run into this problem in a linux environment.

My advice is try as hard as you can to get a 64-bit machine. You may need lots of RAM some day and, personally, I'd like to see the day when 32-bit OS is history.

bradgrafelman

sneakyimp;10993915 wrote:
AFAIK I have never run into this problem in a linux environment.

The environment isn't really the most important factor, rather how that software was written at a lower level (something written in C, for example). Some mathematical operations/comparisons might need to be revisited when porting a 32-bit app over to a 64-bit arch.

sneakyimp;10993915 wrote:
I'd like to see the day when 32-bit OS is history.

Think we learned our lesson over the Y2K scare, or will we panic all over again when Y2K38 comes about? :p

sneakyimp

bradgrafelman;10993918 wrote:
The environment isn't really the most important factor, rather how that software was written at a lower level (something written in C, for example). Some mathematical operations/comparisons might need to be revisited when porting a 32-bit app over to a 64-bit arch.

I mentioned the OS because I've had frequent occasions on both Mac and Windows machines where the software just won't run. I have so far not had this issue with my linux machines -- although there's an astronomy app on ubuntu that was missing all of its buttons on the 64-bit OS but ran fine on the 32-bit OS.

bradgrafelman;10993918 wrote:
Think we learned our lesson over the Y2K scare, or will we panic all over again when Y2K38 comes about? :p

I would imagine that some consultants made a lot of money over the Y2K scare. As for our PHP code, I would imagine that the zend guys will have sorted it by Y2K38 -- unless we happen to keep our apps running PHP 5.x that long :p

Brogan

Thanks Guy's, I think I have found out what I needed to know.
I am working with a Bot for Farmville (am not a programmer), I beta test and we only have one programmer and need many more. All the calls for help come from 64 bit sys.'s of all flavors, this is what prompted my post.
If only we had more programmers, of any skill level.

Thanks again
Brogan

Bonesnap

sneakyimp;10993915 wrote:
The biggest difference between 32-bit and 64-bit OS in my opinion is that a 32-bit OS usually cannot handle more than 3.2Gigabytes of memory.

It's actually 4GB of memory. You usually only see 3.2GB - 3.5GB due to the OS using address space for other things like the PCI/PCIe bus (or both) and some other low-level things.

Good thing 64-bit OSes can allocate 16EB, since that's all we'll ever need, right? 😉

Derokorian

EB? EpicBytes?? 😛 What is that roughly 10⁹ GB right? I can't imagine having that much ram ever being necessary but I'm sure 25 years ago people couldn't imagine having a GB of ram so... Time will tell!

Bonesnap

EB = exabyte

Agreed, who knows what the future may hold, but the difference of memory allowed in a 64-bit system vs a 32-bit system is astronomical.

And sorry, I should have written 64-bit OSes can allocate 16EiB (exbibytes).

sneakyimp

Yes bonesnap you are right I think. If you use 32-bit integers to uniquely identify all of your memory locations, that permits a maximum of 4,294,967,296. If you use 64-bit integers, you get 18,446,744,073,709,551,616 locations. And after 64-bits, there are always 128-bit processors and operating systems:

wikipedia wrote:
128-bit processors could be used for addressing directly up to 2¹²⁸ (over 3.40 × 10³⁸⁾ bytes, which would greatly exceed the total data stored on Earth as of 2010, which has been estimated to be around 1.2 zettabytes (over 2⁷⁰ bytes).

Apparently the IBM System I servers are ready for 128 bit processors when they become available.

Ashley_Sheridan

I've had problems with 32-bit Linux when trying to get file data (timestamps, owner data, etc) from files that were over 4GB using the standard PHP functions. Not sure why the timestamp of a 4GB file wasn't readable with a 32-bit system, but switching to 64-bit did fix this.

Saying that, there can be occassions where libraries/binaries used in PHP don't work correctly in 64-bit, although largely I think they are historical issues which are mostly resolved now.