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.

Page:

  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

        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.

Page:

This topic is closed for new posts.

Other stories you might like