back to article Apple’s iOS 64-bit iUpgrade: Don't expect a 2x performance leap

What are the implications of Apple’s 64-bit ARM A7 processor for the iPhone user who upgrades to the new 5S? Not as many as you might think. Apple has said the chip is compatible with all the iOS software out there that is still 32-bit. For the moment, at least, that is all third-party programs. Apple hasn’t said how much RAM …

COMMENTS

This topic is closed for new posts.
  1. IHateWearingATie

    It'll be interesting to see how this is handled on Android when the time comes...

    Eventually the amount of memory in smart phones will move beyond 4GB, so Android will have to make the move to 64bit at some point.

    Given the amount of control that Apple have over the hardware and development environments compared to Google and Android, if Apple are having problems I wonder how bad the fragmentation will get for Android when they make the switch?

    1. Anonymous Coward
      Anonymous Coward

      Re: It'll be interesting to see how this is handled on Android when the time comes...

      "environments compared to Google and Android, if Apple are having problems I wonder how bad the fragmentation will get for Android when they make the switch?"

      Possibly that will be event that Google will use to pull the drawbridge up and freeze weaker OEMs out?

    2. Anonymous Coward
      Anonymous Coward

      Re: It'll be interesting to see how this is handled on Android when the time comes...

      > so Android will have to make the move to 64bit at some point.

      Well it could do some kludge to use 40bit addressing or something. Just like the old x86 days: 16-bit architecture with 20-bit addressing.

    3. DrXym

      Re: It'll be interesting to see how this is handled on Android when the time comes...

      Most apps on Android are running bytecode on a virtual machine called Dalvik. So essentially it doesn't matter a fig what processor architecture is on the outside, it all looks the same on the inside as far as the app is concerned. Dalvik is a 32-bit register based VM and if ever it was extended to 64-bit I assume the easiest route would be to change the build tools to spit out some Dalvik 2 format instead.

      Apps do have a number of ways of escaping Dalvik which could benefit from 64-bit. First of course is they can compile native shared library and stick it behind a JNI which can be called from the process. If a 64-bit version of Android appeared it would be just one more target to build for (but see #3)

      The second way is the dev could write Renderscript (sort of like OpenCL) for any compute heavy stuff and leave it up to the OS to figure out how to farm the work out to the available CPU/GPU. i.e. if my code wants to blur a bitmap, I write some RS to do it which I invoke from Java and it gets done. Renderscript would be the recommended route anyway for heavy processing since it has heaps of intrinsics for this kind of stuff. This is LLVM based so a future 64-bit version of Android could execute 64-bit code if it made sense.

      The third way (which doesn't exist but potentially could) would be for Google to support LLVM bitcode as a target from the NDK. The dev could build one shared lib in an architecture neutral bitcode format and leave it up to the OS to figure out how to generate the appropriate native code when the app was first used.

    4. Anonymous Coward
      Anonymous Coward

      Re: It'll be interesting to see how this is handled on Android when the time comes...

      Android is easy. Linux already does a 64bit kernel, so an Android kernel port is straighforward. Almost all apps are running onto the Davlik virtual machine, so they don't care how memory is allocated. Some native apps will need to be recompiled to work as 64bit, but they will surely still run as 32bit apps also.

      In short, unlikely to be any fragmentation problems at all on Android (except the ones in Apple's head).

      Interesting that Apple failed to highlight the downsides of 64bitness, namely swollen pointers and byte alignmnet padding, which has a 30% increase in storage and in-memory footprints.

      Go find your favorite app that comes in two flavors and compare the file systems and memory useage. 64bit makes little sense on a desktop PC, let alone a mobile phone. The only exceptions are apps that can really make use of the extra registers and available memory. Databse apps, mathimatical apps etc.

      1. t.est

        Re: It'll be interesting to see how this is handled on Android when the time comes...

        Mathematical apps etc.

        With that you say, any 2D & 3D graphics apps. Heck, the PowerPC G4 had a 128-bit altivec unit for this purpose. And that is a long time ago.

    5. IHateWearingATie

      Re: It'll be interesting to see how this is handled on Android when the time comes...

      Only 4 thumbs down for daring to mention fragmentation on Android?

      Come on Fandroids, you're not trying hard enough!

      (I've just moved to an Android phone from iOS btw, and my question was genuine, not trolling. Very interesting answer from @DrXym to my point )

      1. Charlie Clark Silver badge

        Re: It'll be interesting to see how this is handled on Android when the time comes...

        @IHateWearingATie

        Okay, I'll bite - fragmentation has been a red herring for a while on Android. It was initially a big problem as new 1.x releases introduced extensive new APIs that often required hardware support which a lot of the first phones didn't provided. This was exacerbated by manufacturers and networks not having the right kind of resources to manage and distribute updates of the OS together with their own stuff.

        The hardware API has been pretty stable since about Android 2.2 which is why you see stuff in the store saying that devices with less than 2.2 won't be supported. Over the last 18 months the major manufacturers have got much better (though there is still some way to go) at managing OS updates and taking advantage of the reference Nexus models to road-test the hardware / software combination.

        So, I have a two-year old Galaxy 8.9 with Android 4.0, an X-Cover 2 with 4.1 an S4 Mini with 4.2 all happily running the same apps except for a couple that are tablet only. Interestingly the S4 Mini and X-Cover 2 are good examples of how well Android handles different screen resolutions: the screens are roughly the same size but the mini has significantly greater pixel density, obvious when comparing say map applications but icon sizes are physically almost identical which makes them both equally easy to operate. Compare and contrast with Apple's own rule-breaking I-Pad mini.

      2. Anonymous Coward
        Anonymous Coward

        Re: It'll be interesting to see how this is handled on Android when the time comes...

        >Only 4 thumbs down for daring to mention fragmentation on Android?

        I think you'll find it was the cardinal sin of regurgitating naïve marketing crap at a generally more shrewd commentarderate that garnered the downvotes.

        Saying something as fuckwitted as "the iPhone will soon have more than 4GB RAM and so need a 64 bit CPU and the same is gonna happen to those dozey fandroids but there too stoopid to realize" around these parts is akin to saying "I'm the moron bastard of your filthy slut mom and your brother, kick me"

        ...and not JUST because the new Jesusphone WON'T have >4GB RAM and so WILL NEVER need an ADDRESS SPACE >32bit - it's altogether more fundamentally braindamaged than that.

        ref: http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf

        1. Andrew Hodgkinson
          Boffin

          Re: It'll be interesting to see how this is handled on Android when the time comes...

          Given the thread size already, my comment will almost certainly never get read, but here goes anyway.

          Kids today... Sigh. This isn't about physical memory and never was, it's about logical address space.

          My background is post-ARM Acorn since 1996 (the company from which ARM originated) and RISC OS (the OS for which the ARM processor was originally created, via Arthur). See http://www.riscosopen.org/ and the Raspberry Pi for where things are with that these days. I'm one of the founder members of the not-for-profit RISC OS Open Limited.

          When the OS moved from 26-bit (http://en.wikipedia.org/wiki/26-bit) to 32-bit addressing, one of the big benefits was increased available logical address space for applications. The overall OS memory map could make much better use of the 32-bit space available and applications could have considerably larger logical address space allocated.

          Because of a dubious memory allocation API called "dynamic areas", RISC OS can still easily suffer logical address space exhaustion even if there is plenty of free physical RAM, just by asking for the reservation of dynamic areas - which are contiguous areas of reserved addresses - with the potential to grow to an indefinite physical size. This means that a large chunk of logical space has to be reserved on the off-chance that the application actually does try to extend that space to the maximum permitted size (IIRC the "maximum size" value used to be "available RAM" until 32-bit machines arrived with larger memory capacities - a 512MB RAM machine could've otherwise exhausted all virtual space in just a handful of unbounded dynamic area allocations, so application authors were encouraged to always specify an upper limit and the OS introduced a much-lower-than-RAM limit for those applications which said "as big as possible").

          Under a 64-bit CPU, you have a *vast* address space you can use for logical addressing, so the memory map becomes very flexible and all sorts of constraints and limitations that don't necessarily have anything to do with physical RAM become lifted. There are usually performance benefits from increased register availability as others have correctly already pointed out but, as already pointed out too, the cost is the increased storage requirements and potential impacts on caches and memory accesses.

          In any event, while it might not be *necessary* to have 64-bit address space in something as small scale as a phone, it can certainly be *advantageous* and there's no need to have anywhere near 4GB of actual physical RAM installed in order for it to be useful. One could, for example, memory-map the entire flash storage device into logical space without needing any of the additional special tricks required with 32-bit addressing.

          1. Anonymous Coward
            Anonymous Coward

            Re: It'll be interesting to see how this is handled on Android when the time comes...

            "One could, for example, memory-map the entire flash storage device into logical space without needing any of the additional special tricks required with 32-bit addressing."

            Could this not also be done on various platforms and various OSes, perhaps with a bit of handwaving to account for logical sparseness of the used application/OS space vs logical contiguousness of the blocks on "disk"?

            Does anybody do it?

            If not why not?

            1. Andrew Hodgkinson

              Re: It'll be interesting to see how this is handled on Android when the time comes...

              "Could this not also be done on various platforms and various OSes, perhaps with a bit of handwaving to account for logical sparseness of the used application/OS space vs logical contiguousness of the blocks on "disk"?"

              I don't understand what you mean really... But bearing in mind the flash on phones is almost always more than 4GiB - the maximum logical address space of a 32-bit device - and given that some of the space will of course be required by the OS, then the answer is no, not without lots of trickery (usually support hardware - an IOMMU). This tends to add complexity and degrade performance. My point was, you don't need trickery or extra hardware with 64-bit. You just map stuff. You've 16 exbibytes[1] of address space! It's lots and lots and lots.

              Again, there's a huge difference between physical and logical address space and those that don't understand this need to go and read up about it to understand why 64-bit addressing has nothing directly to do with 4GB of RAM.

              [1] http://en.wikipedia.org/wiki/Exbibyte

        2. Anonymous Coward
          Anonymous Coward

          Re: It'll be interesting ...

          New word !

          commentarderate FTW !

    6. Bob Vistakin
      Facepalm

      Exactly - with a multitasking OS this would do really well

      Like the one Google introduced for their phones way back in 2007. Unusually, Apple really have stick to their Think Different slogan through all those years and stuck with their dumbed down single tasking toy for the non-technical. And the lost, if they stlll use their comedy maps offering.

      1. Anonymous Coward
        Anonymous Coward

        @Bob Vistakin

        You really are a set tedious little man.

    7. h3

      Re: It'll be interesting to see how this is handled on Android when the time comes...

      Don't see why arm cannot use a 32 bit mode with more registers and the lower code size.

      (Like sparc and I think powerpc does.)

      Not even sure the 4GB thing is really a problem for arm (The original ones used 26 bit). Very few things that would need to deal with that in the OS.

      (Funny that these changes make it closer to what mips already was but more baggage).

  2. tin 2

    Again I say they should have made the flash capacity of the low end model a lot bigger, and this would appear to be another (minor perhaps) reason.

    I wonder what this is going to do for obsolescence of the older phones. If apps start coming out that are 64 bit only? Worrying.

    1. Sander van der Wal

      Given that you can have 32 and 64 bit binaries in the distribution, that isn't worrying at all. Developers will provide both as long as the toolchain will create them.

      1. SuccessCase

        "Given that you can have 32 and 64 bit binaries in the distribution, that isn't worrying at all. Developers will provide both as long as the toolchain will create them."

        Your thinking is a bit old fashioned there. Since all the apps are delivered from an App Store, I expect the 5S will only receive the 64 bit versions when there is a 64 bit version available. There's no need to keep 32 bit version of apps that will never be run on a 64 bit device.

    2. chr0m4t1c

      "I wonder what this is going to do for obsolescence of the older phones. If apps start coming out that are 64 bit only? Worrying."

      We already have this situation and have done for years, there are apps that require minimum versions of the OS that can't be installed on earlier hardware, sometimes because the drivers aren't there or quite often because it simply won't fit.

      In common with other operating systems, I expect iOS will maintain backwards compatibility for a few years and then drop it when the majority of applications are 64-bit; expect Android, Windows Mobile and BlackBerry to follow the same path - although with such a relatively small market share and number of apps the last two could opt to just make a clean break at the next major OS release.

      1. cambsukguy

        Yeah, 170,000 apps should not cause any trouble

        Given that WP8 can run in 512MB reasonably, and perfectly in 1GB - the merest perturbation on rare occasions, presumably while some swap takes place - I hardly see the need for the so-called step up.

        The Lumia 1020 has 2GB but I suspect that is because of the requirement for processing, using a separate GPU, of the giant images down to 7MP. I imagine there will be extra for normal use (all of it presumably when not taking pictures). The upshot is that maybe, instead of 6 apps resting/tombstoned/background, it may be 10 or more. Personally, I don't want to flick through too many because just restarting the app is often easier.

        Given the (very) well documented issues with 64-bit code, I think that it would be a hard-sell to consumers to just say "It's got 64 instead of 32, gotta be better", hmmm, sounds like an advert that just could work now.

        I doubt it will be a visible improvement, hilarious if it is indeed slower for 3rd party apps - which, after all, is apparently the whole point of buying IOS over WP (wot, no Instagram? - Jeez!), what with the aforementioned paucity of apps on WP8 (what? Only 10 RDP app and 30 facebook apps, Oh No!).

        My guess is that the 64-OS speed improvement (I assume) will mitigate and leave the result of no difference, iPhones work well in terms of fluid operation AFAIK so is improvement actually needed? it's not like they put more pixels on the screen or the camera sensor to draw/read is it?

        1. t.est

          Re: Yeah, 170,000 apps should not cause any trouble

          That image handling on the lumia would definitely benefit from 64-bit if not even from 128-bit.

          Check the Apple keynote and see what Epic says about their infinity blade game on the 64-bit iPhone 5S. Their performance improvement claims were much higher than those of Apple. Apple said 2x, Epic said 5x.

          When has that happened before, that the hardware maker says less than the game maker say the reality is?

  3. Captain Queeg

    Touch UI on desktop

    Given Apples's obsession with UI/UX and Google's pragmatic approach, I see MS as the only touch hybrid circus in town for a long time to come.

    This should mean steady (if not game changing) gains for OSX and Chrome OS as Win8 stumbles on,

    1. Anonymous Coward
      Anonymous Coward

      Re: Touch UI on desktop

      @Captain Queeg - "Given Apples's obsession with UI/UX and Google's pragmatic approach, I see MS as the only touch hybrid circus in town for a long time to come."

      Well, that "only touch hybrid circus" didn't last long. Google's Chromebook Pixel is already touch enabled, and Chrome OS has touch coded into it.

    2. Vector

      Re: Touch UI on desktop

      "Given Apples's obsession with UI/UX and Google's pragmatic approach, I see MS as the only touch hybrid circus in town for a long time to come."

      No. More likely, users will discover bluetooth keyboards and, shortly thereafter, find that they can do most of their day-to-day on their IOS/Android tablet and that'll pretty much be it for desktop/laptops.

      Mind, there will still be some applications that need the extra horsepower, but for your average "browse the web, write some emails and documents, do some spreadsheets" user, the tablets will do just fine.

      ...let the downvoting begin!!!

      1. Anonymous Coward
        Anonymous Coward

        Re: Touch UI on desktop

        I miss netbooks, I loved those lil things.

      2. t.est

        Re: Touch UI on desktop

        Actually I find the iPad a much better device for, Web and email than a computer.

        I also think that spreadsheets and document handling, has all the possibilities to become a nicer experience on a tablet than on the computer. However these kind of apps needs a developer who thinks out of the box to make it happen. Image editing will continue to require big screens, but as the touch interface still is just in it's early development, I think that lightweight 2D apps also can become better on tablets than on a computer, in due time.

  4. JDX Gold badge

    iOS-based laptops?

    Seems a bit of a stretch to conjecture that simply because iOS and OSX moved to 64-bit, they plan to release iOS laptops. Maybe Apple just like 64-bit.

    1. Charlie Clark Silver badge

      Re: iOS-based laptops?

      Maybe not IOS-based but potentially ARM64-based MacBook Airs. There is a lot to be gained by consolidating the tool chain for the underlying OS which is what Apple has been doing in the last two releases of MacOS with Mavericks presumably due to go further.

      Of course, for users the move to 64-bit is just another ratchet to buy a new handset as more and more apps require 64-bitted IOS 7.

      1. cheveron

        Re: iOS-based laptops?

        I agree. Most MacBook Air users probably aren't running a virtual Windows desktop and wouldn't care what CPU they were using as long as their apps all worked (although that would noble anything running on Cider). Switching from x86-64 to ARM64 would probably mean higher margins for Apple.

    2. Armando 123

      Re: iOS-based laptops?

      Would the iPad count as an "iOS-based laptop"?

      I know, not really, but a touch interface doesn't seem to really work for a laptop. (Now, having said that, I'm sure someone will prove me wrong.) Still, it is surprising what you can already do on an iPad.

    3. jubtastic1

      Re: iOS-based laptops?

      They're calling it 'desktop class architecture', they're also bundling the iWork suite of apps free with cloud storage on the device come iOS 7, I note they also sell a $99 box that allows you to turn any recent TV or monitor into a mirrored or secondary large display for the iPhone etc and they've added a low power bluetooth stack for external devices like say a keyboard.

      To recap:

      Bluetooth, Wifi, 3/4G networking, up to 128GB storage + cloud, POP, IMAP, Exchange, Shared Contacts, Calendars, VPN, An Office Suite and an extensive third party app catalogue with support for variable sized screen resolutions and aspect ratios**.

      That sounds like all the pieces you'd need to replace a desktop for a lot* of users to me.

      * a lot, not all, but certainly lots of home users without even needing to add support for LDAP, AD, fileshares etc.

      ** A subset of the App Store, so named 'Universal' apps that already support Retina / non Retina 4:3 iPads, Retina / non Retina 3:2 iphones, Retina 16:9 iPhones and aTV 16:9 720/1080.

      1. Tom Chiverton 1 Silver badge

        Re: iOS-based laptops?

        "also bundling the iWork suite of apps free"

        Where can I download without them then ? No ? Then they aren't free - you are paying an extra $50 or whatever on top of the O/S base cost for fancy powerpoint effects.

        1. PJI
          Pint

          Re: iOS-based laptops?

          Where? Perhaps I misunderstand your version of English. But, from the Apple web site:

          "iPhoto, iMovie, Keynote, Pages, and Numbers are free on the App Store for qualifying iOS 7 compatible devices activated as of September 1, 2013. See www.apple.com/ios/whats-new/ for iOS 7 compatible devices. Downloading apps requires an Apple ID."

          Reference: http://www.apple.com/iphone-5s/built-in-apps/

        2. Lord Elpuss Silver badge

          @Tom Chiverton 1

          Your cynicism is misplaced; iOS7 costs nothing to upgrade. Apple have never charged for an iOS upgrade. And as older iOS devices (back to iPhone 4 if I remember right) will also receive iOS7 for free, claiming that bundling iWork adds $50 to the cost is nonsense.

          Any iOS devices registered after 1st September receive iOS with bundled iWork, those registered before 1 September will receive iOS without bundled iWork.

          No charge, no $50, no FUD, just an incentive to buy more shiny shiny.

          1. John 62

            Re: @Tom Chiverton 1

            Apple did charge for iOS updates on iPod Touches for a couple of years

    4. Voland's right hand Silver badge

      Re: iOS-based laptops?

      Not necessarily.

      Now Arm based MacBook air using A7 with OSX rebuilt for Arm... That's a thought... In fact this is my first thought when reading the announcement. Apple is setting up the stage for that.

  5. LaeMing

    Not sure why the author thinks moving to 64 bit requires that all integer values in a program now be 64 bit. If you only need 32 bits, you keep using 32 bits - AA64 still supports 32-bit operations. Addresses is a different matter, of course, but the author is talking about data, not code, in the statement made.

    1. Gerard Krupa

      Re: LaeMing

      What it does mean is that when you need to push all of your registers onto the stack (e.g. calling a function or switching thread context) that will take up much more space.

      1. Steve Todd
        Stop

        Re: LaeMing

        It's rare in any program to push ALL your registers to the stack, you just need to push those that will be modified. If you don't touch the upper 32 bits of a register then just push the lower 32 bits etc.

        1. rurwin

          Re: LaeMing

          Interrupts will generally stack all or most registers, and they happen relentlessly with great frequency.

          1. Steve Todd
            Stop

            Re: LaeMing

            Even ISRs need only push the registers they use (and modern compilers track this for you). On a CISC machine like x86 then that tends to be most of them, on RISC machines with many registers then no, you don't bother.

            1. tom dial Silver badge

              Re: LaeMing

              What is the guarantee that the OS will redispatch the interrupted program after interrupt exit? If it does not, is the contents of unsaved registers or register parts predictable the next time the interrupted program is run?

    2. DrXym

      "Not sure why the author thinks moving to 64 bit requires that all integer values in a program now be 64 bit."

      Perhaps the article has been changed but it says "long integer". Compilers can and do change the length of ints and longs and usually only guarantee "at least 32-bits" but it could be more. Pointers would probably be wider too. If you need a precisely size ints there are are definitions in stdint.h for that.

      1. Tony Smith, Editor, Reg Hardware (Written by Reg staff)

        The article always said 'long integer', very deliberately.

    3. cambsukguy

      You obviously never recompiled 32-bit code to 64-bit. Sloppy coding is rife, the "Make it work, then make it good" mantra is valid, have used it myself, but time constraints of business ("fix the bugs first") then cause one to not have the "make it good" stage resulting in bloated code with repeated sections doing the same thing or very slightly differently.

      The code size will increase a lot and all those silly loops using 'int' even though they only loop 0 - 100 say, will slow down and take up more space (native code is Objective C I believe so 'int' seems likely).

      1. Anonymous Coward
        Anonymous Coward

        @cambsukguy

        Obviously YOU have never recompiled 32 bit code to 64 bit, or have done so only in a very limited environment that doesn't work the way most do. Otherwise you would know that in all 32->64 bit architecture migrations I'm aware of, an 'int' is still 32 bits even when you compile for 64 bits.

        Depending on whether the iOS dev environment uses LP64 or LLP64, even a long won't be 64 bits, you'd need to use 'long long' to get that. That is likely what Apple will do for maximum code compatibility, and likely iOS has already supported 'long long' since the beginning as many 32 bit compilers do (they emit multiple instructions when operations are done on long long variables)

        So likely only pointers will increase in size when you recompile iOS code to 64 bits, or if they use LLP64 like most Unixes do longs would increase too - but most developers would not use long in code targeted at a 32 bit environment since it is no different than int. They'd only use long if they intended for it to (maybe) increase in size in a 64 bit environment.

        Assuming the 5S doubles RAM from 1GB to 2GB, any code/data size inflation will be far less than 100% and it will effectively have more RAM than the 5 did.

  6. Anonymous Coward
    Anonymous Coward

    >> It'll be interesting to see how this is handled on Android when the time comes...

    Most Android applications (games aside) are written in Java so porting will be trivial. The native apps will need relinking to a 64 bit version of the NDK, but I don't see that it would be difficult to avoid a big mess with careful use of metadata in the Play store.

  7. jzlondon

    >> It'll be interesting to see how this is handled on Android when the time comes...

    Most Android applications (games aside) are written in Java so porting will be trivial. The native apps will need relinking to a 64 bit version of the NDK, but I don't see that it would be difficult to avoid a big mess with careful use of metadata in the Play store.

    1. Pascal Monett Silver badge

      Re: written in Java so porting will be trivial

      Porting is never trivial.

  8. Chairo
    Meh

    So why bother with a 64-bit chip at all?

    The cynic might say, not unreasonably, that it’s nothing more than a marketing exercise.

    The realist might say, it is a good excuse for Apple to cut off support for their "old stuff" at some not too far away point of time. Just as it happened when they went from ARMv6 to ARMv7 instruction set.

    1. Anonymous Coward
      Anonymous Coward

      Re: So why bother with a 64-bit chip at all?

      Actually by going to 64 bit early Apple is extending the life of the 5S. Given that it only has 2GB of RAM (or so reports go, I don't think that's confirmed yet?) it doesn't NEED 64 bits. If they wanted to screw over people like you seem to think, why not wait until you ship a device with 4GB of RAM and do the transition then? Then they could obsolete the 5S sooner.

      Obviously they will go 64 bit only at some point, probably with iOS 10 or so. Consider that iOS 7 is the first OS that won't run on the 3gs, which is over four years old. If they want an equivalent lifetime for the 5, they need to wait until iOS 10 to make the transition. If they made the 5S 32 bit, then they'd either have to wait longer to make iOS 64 bit only, or obsolete the 5S sooner.

    2. ThomH

      Re: So why bother with a 64-bit chip at all?

      Apple has made it clear that binaries that include 64-bit code must have a minimum deployment target of iOS 6. That's about 95% of active users so it's not so awful but it is indisputably a reduction in legacy support.

    3. Voland's right hand Silver badge

      Re: So why bother with a 64-bit chip at all?

      I have no opinion on Arm. In Intel/AMD land rebuilding for 64 bits gives you 3-7% speed-up for day-to-day network applications. That is not insignificant.

  9. Len
    Pint

    It's not about addressable memory

    That 4GB memory limit is a red herring. Its bigger cousin OS X was in its 32bit days limited to 64GB addressable RAM because it used Physical Address Extension (PAE). That 4GB limit was mostly a Windows issue because Microsoft never fully implemented PAE. Considering iOS and OS X share large parts under the hood I assume the iOS 32bit limit could easily be 64GB too.

    My take is that it just made development a lot easier (for Apple at least). OS X has dropped 32bit support years ago and large parts of OS X are never compiled for 32bit. I suspect that some of the bigger low-level overhauls to OS X (ASLR and OpenGL among others) we have seen in the last years are because they waited until 32bit was dropped. That will have significantly reduced coding, testing and bug fixing complexity as they only needed to focus on the 64bit binary.

    The only parts that still needed be be developed for both 32bit and 64bit were those that were shared between OS X and iOS. They still have to be developed, maintained, tested, bug fixed in both 32 and 64 versions. With their mobile hardware going 64bits, they can now start phasing out 32bit on their mobile platform too.

    1. Mike Dimmick

      Re: It's not about addressable memory

      *Microsoft* implemented PAE just fine, from Windows 2000 onwards. Manufacturers of commodity hardware didn't - most hardware and drivers in the PC world could not handle being presented with 64-bit physical addresses. So when introducing Execute Disable/No Execute in Windows XP SP2 - which requires PAE to be turned on, on x86 processors - Microsoft deliberately capped the physical address space at 4 GB for compatibility with the cheap hardware and bad drivers.

      Server editions of Windows on 32-bit processors, both before and after XP SP2 / Windows Server 2003 SP1, can access however much RAM is fitted, up to whatever the limit is for that edition of Windows. Windows Server 2003 and 2008 Standard Editions are also limited to 4 GB, but for market segmentation reasons, not technical ones (i.e. want access to more than 4 GB of RAM? Pay more).

      1. This post has been deleted by its author

      2. t.est

        Re: It's not about addressable memory

        Still my 4GB installed ram only where accounted for as 3.5GB.

        I lost 0.5GB. Now some say that is HP fault, but no it's so simple. Windows was keeping it self backwards compatible with 386 instructions set. While the Inte core architecture gave you much more efficient way of handling. Aka why Apple never had any problem with blending 64-bit and 32-bit.

        My mac runs a 32-bit kernel where almost everything else runs in 64-bit.

    2. Anonymous Coward
      Anonymous Coward

      Re: It's not about addressable memory

      PAE sucks. It's a terrible kludge that was needed only because Intel held back on going to 64 bits in x86 because they wanted to push IA64.

      Android will not use it, because Google is smart and knows it sucks.

      1. Anonymous Coward
        Anonymous Coward

        Re: It's not about addressable memory

        And since I posted my earlier reply to this, Samsung has announced that they're working on a 64 bit ARM and it will be out but "not soonest", whatever that means. So they're clearly not going to be using PAE, because they too know that it sucks.

    3. ThomH

      Re: It's not about addressable memory

      I was wondering whether the semantics of Objective-C might have something to do with it. With only two special cases, all objects are created on the heap. Although the C primitives are available, what that means is that quite often you're doing things that seem a little ridiculous like passing around a temporary 32-bit number by putting it on the heap and kicking around the pointer.

      On OS X, 64-bit pointers have to be quad-word aligned to be valid. So three quartets of pointers are invalid. Apple has used certain subsets of them so that e.g. 32-bit NSNumbers are encoded directly into the pointer, with nothing stored on the heap. So creating them, accessing them and destroying them is much cheaper. It's heap semantics but actually the entire object is on the stack.

      If iOS does the same then that presumably would be a way that the move to a 64-bit runtime benefits programs much more than just by providing extra registers.

  10. JonHendry

    You don't *have* to use bigger data sizes...

    Pointers will double in size, of course, but if you only need a 32-bit int, you can use int or, more explicitly, int32_t.

    Etc.

  11. Steve Todd
    Stop

    One wonders

    How much the author actually knows about programming. There is no need to have a 32 bit and 64 bit version of the operating system software loaded at the same time. Worst case you need a mapping layer which adds a small overhead. Just because Microsoft have traditionally made a complete mess of this doesn't mean that everyone has to. Take a look at the migration path for OS X apps. 32 bit and 64 bit apps coexist happily on the same core OS. The only part that MUST be 64 bit are device drivers.

    1. qwarty

      Re: One wonders

      Clarification. Sure Microsoft could have done a better job yet 32 bit Windows application binaries going back to last century happily coexist on 64 bit Windows 7 and 8. Theres no particular OS X advantage here.

      1. Steve Todd

        Re: One wonders

        Not quite that simple. 32 bit apps have to run inside of the WOW32 environment in 64 bit Windows, DLLs have to be kept separate and, at least by convention, programs live in a different directory tree. There is no such distinction in OS X. Apps run side by side. The OS knows if they are 32 or 64 bit, but there's no segregation.

    2. SuccessCase

      Re: One wonders

      Agreed, Tony Smith has made all sorts of assertions about performance without even waiting to check the device. Its disingenuous to pretend Apple were claiming a 2x performance leap based on moving to 64 bit. 64 bit is in the mix but they are different statements. So equally this comes across as a cheap attempt to trash the 2x performance claim by pointing out why simply a change to 64 bit architecture wouldn't bring it.

      Many most of the points Tony Smith has made are correct (apart from the il informed point made about duplicate libraries being required), but it is a very selective reading. As there are general performance increases distinct from the 64 bit-ness of the device, and the effort of delivering a 64 bit versions of apps is extremely low on OSX (and will also be on iOS - in many cases will be little more than hitting compile and testing), I find it highly doubtful the user will find apps slower as compared with the iPhone 5 but the piece seems to be written as though trying to leave the impression that will be the case.

      Additionally, on the selectivity of the arguments given, most memory is taken up with graphics/video data, and 64 bit does provide a significant performance benefit when dealing with such. So memory access and graphics processing, the things that are the most often encountered culprits hitting the main thread and affecting performance as perceived by the user, will be much sped up. On an average, only a comparatively small percentage of data loaded in memory is going to be inefficient as compared with 32 bit apps (which as I have said will in all probability be overtaken by clock-spead increase and other improvements in cache etc. anyway). So I expect the average app, as soon as it is compiled for 64 bit, could well be faster even if we were taking about a theoretical device where everything is the same as the iPhone 5 except that required to make it 64 bit.

      To assert Apple will have coordinated the effort to make the change to 64 bit for marketing reasons (when their marketing doesn't emphasise under the hood technology anyway) and that they would undergo the upheaval of such a major shift just for a bullet point, is taking Apple cynicism to an (all too often encountered) ill justified level.

      The reality is iOS has to a very large extent a shared code base with OSX (it isn't too much of a simplification to say it is basically OSX with some extrenuous stuff stripped out and the Cocoa Touch UI library added in). To make all code 64 bit too would be a healthy consolidation for Apple as well as being a good preparation for the future. There are also many other subtle considerations. One important one, it isn't just finger print scanner security that this will help, but full encrypted file system security. With 64bit it is much more feasible to ensure the whole schebang is encrypted and will have a lower impact on performance.

      It's true the benefit of 64 bit is a subtle case and not in and of itself something most users should consider a feature, but there are many many strategic reasons it is good to make the move.

      One thing I have noticed with Mavericks (hate the name) is that the system is far more aggressive in managing background processes to conserve battery. I suspect Apple are very much moving OSX towards the iOS appliance model. I expect we will see a RISC only version of the MacBook Air constrained to the App Store. This is something I have been worrying about because it will be a next step to sealed appliance PC's.

      I very much doubt Apple will be moving entirely away from PC architecture for the pro and developer market for the foreseeable future, but I do think there will be a very big market for users who would love a MacBook Air where they can't screw it up in the same way as they find it difficult to screw up their iPads. For many people the benefits of having an to all intents and purposes virus free, virtually un-screw-uppable computing appliance, where if you drop and break it, like the iPad everything is simply restored* will be immense.

      *Except for photo's, where inexplicably one of the most valued data assets people have are badly served by the otherwise excellent "1 login" restore process Apple have implemented. How can they have done such a good job for everything EXCEPT photos !!!

      1. SuccessCase

        Re: One wonders

        "So I expect the average app, as soon as it is compiled for 64 bit, could well be faster even if we were taking about a theoretical device where everything is the same as the iPhone 5 except that required to make it 64 bit."

        I'm not entirely happy with my statement there, because I should have made it clear there would also need to be compensation for the conditions where byte size reduces memory usage efficiency through increased cache sizes so read the statement "except that required to make it 64 bit" to also imply increased cache sizes too.

      2. Tony Smith, Editor, Reg Hardware (Written by Reg staff)

        Re: Re: One wonders

        FWIW, the point about the requirement for separate 32- and 64-bit libraries comes from Apple's own documentation, as does the claim that going 64-bit will deliver a performance boost of up to 2x. I believe Phil Schiller also made that claim during the iPhone 5s launch.

        1. SuccessCase

          Re: One wonders

          There is a difference between saying "our new 64 bit processor delivers twice the performance" and "the 64 bit architecture of our new processor delivers twice the performance as 32 bit," so I still think this piece is intended to denigrate the design choice of Apple opting for a 64 bit processor by implying the 2X performance claims are bogus by attributing a false claim to Apple.

          To be fair there are very, very many ways to measure processor performance and Apple, like most other manufacturers, will most surely have picked those measures that show it to it's best advantage (though unlike a certain other rival manufacturer, I suspect Apple would stop short of cheating by writing code to implement custom profiles when certain benchmark tests are detected and change the processor configuration to suite). So some of your points could turn out have some validity (though for reasons given above not to the degree you imply). My point is simply that you can't know without testing it out. Those who are close to Apple and know about their processor design chops know - despite the received "wisdom" of the ya-boo crowd - are becoming very, very good at it (they are one of the world's largest employers of chip designers).

    3. davefb

      Re: One wonders

      Yeah maybe..

      Only yes, on ios7 if you have an app running in 32bit, then it calls 32bit os functions.. So, if you can have everything 64bit, then you only load the 64bit frameworks, hence use less ram.

      You have read the docs haven't you?

  12. rurwin

    If this goes the same way as Linux x86 64-bit, then there will be either no visible difference between 32-bit and 64-bit, or 64-bit might be a little slower. It's a highly complex equation and the only way to find out is to suck it and see.

    1. LaeMing

      Yes. Or it might even be a smidge faster even! Beyond register expansion, AA64 is has had its instruction set somewhat optimised for modern compilers and programming techniques. Like with AMD64, that is often a lot more valuable than the actual 64-bittedness (though on desktop systems now and portables in time, that is also a very good thing in its own right - flat memory maps are always less headache-inducing!) :-) Like you said: "a highly complex equation"

      1. Len

        64 bit Firefox for OS X meant considerable improvement

        Yep, that was at least the case in X86 land. When Firefox for OS X moved to 64 bit, the performance increase was spectacular at some points:

        * Cold startup: x86_64 is ~26% faster

        * Warm startup: x86_64 is ~5% faster

        * MS Psychadelic Browsing Demo: x86_64 is ~540% faster

        * MS Speed Reading Demo: x86_64 is ~35% faster

        https://boomswaggerboom.wordpress.com/2010/11/10/firefox-4-for-mac-os-x-under-the-hood/

        Most of these improvements from moving to 64bit were not because of the 'extra bits', it were those additional registers and instructions that were part of X86-64.That might be the same on the ARM architecture.

  13. A Non e-mouse Silver badge

    There are several reasons why you might want a 64-bit O/S. (There are probably others)

    - Bigger address space. (This is NOT the same as more memory!)

    - Handle bigger numbers in hardware.

    - Architectural improvements (more registers, bigger cache, new instructions, etc)

    - Commonality with other systems. (e.g. with other 64-bit systems)

    - End of life of 32-bit system. (Not a major issue with ARM)

    I haven't seen any announcements from Apple as to why they moved to 64-bit, so at the moment everyone is just guessing/speculating as to Apple's reasons.

    Does Apple's IOS move to 64-bit mean much to customers? Right now probably not. (Expect for bike-shed bragging rights)

    1. Anonymous Coward
      Anonymous Coward

      OSX is 64-bit. They just wanted to cut down the number of kernel code bases they had.

  14. Anonymous Coward
    Anonymous Coward

    Well done Apple for moving things along and up but give it 6 months and I'm sure we will see fingerprint sensors and perhaps 12 months down the line 64 bit processors on Android.

    1. Humpty McNumpty

      Motorola Atrix..........

      ......had a fingerprint sensor. I turned it off because it was annoying, but it was there....

      1. Darryl
        Gimp

        Re: Motorola Atrix..........

        What you see there is the beginning of the Fanboy revisionism. Within days, history is changed so that Apple invented the fingerprint sensor and everyone else copied them, even if they copied them two years ago.

        1. Anonymous Coward
          Anonymous Coward

          Re: Motorola Atrix..........

          Sorry but from what I can see the iPhone fingerprint reader is just a simple touch based one using capacitance.

          Other fingerprint readers I've seen on laptops have been a black bar you slide your finger down, often not working because you dragged your finger too quick (much like those old handheld document scanners).

        2. Anonymous Coward
          Anonymous Coward

          Re: Motorola Atrix..........

          Apple have a magic fingerprint sensor which sees under the outer skin layers and isn't fooled by a lifted image. So I read. But as the encrypted print never leaves the phone, and the code is closed source, up to you what you choose to believe.

  15. Jon Green

    Performance?

    Let me get this right: Apple claims 64bit apps will run more efficiently than 32bit apps. But that also admit 32bit apps will run more slowly because of the 64bit framework. So, when Apple compares 32bit to 64bit, are they doing so on the same platform? After all, if you slow down 32bit enough - whether or not deliberately - 64bit will be quicker.

    My question, cutting through the smokescreen is:would a 64bit app running on a 64bit processor under 64bit iOS run more efficiently than a 32bit app running on a 32bit processor on 32bit iOS? Because without that, we don't know whether the shiny new A7's worth getting.

    1. Steve Todd

      Re: Performance?

      Until someone gets around to running 32 and 64 bit benchmarks on the new phone we don't really know the answer. It is however unlikely that the new chip would run 32 bit code slower than the old model.

  16. Bob Vistakin

    Exactly - with a modern multitasking OS this would do really well

    Like the one Google introduced for their phones way back in 2007. Unusually, Apple really have been true to their Think Different slogan through all those years and stuck with their dumbed down single tasking toy for the non-technical. And the lost, if they still use their comedy maps offering.

    1. Steve Todd
      Stop

      Re: Exactly - with a modern multitasking OS this would do really well

      Erm, iOS is a modern, multitasking OS. It limits what an application can do in the background (and those limits are being relaxed further in iOS 7) to conserve battery life, but under the hood it's the same BSD/Mach hybrid that powers OS X. Google are doing the same kinds of thing under Android BTW.

    2. Anonymous Coward
      Anonymous Coward

      Re: Exactly - with a modern multitasking OS this would do really well

      OSX is proper Unix. Not Lunix.

      1. M Gale

        Re: Exactly - with a modern multitasking OS this would do really well

        OSX is proper Unix. Not Lunix.

        GNU's Not Unix.

        Never has been, never pretended to be. Why does it have to be?

    3. SuccessCase

      Re: Exactly - with a modern multitasking OS this would do really well

      " stuck with their dumbed down single tasking toy for the non-technical."

      >Sigh<, ignorance knows no bounds. The ways in which iOS restricts developer access to multi-tasking at the OS level has been implemented by design. Apps can of course multi-task just fine, and are allowed to multi-task with with OS level functions and when the app is switched to the background through the application of "task" profiles or types which enforce orderly and fair use of system resources. The alternative is equivalent to putting a bucket filled with money in the middle of the street and saying "now now everyone, this is a free system supplied resource, only use what you need to, share fairly and leave some for others."

      Strangely it doesn't work out too well when you do that.

      1. M Gale

        Re: Exactly - with a modern multitasking OS this would do really well

        I think you're mistaking pre-emptive multitasking with cooperative multitasking. Coop multitasking was what Mac OS had all the way up to OS X, and Windows up to 3.11 (up to 9x for 16 bit apps). It is, to use the crap analogy, the equivalent of leaving a bucket of money out and asking people to only take from it fairly. The program hogs resources until it gives them back to the OS.

        Pre-emptive multitasking on the other hand, is where the OS decides how much CPU time each process is having, and rations timeslices accordingly. Unix has always had it, right back to 1969. Linux has had it since its inception in 1991, and since Android is based on Linux, well, Android has had it since day 1, too.

        Strangely, pre-emptive multitasking works, regardless of how much an individual process wants to hog things. The only remaining argument is the best type of rationing policy - round robin, least-used-first, priority-based or other?

        Ignorance, eh? It's everywhere.

  17. Anonymous Coward
    Anonymous Coward

    64bit and 32bit frameworks?

    You seem to be assuming that Apple will have handled the 64/32bit duality in the same way as Microsoft by basically having duplicates of every usermode binary? Do you have proof of that or is it a big assumption? Apple in the past have been very good at dynamic emulation or recompilation, maybe they support 32bit code in that way?

    1. Dan 55 Silver badge
      Meh

      Re: 64bit and 32bit frameworks?

      You don't have to look too hard for an example, even the almighty Mac OS X has the 32-bit and 64-bit browser vs plugin problem, just like the rest of Unix, Linux, and Windows...

      1. Henry Blackman

        Re: 64bit and 32bit frameworks?

        Actually it doesn't. Plugins run in a desperate process so can be 32 bit or 64 and load regardless of the app bring 64 bit or not.

        1. Dan 55 Silver badge

          Re: 64bit and 32bit frameworks?

          Tell that to Chrome and Java 7.

          (Maybe you're saying that you'd have to be "desperate" to run Java 7.)

  18. Mark 62

    Errata

    Mac OS has been 64 bit since 2003.

  19. LemmingO

    64-bit improvement

    I find it amusing that there is this entire argument about 64-bit processing when the first real improvements won't be on "performance" but will actually be on "efficiency", and on a smartphone efficiency translates as power savings. That's all. Of course if Apple is in fact using a Cortex A53 dual-core processor with an attached Cortex-M3/M4, then they are just following common sense.

    Apple did not disclose the amount of RAM on the iPhone 5S (we can safely presume 5C will be identical to the 5, ie: 1GB), but if all you are looking at is memory addressing then you're looking in the wrong place. A 64-bit processor like the A53 will bring with it some nice enterprise features, including virtualization, which is like the Pandora's Box of enterprise computing. If Apple can bridge iPhone and Macs properly, you've got a world of software possibilities at your fingertips.

    What astounds me is that Apple hasn't really presented anything worthy of praise. They've taken concepts that have been around for a while and just repackaged with the iPhone brand value. It's worth a lot, but some time down the road, even the flock will start questioning the shepherd.

    What Apple did:

    Let's call it "C" for Colorful and we'll let people think "C" is for Cheap...( £469 is not cheap, or affordable). It's cheaper to make, no doubt, but it's definitely not affordable. On the other hand, let's up-price the 5S by a tenner and say it's 64-bit, that'll shut the techies up.

    I have a dual-core 1.5GHz Windows Phone 8 with 512MB of RAM, FWIW. I'm ecstatic with it. It's cheap, it's cheerful and it DOESN'T slow down like my previous Android phones. I'm far from a Windows fanboi, but I recognise that you don't NEED to pay an arm and a leg to have better-than-iPhone kit.

    1. Steve Todd

      Re: 64-bit improvement

      Apple have an ARM Architechural license. They design and build their own cores. They have done since, IIRC, the A5. The A6 Swift core was quite a lot faster, clock for clock, than a stock Cortex A9, getting close to the A15 in performance on much less power.

      The A7 is slated as twice the speed of the A6, but with the same battery life. That isn't efficiency?

      As to Apple packaging features up, have you not yet learned that this is what they are best at. They package them in a way that is attractive to users rather than what techies think is attractive (see Windows Tablet Edition vs iPad for an example of that).

  20. JeeBee

    "Using more bytes to store a value"

    You are aware that ARMv8 ints are still 32-bit long?

    It's when you use longs (long longs for you windows people) that you benefit from 64-bit registers. And in this case ARMv8 has 30 64-bit registers, compared to around 12 free 32-bit registers (i.e., six 64-bit values) - five times the register space.

    Immediately you can see how code that can make use of 64-bit values will become far faster. Not only does it have more register space, but CPU instructions will be done faster (single pass through the ALU, not two passes through a 32-bit ALU). And because your problem is using 64-bit values regardless of how it is processing them, the amount of memory used for value storage isn't different.

    So the only caveat, for 64-bit integer calculations, is that your problem needs to be able to make use of 64-bit values. And if it can, it will be faster.

    Also note ARMv8 doubles the size of VFP (standard ARM floating point, not NEON) registers. IIRC.

  21. Anonymous Coward
    Anonymous Coward

    "architecture neutral bitcode format"

    Oh dear. Another one - no offence, I assume unlike me you're not a dinosaur.

    I'm old enough to remember Architecure Neutral Distribution Format from the OSF (though originally from the UK Defence Research Agency?).

    And before that there was p-code (from UCSD Pascal). And doubtless others not worth mentioning even if I could remember them.

    Obviously more recently the success of Java's "write once, vulnerabilities everywhere" philosophy has improved the chances of future architecture-independent distribution formats. Hasn't it?

    These things aren't necessarily bad ideas, but somewhere between the idea and the implementation, something frequently falls off. Maybe LLVM will, courtesy of Apple and others, make it more mainstream this time round.

  22. dorsetknob

    64 bit chip

    My Android phone/tablet has a intel 64bit chip

    Nothing new about apple introducing 64 bit chips to phones here

    1. Anonymous Coward
      Anonymous Coward

      Re: 64 bit chip

      Can it actually use it in 64-bit mode?

    2. Steve Todd

      Re: 64 bit chip

      Even Intel don't think the Atom Z series is ready for use under a 64 bit OS yet. They are talking about 2014.

  23. Anonymous Coward
    Anonymous Coward

    Apple is NOT claiming 64 bits gives them a 2x performance improvement

    Just like anyone other chip designer, Apple is going to be able to make performance improvements in the design itself that would make it perform better even when running at the same clock speed. It is made in a smaller process, so will also be clocked faster, and given that the A6 was fairly conservative with its clock rate there would be a lot of room for improvement there should they wish it. The A7's transistor density (based on "over a billion" transistors in 102 sq mm) is twice that of the A6 and surprisingly is slightly higher even than Intel's 22nm Haswell (though Intel's design rules aren't set up to maximize density since production cost isn't their top concern)

    Between improvements in IPC and improvements in clock rate over the rather conservative A6, getting a 2x performance boost compared to the A6 isn't really a stretch. Especially when you consider them saying 'up to 2x' means it is 2x faster in at least one thing and almost certainly less than 2x faster in others.

  24. Anonymous Coward
    Anonymous Coward

    1GB of RAM isn't it? Unless it has 8GB there's no need for 64-bit.

    What has happened to Apple? they've become so "techie" all of the sudden, showing off manufacturing processes, boasting about 64-bit. Please go back to demonstrating how your new device does something new or better. Oh it doesn't? try again then!

    1. Frumious Bandersnatch

      @AC: Unless it has 8GB there's no need for 64-bit.

      I think this has been amply dealt with by previous posters, but for another example, what if you want to mmap a file (or device) that's bigger than 4Gb? The switch to 64-bit means a bump in addressable space, which isn't the same thing as physical RAM!

  25. nanchatte

    Help me please…

    How can it address 1TB of physical memory yet only 4GB of virtual memory? I don't get it… The opposite makes more sense, no?

    1. Anonymous Coward
      Anonymous Coward

      Re: Help me please…

      "How can it address 1TB of physical memory yet only 4GB of virtual memory?"

      The same way this "narrow logical address, wide physical address" has worked for decades. Yea, even unto the PDP11 (16 bit (64kbyte) logical address, physical address up to 22 bits (4Mbyte) depending on model, back in the 1970s or thereabouts.

      Use memory management registers creatively. Change the memory management setup so that although at any given time only 4GB (PDP11: 64kB) of logical address space is visible, you can choose (and change) that 4GB to be anywhere within the nominal 1TB (PDP11: 4MB) address space.

  26. Hyper72

    64bit - thoughts.

    Apple didn't claim the processor is up to 2x faster due to 64bit, it is certainly due to other architectural improvements and they hinted at that.

    Users will get forward compability for 64bit only apps, even though it's not immediately obviously useful it extends device lifetime.

    Address space layout randomization (ASLR) - much better on 64bit architectures.

    Convergence with OSX codebase...

    They can use the same processor in other devices that may require >4GB addressing (RAM and memory mapped devices). For example AppleTV.

  27. and-job

    A long term plan

    Apple have set a long term plan in motion, they are in the ideal position with their closed in system to start the push towards all devices running 64 bit architecture. iPod, iPad and iphone.

    I bet that they will launch three devices next year. A low memory 8Gb model with a 64 bit processor and cheaper camera and no fingerprint camera and probably no M7 chip with the same plastic case design rather than dump the 5C onto market as the freebie they will have a 64 bit system. The old 5S will be the middle tier model and the replacement for the 5S will have a faster processor with extra ram to allow the processor to 'breath' and maybe even a larger screen or some other new feature to the design.

    The 5S is merely seeding the transition. Getting the App dev's to write apps for the 64 bit system and move away from 32 bit pushes people with older model iPhones to transition to the new 64 bit architecture so that they can use many of the apps which will soon start to become 'less available' to the older phones.

    Expect the same thing to happen to the iPad and the iPod Touch range of devices.

    For Apple it revives a stream of revenue as people start to upgrade their devices.

    Meanwhile, Android devices, even those that are 64 bit (as they come onto the market) will be trapped in the fragmentation and there is nothing to compel the dev's from updating their Apps to be biased towards the 64 bit architecture, in the Android world 32 bit will be around for a very very very long time as the processors get older and are used in the economy models used for many prepaid carriers.

    so Companies such as Samsung may launch 64 bit devices but unless they launch their own App Store or invest in a way of getting App dev's to recompile for the 64 architecture they will be in the same situation as Windows PC's have been! Lots of 64-bit windows PC's out there but not many companies that have developed 64 bit software because it makes them comfortable knowing that they can have 32 bit software running on the 64 bit systems and while there is a little increase in speed the PC is not operating at its full potential!

    Apple may lose some 'customers' to lower cost Android devices but in the long term they will have an Appstore filled with 64 bit apps running on 64 bit architecture and Apple will have income as their customer base transitions over they next two or three years to new iPod, iPad and iPhone's that are 64 bit!

  28. AndyDent

    64bit misunderstandings and priapisms

    "you need twice as much memory to store the same amount of information."

    NO NO NO

    You need twice as much memory to store the same amount of integers if they are a type which becomes 64bit.

    You don't find images or text or most data structures doubling in size.

    Also, the big deal about having 64bit pointers is NOT about the physical RAM you can address but about the size of your virtual address space. That makes it a lot easier to write code processing images larger than 3GB, for example. Even having a 64bit OS increases the size of address space for 32bit applications. I'm not sure how OS/X does it but on Windows a 32bit app under 64bit Windows has a full 4GB address space instead of its normal 2GB (or 3GB with special OS setting) on 32bit Windows.

  29. joe_bruin

    Retraction?

    I expect Tony Smith will print a retraction when he is proven wrong next week.

    Criteria for invalidation of his assertions:

    1) 32-bit apps run faster on the A7 than they do on A6

    2) 64-bit apps run faster than 32-bit apps on A7

    3) 64-bit apps on A7 can reach 2x performance of 32-bit apps on A6

    The article's understanding of CPU architectures is shallow and its conclusions are faulty. Many others have pointed out some of the reasons why. I imagine AnandTech will shortly embarrass the author by performing a real analysis when they have hardware in hand. Once that is accomplished, surely The Register will print a full article, not an update comment tacked on to this one, detailing the extent of their error. How about it, Tony?

    1. joe_bruin

      Re: Retraction?

      Well, Tony? We're waiting for the correction article now that you've been properly embarrassed by the facts.

  30. Henry Wertz 1 Gold badge

    Regarding a >4GB limit on 32-bit ios. ARM is not x86, and I do not think it has any PAE-like kludges.

    Anyway, recent enough gcc has a ARMv8 target, that takes care of taking advantage of the extra registers and all that. In many cases, there'll be nothing to do to take advantage of speedups of 64-bit instructions but rebuild the application. I think video players on ARM tend to use the DSP rather than main ARM CPU anyway, so they may not need much done either, otherwise you'd want different hand-optimized assembly for some of the decoding and scaling code.

    As for Android -- Linux kernel has supported 64-bit ARM for about a year. Dalvik would have to be upddated to take advantage of ARMv8, almost everything runs under Dalvik on Android. The userland available to NDK is very minimal, there's very few libraries to need 32-bit and 64-bit versions of. I would assume 32-bit NDK code may be limited to 32-bit 3GB or so limit (1GB is reserved for kernel address space), and if Dalvik ended up staying 32-bit for some reason, it'd be limited to 3GB too, but per-process rather than system-wide.

  31. davefb

    So these A7's..

    Would they run in servers? Or would they be totally unsuitable? Just thinking since the world+wife are slowly dipping the toes into arm-64 serverland have Apple built their own tech?

This topic is closed for new posts.

Other stories you might like