Slashdot Mirror
Why Apple Went 64-Bit With the iPhone 5s
Hugh Pickens DOT Com writes "Adrian Kingsley-Hughes says it's not just because Apple likes bragging about being first and because a 64-bit processor sounds cooler than 32-bits that Apple used the 64-bit A7 chip in the new iPhone 5s. A shift from a 32-bit processor to a 64-bit part paves the way for iPhones to be fitted out with 4GB+ of RAM down the line, but more importantly the move brings iOS and OS X apps much closer. The architecture for 64-bit apps on iOS will be almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. 'Apple has slowly been bringing iOS-like features to Mac OS for years now: think of Launchpad and Gatekeeper,' writes Sascha Segan. 'The ultimate prize, of course, would be to bring the million-plus iOS apps to Macs. Apple could do that with an ARM-compatible virtual machine on Mac hardware, but it would want the VM, the OS and the associated apps to play nicely in the much larger memory space available on Macs. That means moving the whole system over to 64 bit.' By unifying iOS and Mac OS with Xcode developer tools in a 64-bit space, Apple could once again leap ahead of Microsoft and Google, says Segan. Microsoft hasn't yet been able to leverage its desktop strengths to achieve success as a mobile OS. The 64-bit chips for Android devices aren't ready, and neither is Android itself."
If it's such a big deal in order to get the same software to run on both systems then how does the Debian project manage to bring 37 000 packages to all eight architectures that it's currently running on? Magic?
The vast majority of which will be horrible on OS-X due to being designed solely for a touch interface.
Having iOS and OS-X be close together to ease development for both platforms is good but expecting the same program to run well on both isn't.
Some changes will need to be made for the keyboard and mouse versus fully touch interface as well as the difference in screen resolutions.
This isn't going to make a magic pill to port them all over flawlessly.
Comment removed based on user account deletion
If they wanted they could just throw their ARM chip into the Mac. Cross platform both ways. The reason why Apple went 64bit ARM is: it was time.
Help stamp out iliturcy.
So you didn't even bother to read the summary did you?
I doesn't hurt Apple that this will effectively make all 32-bit iOS devices worthless in a year or so.
4GB RAM? Current iPhones have 1GB, and since they don't have real multitasking there is little need for 4GB+.
As for bringing OS X and iOS closer, clearly this guy doesn't understand what a compiler does or why the difference between 32 and 64 bit is irrelevant for porting 99.9% of apps.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I forget how many cat versions Apple used to say was finally ready for 64 bit. I think it started in 10.2, 10.3 definitly had it. But Cocoa didn't go 64 bit until 10.5 and the kernel was still 32 bit until 10.7. So I don't know about this "designed from the ground up", more like "bolted on in the last minute."
I'm sure marketing was a big reason. They didn't seem to have much else to offer with their latest phone.
Phones are not going to have more than 4GB or RAM any time soon.
Right, because they don't already have 2GB.
64-bit is Marketing BS at this point.
Right, because there are no algorithms, none whatsoever, not mmapped in-memory databases, not modern runtimes, which benefit from having a large address space that will not be exhausted by fragmentation. Yep, none at all.
Adrian Kingsley-Hughes says it's not just because Apple likes bragging about being first and because a 64-bit processor sounds cooler than 32-bits that Apple used the 64-bit A7 chip in the new iPhone 5s.
Mmmm, that 6th grade sentence structure. Stay in school, kiddies. Make sure you don't wind up a Slashdot editor. That's like the McDonalds Drive-Thru of tech blog jobs.
All of the iOS "features" that Apple has ported to my Mac have been stupid and irritating and I have disabled them (when I could).
Please, my computer is not a phone. Haven't you learned anything from Windows 8?
There is a reason that Microsoft has not been able to leverage its desktop strengths in a mobile device... it's because my computer is not a phone and it doesn't want to be a phone and I don't want it to be a phone. I want a keyboard and a mouse, not a gorilla arm and a smudged screen.
I don't read your sig. Why are you reading mine?
Several journalists have made this mistake, such as the drivel posted here: Trusted Reviews
They seem to think that the register size being equal means that software written for them is somehow much more similar. In reality the CPUs and the software they run are no closer to each other than before. The main benefit of this move to the latest ARM CPU design is ironically much the same as the advantage brought by x86_64 - more registers are now available and some floating point operations are more efficient. This will translate into a small performance increase but it won't be night and day.
Android is ready for x64, TFA doesn't have a clue. It's just a recompile away. In fact, because most Android apps are written in Java they will take advantage of 64 bit CPUs without even a recompile.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
If you're virtualizing ARM, making it 64-bit just makes it harder. 64-bit CPUs have access to all the 32-bit instructions you need. It's still virtualized, though.
Apple loves to be "first". They love to have something they can claim to be first on, be better on. Doesn't matter if said thing really is an improvement, they'll sell it like one and fanboys buy in to it pretty heavily.
So, here they can claim to be 64-bit and talk about how that is better. Doesn't matter that it doesn't actually help in the real world, at least at this point, they can sell it as awesome and powerful and something those other nasty, crappy, phones don't have.
In terms of app compatibility, that is all to do with APIs. 64-bit matters not at all, since ARM and x86 are completely different architectures so there WILL be a recompile, no matter what. If they put their iOS APIs on OS-X, then that can be used to port apps to it pretty easy.
So my bet is you are right, this is all marketing at this point. They can say "OMG we has 64 of t3h bits!" and use that as a selling point.
the ubuntu edge was going to have 4gb of ram, but it only got 13 million out of the 32million funding goal
I get the technical reasons why this would allow the flexibility of easily porting/running iOS apps on OS X Macs ... but I'm trying to figure out what the real benefits would be?
The vast majority of apps developed for iOS are designed to work better with the limitations of a very portable device (small screen, limited memory and disk storage, etc.). In most cases, they already have more full-featured and capable counterparts that run on regular computer operating systems.
Many times, the only reason an "app" exists for iOS (or Android) is to improve an experience that's just fine with a web browser on a Mac or PC, but winds up sub-par on a small touchscreen device. I'd put almost all of the "shopping" apps in this category. Whether it's the Amazon mobile app, eBay's mobile app, or a retailer like CVS or Target -- you'd never really care about the app in the first place if the company's web sites functioned better on a phone or tablet.
Apple's move to the 64-bit ARM platform isn't about compatibility with OSX, support for over 4G of ram (per process, the 32-bit ARM processor can handle 1TB of RAM already) or for performance reasons (the additional memory load will almost undoubtedly overpower the slight increases in the 64-bit ARM processing improvements).
If you read through ARM's announcement of it's 64-bit platform a large portion of it is dedicated to the new security layer allowing for better segmentation between applications and a more in-depth security layer in between the segments. This will allow Apple to sit a hypervisor below the kernel and protect the system from "attacks" and if we can get through the hypervisor there is an additional ARM security layer before you can run in the top processor privilege layer.
64-bit ARM isn't about anything other than preventing jailbreaking.
These are completely different architectures, and I highly doubt portability will be easier between the two, just because one makes the jump to being native 64bit.
Emulating an ARM core on x86 is totally doable (QEMU, in fact, does it for the Android SDK's test/emulator component. I don't think anybody has an OSS iPhone clone fully working; but that wouldn't take Apple long); what I find baffling is the theory that the application being emulated would need to be 64 bit to 'play nice' with the larger memory space available to the host.
Even if Apple decided to support cross-platform binaries(and that's one hell of an 'if', Apple Loathes half-assed ports, and has so far not embraced touchscreens in desktops and laptops, so cross-platform binary support would be asking for half-assed ports in both directions); allocating one or more 32-bit processes its own happy little address space has been trivial on 64-bit OSes for ages. Hell, even pre-64-bit, PAE systems were happily slicing large quantities of RAM into 32-bit address chunks to support 32-bit processes. Since Apple makes no ARM devices with 4GB+ of RAM(indeed, they tend to ship rather on the low side compared to the pricier Android OEMs), iOS apps aren't exactly going to be starving on the desktop, and a desktop OS has no trouble carving up a larger memory space into smaller chunks.
I can't think of a single iOS app that would be useful to run, and doesn't already exist on a Mac. And I'm not talking about app versions of webpages, like ESPN or Pizza Hut. If you can think of one, please list it here.
First, most iOS apps tend not to have requirements that would make them rely on word sizes, and ones that do (say ones that transform image data as RGBA buffers) can usually be written in an architecture independent way by using fixed-width type primitives. So the idea that you would write an app that only works with 64bit words doesn't seem sound. All you have to do to run an existing app on the new 64bit iOS simulator is to recompile it and in most cases it will run just fine.
Secondly, when the iPad was first released, developers were given a big, fat warning "this is not a big iPhone, it's a completely different UI paradigm, enough to make you want to rethink your design." This in spite of the iPad being a mobile device with a touch interface, like the iPhone. Desktops and Laptops are far off from this UI paradigm and it's hard to imagine Apple wanting to run iOS apps on Mac OS more or less unmodified.
32-bit addressing fits just fine in 64-bit memory space, and the emulator needs to translate the syscalls anyway, so there's not really any benefit to doing this...
On the contrary, if the emulated applications were only 32-bit, the JIT emulator has plenty of scrap space in a 64-bit system to throw its own memory without needing to do magic to avoid overlapping.
Really, I don't see any need for 64-bit addressing on portable devices today; it's only important if a single application needs more than that and can't handle some memory banking tricks. At the same time, it also means applications need to waste more memory for all their pointers, so it doesn't go as far.
Some think it's due to the new AppleTV [1] coming out (which may require more addressable memory >4GB - silly IMHO, PAE type extensions can make addressing more than 4GB easy for 32bit architectures - Intel did this in the 90s). That same article even mentioned the iWatch.
Another is saying it's performance related. And then there's the TFA which implies iOS/OSX synergy.
Personally, I think it's none of the above. It's just a marketing data point, and lays very important groundwork for future releases. Assuming like the difference between x86 and AMD64, there may be additional registers or other architectural performance improvements, it both makes current (new) hardware faster and more scaleable, and gives Apple options on where they can strike next (ie, nothing specific at all).
Maybe, given Phil Schiller's more macho, confrontational, attitude ("can't innovate my ass"), Apple just presented it to swing their big ones in the face of Samsung/Moto/Google/etc?
Make sure everyone's vote counts: Verified Voting
Well programmed application should switch over to 64bit without a single code change, and same goes for 64bit application compiled to run on 32bit. There might be performance improvement if you use lot of 64bit address, so moving to 64bit make sense, but for a cell phone, it far from a requirement for the moment.
But is it bad to switch to 64bit, I don't think so... But it no big deal to do it neither.
The real reason to do this switch over is so apple will bundle 64bit A whatever chip into their next line of laptop / desktop. So they can have super long battery life in 'low' requirement mode, and switch super quickly to the full OS in a snap. This will make it easier to interconnect both system if they are both 64bits (Maybe even tap to the data/memory storage directly... So let say you watch a video, it can switch online irc/IM checking process to the ARM processor and use the arm processor to do the disk to hardware video decoder for the video... When an event occur, the arm can wake up the main intel processor and switch the process to it. So sharing the same address space will make it possible to share the same ressources.
Right, because they don't already have 2GB.
32-bit can address up to 4GB of RAM. So 32-bit will be fine until they create a phone with > 4GB of RAM.
Right, because there are no algorithms, none whatsoever, not mmapped in-memory databases, not modern runtimes, which benefit from having a large address space that will not be exhausted by fragmentation. Yep, none at all.
Not yet, not on your phone. In a few years, maybe. In the mean time if you're trying to use a DB that's larger than 4GB on your phone you need to get a laptop.
They'll "leap ahead of Microsoft and Google" sometime after they figure out that they need to dump Objective-C and allow a memory-managed runtime to be a first-class citizen in their OSes.
The day I can write a natively-launchable MacOS X or iOS app in .Net/Mono or Java is the day Apple finally wins that fight. Until then, we're all stuck running mono whateverMyAppIsNamed to get things to launch in OSX, and iOS is just out of the question. Interesting note: they added kernel hooks in OSX for this feature in 10.5, and iOS has had it since day 1. They just don't use this functionality.
the ubuntu edge was going to have 4gb of ram, but it only got 13 million out of the 32million funding goal
But Ubuntu Edge's 4GB of RAM is not greater than 4GB, and 32-bit can address up to 4GB of RAM.
Apple has already tacked the transition of RISC to CISC when the took OSX from PowerPC to x86. An self sourced 64-bit SOC would allow them to no longer be dependent on the Intel CPU monopoly for their laptop, desktop, server offerings.
Cortex A15 has 40 bit addressing and can access 1TB of physical RAM.
The 32 bit limit is per process.
Gee, a common code base between mobile and desktop? Too bad the shitheads at Microsoft weren't in this right frame of mind when they created the abomination known as WinRT. Have you tried sharing .NET code between WP8 and the desktop? It's almost impossible.
app store lockin on top of high cost hardware will kill mac os.
It's bad that lock down the hardware as much as they do but to add software lock down as well?
This analysis of the switch presented a more intriguing idea than the one proferred here. They suggested that the switch to 64-bit is a case of Apple laying the groundwork for later devices. Specially, their thesis is that because it's ridiculous that a phone will need 4GB+ of RAM anytime soon, the chip has actually been designed with a different product in mind, such as Apple's rumored TV product. The thinking is that something designed to be on more even ground with the likes of the PS4 or Xbox One will need to match the 8GB of RAM that each of them has, and with Apple adding game controller libraries to both iOS 7 and OS X 10.9, it looks like they're paving the way for an entry into that field, perhaps with a new class of more powerful iOS devices that use your TV as a screen and run apps from the AppStore.
What exactly don't you consider real about iOS 7's multitasking? Can apps run in the background? Yes, although you are supposed to do so sparingly. Some other requirement of which I'm unaware? iPhones aren't likely to have 4GB any time soon because of cost and battery use. But iPads might.
I did. The whole thing is nonsense. You don't have to enforce a single architecture to have common code. Neither do you need to have a virtual machine running the same bit-ness as the host operating system. This is just the usual kind of cluelessness that comes from a community that is proud of being stupid.
Yeah. 64-bit BS.
A Pirate and a Puritan look the same on a balance sheet.
You're not important enough to add to this list.
http://www.macobserver.com/tmo/death_knell
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X, so at this point virtually all processor-dependant code has been abstracted away. They could switch the Mac Pro to a 128 core 32 bit ARM chip—or the iPhone to an Intel 64 bit chip—and all you would have to do is recompile. So yes, the transition will be easy.
Regardless, it's 2013. If you're writing assembly or ultra low-level C and you aren't simultaneously writing generic fallbacks, then you're basically "doing it wrong."
So you didn't even bother to read the summary did you?
Big deal, the summary is just a bunch of marketing crap. Their stated reasons are weak at best, and more than likely just flat out wrong in most cases. It makes several assumptions about users which are most likely wrong.
The only good reason for making this change NOW, and the announcement NOW, is Marketing. They want to be able to say "Oh look, we have so many more BITS than the other people!" and the fanboys will all rush out and buy the new shiny for a premium price.
Few people even give a shit about using a smartphone app on their desktop. And if you want to do it, you already can. It does not solve portability issues, and does almost nothing in terms of making the code base more uniform. The only real, tangible benefit would be increased memory space. But that's not what is going to happen... the next iPhone will still only ship with 4gigs of RAM and it's not like you can upgrade it either.
I'm sure there's some reason like battery life or whatever but more than 64bits I want virtual memory.
Go to a heavy webpage like scrolldit.com on your tablet/phone, scroll down a few pages, watch the browser crash. Go get a P4 with 256meg of ram, view the same page on a desktop browser (VM will do). Runs just fine. Why? Virtual memory.
I ran NT4 and 3DSMax on a machine in 1995. They claim my iPhone/Android/iPad/Tablet has more power but it can't run 3DSMax nor could it compile a large app. Why? No Virtual memory.
Note: I know scrolldit is not and important site but there are plenty of sites that will kill your mobile browser usually because it runs out of memory.
Android is ready for x64, TFA doesn't have a clue. It's just a recompile away. In fact, because most Android apps are written in Java they will take advantage of 64 bit CPUs without even a recompile.
And apparently it isn't just a recompile away on iOS. For anyone who didn't watch the iPhone 5S announcement, one of the big things they mentioned during the presentation was "how easy it was" to enable an app for 64-bit: it took them "only two hours" to port an existing app to 64-bit!
Uh, what?! It takes me "changing a compiler switch" to do that for everything I've ever written. I can't wait to find out how Apple managed to fuck that up with iOS 7!
x64 is not the same thing as 64 bit. x64 is 64 bit but 64 bit is not x64. You should be ashamed of yourself for making such a n00b mistake.
Some other points about x86 vs x86_64 there is an overhead to using 64bit (hence people wanting the x32 abi). In all likely hood this is more about being a precursor to the Mac line moving to ARM chips.
Yeah... because java and the Linux kernel don't run on 64bit hardware. And of course NO ONE uses either Linux nor Java outside of Android. *rolls eyes*
Friggin' Fanbois
Tell me what you believe...I'll tell you what you should see.
Welcome the NEW! 27 inch iPhone!
“He’s not deformed, he’s just drunk!”
You're funny.
Are you seriously suggesting that Apple migrates their desktop machines to hardware that's about 10 years behind the curve in terms of performance when compared to x86?
Stop swimming in the kool-aid.
A Pirate and a Puritan look the same on a balance sheet.
You are absolutely right. The whole summary doesn't make any sense at all... first of all, the Macs run 32-bit applications just fine. Second, if you can emulate a 64-bit ARM, you can emulate a 32-bit ARM. Third, phone apps would suck on a laptop or desktop.
I suspect they went to 64-bit for the simple reason that it is the direction ARM is going. This processor design is likely to show up in their lower-end products for years after it leaves their flagship device, and the sooner they go to 64-bit, the sooner they can depreciate the 32-bit stuff. Unless the 64-bit chip cost significantly more to design, produce, or unless it has a significant performance penalty, there is no reason to delay making it.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X
Intel chips have been RISC internally for so long that your ignorance isn't even funny. The whole RISC vs. CISC thing blew over when I was still in short trousers!
They could switch the Mac Pro to a 128 core 32 bit ARM chip—or the iPhone to an Intel 64 bit chip—and all you would have to do is recompile.
Yeah... and if you wish to make an Apple pie from scratch all you would have to do first is invent the Universe.
The only real, tangible benefit would be increased memory space. But that's not what is going to happen... the next iPhone will still only ship with 4gigs of RAM and it's not like you can upgrade it either.
The iPhone 5 & 5C have 1GB of RAM. I don't recall Apple announcing that the 5S will have 2GB, but even if it does the iDevice lines won't be offering 4GB of RAM this year or next year ... and probably not until 2015 at the earliest. So exceeding 4GB won't happen for years.
The A7 is 64-bit because it gives apple the only phone that's capable of taking us past 4G. And to think some phones are still 3G. ;)
I'm running 32 bit applications on macosx without problem (Dropbox + uTorrent). Where do these experts take their clueless arguments?
Android is ready for x64, TFA doesn't have a clue. It's just a recompile away.
Bullshit. Making an OS 64 bit is far more complex than a recompile. And the next Android version, Kit-Kat is not expected to be 64 bit compatible.
Android 64 bit is at least a year away.
Oh great, fat sloppily coded apps on my cell that run slow and are made by people with no idea that they have to get along with everyone else.
Just what I need.
It's like the 2/3 of apps on the store that are basically wrappers around garbage.
That said, this is why I'm looking forward to the iPhone 6, not the 5s.
-- Tigger warning: This post may contain tiggers! --
So you would think that this new large address space will allow more complex and productive apps brought to the iPhone.
But, if you read the article, you'll see this:
But it's the iPhone that's being brought up to the same address space as the Mac, not the other way around. Interesting that Apple puts this in terms of making the Mac more like the iPhone instead.
Macs are already technically capable of running iOS apps.
Plus, and this is not a small concern, I think there are plenty of Mac users (like me) who see the notion of OSX becoming more like iOS as something of a big step in the wrong direction. Maybe Apple's purpose is not the same as the purpose of people who use Macs.
You are welcome on my lawn.
Infinity Blade. Now, it'd be pretty hard to play it in a macbook pro.
How about on my tablet?
Can I use a 4GB database there?
Right?
Next thing you know you'll want it to talk to the iWatch.
-- Tigger warning: This post may contain tiggers! --
The iPhone 5 only has 1 gig of RAM.
The iPhone 5s DOES NOT SAY how much RAM it has. For those who are marketing-impaired, this means it almost certainly also only has ONE gig of RAM.
Do not come around bragging about how much fucking RAM a 64bit OS can use when you're talking about a device which is still only utilizing one QUARTER of what 32bit address space provides.
You can't upgrade the onboard RAM in the future. You will have to buy a new phone for that.
This story is about Apple pushing the 5s model to sucker fanboys into spending more money than they need for no actual advantage. It's about Apple launching a marketing campaign where they will make a big deal out of "Having more BITS" than the competition- because they know most people don't have a fucking clue that it doesn't actually equate to any advantage for the phone they're buying.
Maybe down the road 64bit will be nice to have, but not right now on this phone, and probably not on the next model or two either.
How about on my tablet?
Can I use a 4GB database there?
You didn't say please, so no.
Actually, tablets probably will exceed the 4GB limits of a 32-bit architecture before phones will. But, since this story is about an iPhone with 1GB of RAM I stand by my statement that the need for 64-bit is just Marketing BS.
But, if you read the article, you'll see this:
The article is pure speculation. I seriously doubt that bringing iOS apps to Macs is the reason to go 64-bit.
Plus, and this is not a small concern, I think there are plenty of Mac users (like me) who see the notion of OSX becoming more like iOS as something of a big step in the wrong direction.
I agree. Some of the features brought from iOS to Mac were actually nice. Some were very ill advised. What was obviously lacking was some good sense about making choices.
There is a depressing depreciation in total knowledge of the word "deprecation".
You don't have to enforce a single architecture to have common code.
But it makes it easier. In this case Apple will have 64-bit ARM and 64-bit Intel to maintain instead of 32-bit ARM and 64-bit Intel. I think there's a longer term strategy here. I'm not sure what it is.
Well, there's spam egg sausage and spam, that's not got much spam in it.
There's no grand scheme or plan for 64-bits vs 32-bits. They went 64-bits simply because it's the next evolution of chip design. 64-bit processing doesn't strike at a a need today but eventually it will be beneficial and even necessary so if you're going to spend millions on an ARM design you might as well make it 64-bits.
Google isn't porting an OS to 64 bit from scratch. Linux for ARMv8 probably already exists. So does GCC.
They mainly need to make sure their userspace, including java VM, still compiles on 64 bit. Then current Android application will benefit from ARMv8 without the need for a recompile.
IPv6
In the land of the blind, the one-eyed man is king.
Third, phone apps would suck on a laptop or desktop.
That's not quite true. A touch-screen iMac or Macbook would be perfectly suited for running iPad apps. I think this is a brilliant move by Apple, if they do indeed seamlessly bring the entire iOS application ecosystem into the OSX family of computers.
Better known as 318230.
Unless all of the memory is shared (or I am mistaken), a 32-bit device may not have access to even the full 4 GB of RAM.
Well that's just sheer pigheadedness. "The need for 64-bit is just Marketing BS" - except that if you agree that a tablet could use more than 4GB of RAM, and it's a fact that the iPad uses the same OS as the iPhone, then why would a 64-bit iOS be marketing BS? It might not be needed for iPhones, true. But this was announced at the iOS 7/iPhone 5S release party. Why would they have to separate the hoopla, just to make it clear to you that 64 bit iOS 7 wasn't geared towards their 2GB RAM iPhones? The iPad is due for an update. And, much like a poster above said, it will help them to deprecate out older code (32 bit apps), if they move to 64 bit *now*, instead of when it is absolutely needed. iOS 7 is the first update that my iPhone 3GS can't use, and the 3GS is a 4 year old device. That means, by switching to a 64 bit processor line now, they can phase out 32 bit apps in about 4 years. Do you argue that phones won't need/have 4GB of RAM in 4 years?
32-bit can address up to 4GB of RAM. So 32-bit will be fine until they create a phone with > 4GB of RAM.
Seriously, has no one here heard of Physical Address Extension? 32-bit architectures can definitely access more than 4GB of RAM. There are MS Server 2008 editions that can access 64GB. MS uses it as leverage to get customers to buy more expensive SKUs. A single process is what is limited to 4GB on a 32-bit system.
More BS, because ARM has had 40-bit LPAE since 2010, which supports addressing of up to 1 TB.
Apple needs to not only offer more robust software (and hardware) but you people need to support legacy software all the way back to MacOS 1.0 CLASSIC and iOS 1.0. You should support 68K, PPC, Rosetta, etc. Frankly you should even support the original Apple II and I, the III, the Lisa. Heck, throw in CPM, DOS and Windows as well. All under the same roof. Just make software work. There is a tremendous amount of wonderful legacy software, especially in the education field but also in entertainment and small business that does not work anymore because Apple abandoned it. Bad Apple, bad apples. Apple has the manpower, the money and the code to make this all work. Just do it.
Interesting that Apple puts this in terms of making the Mac more like the iPhone instead.
Apple did not write the speculation in TFA. They merely said it makes maintaining a common code base easier. Nothing about making the Mac more like the iPhone.
The register pressure they are experiencing now is fairly low so more will help, but it won't be as big a deal as with x86-64.
There is far more likely to be a drop in performance due to increased pointer sizes (poorer cache utilization and increased memory footprint).
Are you an idiot? iPhone's come with 16GB, 32GB, and 64GB of flash RAM. It would not be hard to make that addressable from iOS. Go to Apple's web page it is right there in front of you! Don't hate Apple just because they got it like that! Google, Samsung, and Microsoft just fired up their photocopiers!
64-bit AMD actually... Intel licenses their 64 bit architecture. The 64-bit architecture Intel developed underperformed. The moment emulation was mentioned is the moment the arguments in this summary fell apart...
OMG! ROTFLMAO! Convergence, with a vengeance!
Seriously, has no one here heard of Physical Address Extension?
Yes. Let us never speak of it again.
If God forks the Universe every time you roll a die, he'd better have a damned good memory.
You are right. But the other thing this says is how great it would be to bring all the iOS apps to OSX. This is hilarious! Apple's development environment for iOS doesn't encourage scalable apps. Notice how they had to keep the resolution on their devices the same over time? How when they went to a HD type of screen (longer), they had to put "black bars" on the apps so they "look right"? It would be a big mess to take the existing apps over to OSX. Android would generally be much better off here since the developers are at least used to different screen sizes. But those iOS apps? Yeah, that's what all MAC users want.
I used ARM in 1987 to emulate x86 running MS-DOS 3 at 8088/PC-XT speed (in the 80286/PC-AT era). I used it to compile Modula-2 assignments and to edit WordPerfect documents.
Most of my friends didn't believe this was even possible ("Yeah, my Mac/Amiga/MSX can also read PC floppies." - "I'm not talking about merely reading the disk format, I'm talking about emulating the complete PC.") until I showed them.
Archimedes PC Emulator documentation (PDF).
I really need a flashlight app on my iMac.
WTF? We're talking about Apple and Android here, dumbass. Now go back to the children's table with the other 3 Lin-sux users.
Not yet, not on your phone. In a few years, maybe.
Well, no shit sherlock. Of course there are not any algorithms running on our phones which require a large virtual address space, because phones don't have that. Duh. Are you really proposing that developers write such software for phones first, and then, upon passing some threshold for the quantity of super-cool new software developed for iPhones but which cannot actually run on iPhones, that then and only then Apple should go to 64-bit???
In the mean time if you're trying to use a DB that's larger than 4GB on your phone you need to get a laptop.
Bullshit. 4GB is tiny.
I think there's a longer term strategy here. I'm not sure what it is.
To fill up your processor cache faster with 64-bit memory addresses?
by Mike Buddha -- Someday the mountain might get him, but the law never will.
Seriously? You call someone else an idiot yet your post clearly shows you don't understand the difference between RAM and FLASH storage?
Apparently the phone has 1016 MB RAM.
Good point - a touch screen Mac could be a lot like an iPad.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Right, because there are no algorithms, none whatsoever, not mmapped in-memory databases, not modern runtimes, which benefit from having a large address space that will not be exhausted by fragmentation. Yep, none at all.
Don't forget all the extra registers that compilers/optimizers have available to help reduce memory bus accesses.
They could have both ARM/x86 CPU's sharing a common memory, and so on.
That would be a neat setup, if they could run the ARM like a co-processor to avoid emulation. ARM is certainly cheap enough.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
For most people, "changing a compiler switch" to get 64-bit builds for iOS is all you need to do. The situations where you need to make changes are the same ones that have existed for years in C, C++, and ObjC applications. In my case, flipping the switch just triggered some compiler warnings regarding ambiguous data types like size_t where I wasn't being specific as to their size. The compiled builds still worked perfectly fine out of the box, but I was able to go in and be more specific or cast when necessary to eliminate those warnings. An application like Infinity Blade 3 (which is the one you mention during the presentation) is fairly complex, maybe they had some native ASM code in there or something.
Yes it can because we are not talking about x86 shortcomings here.
Phones are not going to have more than 4GB or RAM any time soon.
Right, because they don't already have 2GB.
Seriously? It took 10,000 years of human history to get 2GB RAM in phones. You think we're just going to double that anytime soon?
The IPhone 5s has 1 GB RAM. That is less than 4 GB. Inescapable conclusion is that the state reason is pure spin. Let's be honest, Tim Cook couldn't think of any actual innovation to build into the phone so doubling the processor width and increasing the battery size is as far as his paper pusher imagination could take him. Face it, Tim Cook is an operations guy, not a visionary.
What Apple absolutely needed to do this time was:
1) Not a product refresh! A new model please.
2) Bigger screen... duh.
3) Banish the dot-for-dot resolution albatross that ties ios products to multiples of 640 horizontal resolution
For extra credit:
4) Removable battery
5) Expandable flash slot
Apple's final score: zero for five. Better luck next time.
When all you have is a hammer, every problem starts to look like a thumb.
Boot up snow leopard and see what the default kernel used is, why yes it is the 32 bit.
" Snow Leopard 10.6 default boots into 32-bit kernel, but for developers working on 64-bit kernel extensions, Snow Leopard could boot a 64-bit kernel. This gave developers over 2 years to create 64-bit kernel extensions and drivers. "
Yep, from the "ground up"... Just don't let the facts get in the way..
Right, because there are no algorithms, none whatsoever, not mmapped in-memory databases, not modern runtimes,
Yea, all those runtimes running on IOS! And mySQL, Apple edition, I love that!
Parent wasnt making an absolute statement, he was (correctly) stating that 64-bit will have almost no benefit on a cellphone for a very long time; and that the author of the article has no idea what they're talking about (since ARM being 64-bit has no relevance to compatibility with a 64-bit Intel processor).
Third, phone apps would suck on a laptop or desktop.
If only Microsoft would realize this.
They could depreciate stocks of older chips in order to invent a loss and maneuver around some taxes. Dunno if it would fly...
A 32-bit device can address 48-bit memory addresses with PAE. Lets not mistake Windows memory addressing artifacts for limitations of an architecture.
I call troll.
If the expanded address space was the only reason to go 64-bit, then consider Apple might be preparing very soon to introduce another device type that contains more than 4GB memory, like an ARM-based laptop or super iPad. Going 64-bit now gives Apple early experience and paves the way for phasing out 32-bit ARM sooner.
But of course there's the doubled number of registers, double-wide registers, and expanded instruction set with which to speed up code (in most cases) with a simple re-compile. But you knew that already... and yet you still kvetch.
Android (and Android devices) will have a lot of trouble keeping up. So another reason for Apple to start the switch now is to stick it to Google/Motorola/Samsung/HTC/Microsoft all that much sooner. ROFLBBQ!!!!!!!!!!!
I suspect they went to 64-bit for the simple reason that it is the direction ARM is going.
I (like many others) suspect that they went for 64 bits to hand the marketing department a bigger number to crow about.
When all you have is a hammer, every problem starts to look like a thumb.
Anything that would benefit from the move to 64 bits is, most likely, too heavy to be useful on any ARM processor, much less in a phone.
Sure, you can give each app its own chunk of memory addresses with little regard for fragmentation, but that's not an issue on any modern environment.
But, you seem to have examples - care to support your statements with some of them?
4GB is not tiny for a phone. We should try to minimize bloat, not add hardware to pretend there is no bloat.
I didn't mean depreciate the chips, I meant depreciate the XCode 32-bit stuff. Mac is all 64-bit now, so the only reason for them to maintain 32-bit tools is for 32-bit ARM.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Processor-only emulation isn't so bad (especially with a good dynarec). It's emulation of the whole computer (especially at a very low level, needed for accuracy when emulating older systems but not as important for modern archs) that really bogs things down.
FC Closer
Now can you cite some real world examples of why IOS 64 bit is better then the 32 bit version?
Not some theoretical examples, a real reason why i as an end user care?
Isnt android based on the linux kernel? This certainly is a recompile away from being 64 bit.
Maybe they want their codebase to properly support 64-bit well before they plan to require it?
I wonder how many people initially shat on the hybrid 68k/PPC approach Apple took in the old days, or on their transition between x86 and x64.
FC Closer
Parent wasnt making an absolute statement, he was (correctly) stating that 64-bit will have almost no benefit on a cellphone for a very long time;
That statement is unequivocally wrong. It will have a benefit very soon. It is exactly what I have been waiting for, and I know other developers in the same position. I was hoping for it in 2014, getting it a year early is incredibly sweet.
...and that the author of the article has no idea what they're talking about (since ARM being 64-bit has no relevance to compatibility with a 64-bit Intel processor.
But that's not what the article said. It talked about using the "same codebase", meaning same source code, and thought it didn't state it explicitly, it sure sounded like he was implying same backend data-handling code, not UI. And yes, this is important. If you use algorithms that need a large virtual space on OS X, and you have to completely back off that and use something else on iOS, what a pain--oh, and in some cases, the iOS version is lower-performance as well because of that change. And that sucks. Having to go to lower-performance algorithms on a mobile platform is a double hit to performance.
But hey, if you don't actually have a clue of all the things a 64-bit address space enables, then the above will sound like gibberish...
Android could be 64 bit. Right now the hardware is not. It will take some coordination between Google and the OEMs to make it 64-bit. An obstacle is that the chipmakers haven't released a 64-bit ARM chip yet. Most likely it will be based on the Cortex 50 series.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Eventually (5 - 10 years down the road) even those stupid "smart watches" could have more than 4GB of RAM, but that doesn't mean they need to be 64-bit now. There is nothing on the iPhones that will actually take advantage of the benefits of a 64-bit architecture. Not the iPhone 5S and its 1GB of RAM, and not the iPhone sometime soon and its maybe up to 4GB of RAM.
I originally said "Phones are not going to have more than 4GB of RAM any time soon", and "Do you argue that phones won't need/have 4GB of RAM in 4 years?" is not anytime soon. Not in everyday life, and not technology. Yes, in 4 years phones will probably hit or pass the 4GB mark, but how does that apply to rolling out "iPhone is 64-bit!" now?
iOS 7 on the 1GB iPhone 5S will be 64-bit ... but the 1GB iPhone 5C - announced the same day as the 1GB 5S - will run iOS 7 32-bit. It uses the same chip as the iPhone 5, and the latest iPads, which all will be running 32-bit to access their 1GB of RAM.
No actual benefit from 64-bit = Marketing BS.
Not just their marketing department... I seriously doubt that ARM itself is going to develop the 32-bit platform much beyond where it is today. And if they ever decide to jump to Intel, Atom is also 64-bit.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Phones are not going to have more than 4GB or RAM any time soon. 64-bit is Marketing BS at this point.
A similar statement regarding 640KB of RAM was also completely correct at the time it was made.
A few years later though, it was horribly wrong.
We already have phones with 4GB RAM available for purchase right now. It might be that this upper limit of 32-bit CPU's is coincidentally also the exact upper limit of what we could possible ever want on a phone.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
PAE on 32-bit is a kludge. It also doesn't remove the 4GB per-process limit, it merely allows more total address space across all applications. Yes, there is AWE, but it's basically old-school memory banking in a modern context, and bankswitching sucks donkey balls. Remember how much better XMS was than EMS back in the MS-DOS days? I recognize the parallels between then and now, and would rather things go forward in a more native way, the type that 64-bit supports. So what if pointers are larger? BFD.
FC Closer
You are absolutely right. The whole summary doesn't make any sense at all... first of all, the Macs run 32-bit applications just fine. Second, if you can emulate a 64-bit ARM, you can emulate a 32-bit ARM. Third, phone apps would suck on a laptop or desktop.
The logic of the article may still make some small amount of sense. Imagine a photo editor on iOS. Now imagine that there is an easy way to use your iOS apps on OS-XI. The only problem is that if your Mac Pro has 64 GB of RAM, and your iPhone is 32 bit, you may not get much benefit running that app on the bigger fancier system. OTOH, if the iPhone is 64 bit, then a future developer might make sure that the app has some extra bells and whistles in it that aren't very practical on a phone, but are really only useful when you run that app on a larger system.
It's not just a technical issue that the article seems to be trying to talk about. It's a broader ecosystem / psychology / platform possibility.
There's been talk lately about hybrid RAM-Flash memory spaces or making Flash fast enough to act as RAM. Either way, 4GB is right around the corner with most smartphones currently having 1-2GB of RAM, remember when you had 2-4GB of RAM in your computer? Today you have what - 16 to 32GB in the mid-level base systems?
Either way there are a lot more benefits besides the larger addressing space. If it were just about the larger addressing space, 64-bit would be slower and take more energy on anything that doesn't have >4GB (you may remember that conundrum when 64-bit was introduced on the desktop).
But this news article makes little sense. You can cross-compile iOS apps already to Mac OS (just create a different viewport) and depending on your target even 32 and 64 bit simultaneously. The problem is that iOS apps are not useful on a desktop. This iOS-will-converge-into-MacOS will never happen. Microsoft tried it with Windows 8 and you can see what a disaster that turned out to be.
Custom electronics and digital signage for your business: www.evcircuits.com
In all likely hood this is more about being a precursor to the Mac line moving to ARM chips.
The day Mac can run RISC OS, I'll buy one!
Useless for content creation?
Spelling and Grammar errors have been added to this post for your enjoyment
Intel chips are RISC as well, the CISC is bolted on top for compatibility reasons.
Custom electronics and digital signage for your business: www.evcircuits.com
No, you meant deprecate. Two different words with two different meanings.
Any idea to the contrary is absurd. It's just a matter of Apple releasing iMacs and MacBooks with it.
They think that it is much, MUCH faster and more efficient than that nasty x86 and ARM could make desktop CPUs that would crush Intel, if only they wanted to or thought there was a market. So Apple-ARM fans want to see Apple move to ARM so that Apple can once again be "faster" than those evil PCs.
A big part of the Apple fanboy identity was that Macs were faster and better because of their different CPUs. Didn't matter how manifestly wrong that was becoming (particularly near the time when they transitioned), they had contrived benchmarks to prove that to themselves and it made them happy. They got real upset when the transition to Intel leaked. In fact, some came up with elaborate fantasies that Intel was going to release a new "Core X" chip just for Macs that was faster and more efficient.
So when you have someone who;s both an ARM fanboy, and thinks ARM has some magic juju that Intel doesn't (and for some reason just doesn't use that on bigger CPUs) and a Mac fanboy who wants Apple to be different and better, well you get them thinking Apple should stick an ARM CPU in their desktop.
Let's also not bring PAE into the discussion at all, since it's an x86-exclusive kludge and best relegated to low-cost embedded x86 systems and old, non-upgradeable Windows servers. Cell phones have no need to bolt something like PAE onto the CPU. Remember, cell phones don't generally run x86 or x64.
FC Closer
Apple doesn't need a large market share to be MORE profitable then other companies. It will stifle Apple's market share, but increase their profitability.
Spelling and Grammar errors have been added to this post for your enjoyment
Anything that would benefit from the move to 64 bits is, most likely, too heavy to be useful on any ARM processor, much less in a phone.
Not quite. I think it'd be more accurate to say pushing the limit, rather than over it. And 64-bit helps expand the limit.
Sure, you can give each app its own chunk of memory addresses with little regard for fragmentation, but that's not an issue on any modern environment.
True, but that is not what I'm interested in.
But, you seem to have examples - care to support your statements with some of them?
Not beyond what I've already said. Sorry, but there's things I just should not discuss in a public forum...
Hahahah, you called it "flash RAM".
Shill.
FC Closer
So, you believe that this is something other than an Apple marketing press release. I don't.
Anything you read in the tech press immediately after an Apple product announcement is suspect, to me, since there is absolutely no original reporting in any of it. The only information that a journalist has at this point is what Apple is putting out, complete with Apple spin. That's the whole purpose of the secrecy surrounding these things.
See above. Except for the fact that the story is about iPhones becoming more like Macs, except spun to make it sound like this was somehow going to make iOS apps run on Macs, which have had 64-bit address space for years now.
Remember, the only information that anyone, including the press, has at the moment is what Apple has spoon-fed them.
You are welcome on my lawn.
You don't need 32bit x86 tools to support 32bit ARM. They need tools for x64 and ARM, whether ARM is 32bit or 64bit is irrelevant. In fact, they now need 3 sets since they now need to support x64, ARM 32bit and ARM 64bit as there would be outrage if Apple dropped all support for existing hardware.
ARM and x86 are so different that the matching bitness makes no difference whatsoever in supporting both architectures.
Little man, your argument is just a bunch of trolling crap.
whoosh
But hey, if you don't actually have a clue of all the things a 64-bit address space enables, then the above will sound like gibberish...
Tell us, mister know-it-all, what part of the 64-bit address space is Apple going to use on this iPhone? What benefits will a 64-bit architecture deliver in this iPhone? No marketing crap, no "possibly ..." or "eventually they could ...", just the facts. What does it deliver now besides the "We're 64-bit now!" ??
Many times, the only reason an "app" exists for iOS (or Android) is to improve an experience that's just fine with a web browser on a Mac or PC, but winds up sub-par on a small touchscreen device. I'd put almost all of the "shopping" apps in this category.
One problem is that Apple has lagged in implementing a lot of HTML5 features in Safari for iOS, even when the feature would apply better to a handheld device than to a Mac. One of these features is the getUserMedia draft, which gives the user a button to turn on the camera and let the web site take pictures of things. Taking pictures is essential for scanning barcodes inside an application, such as price-checking a product in a store to see if it'd be cheaper on Amazon.
Do you think a phone will have a single process that will need more than 4GB of RAM anytime soon?
Phones and popular tablets don't multitask the same way desktop PCs do. Phones and popular tablets tend to have only one application running at once.. Unless you plan to split a single app into multiple processes (does iOS even allow this?), you can't make use of all 8 GB of RAM with only 4 GB per process unless you're devoting about 3.5 GB to caching the flash memory.
At low levels no. But in terms of APIs that Apple would expose there's on less thing to worry about.
Well, there's spam egg sausage and spam, that's not got much spam in it.
While it's ambiguous whether the poster understands how memory is utilized in contemporary iDevices, you seem ignorant to the potential opportunity for virtual memory to exceed 4 GB in the iPhone 5s. By your own definition, that makes you idiotic.
Apple is infamous for dropping older hardware.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
I don't think you understand how pervasive the use of Core Animation is throughout the operating system. Do you ever, for instance scroll a view? Move a window, drag an icon, update some onscreen text? Does it do so smoothly without you noticing it much. Do you remember how horrible it used to be to resize a window on OS X, and how now, it's pretty darn smooth? Well that is all running through the Core Animation compositing engine, which was developed so that the iPhone GUI would be smooth.
Debian is the only project on Earth that maintain so much architectures from the same code base and build system.
Don't forget NetBSD.
I don't know whether NetBSD has more archs than Debian (and refutes your statement), nevertheless still worth mentioning.
(yeah yeah, Netcraft etc.)
I seriously doubt that ARM itself is going to develop the 32-bit platform much beyond where it is today. And if they ever decide to jump to Intel, Atom is also 64-bit.
Do you seriously think your washing machine needs a 64 bit processor? And do you have any idea how many more applicance-level processors you have in your home than cell phones and tablets? And how many people in the world want a phone but do not want to pay anything remotely close to $500 for it?
When all you have is a hammer, every problem starts to look like a thumb.
Whatever Mr Bill-Gates-without-the-money-or-talent.
There's another option: 64 bit kernel, 32 bit userspace. And if you do multiarch or (eeew) multilib, you can have a gradual transition.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Not yet, not on your phone. In a few years, maybe.
Well, no shit sherlock. Of course there are not any algorithms running on our phones which require a large virtual address space, because phones don't have that. Duh. Are you really proposing that developers write such software for phones first, and then, upon passing some threshold for the quantity of super-cool new software developed for iPhones but which cannot actually run on iPhones, that then and only then Apple should go to 64-bit???
No, I am not proposing that. I didn't say anything along those lines at all. I am saying that phones - especially the current iPhones - don't have 4GB yet, and won't have more than 4GB of RAM for several years. So writing those algorithms now is a bit premature.
Any developer who really, really wants to write algorithms & applications that take advantage of a 64-bit architecture, large amounts of RAM, and all those other goodies can do that today using current development tools, dev boards, kits, etc, etc. They don't have to wait for a phone - especially the current iPhones - to do that.
So they'll just use MIPS instead? Or older ARM chips?
I'm starting to think GNU is the problem with "GNU/Linux" these days.
The whole RISC vs. CISC thing blew over when I was still in short trousers!
Precisely my point. Unless you write assembly, you don't even need to think about it.
Yeah... and if you wish to make an Apple pie from scratch all you would have to do first is invent the Universe.
Eh? I've moved tens of thousands of lines back and forth between iOS and MacOS, 32bit to 64 bit. It's essentially painless. Did you have an actual point?
A great deal of effort has gone into the design of these Mobile OSs to free the users from having to be concerned with where their files are stored
Right now it's either on the device or in the cloud. And users have every right to be concerned because unless one subscribes to broadband at home and happens to be at home, files in the cloud are limited to a couple GB up or down per month. Does the OS attempt to hide whether files are in iCloud vs. Dropbox vs. Google Drive vs. the service formerly known as SkyDrive? If not, then inserting a memory card could be handled like logging in to one of these online storage services.
Your washing machine doesn't even need a 32-bit processor.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Come on, this is not news for nerds or stuff that matters, it's uninformed technical speculation from some guy who apparently knows nothing about CPUs and operating systems.
IOS runs on ARM, OSX runs on x86, that's a pretty much bigger leap than 32 vs 64-bit. And saying android is not ready for 64-bit demonstrates the authors knows nothing about android and linux and I won't event waste my time finding links to the first x86-64 ready kernel that was released almost 10 years ago.
PAE? Good luck trying to split your application into dozens of different processes just to fill memory.
Yep, I'm sure Apple will get right on that.
Whilst the execution engine in an x86 chip may be RISC (or RISC-like) code running on the chip is well and truly CISC - programs running on x86 have no access to the low-level RISC features.
Specialist Mac support for creative pros, Melbourne
I don't hate Apple. I own an iPhone and have for 5 years. But the iPhone 5 series only have 1GB, and Apple doesn't have "run in place" technology on iDevices to utilize the storage of the device as slow assed "molasses" memory.
I concede the point... All the random, contradictory Apple product speculation on the Internet is secretly controlled by Apple. I wish I'd realized it sooner.
Absolutely right. Article is horseshit.
"32-bit can address up to 4GB of RAM. So 32-bit will be fine until they create a phone with > 4GB of RAM."
Right, just like the original PC could only address up to 64KB of RAM because it was 16 bit.
The level of ignorance these days is astounding. 32 bit does not limit total memory to 4GB.
The typical /.'er was, in fact, born yesterday.
There was once an obscure computer that could address beyond its word size. It was called the IBM PC.
"It also doesn't remove the 4GB per-process limit, it merely allows more total address space across all applications."
What mobile processes are compromised by a 4GB per-process limit? It's a distinction of absolutely no value.
"Merely" allowing more total address space would be the entire value on a mobile phone.
"So what if pointers are larger? BFD."
Of course, you have to fill that memory up somehow!!! Really great way to conserve power.
One of ARM's big claims to fame is power efficiency and one way they do that is reduction in memory footprint. Glad to see you get that.
The summary is full of bullshit.
"The architecture for 64-bit apps on iOS will be almost identical to the architecture for OS X apps".
Oh really? x64 and ARM are almost identical?
"By unifying iOS and Mac OS with Xcode developer tools in a 64-bit space, Apple could once again leap ahead of Microsoft and Google, says Segan."
How is the 32 and 64 bit relevant to developer tools? Can't we have a 32 bit and 64 bit compiler on the same tool? I just ignore the last part (though I puke, and who's Segan? Not that I care.)
"'The ultimate prize, of course, would be to bring the million-plus iOS apps to Macs". Apple could do that with an ARM-compatible virtual machine on Mac hardware,
How is that relevant again? Can't we have a 32bit virtual machine on a 64bit machine?
"Play nicely..."
WTF does that even mean? We are either talking technical or marketing. Which one is it?
A 32-bit device can address 48-bit memory addresses with PAE.
Provided you're willing to split your application up into hundreds of processes, each responsible for managing a few GB of RAM.
Let's also not bring PAE into the discussion at all, since it's an x86-exclusive kludge
If ARM Cortex-A15 supports 40-bit PAE, I don't see how it's so x86-exclusive.
"It talked about using the "same codebase", meaning same source code, ..."
And since you call yourself a developer, and apparently one knowledgable in this area, you know that it's a pretty shitty codebase that has to change because of word size.
Considering that you are a developer who is "waiting" for 64 bit on iOS, what does this say about your code?
"But hey, if you don't actually have a clue of all the things a 64-bit address space enables, then the above will sound like gibberish..."
Right back at you. Name one useful mobile app that could be enabled by > 4GB virtual space. Come on, Ace...
How many desktop apps, Windows, Mac, or otherwise, cannot be offered in 32 bit? I suspect the answer is essentially none. Sure, there is an occasional one but that's more a business decision than anything. There is no market pressure whatsoever to produce a 4GB phone, much less one over 4GB, and that's an existence proof that you are wrong.
So awe removes the 4g limit from 32 bit apps, using a standard old school technique ... So old that .... All intel and and x86 based processors for the last 20 or so years have supported it, even though most OSes don't use it ... It's called segmented addressing, and it's why you can boot an x86 chip and move your kernel from the first gb of address space to the upper gb ofaddress space on the fly with only a segment change.
You really don't have any idea what your talking about. AWE was made to let 32 bit apps deal with gobs of memory, used properly, it's really not that bade for most data sets and can actually be faster than 64 bit code even though you have to swap segments.
64 bit addressing just makes it so the programmer can be dumber and still work with larger address space, which is important because of people like you writing software are the norm.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
They still need to maintain 32 bit arm for the 5c, which will have the same lifespan of the 5s. If there were any real world reason to move at all, this release cycle was a wasted opportunity to move all of their stuff to 64bit
Well considering that all iPhones contain more than 4GB of storage, how about cleaner filesystem access? Or how about not focusing on just 1 part of 3 that a 64-bit processor includes? Longer addresses is just one. Don't forget about larger registers and larger I/O bus. I'm all for both of those, both of which can significantly impact performance.
" I think it'd be more accurate to say pushing the limit, rather than over it. And 64-bit helps expand the limit."
How can saying nothing be "more accurate" that the simple, straightforward, and correct comment you were replying to?
"True, but that is not what I'm interested in."
Right, you are interested in masturbating to large numbers that you don't understand.
"Not beyond what I've already said. Sorry, but there's things I just should not discuss in a public forum..."
Right...another pretentious, ignorant juvenile. Can't wait to see the revolution you start with this pent-up 64 bit codebase that we all really need in a mobile phone...
"640 Kb of RAM is enough for anybody."
Snow Leopard is two os generations old, soon to be three.
SJWs are the new boogeyman. -Me
Seriously? You correct someone by trying to point out a mistake they made and then go on to prove that you don't understand it? Flash IS a type of RAM, perhaps you don't know the difference between DRAM and non-volatile RAM. Whilhoitm may or may not understand the difference, however, he is correct in that a 64-bit processor would allow easier access to the flash RAM storage, as it would be able to reference the entire space in a single pointer rather than however it does it currently (pointer to pointer, or MSR/LSR, or "sector" number in one register and offset in the other).
We have phones with at least 65GB of RAM now (1GB DRAM + 64GB FLASH). I believe you meant 4GB of DRAM, but that isn't what you said.
I think this is pretty simple: Next year, the only phone that Apple sells that's 32-bit will be the A6 5C.
The 6C and 6S will run A7 and A7x/A8 chips respectively.
The year after THAT, the 5C will be EOL. The 5S or equivalent will be sold as the bottom-end phone. This means that in less than 3 years, Apple can have a line-up of phones that are still receiving full OS updates but only have one OS code line.
The 5C will probably be officially cut from updates for iOS X. The 5S will still get them. At that point, they can do whatever they want. The devices of that year or the next will probably be using 4GB of RAM. It'll be both cheap and small enough to fit into a mobile device, and it'll have OS support.
I really think that's all that is really behind it. The fact that they get to make Samsung look like an also-ran is just icing on the cake; forcing your main competitor to look like the copycat that you've been trying to convince everyone that they are is a fantastic side benefit to a long-term technical strategy.
For me, this also says that if you're looking to keep your phone that you buy THIS year for 3+ years, you're better off with the 5S because the 5C will be locked out all too soon.
The whole thing sounds like a web site tech writer who doesn't understand how things work but who knows how to read press releases and repeat what marketing liaisons say.
64-bit processor will consume more power than an equivalent 32-bit version, so if the extra abilities aren't being used then it's a waste. And the extra abilities are almost all about memory addressing ranges.
The assumes there is such a thing an iPad app that would be useful on a Mac. Windows 8 is currently flailing in this area, and it's not because of the lack of apps (one million more fluff apps won't fix that) but because it's a misguided idea to run a phone/tablet interface on a full blown computer.
The architecture for 64-bit apps on iOS will be almost identical to the architecture for OS X apps
Well, if you read the full quote from the Apple document in question, it says:
That sounds more like "we 64-bitified iOS in a fashion almost identical to the way we 64-bitified OS X", not "64-bit iOS and 64-bit OS X are closer to each other than are 32-bit iOS and 32-bit OS X". You still have to go from Cocoa to Cocoa Touch....
Linux: the most popular kernel for high-performance environment, portable devices and embedded applications. Chances are you have many devices and dont know about it. Get a clue, stop playing games like a compulsive kid and learn something.
Tomorrow is another day...
Oh! I know this one!
http://www.youtube.com/watch?v=pO_tXzeiZAQ
Ray Stevens!
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
This is a phone. Yes there are applications that can make use of memory, but that's why you use a full blown computer for it, not something in your pocket that's used to update facebook status and play candycrush. Sure, some people use the phone as a camera or video recorder but if you're at the point where you need tons of memory to do image processing there that means you're much more likely to want to use a more professional system (the smartphone camera system is essentially the modern equivalent of the instamatic or polaroid).
The phone is great when you're not near your real computer, but it's not a replacement for it and never will be except for people who don't need computers except to chat or consume media.
And since you call yourself a developer, and apparently one knowledgable in this area, you know that it's a pretty shitty codebase that has to change because of word size.
I never said anything at all about word size; it's all about virtual address space. In fact, I specifically said: "And yes, this is important. If you use algorithms that need a large virtual space on OS X, and you have to completely back off that and use something else on iOS..." But of course you ignore that part, because when I refer to "algorithms that need a large virtual space", you simply have no clue what the hell I'm talking about, so you come back with some lame non-sequitur about word size because that's the best you've got.
Considering that you are a developer who is "waiting" for 64 bit on iOS, what does this say about your code?
It says that I have something on Mac OS X that is literally orders of magnitude faster than competing products, and my solution will require a large virtual address space, NOT large amount of physical RAM, to work well on iOS. But, again, you have no clue what that means, do you?
Right back at you. Name one useful mobile app that could be enabled by > 4GB virtual space. Come on, Ace...
Well... An entire category of keyword/text search. There ;-) Oh, of course it can be done in 32 bits and has been for decades. You go ahead and do yours in SQLite, and I'll do mine, well, my way. And for a decent-sized corpus I'll be somewhere around 1,000 - 10,000 times faster than you.
How many desktop apps, Windows, Mac, or otherwise, cannot be offered in 32 bit? I suspect the answer is essentially none.
Snicker, snort...
There is no market pressure whatsoever to produce a 4GB phone, much less one over 4GB...
Have you actually read one word that I wrote? Seriously, once again, hoping that you actually read it this time, it is NOT about the amount of physical RAM, it is about large virtual address space, alloc'ing and, in some cases, later extending fairly large blocks, and not running out of VIRTUAL ADDRESS space while there's still physical RAM left, but fragmented.
...and that's an existence proof that you are wrong.
Well, that's just the stupidest fucking thing anybody has said in the entirety of these comments. It's wrong in so many ways... First off, you have NO EVIDENCE whatsoever that there is no such market pressure. In fact, all the available evidence that exists points toward users wanting MORE memory. Second the lack of existence says nothing about the desirability, after all RAM takes space and power... Third, there have been 2GB phones shipping for over a year, and there will be a 3GB "phablet" shipping in less than 3 weeks, so 4GB is, right now, today, just one generation away.
I thought this was about iPhone 5s, which is not a tablet.
Can someone remember me why we still come here for industry news when editors obviously have no clues what so ever about technology.
Tomorrow is another day...
Did you read the OP? They state "OS X was designed from the GROUND UP to be 64 bit." I'm simply indicating this is untrue.
The default kernel for compatibility reasons is 32 bit. Any version of OS X before this was ONLY 32 BIT (at least according to Apple) http://support.apple.com/kb/HT3773
Mac OS X v10.6 and later include a 64-bit kernel. On hardware that supports the 64-bit kernel, you can choose whether to start up (boot) your Mac using the 64-bit kernel or the earlier 32-bit kernel.
They're all transistors at the bottom, therefore they're all the same!
I haven't seen any references anywhere about a 64-bit iOS, this sounds much like the amd64 systems being used to run the 32-bit version of Windows. While they will have some advantages with registers for 64-bit arithmetic now, more likely this has been done so when Apple releases a 64-bit version of iOS in 2-3 years they can also update the 5S users.
The numbers are bigger, since 64 > 32, therefore 64 is better. This also applies to version numbers; 8 > 7, therefore Windows 8 is better than Windows 7 (and by extension, Windows 8 is better than iPhone 5 and Linux 3.11).
This is basic consumer arithmetic, how can you not know it?
Actually, I am dismayed at the disastrous lack of quality in the app store, both apps and "apps".
Shareware from 2002 had better quality than 40% of the stuff there! When did mobile devs get the collective meme to be lazy in mobile apps?
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
don't try that open source trickery with me homie, i wasted like five years on debian until i stopped being cheap and bought a mac.
This post started by this comment "Phones are not going to have more than 4GB or RAM any time soon. " RAM, not virtual memory...
I'd be curious to know what you would do with any device with 1GB of physical ram and >4GB of virtual in use. Wouldn't it be spending 99% of its time swapping?
Lastly, 32bit devices can swap just fine, they are just subjected to the 32bit limits (4gb).
Depreciate is the wrong word. You want deprecate, with no i.
Depreciate (dep-ree-she-ate) means to decline in value. Your old computers are depreciating.
Deprecate (dep-rec-ate) means to denounce, as in 'self-deprecating humour'. In the context of technology, to deprecate is to say "we're not using that any more".
So your old 32-bit computers are depreciating because 32-bit tech is deprecated.
" I think it'd be more accurate to say pushing the limit, rather than over it. And 64-bit helps expand the limit."
How can saying nothing be "more accurate" that the simple, straightforward, and correct comment you were replying to?
How is "too heavy to be useful on any ARM processor" is simple straightforward and correct, while "pushing the limit, but not over it" is saying nothing? You're really just spewing.
"True, but that is not what I'm interested in."
Right, you are interested in masturbating to large numbers that you don't understand.
No, I'm interested in exactly what I said I was interested in.
"Not beyond what I've already said. Sorry, but there's things I just should not discuss in a public forum..."
Right...another pretentious, ignorant juvenile. Can't wait to see the revolution you start with this pent-up 64 bit codebase that we all really need in a mobile phone...
Boy, talk about pretentious. Over and over again, you're pontificating with nothing but ignorance. You won't see any revolution, because the product I'm working on is in a boring, old, stagnant sector of business software that is dominated by Windows-only products. (There's good money to made in things like that!) And I never gave ANY implication whatsoever that I had in mind a product that "we all really need", that's just a straw man, purely your own bullshit that you injected. Finally, I am not a juvenile--I suspect I may be twice your age or more, given the immature nature of your attacks. (And don't even bother whining that I'm attacking you too. I'm just responding in kind, and I don't need any more proof that you're so full of shit that it's bubbling over out your mouth.)
Nicely put.
There are advantages and disadvantages of 64-bit mode. In the case of ARM, having double the number of registers should add a noticeable improvement. The main disadvantage of using a 64-bit ABI is that now pointers consume twice as much memory and in the case of RISC processors, loading 64-bit constants into registers can take more instructions. There is ongoing work with ARM to provide a 32-bit ABI using the 64-bit mode, much like how MIPS has the N32 and N64 ABIs (most of my experience is with 64-bit MIPS but much of it applies to ARM). In the case of ARM, having twice the number of registers should make a noticeable improvement since unlike X86 most instructions don't operate on memory locations directly except via load/store.
One weakness of 64-bit ARM is the instruction set is very new and the tools are still maturing. It was not necessarily the best thought out instruction set either and the instruction binary encoding is overly complex, making a lot more work for the toolchain developers. The difference between ARM 32 and ARM 64 is far greater than the difference between X86 and X86_64.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Name one useful mobile app that could be enabled by > 4GB virtual space.
An enhanced Siri that doesn't have to talk to the mothership to interpret each voice command.
I think the A7 SoC (system on a chip) may be more intended for the iPad than the iPhone. 64-bit memory may make it possible for iPads with as much as 4 GB of RAM, which may become important as iOS apps become more and more sophisticated in future years.
You understand that Android is Linux, and Linux has been on 64 bits since it was ported to the Alpha processor in 1996. Linux has also been on 100,000+ processors for more than 15 years. *That*s why multi-core arm processors are not a problem. FTFY
The size of a data set is irrelevant. Only the size of RAM allocatable by a single process.
- Michael T. Babcock (Yes, I blog)
Not sure what "my own definition" would be, i never resorted to name calling..
Perhaps you can provide some real world examples of why your phone needs to access 4GB of ram? So it sort of is marketing BS?
Most systems when installed tend to recommend the max size of virtual memory equal to physical ram which is reduced as the amount of physical ram increases. For example Solaris recommends that if physical memory is between 2.5 and 16gb the swap is equal to physical. Above 16GB they recommend 16GB.
Looking at the computers in front of me which were setup with the defaults:
Kids content filter has 24GB ram and a max page file of 12GB.
My desktop has 16GB ram and the default page file created is 4GB.
Since the RAM in the phone cant be upgraded you are proposing 1GB of physical ram and up to the max storage capacity of the phone?
This works out to 16x over commitment on the low end and 64X on the high end (1GB physical and 64GB virtual)?
I didn't even notice that I put the i in there, twice no less. If it matters at all, I at least say it right. :)
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
When did mobile devs get the collective meme to be lazy in mobile apps?
It's the platform vendors that are encouraging it. "Come make apps over here, kids, it's a goldmine! We need tens of thousands more apps by next week to help sell the platform, so get cracking!" A couple of weeks ago, Microsoft put out a tool that was basically a wizard-based UI for generating trivial, pointless "info about my restaurant!" apps. How are customers supposed to find the signal through all the noise when that's how the app store is run?
Breakfast served all day!
The article is BS, because it assumes there are no legit technical reasons to go to ARM's 64-bit standard. To name a few:
1. Twice as many general purpose registers
2. Twice as wide general purpose registers (so 4x the number of bytes in the register file)
3. Twice as many SIMD registers
4. Double-precision SIMD
5. On-chip encryption
6. Sparse address space for security
7. Memory mapping huge files (49-bit virtual address space)
8. A64 cleaned up the old instruction set quite a bit
And yes, tablets will probably have 8GB of RAM in the next couple of years. The XBox One and PS4 will both have 8GB, and Apple is rumored to be gunning for the living room soon as well, so putting this in the 5s gives them economies of scale before they even release a product.
Besides, the iPhone Simulator has always run on the Mac in x86, so most iPhone software has already shown a high degree of Mac interoperability. In short, having the bittedness in common with the Mac is probably way, way down the list for why they went 64-bit so early.
E pluribus unum
I like the idea in TFA.
First, implement an emulator to run OSX apps in a windowed environment on iOS, implementing panning and zooming to allow these apps to be viewed on mobile device.
Secondly, install a dynamo in Steve Jobs' coffin, allowing Apple to become energy self-sufficient.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
Citation on a phone with >4GB RAM (not storage)?
The word is 'deprecate' not 'depreciate'. That is what the patent was trying to tell you.
If i could mod you up i would...
Bullshit. Making an OS 64 bit is far more complex than a recompile. And the next Android version, Kit-Kat is not expected to be 64 bit compatible.
That is true, porting objective-c code from 32 to 64 bits is tricky, and that is why Apple is doing it now. In the future when apple does need more than 4 GB of RAM in their devices, they will need to have apps that can take advantage of that. They are making 64 bit available very early so apps will be ready by then.
64 bit gives more registers and some bigger floating point operations, which marginally benefits some apps (it is not ground breaking). But the real advantage of 64 bit is the ability to address more than 4 GB of RAM, which is moot in the iPhone 5c and 5s since they only have 2 GB. So this is more about laying the foundation for future devices/apps than actually benefiting users of 5c and 5s.
Android 64 bit is at least a year away.
Sure, but the situation is very different. You see, most android Apps are not compiled to ARM. They are compiled to Dalvik, which has a bytecode that does not care if it runs in 32 bit or 64 bit. What this means is that at some point, when Google makes Dalvik 64 bit, the vast majority of the apps that run in Android will automatically be 64 bit, without even recompiling.
So unlike with iOS, Google can take its time and do the switch when it is actually useful.
A kernel isn't an OS isn't a kernel.
Your washing machine doesn't even need a 32-bit processor.
You would be surprised The question is, do you want to put up with 8051 weirdo nastiness or a nice clean arm design. The original 8051 was about 30K transistors, so was the ARM 2. Which would you rather program?
Since those days, transistor density increased more than a factor of a thousand, essentially wiping out the cost advantage of 8 and 16 bit processors, they all cost less than a buck. And see this coherent argument for why a 32 bit arm may be more efficient than an 8 bit 8051 variant: it takes way fewer cycles to get things done.
Finally, there is productivity. Quick to market counts for a lot, and low engineering costs means shorter, more agressive product cycles. The modern manufacturer just can't afford to have expensive engineers futzing around with processor limitations.
I don't know about you, but my new LG washing machine seems to put a lot of thought into what it's doing in order to get the clothes clean using the least amount of power and water, with dozens of different options. They probably saved some parts cost by implementing the motor controller in software. I would not be surprised at all to learn that they spent a buck to put a 32 bit arm core in it. My next washing machine will be on my home network and when it's done it will notify my cell phone. Probably running Linux.
When all you have is a hammer, every problem starts to look like a thumb.
ðYs¾ðYðYsZðYs
But it makes it easier. In this case Apple will have 64-bit ARM and 64-bit Intel to maintain instead of 32-bit ARM and 64-bit Intel.
That doesn't make it easier. The key is to write your code in a way that it is compatible with both 64 bit and 32 bit mode. It's really not hard to do and mainly involves not storing pointers as integers.
The biggest difficulty will be in the kernel, and even there the difference is minimal compared to the problem of completely different architectures. Especially since the Mach kernel has been working on different architectures for a long time.
"First they came for the slanderers and i said nothing."
Apple is rumored to be gunning for the living room soon as well,
FWIW I remember an article in Newsweek back around 97 which quoted Steve Jobs saying this was his goal. So they've been thinking about it for a while now.
"First they came for the slanderers and i said nothing."
Android 64 bit is at least a year away.
Really? What remains? Serious question.
"First they came for the slanderers and i said nothing."
Are you suggesting that they move towards a Windows 8 like environment where there's a tablet mode and a desktop mode?
Next time, don't go full retard.
Adrian Kingsley-Hughes should stick to writing Visual Basic books, not giving his opinions on something he doesn't know. I can advise him to read the first chapters of Mac OS X and iOS internals. Excellent book !
Dude, you do realize that switching the biggest community of mobile apps, their kazzilion apps and customers cannot be done in a week, right? Also, you seem to dwell on the "not yet" part. Almost like you"re angry it already happened. Are you with google's android marketing department?
Curiously yours, crip.
The iPhone 5c is 32-bit ARM (same internals as the original iPhone 5) and it's not even on sale yet. It'll be a while before Apple can stop letting developers target it.
The level of ignorance is astounding.
64bit gives you more than 4GB virtual address space.
Which is completely (yes, due to methods like banking completely) separate from how much RAM you use.
Virtual memory has its own uses, for example mapping in all data you need instead of reading manually.
If virtual memory is plentiful quite a few algorithms become viable, even if there is only 1GB of actual RAM.
Dear Mr. sribe (304414)
I can't help but notice you come off as very disingenious. You berate the person you're replying to without actually offerling any real data to prove your side: you literally stand there waving your hands espousing empty sarcasm. This is considered to be a slimy debate tactic, which I'm going to avoid that tactic with you.
You say you have been waiting for a 64-bit address space on your iphone, yet you don't say why. What makes this so necessary? If this is remotely common, you can at least rattle off some algorithms or use cases. Or common tasks that are used by your average person on a computer that use these, yet haven't been doable on a phone?
Is there the slightest chance anyone who witnessed the 32bit to 64bit jump in various RISC processors has seen this all before, as well as where it worked and didn't? For example, Apple had 64-bit chips with the PowerPC G5, and were ahead of the curve! Unfortunately, none of the GUI libraries were compatible, so if you wanted a 64-bit process it was CLI-only. If you wanted a GUI, you built two apps and passed the data along between them. A little extra work, but considering it would be 4-ish years till the GUI libs caught up, and there were all these awesome algorithms you mention out there... plus not everything (especially awesome algos like you mention) needs a GUI, and can always hook up to a web interface!
Except that several years later, during a point release Apple broke every app that ran as a 64-bit process, and it took several months for anyone to notice, because no one was using it. I'm sure someone in a bunker noticed, but not in the real world. Which was the guy's point: while there are surely going to be bumps, it's a pretty damned niche thing.
Is there the slightest chance you don't know as much as you let on about these things, but your vague hand-wavery looks good to those less-informed and has served you well in the past?
It was called the IBM PC.
Or the PDP-11 (no, the original 11/20 and 11/15 couldn't, nor could the 11/10 and 11/05, but the 11/45 could, as could most of the later ones - I forget whether the LSI-11 could). The PDP-11 had a number of obscure OSes that ran on it, none of which left behind any legacy whatsoever in present-day computing.
(Yes, I'm being snarky here. And, yes, I'm thinking of more than one OS, although the legacy of the other one is more indirect.)
Author is an idiot.
'The ultimate prize, of course, would be to bring the million-plus iOS apps to Macs.
Which is what will definitely not happen, because Apple is about the only company on this planet that really understands that mobile and desktop are two different animals, with different needs and patterns of interaction.
Microsoft's "surface" isn't a fail because the hardware sucks, you know?
The ultimate prize is that developers will have an easier time writing stuff for both iOS and OS X, because they can share the backend code between the two and only have to write a new frontend.
That way, instead of getting a million crap apps that work badly on OS X, you will get a few thousand quality apps with a true OS X interface.
Assorted stuff I do sometimes: Lemuria.org
Nothing to realise - the frame works for Windows Phone and Windows RT are not the same. Microsoft don't have phone apps running on desktops or laptops, they have tablet apps running on them.
So, you believe that this is something other than an Apple marketing press release. I don't.
What Apple said in their document was
which explicitly speaks of both "Cocoa" and "Cocoa Touch", so there are limits to the extent of the "common code base" - it doesn't include UI code.
The stuff about "Unifying the iOS/OS X app codebase" is, however, just Mr. Kingsley-Hughes trying to score points by Yet Again bringing up the damn "iOS/OS X unification" meme up to show how Forward Thinking he is; perhaps developers might understand what "common code base" meant (having as much of the non-UI parts of the app as possible common between 32-bit iOS, 64-bit iOS, 32-bit OS X if they still care about it, and 64-bit OS X, with the UI built atop Cocoa on OS X and atop Cocoa Touch on iOS), but technology journalists might not.
Anything you read in the tech press immediately after an Apple product announcement is suspect, to me, since there is absolutely no original reporting in any of it.
But what about original bloviating, which is what we have in Mr. Kingsley-Hughes's column? That, unlike original reporting, doesn't require real work.
Dear samkass (174571),
The article is indeed BS, but so are many of your points. For example:
[1. Twice as many general purpose registers ]
This isn't x86, while more registers are a good thing, their gain will be eaten up by going to 64-bit (everything gets bigger). In a few things you'll see some direct wins, mostly media-related, and they won't be large.
[2. Twice as wide general purpose registers (so 4x the number of bytes in the register file)]
See above, you actually said what I did, you just didn't understand it.
[3. Twice as many SIMD registers]
This could be helpful! Primarily for image data, but not as much as you'd guess (this isn't the first time this has been done on other chips, see intel's recent sse4 to avx). On mobile, video is taken care of by special chips.
[4. Double-precision SIMD]
Where exactly do you think this gets used on a traditional desktop, let alone a phone, that it's something people care about?
[5. On-chip encryption]
Oh, I don't think hw-accel encryption is limited to 64-bit chips. Considering things like VIA's padlock, well I know it isn't.
[6. Sparse address space for security]
Wait, what? It's true this has some funky anti-user security stuff in it (if you want to jailbreak your phone, things that don't want you to do that, as the user, are against you)
[7. Memory mapping huge files (49-bit virtual address space)]
Ok, you're right. With a 32-bit chip and using say, PAE, you're talking 32gigs per process. I'm not a huge fan of PAE, but you don't need to go to 64-bit for larger files, especially when you don't have a clear and present use case.
[8. A64 cleaned up the old instruction set quite a bit]
That's such a rabbit-hole of a statement that I'm going to ignore it and actually give you one: it allows Apple to know that when something is compiled to run for its 64-bit chips, a certain set of features are available. Some of these features and instructions might have been available in other chips it shipped before, but weren't targeted or used by others because a 2-4% gain here and there wasn't worth a seperate code path and testing.
64-bit processor will consume more power than an equivalent 32-bit version, so if the extra abilities aren't being used then it's a waste. And the extra abilities are almost all about memory addressing ranges.
The extra abilities include >2x integer registers, 2x FP registers, 2x SIMD registers, new SIMD instructions including AES (one area where Intel smashes ARM performance) and a number of archicture improvements that make it significantly more efficient to implement.
Similar issues apply to AMD64 vs x86. 64-bit code is generally faster than 32-bit code and faster code saves energy, as does keeping more data in registers.
Power numbers depend on implementation, but 64-bit code is likely to use less power than 32-bit code on a 32-bit-only device. And since much of the power is spent in the OS it is likely that adding 64-bit reduces overall power rather than increasing it even with 32-bit apps.
The iPhone 4 is still getting updates. The 3gs *just* stopped. My partner's nexus 7 stopped getting updates last year. My Galaxy S was outdated i bought it and maxed out at 2.2. Were it not for Cyanogen Mod, which most people don't have a clue about, much less how to install it, that's what I would still be on. You can say what you want about apple, but they generally do update their products for as long as they're capable. Even my 6 year old Macbook Pro is still able to run the latest OS.
That statement is unequivocally wrong. It will have a benefit very soon.
Not saying you're wrong, but... if you're going to state that it provides benefits, it wouldn't hurt if you could enumerate at least one.
If you use algorithms that need a large virtual space on OS X, and you have to completely back off that and use something else on iOS [...]
It would be nice if you actually provided an example of such an algorithm that requires more than 32/40 bits of addressing space (and why exactly would that algorithm be required/useful on a mobile phone).
Having to go to lower-performance algorithms on a mobile platform is a double hit to performance.
Protip: Going from using 32/40 bits of addressing space to 64 bits of addressing space doesn't magically make things faster; in fact, it's very likely to make things slower due to higher overhead (e.g. 64-bit code can be larger than the equivalent 32-bit code, which can result in a higher number of cache misses).
But hey, if you don't actually have a clue of all the things a 64-bit address space enables, then the above will sound like gibberish...
Again, actual examples of what you mean would be nice, rather than just handwaving and going "You simply don't understand." on others. That is... if you want to be taken seriously.
Cheers and have a nice day.
I seriously doubt that ARM itself is going to develop the 32-bit platform much beyond where it is today.
Do you seriously think your washing machine needs a 64 bit processor?
So they'll just use MIPS instead? Or older ARM chips?
ARM sells M-class processors for embedded applications and R-class processors for real-time applications like disc drives and automotive. These are active product lines, not older designs. These compete with MIPS, ARC, Intel Quark and a host of 8-bit and 16-bit devices.
But that's not what the article said. It talked about using the "same codebase", meaning same source code, and thought it didn't state it explicitly, it sure sounded like he was implying same backend data-handling code, not UI.
To what are you referring when you speak of "the article"? There are several things linked in the posting. There's Adrian Kingsley-Hughes's ZDNet article, in which he says:
which does not seem to indicate anything about common backend data-handling code; that's not "unifying the iOS/OS X app codebase", it's "sharing part of the codebase between iOS and OS X, at least if it doesn't depend on a large address space or fast handling of 64-bit integers etc. (in which case 64-bitness isn't that relevant) or if you don't care whether the app runs on anything other than an iPhone 5S and maybe the upcoming iPad 5 and maybe maybe the iPad mini 2 if it's 64-bit", which is a lot less "huge" than "you can just recompile your app for x86 and it'll run on OS X".
And then there's the Apple document, also linked in the original post, which says
which, with its explicit mentions of Cocoa and Cocoa Touch, makes it much clearer that you ain't going to "unify the iOS/OS X app codebase", you'll just continue to be able to share some code between iOS and OS X versions of your app.
Android is ready for x64, TFA doesn't have a clue. It's just a recompile away.
Bullshit. Making an OS 64 bit is far more complex than a recompile. And the next Android version, Kit-Kat is not expected to be 64 bit compatible.
Android 64 bit is at least a year away.
Based on what? Was latest iPhone expected to be 64 bit? Nobody outside of Android knows what's in Kit Kat.
Android *already runs on two completely different architectures* in x86 and ARM (and several variants of ARM at that). It's already far further along the multiarch than iOS, I'd say moving 64-bit on the same architecture is unlikely to be a big deal.
So when Apple thinks of bringing the tablets, phones and computers together, it's genius. When Windows did the same, it's the dumbest business decision of the century. Why ..
64 bit gives more registers
This is by far the main reason why x64 code runs faster than 32-bit x86 code, AMD were able to break the bottleneck in x86 because they were breaking compatibility, and add some much needed general purpose registers. I don't know if this is the case in ARM though, ARM doesn't have the same bottleneck.
Right back at you. Name one useful mobile app that could be enabled by > 4GB virtual space. Come on, Ace...
Well... An entire category of keyword/text search.
So... again, sribe fails to provide a concrete example of an useful app that would be enabled by 64 bit addressing. Just more hand-waving, ad hominems and arrogance...
Keyword/text search of what, exactly? Why would it require to address more than 4 GB of memory directly? And, if that is the case, wouldn't it first require that smartphones actually start being produced with > 4 GB RAM, before one can leverage the new 64 bit CPU for that supposed "keyword/text search" app (which is supposed to do "keyword/text search" on some mysterious domain that he still hasn't explained).
Finally, as sribe admits, even his contrived and vague example could easily be implemented with 32-bit memory addressing.
I'm not saying there ISN'T an advantage to having a 64 bit CPU on a smartphone: what I'm saying is that sribe completely fails to provide any CONCRETE examples to back up his claims (but, of course, it's just because everyone else is ignorant).
To conclude, I'll just say that sribe must be the coolest person to have a live discussion with... given that his arguments range from "you have no clue" to "snicker, snort". My favourite part is when he screams "NO EVIDENCE" at you, without providing any evidence himself... priceless.
I suspect anything you wrote was interpreted rather than compiled.
Ah, yes, the EMM386.EXE of the 32-bit era... (Dang, I feel old.)
Hacker Public Radio is our Friend
Between x86-32 and ARMv7, these are all the same (well, the cost of unaligned loads and stores is more on ARM). Between x86-64 and ARMv8, they are the same. This also means that you can trivially share memory-mapped data between the two. If you were to ship a laptop with some ARMv8 cores and some x86-64 cores on cache-coherent memory interface, then you could trivially translate system calls made on the ARM chip into system calls delivered to the x86-64 operating system - you'd need to tweak the call frame, but any of the data passed by pointer would be readable by the kernel (actually, this doesn't necessarily require cache coherency, as the OS X kernel always explicitly copies data in and out via some well-defined code paths). You could also use shared memory and Mach ports to communicate between the application and the window server.
In fact, given the comparatively stateless nature of the OS X window server, it would be conceivable to have the ability to dynamically switch between a window server running on the ARM core (when in low-power mode, checking email or whatever) or the x86 core (when doing real work).
I am TheRaven on Soylent News
Depends on their market segment. Apple already has the infrastructure in place for shipping fat binaries (sorry, 'universal binaries'). If they can persuade developers to ship x86-64 and ARMv8 fat binaries then a MacBook Air with a quad ARMv8 SoC and a touchscreen (and the ability to run iOS and OS X apps) might be a very interesting device. It would be seriously underpowered in comparison to the MacBook Pro, but the current MacBook Air is anyway.
I am TheRaven on Soylent News
One of my favorite times to read slashdot comments is while deprecating:/
I was referring to their x86 transition. Their iPhone support is OK in comparison to the competition, but remember that the 3GS was still sold until only 2 years ago. That's less that 2 years of support, though I suppose relatively few people would keep their phone longer than that. The Mac support has been pretty good recently except for the original x86 Core Duo devices, which got dropped with Lion. IMHO, the Mac situation is more serious since computers get kept forever. For instance, I have a perfectly serviceable G5 machine which is perfect for the kids, but that gets no security updates. It is completely orphaned. My mother-in-law has a 2004 HP laptop of similar age to my G5 that still gets XP updates. I'm not sore about it at this stage - it is 9 years old! - but I was sore about it back when 10.5 went unsupported with no successor.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
My nexus 7 still gets updates
2 years seems to be their track record between getting discontinued and ending support, IIRC.
The 5C game is not really new - in the past they just sold their flagship
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Thank, I _WAS_ enjoying my breakfast until that.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
I don't think I'm really adding much here but the discussion of the 8051's quirks struck a chord with me! The 8051 is a bit weird in place, although in fairness with a C compiler you can just mash on through that and not worry too much. If you actually have to look at the architecture, you can definitely see its age, though. But for 8-bit stuff, the AVR architecture (Atmel's microcontrollers) genuinely are relatively nice, despite being just an 8-bit CPU. They are RISC CPUs, so they actually have a fair number of registers and comparatively few weird quirks (that I could see).
The other big advantage in my particular line of experience is that as long as a CPU has lots of registers, gcc often supports it. Otherwise you end up having to use slightly less mainstream compilers - which is basically OK, they're still nice software. But they're not as comfortable to me as the standard GNU toolchain. Of course, I'm sure plenty of commercial embedded programmers aren't familiar with the GNU toolchain and so don't care about that.
I see now, said the hammer and saw.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
I meant "Nexus S", though I do wonder how long my Nexus 7 will continue to be supported.
AFAIK, the support for Lion was dropped for the 1st generation core series because the processor could not actually run it. Windows 8 has a similar issue in requiring NX bit support. It's not like Apple is artificially engineering obsolescence. You're right that Apple does tend to abandon old OS'es, but then again, they don't have the install base XP does so there isn't a huge reason to. Old Macs aren't being turned into bots. They might not be as "secure", but for most people, they're secure enough.
Yeah. I meant Nexus S. I have a Nexus 7 as well and it's still getting updates, but it's only a year old.
The modern manufacturer just can't afford to have expensive engineers futzing around with processor limitations.
That's not really true. An engineer costs maybe $100,000-150,000 per year. If you sell 100,000 units and save a buck a part, you've paid for the engineer time for a whole year. I don't know what the sales volume for LG washing machines is, but I'd bet it's in the millions - and probably they can use basically the same controller board with minor revs for a number of years (until the parts go obsolete). We make stuff with much lower volumes - in the 10,000 range - and we sweat over dollars here and there all the time. That said, the newest embedded ARM stuff looks pretty sweet, and I wouldn't doubt that it will show up in more and more applications.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
This is about Mac OS X on x86 only. They've had G5 before going the x86 route so some support for 64-bit AFAIK was there since 10.4
32-bit x86 processors can address more than 4GB of RAM. The ARM specification allows for 40-bit PAE, which should support up to a terabyte of RAM. So we could get an iOS device with a 32-bit ARM processor that has 8GB of RAM; that's not an issue.
Each process will only be able to see 4GB of RAM, but right now, iOS apps get killed after using more than 256MB of RAM or so. The policy seems to be that each application can use about a quarter of the machine's RAM, so if they're keeping that trend and want a device with 16GB of RAM, they'll want a 64-bit processor, but I think that's a ways off.
Are you seriously suggesting that Apple migrates their desktop machines to hardware that's about 10 years behind the curve in terms of performance when compared to x86?
The processor in the iPhone 5 was designed by Apple. So the question is whether Apple think they can design a better processor than Intel or ARM. And since this is Apple we are talking about, they almost certainly think that they can.
This is not a transition from one third-party processor to another: It is a transition from a third-party processor to a processor that is 100% controlled by Apple.
I wonder why your comment is negatively moderated. You are totally right.
To what are you referring when you speak of "the article"? There are several things linked in the posting.
I didn't even notice that. (So many /. summaries have multiple links to the same article...) Anyway to answer your question, the ZDNet article, and it seems that when I read it, I focussed more on the second part of what you quote than on the first. I never have thought of "common code base running across multiple systems" as "the code of entire apps being completely the same across multiple systems". But then again, I don't do much Java work, so maybe his phrasing is more open to interpretation.
So, 2 facts:
1) absolutely indisputable, most journalists writing about the 64-bit thing have no clue at all what it really means and are just spewing,
2) somewhat arguable, but I think true, Kingsley-Hughes seems to be a bit better than most.
Yes, because what prevents that from being implemented is obviously the lack of 64-bit memory addressing.
*rolls eyes*
Maybe Apple plans to cram a full-blown desktop system into the iPhone, Shuttleworth style. Phone personality when stand-alone, and desktop personality when docked. Not right away, of course. The two systems haven't merged yet. But down the road...
Actually, that might be a route for Microkia to take - and the new low-powered intel chips might make it feasible. If so, the desktop OEM's won't be happy. In any case, I hope Android gets there first - followed by Canonical. The interesting bit is that none of the potential players in a 'dockable phone/desktop' arena have a serious stake in desktop hardware. Apple does, but minor compared with their mobile juggernaut. Microsoft has a desktop software business, and I don't suppose they can get away with charging a $100 software premium on their phones (on top of the beefy hardware requirements) to make up for the loss of desktop Windows licenses. So maybe they'll hold back and give Samsung, Asus and Motorola a chance to shine.
Posted from my Android phone. Oh, I can change this? There, that's better...
That's what Microsoft tried with the Metro interface.
One word: mmap()
As a programmer I never read() from a file anymore. I just open(), use stat() and mmap() the file completely in memory and I am done.
With large files like audio and especially video you want an OS that can map such a file in virtual memory. Large files requires a 64 bit OS. And mapping large files in memory will work with less memory, the OS will handle all the buffering and caching, much better than you would.
mmap() it will change your live as a programmer!
When you turn six you'll start to care. That will be your first day of obsolescence. From then on each year they'll retire odd bits and pieces from your history. Sort of like a reverse dementia you'll live in the last five years of the present until one day they pull the plug. Forever five.
Already there.
It would be a big mess to take the existing apps over to OSX.
...because you'd have to replace the UIKit calls (Cocoa Touch) with AppKit calls (Cocoa). 64-bit iOS does not get rid of the Cocoa vs. Cocoa Touch split, even if Kingsley-Hughes misread some Apple documentation and concluded that it might.
mmap() of large files.
As a programmer I never read() files anymore.
Letting the OS handle the nitty gritty details of loading the file into memory is a godsend.
mmap() on a 64 bit OS would give me benefits now.
mmap() does not need a large about of physical memory, but it does require a large virtual memory. A iPhone with the memory sizes that it has now would benifit from 64 bit CPU and OS now.
These are completely different architectures, and I highly doubt portability will be easier between the two, just because one makes the jump to being native 64bit.
Yeah, just as it was extremely difficult to move apps from RISC Macs to CISC Macs. Oh, wait....
(And that transition involved going from big-endian PPC to little-endian x86; I think iOS runs ARM little-endian.)
The difficulty is not the instruction set architecture, the difficulty is the UI toolkit (Cocoa vs. Cocoa Touch) and the different UI choices made due to screen size and touch-screen-vs-{mouse,touchpad} differences in the hardware.
Whow, you are really not listening to this guy do you?
It is about VIRTUAL ADDRESS SPACE. That means VIRTUAL MEMORY. VIRTUAL MEMORY is BIGGER than PHYSICAL MEMORY.
I am another programmer and I always mmap() files into virtual memory, that is files that are larger than physical memory.
Another example is allocating a huge piece of virtual memory, like a couple of terabytes (also with mmap()), it is even bigger than any file that could exist.
Did you know that only when you write into virtual memory the physical memory comes into existence? Therefor you could use a huge piece of memory for a sparsely populated associative table. If a row in such a table also uses about 4Kbyte (a page) of memory then it would be extremely efficient.
Not the same, but they both suck.
The chip I work on requires 64-bit (or 40-bit LPAE) to use more than 2GB of RAM. as the rest of the physical address space is used for I/O programming.
The vast majority of user space applications on our 64-bit Android platform are only 32-bit. We run a 64-bit kernel and 32-bit user space. Not much need to go beyond that, but there is a huge advantage for the kernel to use 64-bit instead of LPAE. Less copying around of buffers for high mem, and the drivers can access all the bits they need. And the virtualization (and thus security capabilities) on 64-bit is massively better.
virtual memory is a lot larger than physical memory and swap space together.
Read about mmap()
Then learn how you never have to read from a file again.
Yes mmap() will work for files that are huge compared to physical+swap.
A lot of people will roll their eyes and talk about how this would supposedly weigh the system down. But it would not have to do so at all. Gnu systems can do this, if you care to set up all the requisite emulators/not-emulators, and dont mind some lack of polish. A modern PC can run all this old software in an emulator without bloating the (by todays standards, extremely modest) requirements of the old software by enough to really notice in most cases. You know why they dont do it?
Because they make money from selling new software. And for decades now they have driven demand for new software by deliberately breaking old software. Just like everyone else in the industry.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X
Intel chips have been RISC internally for so long that your ignorance isn't even funny.
"Internally" doesn't count from the programmer's point of view; you don't get to write uop code for the particular x86 processor you're running on.
More to the point, the issue with the transition wasn't that it was "RISC to CISC", it that it was "instruction set architecture A to instruction set architecture B". If it were a transition from PowerPC to another RISC instruction set architecture, it would only be easier if the other RISC ISA were big-endian (so that you didn't have to deal with code that's explicitly or implicitly expecting to run on a big-endian ISA).
But the real advantage of 64 bit is the ability to address more than 4 GB of RAM
4GB per process, and that is a fucking important distinction. ARM supports a 40-bit (about 1 TiB) address space.
Did you read the OP? They state "OS X was designed from the GROUND UP to be 64 bit." I'm simply indicating this is untrue.
Yeah, the OP was trolling.
The main benefit of this move to the latest ARM CPU design is ironically much the same as the advantage brought by x86_64 - more registers are now available and some floating point operations are more efficient.
I need a citation for that statement. While I can readily believe floating point is faster, I'm highly doubtful ARM64 includes 64 general purpose registers. My understanding was the ARM64 general purpose registers are simply twice as large, which is a rather different from doubling their number (even 32 registers tends to almost be a little excessive). In fact I'd read previously they'd optimized the instruction set to include less state, which is a major win for pipelining. ie rather than every instruction including conditional execution, ARM64 has more traditional branches, so it doesn't need to adjust very much if a branch is mispredicted.
1. Twice as many general purpose registers
3. Twice as many SIMD registers
Could I get a citation for this? While I'm pretty sure the registers are twice as wide (it wouldn't count as 64-bit if they weren't!), I'd like to see a reference for ARM64 having 64 general purpose registers. Every other 64-bit processor besides amd64 has 32 general purpose registers, because programs are rarely able to take advantage of all 32, unless perhaps ARM64 doesn't do any register renaming.
Uh, you already have that with XCode. There's a couple of different versions of emulators...
If you sell 100,000 units and save a buck a part, you've paid for the engineer time for a whole year.
That's just the point: a highly capable ARM processor can be had for a buck these days in quantity, and still dropping. You can't save a buck because it only costs a buck. Now you are back to that expensive engineering team, and the marketing campaign that is being held up.
When all you have is a hammer, every problem starts to look like a thumb.
The potential implications of 64-bit architecture go far beyond simply more computing power. With 18 billion gigabytes of address space, an iDevice could use iCloud as a giant virtual memory store, just as today's PCs use hard drives or SSDs. That means any bit of data--whether it's a document, a photo, or a chunk of program code--can be addressed by the mobile device as though it's in the device's local memory. If it's not, a "page fault" is generated, causing the data to be automatically fetched from iCloud, and the iPhone goes on like nothing happened. It's a much simpler and faster programming model than dealing with data in files, and I suspect the iCloud "Core Data" facility that is currently giving developers grief is just Apple's first step toward this. Stay tuned. Also, with that much available address space, Apple could dedicate a huge block of iCloud addresses to a massive database shared by all iDevices: things like maps, software updates, regional traffic and weather conditions, sports scores, Siri support, and on and on. (Cross-posted at http://www.macworld.com/article/2048623/how-apple-stretched-its-wings-with-the-iphone-5s-hardware-design.html)
swapping? On a phone? Are you kidding me?
How is it "bolted on" when they spent the last several years moving to 64 bit for the kernel, etc? Since everything was re-written, isn't it "designed from ground up"?
Uh, that just means you are still writing and using 32 bit java, sorry, dalvik code. That means your code doesn't get to do 64 bit addresses, etc.
Are you kidding me? And I've got this whole 32-bit to 8-bit migration setup....
I think you are missing a important point! For having a same codebase for 32 and 64 bit processors either you'll need to have a huge HAL (hardware abstraction layer) and inefficient hookes OR the program will have to run in emulation mode, both of these are extremely in-efficient. This inefficiency will be further amplified if the program is of graphics computation of 64 bit colors because generally to make it high performance the programs use direct bit level operations. --- Commercial Break --- BREAKTHROUGH: Zero Point Energy harnessed for creating energy from nothing: http://m.slashdot.org/submission/2946465 donation: minimum $1 to bring it to the people --- Continue --- The is why there is bit difference in code base even for little endian and big endian architectures if the performance needs to be good (if you use compiler flags to do the optimizations, forget that it can do a great job at that) -- I am ex lead programmer of Adobe Acrobat For Linux/Unix platforms and was responsible for fixing architectural and performance issues.
I think you are missing a important point! For having a same codebase for 32 and 64 bit processors either you'll need to have a huge HAL (hardware abstraction layer) and inefficient hookes OR the program will have to run in emulation mode, both of these are extremely in-efficient. This inefficiency will be further amplified if the program is of graphics computation of 64 bit colors because generally to make it high performance the programs use direct bit level operations. --- Commercial Break --- BREAKTHROUGH: Zero Point Energy harnessed for creating energy from nothing: http://m.slashdot.org/submission/2946465 donation: minimum $1 to bring it to the people --- Continue --- The is why there is bit difference in code base even for little endian and big endian architectures if the performance needs to be good (if you use compiler flags to do the optimizations, forget that it can do a great job at that) -- I am ex lead programmer of Adobe Acrobat For Linux/Unix platforms and was responsible for fixing architectural and performance issues.
Yes the adresses are 64 bit. And the extra registers of the ARMv8 architecture would be used. The only downside is that array indexes are 32 bit. So you can't have an array with more than 2^32 elements. Pretty reasonable compromise to keep 32 bit compatibility. But longs in java are already 64 bit. So if your program uses long data types, it will get a speed increase by moving to 64 bit.
http://en.wikipedia.org/wiki/64-bit_computing#32-bit_vs_64-bit
http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_description
ies Why Apple Went 64-Bit With the iPhone 5s from the all-about-the-software dept. Hugh Pickens DOT Com writes Adrian Kingsley-Hughes says it's not just because Apple likes bragging about being first and because a 64-bit processor sounds cooler than 32-bits that Apple used the 64-bit A7 chip in the new iPhone 5s. A shift from a 32-bit processor to a 64-bit part paves the way for iPhones to be fitted out with 4GB+ of RAM down the line, but more importantly the move brings iOS and OS X apps much closer. The architecture for 64-bit apps on iOS will be almost identical to the architecture for OS X apps, making it easy to create a common code base that runs in both operating systems. 'Apple has slowly been bringing iOS-like features to Mac OS for years now: think of Launchpad and Gatekeeper,' writes Sascha Segan. 'The ultimate prize, of course, would be to bring the million-plus iOS apps to Macs. Apple could do that with an ARM-compatible virtual machine on Mac hardware, but it would want the VM, the OS and the associated apps to play nicely in the much larger memory space available on Macs. That means moving the whole system over to 64 bit.' By unifying iOS and Mac OS with Xcode developer tools in a 64-bit space, Apple could once again leap ahead of Microsoft and Google, says Segan. Microsoft hasn't yet been able to leverage its desktop strengths to achieve success as a mobile OS. The 64-bit chips for Android devices aren't ready, and neither is Android itself. Posted by Soulskill a day ago apple iphone os 445 Comments Help All Outstanding Funny 64-bit BS (-1) Anonymous Coward a day ago Filtered due to preferences. Re: 64-bit BS (+1) Anonymous Coward a day ago So you didn't even bother to read the summary did you? Reply Share Flag Re: 64-bit BS (+5, Insightful) jedidiah a day ago I did. The whole thing is nonsense. You don't have to enforce a single architecture to have common code. Neither do you need to have a virtual machine running the same bit-ness as the host operating system. This is just the usual kind of cluelessness that comes from a community that is proud of being stupid. Yeah. 64-bit BS. Reply Share Flag Re: 64-bit BS (+5, Informative) MightyYar a day ago You are absolutely right. The whole summary doesn't make any sense at all... first of all, the Macs run 32-bit applications just fine. Second, if you can emulate a 64-bit ARM, you can emulate a 32-bit ARM. Third, phone apps would suck on a laptop or desktop. I suspect they went to 64-bit for the simple reason that it is the direction ARM is going. This processor design is likely to show up in their lower-end products for years after it leaves their flagship device, and the sooner they go to 64-bit, the sooner they can depreciate the 32-bit stuff. Unless the 64-bit chip cost significantly more to design, produce, or unless it has a significant performance penalty, there is no reason to delay making it. Reply Share Flag iOS on Macs (+1) mozumder a day ago Apple is most likely going to introduce a system where the display is iOS like an iPad, and the rest of the system is Mac. There are several options on how they can do this. They can have a separate machine on the display, with ARM/Memory, to keep main CPU powered off when not in use. They could have everything operate from a single x86 cpu like a laptop. They could have both ARM/x86 CPU's sharing a common memory, and so on. Eventually they will merge, but whatever they do they will have the experience of Windows 8's failures/success to build upon. Reply Share Flag Re: iOS on Macs (+1) MightyYar a day ago They could have both ARM/x86 CPU's sharing a common memory, and so on. That would be a neat setup, if they could run the ARM like a co-processor to avoid emulation. ARM is certainly cheap enough. Reply Share Flag Re: iOS on Macs (+2) donscarletti 16 hours ago I like the idea in TFA. First, implement an emulator to run OSX apps in a windowed environment on iOS, implementing panning and zooming to allow these apps to be viewed on mobile device. Secondly, install a dynamo in Steve Jobs' coffin, allowing
Not artificially manufacturing obsolescence? Care to explain why the first and second generation Mac Pro is unsupported by the final release of Mountain Lion, then? (after they were supported in beta versions!)
I think not. I've found that I blend the touch interface option into all the others that are available. I don't know about other content creators (yeah, right!), but multiple screens is where it's at here and they are not all the same screen size, nor even DPI. Affordable, usable touch-screens are almost in reach and having one to one (or both!) sides would be a "nice to have" option tossed into the mix of multiple up-front screens. Unfortunately, any such setup is going to run right into the solid block of iridium that seems to be put in front of such a "maestro" configuration by all the operating machines. [Ars Technica has a really nice piece on this topic right now. Can't miss it.]
Giving content-creators more options is almost never a bad thing. And I for one can't think of any of us that strictly approach things in exactly the same way. Which gets to the crux of the Ars article, in my not so humble opinion. This consumerization thang ain't so gud for we ars-tist-tick types. That could be worrying if the strict limitations of iOS pisses in the OS X pool. Going the other way... could be nice for off-the-cuff mods. Which is why I had deja-vu when I read that 4 GB ggggGP remark. Didn't someone allegedly say something about 640K, sometime?
Aside: Content creation, while usually thought of in the media sense, isn't strictly just that. Given that I work in multiple schools of engineering, fields of science, yada, yada, content creation extends to those areas as well. Modeling and manipulation and visualization are essential points even before blending across applications. And flicking around manipulating multiple screens using multiple input methods (keyboard, mouse, pen, voice (yes, voice), and touch) are just starting points for the high end. Until direct-thought-controlled machines come along....
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
It's not like Apple is artificially engineering obsolescence.
Care to explain why the first and second-generation Mac Pro aren't supported by Mountain Lion, then? After being supported throughout the beta period? They ripped out working code, just to get people to buy new machines. That's just one instance...
Exactly, this should worry competition. While other guys are adding quad and octo cores of various types, Apple is content to let them be peedier for now... While Apple sets up its next move two or five years down the road. People miss that Apple was TRIPLE booting OSX in the earlier days while they were moving from PPC to X86 but also to ARM or iPhone at the same time. Apple is making this move to position valuable Engineering resources for the NEXT big project we don't even know about yet... And they make modest gains in performance with the current device right now.
This could signal Tim Cook has "something up his sleeve" and Apple learned how to REPEAT moving to new products that Steve taught them.
I've seen a few apps which have both desktop and mobile versions. I can't name them offhand because I didn't expect this question. I think they were primarily "productivity apps" like spreadsheets, where you can expect to spend a bit of time in. I think the reason it's not more common is iCloud integration. It's not difficult to implement, but does require additional effort in the form of design and most especially testing. I suspect that most developers don't think the effort is worth it. I considered adding it to my app, but when I looked at all the apps I use regularly, none of them include iCloud integration.
I haven't ported my app to OS X, but the base would be easy enough. I'd have to be sure of demand before spending the time and money. I'm sure that's true of any IOS developer of apps that don't require specific hardware.
Plan My Week for iPhone
64 Bit ARM ups the general purpose register count up from 14x32 bit to 31x64bit.
So it wasn't short of general purpose registers before. But for sure, those extra registers will be made use of by a decent compiler.
For them to start the process, do the development, alpha, beta, and then to put it in an actual release. And a switch to 64 bit is something for a major release not a minor release.
The next major release, KitKat is due next month. And it had 64 bit functionality we'd have heard about it by now.
It's going to be a year till the next major release after KitKat.
Based on what? Was latest iPhone expected to be 64 bit? Nobody outside of Android knows what's in Kit Kat.
So much for open source! In reality when it comes to software, Apple keeps their intentions utterly secret till it comes time to release either hardware with it on, or an SDK. With Android, the time between their mentioning that something is coming, and it appearing on a device or a shipping SDK is a long time. For example, Samsung have announced they will do 64 bit on their phones next year, in response to Apple's announcement.
Android *already runs on two completely different architectures* in x86 and ARM (and several variants of ARM at that). It's already far further along the multiarch than iOS, I'd say moving 64-bit on the same architecture is unlikely to be a big deal.
The low levels, where the CPU architecture matters, is largely shared between OSX and iOS, and thus is already x86, x86-64, ARM and ARMv8 compatible, and had previously has PowerPC as the major architecture. So no, iOS wasn't in any way less multi-arch than Android.
But that's not the point. I'm not saying that Android is any harder to go 64 bit. It's just that Apple have already done it, before it seems to have even become a thing to consider for the Android developers.
Sadly, many (most) of the people that do work on emulators aren't a mile deep in the hardware, software, system, etc., engineering disciplines. With today's multi-core, multi-threaded architectures, it's quite a bit easier to do it right even to a fine level of detail. It helps if you weren't wedded to any particular architecture to begin and can draw from a raft of different ways of doing things in hardware, software, and especially how to substitute one for another, why, and at what expense. Being adept at blended solutions helps.
... ;-).
I've been using emulation and virtualization for 3 1/2+ decades, 2 1/2+ for PC/Mac/*nix alone, but I was blessed with good teachers, especially in thinking about constraints, at a very early age followed with a lot of time having to work with less that adequate budgets of anything except my time while not attending to other duties. Then again, I was usually only called in for major disasters so time wasn't such a limiting factor after all and having it as a hobby
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
You are right, they aren't publicizing it as a feature of KitKat. I'm not sure the work necessary is all that great, it might literally only need a new compile to be 64 bit. I'll check that out when I get to work Monday if I remember. Android already runs on a surprising variety of architectures, ARM, x86, MIPS surprisingly enough.......
"First they came for the slanderers and i said nothing."
Wait, it's "speculation" that the new iPhone is 64-bit?
I'm sorry, It thought the product announcement from Apple stated it was 64-bit.
You are welcome on my lawn.
One word: mmap()
450 comments, and as far as I can tell, precisely 2 people here who understand this. Fucking pathetic.
But hey, if you don't actually have a clue of all the things a 64-bit address space enables, then the above will sound like gibberish...
mmaping larger files without using offset windows. And because ARM64 and AMD64 only have 40/48/56bit virtual addresses, you still have to use offset windows when working with really large files.
So, not much.
There are no new algorithms requiring 64 bit architectures, mmap is not a different algorithm to reading files, it's just a linear optimisation of the same algorithm, one which often doesn't pay off. I've tweaked IO code in software to use mmap, and at times I've pulled that code out again because it had a negative pay off. Specifically if you're doing a bunch of sparse random IO, you get better performance by not mapping records into memory, and instead using an LRU cache to find hits, if you mmap, you have to cache the entire page, rather than the one record you needed from that page aligned block on disk, keeping 4k resident to avoid copying 128 bytes is not a win, usually.
Dude, have you seen how cheap embedded 8051 CPUs in USOT8 packages are? Plus they use less power than a 32 bit processor, and have denser code, saving on flash. Also programming 8051 assembler is easier than fucky pseudo-risc ARM.
I think the longer term strategy is clear: iOS isn't getting more Mac-like, Macs are getting more iOS-like. The article has it backwards... Why would Apple invest in its own chip development only to emulate that on the Mac? If the iPhone doesn't need a 64-bit chip what does? iPads and Macs. We're going to see an ARM-powered OS X. Getting developers on board with the easiest to port apps (iPhone specific ones) is just the beginning. I would kill for a MacBook that had the battery life of an iPad. If only it had the computing power too..
You do realize the architecture isn't the same as your windows machine? The 4 GB argument is only put forward by those that don't know what they are talking about.
Jealous much?
This is not x86 architecture. You don't know anything about ARM.
No, you meant deprecate. Two different words with two different meanings.
Actually, depreciate and deprecate both have 2 meanings, one of which is the definition of the other.
http://www.google.com/search?hl=en&gl=US&ie=UTF-8&source=android-browser&q=depreciate
http://www.google.com/search?hl=en&gl=US&ie=UTF-8&source=android-browser&q=deprecate
THINK! It's patriotic
Regardless of why Apple are going for a 64bit ARM....
Just like the desktop, it will be another 10 years before the software is native 64bit. By that time, who knows, 128-256bit will be here lol
As soon as you allow for 32bit emulation, your basically telling the software developers to stick with it.
Why would any developer want to actively support 2 compiled versions, and, double the support workload?
Even now, on the PC platform, i have "64bit" versions of software that still rely on 32bit applications. The service or driver is 64bit, yet the core applications that runs is still "32bit".
32bit applications will be here forever. No doubt emulated on 128-256bit hardware in the future. Welcome to the future of computing...........
I forget how many cat versions Apple used to say was finally ready for 64 bit. I think it started in 10.2, 10.3 definitly had it.
That is simply not true. 10.4 was the first version that offered any 64-bit support, and that was only for non-UI background processes.
Several journalists have made this mistake, such as the drivel posted here: Trusted Reviews
Please give a stronger warning when you post links like that. Quoting, "Smartphones that use older 32-bit processors can only work with data strings that consist of 32 characters" those details are so badly wrong that is well beyond drivel. I believe the much larger performance gain from ARMv8 is the reduction in context by making only branches conditional. While it loses for tiny bits of conditional code, it means far less state is required in the instruction pipeline. Going from 15 general purpose registers (ARM's program counter takes one of those slots) to 31 general purpose registers allows more code to only use registers, but not all that much.
4GB RAM. Please.
iPhone barely likes giving away 16GB STORAGE. Never mind RAM.
It sets price points on cheap memory. It is going to install expensive memory now?
Likely this is just a strategic next step in technology. The chip is going there anyway, Apple along for ride. Much like 95% of desktops out there that have 64bit cpus and don't utilize I iota of them, neither in size or RAM, special instruction sets, or in programming.
Try to download an iOS 7 app on your older iOS, it'll offer to give you an older version.
The extra registers won't mean that much of a difference as x86. This would be going from 16 to 31 (unless Apple decided to do something different), which you are right probably won't mean much since that probably isn't the performance choke point. But x86 went from 6 to 14, and I remember one game got a 20% speed improvement just recompiling to use the extra registers. Still notice current ARM 32 has more registers than x86-64.
OS X and iOS are much the same. Likely they already have an ARM OS X running (they had x86 running years before the switch). In a few years expect Apple to design a more powerful 4+ core A series chip, and for the latest MacBook Air to be running it, advertised battery life "all day long."
It will translate x86 applications to ARM and cache the translated executable. XCode will have another checkbox for ARM to produce fat binaries native on both platforms. They're using OpenGL on both, so that should translate between the PowerVR and NVidia GPUs.
32-it ARM already has more registers (16) than 64-bit x86 (14). This is far less of a "break the bottleneck" scenario than when x86 went from a paltry 6 to 14.
OS X was taken 64-bit from the sky down. First certain performance-intensive libraries like math, then others, then Finder, then BSD, then Mach. It allowed for a more gradual approach that didn't break tons of applications require 64-bit hardware from the beginning.
For iOS it's much easier. They can just install a completely 32- or 64-bit version based hardware. There are fewer than 10 32-bit major hardware variations out there, and all will be out of support in about four years. By that time, the "Apple TV" product will be using the then-old 64-bit A7 processor while the latest iPhone (or even MacBook) gets the A10.
But a big reason that I don't think anybody has mentioned is that with ARM64 cryptography functions in the SIMD unit now handle AES and SHA. That right there should give a huge speed boost to anything encryption related, which Apple is building more and more into the system.
Several journalists have made this mistake, such as the drivel posted here: Trusted Reviews
They seem to think that the register size being equal means that software written for them is somehow much more similar. In reality the CPUs and the software they run are no closer to each other than before. The main benefit of this move to the latest ARM CPU design is ironically much the same as the advantage brought by x86_64 - more registers are now available and some floating point operations are more efficient. This will translate into a small performance increase but it won't be night and day.
http://www.anandtech.com/show/7335/the-iphone-5s-review/4
Speedup in Geekbench (just from a re-compile): Integer gain between -25% (Dijkstra, heavy on pointers) and +825% (AES, uses new cryptographic instructions), geometric avarage +37%, median +9%; FP gain between 0% (Mandelbrot) and +195% (DGEMM, uses new DP-SIMD), geometric avarage +36%, median +21%
You're funny.
Are you seriously suggesting that Apple migrates their desktop machines to hardware that's about 10 years behind the curve in terms of performance when compared to x86?
Stop swimming in the kool-aid.
Funny how about he only ones who keep claiming that are the Fandroids. Tastes more like Hatorade.
Intel chips are RISC as well, the CISC is bolted on top for compatibility reasons.
Errm, the best way to tell if a chip is CISC is to see if it has a microarchitecture inside distractors insist on calling a RISC.
Wowsomeone that actually knows about and possibly used a PDP-11 machine! Going back a bit further, do you remember the Xerox Sigma 9?
Wowsomeone that actually knows about and possibly used a PDP-11 machine! Going back a bit further, do you remember the Xerox Sigma 9?
Nope - the PDP-11's came out roughly the time the Sigma series went away, and I never had a chance to use a Sigma (did get to use a S/360-40 and KA10 PDP-10 in a summer program when I was in high school and an 1130 at my high school, though). Did work on PDP-11s in college and in my first two post-college jobs.
Yeah, see you're responding to one of the grandparent or great gp posts. This discussion is not so much about mobile anymore, but about the abomination that was PAE and AWE (long may it stay dead and never return ever).