7 ms·
The main issue would be that 64-bit may cause an app to use more memory. Every pointer doubles in size, the alignment of a structure containing a pointer may g
by makecheck 8y ago
The main issue would be that 64-bit may cause an app to use more memory. Every pointer doubles in size, the alignment of a structure containing a pointer may grow, etc. Basically, if you needed a lot of structures allocated and they all grew, your memory use becomes noticeably bigger.
Sometimes legacy code can make assumptions about pointer size. These hacks were more common in the days of porting older systems to 32-bit but it could still happen moving to 64-bit.
If there’s code that tries to manually populate the bytes of data structures, sometimes bugs appear when the target field size changes (e.g. somebody ends up not initializing 4 of the 8 bytes in a now-wider field).
In the case of Apple, the huge pain will be their decision to not port all of Carbon to 32-bit (despite Forstall getting on stage years ago and stating that Carbon was going to be 64-bit “top to bottom”, it never happened). This can mean addressing a whole pile of nothing-to-do-with-64-bit-whatsoever problems before even starting to solve 64-bit problems.
- rusk 8y ago> despite Forstall getting on stage years ago Well we all know what happened to Forstall ... and the entire software development roadmap after he left ...
- microtherion 8y agoApple's 64 bit strategy was in place by 2007 (It would hardly make sense to omit some 64 bit Cocoa APIs in MacOS X 10.5, only to bring them back later, would it?). Forstall left in 2012. Your alternate history timeline may need some work ;-)
- rusk 8y agoI don’t think so. Was there a projected date for completion of the migration? We’ve only got pervasive 64-bit in the last 6 years so doubtful it would have been before then.
- microtherion 8y agoAs far as I recall, userland APIs had all their 64-bit support in place in 10.5 (2007). Kernel 64-bit support came in 10.6 (2009). Which 64-bit features are you thinking of in the last 6 years? To clarify, I'm referring to macOS releases. On iOS, 64-bit support obviously came within the last 6 years, but Carbon was never in the picture on iOS anyway.
- rusk 8y agoCarbon, as per GP ...
- microtherion 8y ago> despite Forstall getting on stage years ago and stating that Carbon was going to be 64-bit “top to bottom” This is the second time I've seen you make that claim. Can you, by any chance, recall on which occasion he said this (or dig up the exact quote)? AFAIK the plan was always to use the 64 bit transition as an opportunity to shed deprecated APIs, so to imply otherwise in public would have been rather irresponsible.
- wlesieutre 8y agoI don't know about that particular quote, but this has a photo of the WWDC side claiming 64-bit Carbon and Cocoa, so that was definitely the original plan https://www.wired.com/2007/06/leopard-won-t-support-64-bit-carbon-apps/ https://www.wired.com/2007/06/leopard-won-t-support-64-bit-c...
- microtherion 8y agoHmm, that is plausible. I stand corrected.
- valuearb 8y agoThe increase in pointer size is trivial in todays memory limits. An application with a million pointers will only use 4 megabytes more memory.
- qaq 8y agoCPU cache will not magically double in size to accommodate, so performance will suffer
- megaman22 8y agoI'm pretty okay with Visual Studio using significantly more memory than it does now, if it meant it would stop thrashing the disk constantly and locking up the text editor. My dev machines have between 16 and 32 GB of RAM, and even the wimpiest laptop I've used in the past five years had 8GB. But anytime it gets close to 2GB of memory used, it starts turning into "Microsoft Visual Studio (is not responding)"