Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Apple Went 64-Bit With the iPhone 5s

Soulskill posted about a year ago | from the all-about-the-software dept.

Iphone 512

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."

cancel ×

512 comments

Sorry! There are no comments related to the filter you selected.

64-bit BS (-1)

Anonymous Coward | about a year ago | (#44844099)

Phones are not going to have more than 4GB or RAM any time soon. 64-bit is Marketing BS at this point.

Re: 64-bit BS (1)

Anonymous Coward | about a year ago | (#44844143)

So you didn't even bother to read the summary did you?

Re: 64-bit BS (5, Insightful)

jedidiah (1196) | about a year ago | (#44844387)

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.

Re: 64-bit BS (5, Informative)

MightyYar (622222) | about a year ago | (#44844467)

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.

Re: 64-bit BS (0)

Anonymous Coward | about a year ago | (#44844409)

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.

Re: 64-bit BS (0)

Anonymous Coward | about a year ago | (#44844477)

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.

Re:64-bit BS (3, Insightful)

sribe (304414) | about a year ago | (#44844185)

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.

Re:64-bit BS (-1, Troll)

AlphaWoIf_HK (3042365) | about a year ago | (#44844249)

Would you do an ass dance in a juicy graveyard? Inquiring minds want to know...

Re:64-bit BS (1)

Anonymous Coward | about a year ago | (#44844315)

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.

Re:64-bit BS (1)

mythosaz (572040) | about a year ago | (#44844515)

How about on my tablet?

Can I use a 4GB database there?

Re:64-bit BS (2)

PopeRatzo (965947) | about a year ago | (#44844507)

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.

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:

'The ultimate prize, of course, would be to bring the million-plus iOS apps to Macs.

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.

Re:64-bit BS (3, Informative)

Xicor (2738029) | about a year ago | (#44844215)

the ubuntu edge was going to have 4gb of ram, but it only got 13 million out of the 32million funding goal

Re:64-bit BS (1)

Anonymous Coward | about a year ago | (#44844331)

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.

Debian (4, Insightful)

kthreadd (1558445) | about a year ago | (#44844111)

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?

Re:Debian (3, Insightful)

dkleinsc (563838) | about a year ago | (#44844165)

If I had to guess, a large number of people put in a large amount of effort. A really fine cross-compiler probably helps immensely.

Re:Debian (0)

Anonymous Coward | about a year ago | (#44844195)

Or just way better hackers. The reason why a lot of developers of non-free software hide their source and prevents users from reading it is that it's so bad the users would quickly move to a better alternative.

Re:Debian (3, Insightful)

Morpf (2683099) | about a year ago | (#44844273)

Well, if I would interpolate from the code I saw in open source projects to closed source projects, being closed source because of bad code... oh boy.

I am always fascinated of our software driven society still working, despite our often really bad, ugly, bug ridden, ill-documented codes.

Re:Debian (1)

BasilBrush (643681) | about a year ago | (#44844175)

Source distribution to users. And all the compilation and linking problems that brings.

Re:Debian (2)

jedidiah (1196) | about a year ago | (#44844411)

You're an idiot. Debian doesn't distribute source to users.

It's all binaries wrapped around the best package manager on the planet. It's something that Apple can't even touch despite their best attempts to try and sort of copy it.

Re:Debian (2, Informative)

Anonymous Coward | about a year ago | (#44844265)

If you are not making an open source application that needs to run on a lot of machines, then you can take some shortcuts.
I develop OS X software and I make it specifically for OS X, this gives tools as a developer to use the libraries in OS X, which makes it very easy to quickly make a well behaving application.

One of my applications was written when it when OS X was still 32 bit, this forced me to read from files using read(), while I rather use mmap() for reading from files. Using mmap() on large files requires (if you don't want to keep remapping) a 64 bit OS. This is one place where a 64 bit OS is useful when you have less than 4GB of memory.

Re:Debian (2)

jcdr (178250) | about a year ago | (#44844321)

Actually it's a big deal: Debian is the only project on Earth that maintain so much architectures from the same code base and build system. There experience on that subject is outrageously ahead of many others projects. There have identified and implemented years before the others the need of a pure amd64 port (and not a quick /lib64 hack). There have adapted all there rules, and process to do that. There are now the only multiarch capable distribution. Many don't understand how complex it is to implement properly. It take something like 10 years, from the idea to the release.

Re:Debian (2)

Jane Q. Public (1010737) | about a year ago | (#44844483)

"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?"

It *IS* a big deal. But it is also misguided.

Apple has had an unfortunate tendency to do this backward. Rather than making apps work BOTH on iOS and OS X, instead they made OS X work more like iOS. And that's a mistake.

As Microsoft has been learning, desktops are not tablets. Apps with interfaced designed for tablets are frustrating and difficult to use in a desktop environment.

What they should be working on is a way to make the apps work BOTH with a tablet-optimized interface, AND a desktop-optimized interface. OS X and iOS don't need to be the same things, though a common core wouldn't hurt a bit. But they should be making the APPS cross-platform, rather than trying to meld the OSes.

Bring the million-plus iOS apps to Macs... (1)

Anonymous Coward | about a year ago | (#44844129)

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.

Re:Bring the million-plus iOS apps to Macs... (-1)

Anonymous Coward | about a year ago | (#44844207)

The vast majority of which will be horrible on OS-X due to being designed solely for a touch interface.

My wife's vagina seems to have been designed primarily for a touch interface, but I still like to plug in a joystick now and again, even if it doesn't work as well.

Re:Bring the million-plus iOS apps to Macs... (4, Funny)

mspohr (589790) | about a year ago | (#44844209)

I don't want a fart app for my desktop.

Re:Bring the million-plus iOS apps to Macs... (1)

Nerdfest (867930) | about a year ago | (#44844245)

I was going to say, I'm sure most OSX users are not thrilled about it becoming more iOS like. Look at how Windows users reacted to 'Metro', and most users' are not even using Windows by choice.

Re:Bring the million-plus iOS apps to Macs... (1)

Anonymous Coward | about a year ago | (#44844257)

Yeah, that would stink.

Re:Bring the million-plus iOS apps to Macs... (1)

clifyt (11768) | about a year ago | (#44844237)

I haven't used X Tools in years, but...you use pretty much the same libraries and compiler to compile iOS apps as you do OS X apps.

And there is already an emulator to check out your apps before you deploy.

And the big 3rd party development software tools already allow you to port directly to the Mac (I was working in a scripting language that I needed for psych research an app built last year for the iPad...and then realize I could do a desktop version just the same for the folks that didn't need to go into the field...it took me another few minutes to figure out how to set the resolution but that was about it).

Honestly, this sounds like someone that has no clue. Or maybe I have no clue...its been a while since I've done a damn thing

Re:Bring the million-plus iOS apps to Macs... (1)

Trimaxion (2933647) | about a year ago | (#44844351)

Apple has different UI frameworks for OS X and iOS. One will not run on the other and vice versa. Thank God!

This migration article is useful:
https://developer.apple.com/library/ios/documentation/miscellaneous/conceptual/iphoneostechoverview/PortingfromCocoa/PortingfromCocoa.html [apple.com]

As is this stackoverflow accepted answer for a higher level overview:
http://stackoverflow.com/questions/2297841/cocoa-versus-cocoa-touch-what-is-the-difference [stackoverflow.com]

Re:Bring the million-plus iOS apps to Macs... (0)

Anonymous Coward | about a year ago | (#44844339)

Yes, yes, and yes.

However, I wonder what would happen if Apple did start making a touchscreen Mac and you could bring iOS apps into a new OS X interface that looked a bit like the tiles in Windows 8 or some weird hybrid of it with Dashboard?

My gut feeling is somewhere between "it would be an abomination" and "Windows 8 already tried that and look what it got them", but Apple has shown previously that just because Microsoft tried something first (poorly) doesn't mean Apple couldn't figure out an approach that worked well subsequently (e.g., Microsoft Windows supported tablet interfaces for years and years before tablets became commonplace).

Not every app would be suitable for such an interface, but some might be. Maybe it wouldn't be as bad as I'm expecting.

app store lockin on top of high cost hardware will (0)

Joe_Dragon (2206452) | about a year ago | (#44844353)

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?

Re:Bring the million-plus iOS apps to Macs... (0)

Anonymous Coward | about a year ago | (#44844427)

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.

Changes will need to be made on a Mac laptop to accommodate touch-screen apps? Oh, you mean like a touchscreen display? Yeah, no way that will ever get invented, you're right.

Meant solely for a touch interface? You mean like the tens of thousands of apps that currently force a small virtual keyboard to pop up on the display for you to enter input? Yeah, dunno how the fuck we're going to accommodate that, while sitting in front of an actual keyboard.

Different screen resolutions? Oh, you mean like the apps that work just fine between iPod, iPad, and iPad mini, with a wide variety of screen sizes and resolutions? Yes, clearly that sounds like an impossible task to port to Mac hardware that currently can use a 20" monitor or a 65" HDTV for a display.

What you want to call a magic pill I'll kindly predict as next years product line.

RISC (iPhone) vs. CISC (OSX) (4, Interesting)

Kr1ll1n (579971) | about a year ago | (#44844135)

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.

Re:RISC (iPhone) vs. CISC (OSX) (5, Interesting)

myurr (468709) | about a year ago | (#44844199)

Several journalists have made this mistake, such as the drivel posted here: Trusted Reviews [trustedreviews.com]

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.

Re:RISC (iPhone) vs. CISC (OSX) (2)

fuzzyfuzzyfungus (1223518) | about a year ago | (#44844285)

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.

Re:RISC (iPhone) vs. CISC (OSX) (1)

g2racer (258096) | about a year ago | (#44844341)

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.

Re:RISC (iPhone) vs. CISC (OSX) (4, Insightful)

jedidiah (1196) | about a year ago | (#44844443)

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.

Re:RISC (iPhone) vs. CISC (OSX) (0)

bensyverson (732781) | about a year ago | (#44844397)

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."

Re:RISC (iPhone) vs. CISC (OSX) (0)

Anonymous Coward | about a year ago | (#44844473)

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.

Re:RISC (iPhone) vs. CISC (OSX) (0)

Anonymous Coward | about a year ago | (#44844433)

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.

Android is finished. (-1, Troll)

Anonymous Coward | about a year ago | (#44844137)

iOS and OS X were designed from the GROUND UP to be 64 bit. Contrast this to Android which is still mired in decades old technology that nobody wants any more. Now that Apple has fully covered the market sections with both low and high end phone AND tablets, there is basically no where for Android left to go and it is only a matter of time before you start seeing Android's marketshare going down the tubes. Every one of my hardcore techy friends is already dumping their Android phones for the iPhone 5C and 5S, so its just a matter of time.

Re:Android is finished. (4, Informative)

kthreadd (1558445) | about a year ago | (#44844157)

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."

Re:Android is finished. (4, Informative)

AmiMoJo (196126) | about a year ago | (#44844201)

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.

Re:Android is finished. (3, Interesting)

Anonymous Coward | about a year ago | (#44844417)

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!

Re:Android is finished. (0)

Anonymous Coward | about a year ago | (#44844421)

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.

Re:Android is finished. (2, Insightful)

BasilBrush (643681) | about a year ago | (#44844495)

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.

Re:Android is finished. (1)

aergern (127031) | about a year ago | (#44844435)

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

Re:Android is finished. (0)

Anonymous Coward | about a year ago | (#44844541)

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.

No. (4, Insightful)

symbolset (646467) | about a year ago | (#44844141)

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.

Re:No. (4, Interesting)

AmiMoJo (196126) | about a year ago | (#44844413)

It's more like they didn't have much else for the iPhone 5S, just the fingerprint sensor. Everything else is either the same or a slight improvement, like the camera.

Planned obsolescence (2, Interesting)

the_scoots (1595597) | about a year ago | (#44844147)

I doesn't hurt Apple that this will effectively make all 32-bit iOS devices worthless in a year or so.

Re:Planned obsolescence (-1)

Anonymous Coward | about a year ago | (#44844247)

Apple devices are already worthless in half a year or less. And it costs so much money to keep upgrading to the next best thing! :(

I wish there was a reliable phone out there that didn't require me to spend $600 or more each time I had to upgrade. Of course, if I didn't have an EBT card that I could use to make my payments, life would probably be a little bit more difficult for me.

Re:Planned obsolescence (3, Insightful)

zidium (2550286) | about a year ago | (#44844305)

The same way Windows 7 x64 made all Windows 7 installations and 32-bit programs worthless, huh?

Oh...wait...

Re:Planned obsolescence (2)

jedidiah (1196) | about a year ago | (#44844487)

Windows is a legacy support platform. The old stuff doesn't just get jettisoned at the earliest opportunity because it's not shiny shiny enough. The platform as a whole is not under the tyrannical control of Microsoft to the same degree as Apple products. So people are much more free to use older equipment.

The user is in control.

I can choose to use 10 year old programs. Try that with the App Store model.

Re:Planned obsolescence (1)

gmuslera (3436) | about a year ago | (#44844399)

This. If new & updated apps will be only for 64bits (the market will let developers to have available both versions?) this will force people to change devices, wanting them or not.

Re:Planned obsolescence (4, Funny)

whisper_jeff (680366) | about a year ago | (#44844423)

You're right. They shouldn't have done anything to move their hardware forward. They should have just released the exact same device they did last year to ensure nothing ever became obsolete.

And, by "you're right", I of course mean "you're a moron."

Mod away.

Moronic (3, Insightful)

AmiMoJo (196126) | about a year ago | (#44844155)

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.

Re:Moronic (5, Informative)

phantomfive (622387) | about a year ago | (#44844319)

He doesn't understand. Here's a picture and bio of the guy who wrote the article [forbes.com] . He's mainly focused on hardware, as in books about assembling PCs from parts, so it looks like his career path was PC-repair-guy-to-author. He's obviously never written any substantial cross-platform software. He was looking through new iPhone documentation (which is right here [cocoachina.com] ), and he saw a line that mentions it's easy to write code that is shared on iOS and OSX. He thought that was something new, he didn't realize that it's already easy, and has nothing to do with 64bit.

Re:Moronic (0)

Anonymous Coward | about a year ago | (#44844327)

1.) Current iPhones have 2GB RAM, not 1GB.
2.) iOS now allows for "real" multitasking.
3.) 64-bit can be beneficial even if you have less than 4GB of RAM. (See, for example, the entry on 64-bit computing on Wikipedia for an introduction.) However, I'd argue that the disadvantages of 64-bit -- the same data and program needs more space on 64-bit due to larger pointers and such -- is particularly relevant on smartphones where storage contraints are much tighter than on the desktop.

Re: Moronic (0)

Anonymous Coward | about a year ago | (#44844523)

>> 1.) Current iPhones have 2GB RAM, not 1GB.

the iPhone 5 has 1 GB of RAM. Do you have any source about 2GB of RAM in any of the new iPhones?

Re:Moronic (1)

Anonymous Coward | about a year ago | (#44844345)

IOS7 has real multi tasking.... Think they are doing this more as a future thing in a few years when they make a phone with 4 gig of ram they can make there os 64bit only and not let it run on older phones so it will still work on a iphone 5s when it is two years old phone but they can say sorry your 3 year old iphone 5 isn't 64bit sorry.

Real Multitasking (2)

glennrrr (592457) | about a year ago | (#44844359)

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.

Re:Moronic (1)

BasilBrush (643681) | about a year ago | (#44844361)

Software inevitably follows Moore's law. As fast as Moore's law provides the transistors, the software makes use of them.

There's no need for more than 4GB in a phone now. But it's as inevitable as PCs needing more than 640K.

For sure, Apple have 64 bit before they need it. Which is better than not having it ready when the time comes that they do need it.

But there are undoubtably other reasons for 64 bit that we're not seeing yet. An Apple TV replacement with 3rd party apps (and thus a games console competitor) has long been predicted. And the next consoles from Sony and Microsoft will have 8GB. Thus 64 bit is very important for that.

Its also easier for Apple internally if both OSX and iOS are 64 bit. Many (most?) of the components of iOS are shared with OSX.

Re:Moronic (1)

UnknowingFool (672806) | about a year ago | (#44844441)

If you didn't read, he says that by moving to 64 bit now, Apple can add memory later easily. Memory on smartphones is limited by cost and space. If other Android OEMs wanted to put more than4GB on their tablets or smartphones, now it would be of limited use.

As for programs, I don't see that it makes the the porting instantaneous. They are still compiled on different architectures. Having a common code set helps Apple in other ways.

Marketing (0)

Nerdfest (867930) | about a year ago | (#44844169)

I'm sure marketing was a big reason. They didn't seem to have much else to offer with their latest phone.

Bingo (2)

Sycraft-fu (314770) | about a year ago | (#44844213)

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.

Re:Bingo (1)

Nerdfest (867930) | about a year ago | (#44844277)

64 bit is better in the real world, but not significantly so for the sort of things that are run on iOS.

Re:Bingo (1)

UnknowingFool (672806) | about a year ago | (#44844377)

Moving to 64-bit doesn't give the consumer much at the moment. The switch is probably a longer term strategy. They could have added more cores like everyone else but thought 64-bit was a better option. There may be some processing that they want to take advantage of instead of more cores.

Re:Bingo (1)

BasilBrush (643681) | about a year ago | (#44844547)

Apple loves to be "first".

What? And Google Android/Samsung don't? They prefer being 2nd or 3rd? Is that your contention?

Samsung are making comments about bringing out 64 bit phones next year. Will those be pointless too?

Or is this just sour-grapes, because Apple WAS first.

Shakin' mah head (0)

Anonymous Coward | about a year ago | (#44844187)

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.

no, no, no, my computer is not a phone (2, Interesting)

mspohr (589790) | about a year ago | (#44844197)

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.

Re:no, no, no, my computer is not a phone (0)

Anonymous Coward | about a year ago | (#44844219)

http://www.debian.org/ [debian.org]

Here you go kid. Go get yourself a better operating system.

Re:no, no, no, my computer is not a phone (0)

Anonymous Coward | about a year ago | (#44844457)

It's not what they're doing anyway. If you understood some basic computer science you'd understand that the summary is vastly oversimplifying the situation and if Apple has any real intentions of bringing the platforms together in a truly homogenous way they're on about step 3 of a 2640 step process.

Re:no, no, no, my computer is not a phone (1)

phantomfive (622387) | about a year ago | (#44844505)

Exactly. The hardest part about 'unifying' iOS and OSX isn't the number of bits, it's getting the UI correct. If it were easy, then Apple would have done it in the initial iPhone.

After all, the core OS is essentially the same between iOS and OSX right now (both Mach kernels with a unix userland).

Re:no, no, no, my computer is not a phone (1)

glennrrr (592457) | about a year ago | (#44844511)

How have you been disabling Core Animation? A library developed for the iPhone and brought to the Mac and now the backing for every view on screen. MapKit, notification center, core location... There are a huge number of frameworks common to both iOS and OS X, and OS X benefits greatly from the engineering effort made to optimize the code both for performance and energy usage.

Huh? (1)

omnichad (1198475) | about a year ago | (#44844203)

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.

Why would users want this? (2)

King_TJ (85913) | about a year ago | (#44844225)

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.

It's about jailbreaking. (5, Interesting)

Anonymous Coward | about a year ago | (#44844267)

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.

iOS apps on a Mac? Why? (1)

SigNuZX728 (635311) | about a year ago | (#44844287)

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.

Re:iOS apps on a Mac? Why? (1)

hibiki_r (649814) | about a year ago | (#44844513)

Infinity Blade. Now, it'd be pretty hard to play it in a macbook pro.

Two things (1)

gwstuff (2067112) | about a year ago | (#44844297)

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.

64-bit won't make emulation any easier. (0)

Anonymous Coward | about a year ago | (#44844299)

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.

No one has a frigging clue (1)

rsborg (111459) | about a year ago | (#44844307)

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?

Re:No one has a frigging clue (1)

viperidaenz (2515578) | about a year ago | (#44844381)

I don't understand how you can claim 64bit as innovation, especially when it isn't being used in a way that the old CPU was.

Re:No one has a frigging clue (0)

Anonymous Coward | about a year ago | (#44844385)

http://www.arm.com/products/processors/armv8-architecture.php

This is the future and apple is building their chips for the future, not the past.

Here the REAL reason ! (0)

Anonymous Coward | about a year ago | (#44844309)

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.

Re:Here the REAL reason ! (1)

viperidaenz (2515578) | about a year ago | (#44844371)

You would need to hack through the memory protections provided the the x86/64 built in MMU and controller to give the ARM core access to process address space.

You'd also need the cooperation of Intel to develop extensions to allow the CPU to sleep while the memory controller is active for the external processor to use.

They also run different instructions, so two lots of code need to be loaded in to the same memory also...

Leap ahead of Microsoft and Google? GLWT. (0)

Anonymous Coward | about a year ago | (#44844323)

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.

32bit ARM - 1024GB RAM with LPAE (4, Informative)

viperidaenz (2515578) | about a year ago | (#44844343)

Cortex A15 has 40 bit addressing and can access 1TB of physical RAM.

The 32 bit limit is per process.

Microsoft can't even get THIS right anymore (1)

I. P. Freely (2969967) | about a year ago | (#44844347)

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.

More intriguing possibility (3, Interesting)

Anubis IV (1279820) | about a year ago | (#44844355)

This analysis of the switch [cannyvision.com] 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.

Re:More intriguing possibility (0)

Anonymous Coward | about a year ago | (#44844481)

> ridiculous that a phone will need 4GB+ of RAM anytime soon

Considering my phone that's nearly a year old has 1 Gbyte of RAM, you're wrong. If Moore's law holds true, then in six months we'll have 2 Gbytes then in 18 months after that, it's 4 Gbytes. That's not that far away.

Virtual Memory Please!!! (1)

greggman (102198) | about a year ago | (#44844415)

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.

Re:Virtual Memory Please!!! (1)

MrEricSir (398214) | about a year ago | (#44844453)

Um, what the hell are you talking about? iOS has had a complete implementation of virtual memory since day one.

Kiss OS X goodbye (1)

fustakrakich (1673220) | about a year ago | (#44844437)

Welcome the NEW! 27 inch iPhone!

64bit is for 4G (2)

Electromigration (3076057) | about a year ago | (#44844485)

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. ;)

Total nonsense (0)

Anonymous Coward | about a year ago | (#44844493)

I'm running 32 bit applications on macosx without problem (Dropbox + uTorrent). Where do these experts take their clueless arguments?

Oh great, fat sloppy code on my cell (1)

WillAffleckUW (858324) | about a year ago | (#44844499)

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.

Nobody will ever need more than 640 mb (1)

WillAffleckUW (858324) | about a year ago | (#44844527)

Right?

Next thing you know you'll want it to talk to the iWatch.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>