or Connect
AppleInsider › Forums › Mobile › iPhone › Inside Apple's 64-bit iOS 7 and the prospects for a 64-bit Android
New Posts  All Forums:Forum Nav:

Inside Apple's 64-bit iOS 7 and the prospects for a 64-bit Android - Page 2

post #41 of 221

Well, with over $140B in the bank, a zillion stores worldwide, people queuing up to buy their products, I would say Apple knows what they are doing.  Even if I understood zippo about technology, I'd look at those telling stats, and have confidence this company is on top of it's game.  So who's got $200B in the bank to tell me otherwise?

post #42 of 221
Quote:
Originally Posted by BigMac2 View Post
 

 

Actually, iOS root like OSX is coming from Nextstep developed on a 33mhz 68040 processor.  While it debuted as a locked OS, they quickly open up the platform with iOS 2.  

 

No one is questioning where iOS came from. I was merely pointing out that like Android, iOS was designed to fit in memory and cpu-constrained environments, and they did a better job of it by aggressively limiting multitasking, etc. Android has more of a traditional multitasking design, with various apps working together via inter-app communication (intents) to accomplish tasks, and ran poorly on lower-powered devices particularly in the early days of dalvik.


Edited by d4NjvRzf - 9/17/13 at 7:56am
post #43 of 221
Quote:
Originally Posted by BoC View Post

The iPhone 5S has a near workstation class CPU of a decade ago.
 

Can't say I completely agree. The definition of a workstation is not merely centered around the CPU. Graphics has a lot to with it too. So does the A7 have the computing and graphics performance of a workstation of a decade ago? Not quite, AFAIK.

post #44 of 221
Quote:
Originally Posted by RichL View Post

Google doesn't need production hardware. Most low-level OS software development is done on dev boards. 64-bit ARMv8 dev boards have been available since last year.

Interesting that your 'evidence' is nothing more than wishful thinking.

As soon as there's some evidence that Google has 64 bit Android ready, let us know. Until then, Apple has a big head start.

Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #45 of 221
Quote:
Originally Posted by RichL View Post
 

 

Not always. I do know many Google and ARM engineers though. Android coped with the move to multi-core CPUs just fine and I don't doubt that it'll handle the move to 64-bit as well. 

 
DED's analysis on Android's transition to 64-bit is completely devoid of evidence. He presents his opinion as fact. He has no insider knowledge and apparently no specialist understanding of modern operating system architecture. 

 

I also love the way that he asserts that Android has no "console-style" games, despite the fact that several consoles are based on Android!

 

Most of his article is devoid of evidence. He's no engineer.

 

Quote:
Originally Posted by Chandra69 View Post
 

iOS, as a platform for webapps?  Give me a break!

 

Another fact disappears down the memory hole.

 

Quote:
Originally Posted by auxio View Post
 

 

Not really.  If you read the backstory on the creation of the iPhone, Apple rushed it to market very quickly (burning out a few engineers in the process).  So some things, like a 3rd party app development environment, had to be left out to make the deadline.

 

As someone who was involved with helping reverse-engineer a development environment for the first iPhone, I can definitively say that all of the native development frameworks were in place already (but only Apple could use them).  I have no doubt that 3rd party application development was planned from the start, they just needed a bit more time to polish the development tools and document everything (not to mention create an app store).

 

Apple were using Objective C API ported from OS X on the iPhone ( in fact Jobs said "we put OS X on this thing" in the iPhone's debut). That doesn't mean that the company had intended to ever make those API open to external devs. As far asI recall reading it was Forstall who campaigned for that. Forstall was much more important than people realize. I don't particularly like the guy but he was important.

I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #46 of 221
Quote:
Originally Posted by d4NjvRzf View Post

To be fair, iOS was also designed initially for low-memory low-powered devices like the original iPhone. Moreover, it debuted mainly as a platform for web apps, and only later were provisions for third-party apps added in.

The iPhone of 2007 did have a 1/40 the power of the new 5s, but it still shipped with "desktop class" email, browser, maps, and media apps,

As in, ObjC Cocoa Touch apps. Not initially supporting any real third party apps is not comparable to Android shipping as a rewarmed JavaME that didn't even get a real browser until years after the iPhone.

Android remained a hobbyist curiosity until late 2009, nearly 3 years after iPhone despite originating as a project years before iPhone was launched.

When did the terrible "Android Browser" finally get replaces with Chrome? 2011?

2012, shipped with android 4.0
Edited by Corrections - 9/17/13 at 8:00am
post #47 of 221
I also think that this article is terrible on the technical details. DED claims that would be too hard to do, fraught with compromises and ultimately not practical. What is fails to realize is that Oracle/Sun has been offering 32 and 64 bit versions of the Java JVM for years now. Recently I had a customer who was having serious problems running their enterprise middleware software stack. The recommendation was to change from the 64 bit JVM from the 32 bit one since they were running on the ragged edge of memory utilization. The change was successful with no changes necessary to the middleware Java code...and trust me, it's a lot more code than runs on a phone. Also, they ended up using the 64 bit version of a Java 5 JVM (not the latest Java 7). So this capability has been around for YEARS.

The article started well laying down the groundwork between the processor differences. But it quickly veered into the realm of BS in making the argument with the technical difficulty of making a 64 bit transition. I agree that Google has more work to do that Apple in this regard. But it's not impossible, nor is it a fool's errand. There will be advantages to Android making the switch, and I expect them to make it in 2014.
post #48 of 221
richl I think you are missing some of the points of the article. ARMV8 was never claimed to be a secret, it was intended to target low power server markets. It was not on any handset roadmap, especially with some rather public failures trying to embed the last arm server arch. Note both qualcomm (KRAIT) and A6 sidestepped that arch with their mobile offerings for a reason and were glad for it.

Apple owns its compiler technology, the frameworks, the developer IDE, the review process, and the storefront. Their iOS underpinnings and frameworks (cocoa) share 64-bit implementations with OS X. This made their decision easier to swallow, and given the large developer community that make almost 75% of the entire mobile SW sales, they have the incentive to get the devs moving.
Doodle Dice iPhone puzzle game: A fun, free physics-laden collection of dice games.  Greatest app made yet?  Perhaps young man... Perhaps.
Reply
Doodle Dice iPhone puzzle game: A fun, free physics-laden collection of dice games.  Greatest app made yet?  Perhaps young man... Perhaps.
Reply
post #49 of 221
Quote:
Originally Posted by BigMac2 View Post
 

 

Actually, iOS root like OSX is coming from Nextstep developed on a 33mhz 68040 processor.  

Is that really true?

 

I realize common lore says Apple acquired NeXT and subsumed NeXTSTEP into Mac OS X. But it's more nuanced than that. Someone here, I believe, worked at NeXT and therefore could correct me.

post #50 of 221
Quote:
Originally Posted by jragosta View Post



Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.

 

The answer is "very easy".  Java byte code is platform (64/32 bit) agnostic. A 32 bit app will run perfectly fine on 64-bit Java with no compilation changes necessary. There is no ambiguity of int sizes in java, an int is always 32 bits. If you need/use 64 bit values in your java app you will specifically declare them and they will work on 32 or 64 bit jvm.

 

The majority of the work in moving to 64 bit Android is in the kernel/jvm and native interfaces. This is "mostly" already established work. 64 bit linux kernels have been around for a long time as have 64 bit java VM's.

post #51 of 221

Take this from DED


"When iOS is executing on a 64-bit device, iOS includes separate 32-bit and 64-bit versions of the system frameworks. When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly," Apple explains.

"Because all of the built-in apps already support the 64-bit runtime, it is to everyone?s benefit that all apps running on 64-bit devices be compiled for the 64-bit runtime, especially apps that support background processing. Even apps that are not performance sensitive gain from this memory efficiency."
 

This really means that, to begin with, the memory footprint for shared libraries in shared memory will double, and will in fact do so until the user gets rid of all 32 bit apps on his machine. And the footprint on the flash drive is going to be larger as well as fat versions of the libraries will be there.

 

So the benefits?

 

Except for calculations of integers larger than the 4G limit, not much. Floating point calculations will have more precision, but not necessarily speed since the CPU is not optimized for floating point operations.

I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #52 of 221
FWIW .... without prejudice ... ExtremeTech has been always ExtremeFullOfShit as I remember browsing their site!

....the lack of properly optimized apps is one of the reasons "why the experience on Android tablets is so crappy".

Tim Cook ~ The Wall Street Journal - February 7, 2014

Inside Google! 

Reply

....the lack of properly optimized apps is one of the reasons "why the experience on Android tablets is so crappy".

Tim Cook ~ The Wall Street Journal - February 7, 2014

Inside Google! 

Reply
post #53 of 221
Quote:
Originally Posted by d4NjvRzf View Post
 

 

Interesting. Were critical elements like the sandbox already present in the original iOS? According to this site (

http://theiphonewiki.com/wiki/Sandbox) the sandbox debuted in iOS 2.0 along with the app store. 

 

How is a sandbox a critical element for creating an app?  It's only needed for security.  Seriously, I (and many others -- Erica Sadun from TUAW for one) had tons of native apps on the original iPhone.  They weren't signed or sandboxed (kinda like apps on jailbroken iPhones), but they worked just fine for learning the capabilities of the iPhone and how to develop apps for it.

 
Reply
 
Reply
post #54 of 221
Quote:
Originally Posted by auxio View Post
 

 

How is a sandbox a critical element for creating an app?  It's only needed for security.  Seriously, I (and many others -- Erica Sadun from TUAW for one) had tons of native apps on the original iPhone.  They weren't signed or sandboxed (kinda like apps on jailbroken iPhones), but they worked just fine for learning the capabilities of the iPhone and how to develop apps for it.

 

It's not critical for creating or running an app, but we were talking about whether the original iOS was intended to run third-party apps, not whether it was technically capable of doing so.

post #55 of 221
Quote:
Originally Posted by formosa View Post
 

It looks to me that the long play (with A7) is an eventual convergence of iOS and MacOS...

 

Definitely. I definitely see a near-future MacBook Air using one of these A7s, or more likely the A7X.  That will free Apple from Intel's ultra-portable processor pricing.  I think a lot of people would be happy with a touchscreen MBA running "iOSX" on an A7X - effectively an iPad with Mac OS X abilities and apps in a more laptoppy formfactor.

 
But they haven't enabled building Mac OS X apps on ARM yet - which will be a major announcement - so it probably won't be this generation. So the A8X. Or the A9X. But it is coming, all signs point to it.
post #56 of 221
Quote:
Originally Posted by StruckPaper View Post
 

Is that really true?

 

I realize common lore says Apple acquired NeXT and subsumed NeXTSTEP into Mac OS X. But it's more nuanced than that. Someone here, I believe, worked at NeXT and therefore could correct me.

 

It's pretty much true.  NeXTSTEP is the grandfather of iOS (with OS X being the father).  iOS, OS X and NeXTSTEP all use Obj-C as the primary programming language, had similar kernel structures, I/O and system calls.

post #57 of 221
Quote:
Originally Posted by BigMac2 View Post
 

 

Of course ARM (a corp co-founded by Apple and Acorn Computer) discuss a lots with their partner, since they doesn't sold any hardware, they only licences their hardware to anyone who want to mfg.  Problem is Google doesn't do any ARM development internally, they got no production hardware to work on a 64 bit version of Android and Samsung and Qualcomm, 2 of the most prominent ARM SoC maker chooses the cores multiplication way, look at the Exynos 5 Octa non-sense. 

 

If you think that a major ARM OS provider has no communication with ARM then I have a nice bridge to sell you.

 

ARMv8 emulators, simulators and FPGA implementations have been around for quite some time for software validation.

 

Samsung and Qualcomm don't only offer the Octa and the SD800 (which are their "X" chips).

post #58 of 221
Quote:
Originally Posted by patpatpat View Post
 

 

The answer is "very easy".  Java byte code is platform (64/32 bit) agnostic. A 32 bit app will run perfectly fine on 64-bit Java with no compilation changes necessary. There is no ambiguity of int sizes in java, an int is always 32 bits. If you need/use 64 bit values in your java app you will specifically declare them and they will work on 32 or 64 bit jvm.

 

The majority of the work in moving to 64 bit Android is in the kernel/jvm and native interfaces. This is "mostly" already established work. 64 bit linux kernels have been around for a long time as have 64 bit java VM's.

 

Meanwhile with Objective C's c legacy, an int vs long is a potential minefield. APple's tech note on this is fairly involved, although more for people using primitives in C rather than Obj C objects.

I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #59 of 221
Quote:
Originally Posted by asdasd View Post
 

Apple were using Objective C API ported from OS X on the iPhone ( in fact Jobs said "we put OS X on this thing" in the iPhone's debut). That doesn't mean that the company had intended to ever make those API open to external devs. As far asI recall reading it was Forstall who campaigned for that. Forstall was much more important than people realize. I don't particularly like the guy but he was important.

 

Jobs was always like that from what I heard -- he had to be convinced of things outside of his scope of focus.  He respected the top engineers, and so if the top engineers wanted something to happen, it would happen eventually.  I'm certain the top engineers wanted 3rd party apps from the start, so it was all but an inevitability.  Which is why a lot of us were prepping for it beforehand.

 
Reply
 
Reply
post #60 of 221
Quote:
Originally Posted by Sevenfeet View Post
 

 

It's pretty much true.  NeXTSTEP is the grandfather of iOS (with OS X being the father).  iOS, OS X and NeXTSTEP all use Obj-C as the primary programming language, had similar kernel structures, I/O and system calls.

 

Applescript is what is left of OS 9. Since the Finder rewrite.

I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #61 of 221
Quote:
Originally Posted by mausz View Post

So what this means for me as an enduser without an A7, is I will get updates for all my apps without actual updates but with larger universal binaries.

Sounds a bit like a period with my iPad2 where I got all these updates which didn't update anything but enlarged the footprint of all my apps (and gave space issues on my 16Gb version) because I needed to download all retina graphics etc.

Most universal apps shouldn't be much bigger than their 32-bit only versions. When you look inside of app bundles you will see that in most cases that the size of the app's graphics is much bigger than the size of the 32-bit executable. Since the 64-bit version can use the same graphics, the app should only need to include the 64-bit executable.
post #62 of 221
I think people don't get the "64-bit in a phone" thing:
This is about transitioning up a base of thousands of developers to a brave new world:

iPhone:
- 2013: 64-Bit in 5S, 2014: 64-Bit in 6C, 2015: All iPhone lineup is A7/64-bit minimum
- iPhone/iOS 10 (2016/2017) when high-end phones have more than 4GB RAM, Apple can push a 64-Bit only iOS on pretty much all iPhones that are younger than 3 years (5s or higher)
- At the same time Android wills till be all over the shop with different processors, different bitness, different graphics architectures, screen sizes, co processors - you name it.

iPad:
2013: iPad 5 in 64-Bit, 2014 64-Bit in iPad mini, 2015 Apple requires all iPad apps to have a 64-bit fork in the fat binary to get the last developers understand the importance.

AppleTV 4
2014: Apple TV 4 with A7 and 64 Bit with the ImagTech graphics engine
- New Apple TV App Store
- Positioned as casual game console
- Developers can port iPad/iPhone games to the big screen with no ramp up time
- Controlled via iPhone/iPad, new Apple Game controller or 3rd party Controller via BT

Macbook Air (ARM Edition) --> Think Chromebook, just in useful and with software
2015:
- Apple announces new Macbook Air with MacOS for ARM on A8 processor (8GB RAM) & touchscreen
- All new Mac Appstore applications need to provide fat binary (x86, ARM)
- Can run iPad apps in a window.
- Roadmap for all Mac to transition to ARM architecture until 2018

Okay. This is all a bit over the top, but this is what I believe the A7 stands for: An unprecedented move to a unified eco system of phone, tablet, set top box and desktop OS.

One company doing it all with the biggest developer community getting one 64-bit architecture for processor and graphics for all platforms with minimum transition time, QA & testing obstacles and supported by 500M credit cards registered by Apple.

Take that, Microsoft, Google and Samsung.

Cheers Max
post #63 of 221
Quote:
Originally Posted by d4NjvRzf View Post
 

 

It's not critical for creating or running an app, but we were talking about whether the original iOS was intended to run third-party apps, not whether it was technically capable of doing so.

 

No, we were debating whether it was purely a platform for showcasing web apps.  My argument is that 3rd party apps were intended all along, and it just took a little longer to get there due to Jobs' tight/crazy release schedules and the need for prioritization.

 
Reply
 
Reply
post #64 of 221
Quote:
Originally Posted by DaveN View Post


Most universal apps shouldn't be much bigger than their 32-bit only versions. When you look inside of app bundles you will see that in most cases that the size of the app's graphics is much bigger than the size of the 32-bit executable. Since the 64-bit version can use the same graphics, the app should only need to include the 64-bit executable.

Most people mistakenly seem to think that 64- bit app is 2x the size of 32-bit. The size increase is fairly trivial, maybe a few percent. The instruction set of 64-bit arm is still 32-bits. 

post #65 of 221
Quote:
Originally Posted by Maestro64 View Post
 

ever time these so call tech experts speak they show how much they do not know about technologies. Yes, apps at this time can not take advantage of the 64 bit architectures and most apps do not need this level of power. But to say a user will not see any performance difference is complete wrong. We all have to assume that iOS was written as 64bit native, therefore, the user will see OS is self running faster. You can also bet that Apple is working with developers so they can take advantage of the new architecture. Therefore it will not be long before those first apps show up for 5S only. Most likely they will be gaming apps and as we all know the ipad and ATV will soon have the 64bit A7.   

 

Most applications spend most of their time within OS libraries. The more the OS libraries are optimised for 64-bit, the more the application benefits, even if it isn't enhanced much (if at all) itself.

 

The main performance benefit from ARMv8 in the integer world are where longs (64-bit ints) are used. Rather than storing around 6 longs across 12 available 32-bit registers, you can now store around 30 longs in the larger register file. In addition each ALU operation on these longs is done in half the time of doing it in 32-bit. Not all problems can make use of longs, but where they can, performance improvements will be drastic.

 

Also the larger and longer floating point registers (not NEON, but VFP) will result in major performance increases too.

 

XCode will create both 32-bit and 64-bit versions of applications for the foreseeable future, either as fat binaries or separate binaries that the Apple Store will use depending on the target device.

post #66 of 221

Very interesting article. Most of the talks have been about the price of the 5c, but the big news is probably the 64 bit(s?) transition.

post #67 of 221
Quote:
Originally Posted by Hattig View Post
 

 

Most applications spend most of their time within OS libraries. The more the OS libraries are optimised for 64-bit, the more the application benefits, even if it isn't enhanced much (if at all) itself.

 

The main performance benefit from ARMv8 in the integer world are where longs (64-bit ints) are used. Rather than storing around 6 longs across 12 available 32-bit registers, you can now store around 30 longs in the larger register file. In addition each ALU operation on these longs is done in half the time of doing it in 32-bit. Not all problems can make use of longs, but where they can, performance improvements will be drastic.

 

Also the larger and longer floating point registers (not NEON, but VFP) will result in major performance increases too.

 

XCode will create both 32-bit and 64-bit versions of applications for the foreseeable future, either as fat binaries or separate binaries that the Apple Store will use depending on the target device.

 

Not to mention the built in crypto instructions which can have a major performance improvement on anything using secure socket layer SSL, or video/audio decryption.

post #68 of 221
Quote:
Originally Posted by Corrections View Post


"64-bit mobile ARM processors have been in the pipeline for a long time" is somewhat true, but you're missing the fact that they were targeting server applications. Nobody had any inkling of putting a 64-bit SoC in a phone.

 

More bullshit from you, Daniel. Even the long dead Symbian had a 64-bit roadmap.

post #69 of 221
Quote:
Originally Posted by StruckPaper View Post
 

 

What strikes me as interesting is that Samsung's JK Shin claimed that next year Galaxy S would sport 64-bit processing. They can't do this without Google's cooperation. So either Shin is speaking out of bravado or he is aware of Android's future timeline.

 

Either that or it'll run a hastily-recompiled version of Tizen with a 32-bit Android compatibility layer...

 

If the S4 was anything to go by, the 64-bit SoC will be too expensive for the market and so everywhere other than South Korea will get one powered by a 32-bit Snapdragon instead.  6 months after release they'll state that they've finally worked out how to get all 64 bits working at the same time and there will be a future software update to permit this.

post #70 of 221
Quote:
Originally Posted by asdasd View Post
 

Take this from DED


"When iOS is executing on a 64-bit device, iOS includes separate 32-bit and 64-bit versions of the system frameworks. When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly," Apple explains.

"Because all of the built-in apps already support the 64-bit runtime, it is to everyone?s benefit that all apps running on 64-bit devices be compiled for the 64-bit runtime, especially apps that support background processing. Even apps that are not performance sensitive gain from this memory efficiency."
 

This really means that, to begin with, the memory footprint for shared libraries in shared memory will double, and will in fact do so until the user gets rid of all 32 bit apps on his machine. And the footprint on the flash drive is going to be larger as well as fat versions of the libraries will be there.

 

So the benefits?

 

Except for calculations of integers larger than the 4G limit, not much. Floating point calculations will have more precision, but not necessarily speed since the CPU is not optimized for floating point operations.

 

There is a lot more is going on with ARM AArch64 architecture than solely 64 bit addressing.  The current ARM v7 architecture has many legacy bottleneck and shortcomings, the registers and security layer was overly complex and limited.  The new 64 bit architecture as gave them the chance to greatly modernize a + 20 years ISA.  I will repeat my self, we don't know much yet about the A7 internal, but if you look at other previous 64 bit CPU like the Athlon 64 or the G5, there internal architecture was radically different then previous generation and gave a big performance boots even to unoptimized apps. 

post #71 of 221
Quote:
Originally Posted by Chandra69 View Post
 

iOS, as a platform for webapps?  Give me a break!

 

So quickly that people forget.

post #72 of 221

It's quite possible that Samsung will be the first Android OEM with a 64 bit ARM processor, and maybe they will develop for a smaller node than Apple is at now for the A7/A7X.

 

Still, the Apple A7 is in production, and Apple likely will have the A8 ready for tapeout with plenty of production ramp before the iPhone 6, and will likely be at a comparable node as Samsung's best effort, with the advantage for Apple of custom ARMv8.

 

What this says to me though, is that ARMv8 is going to be very expensive for Android OEM's to design in, save possibly for Samsung, leaving even less margin on the table to survive. Perhaps between Apple and Samsung, other Android OEM's will be effectively shut out of the premium smartphone market defined by 64bit.

 

Apple will also enjoy a first mover advantage of apps, many of which will be new category apps tailored to business and enterprise organizations.

 

Perhaps its time for Google to push ChromeOS through Motorola and deprecate Android as its premier smartphone OS, relegating it to undeveloped nations where the bulk of its growth will center.

post #73 of 221
Quote:
Originally Posted by Sevenfeet View Post

Oracle/Sun has been offering 32 and 64 bit versions of the Java JVM for years now. Recently I had a customer who was having serious problems running their enterprise middleware software stack. The recommendation was to change from the 64 bit JVM from the 32 bit one since they were running on the ragged edge of memory utilization. The change was successful with no changes necessary to the middleware Java code...and trust me, it's a lot more code than runs on a phone. Also, they ended up using the 64 bit version of a Java 5 JVM (not the latest Java 7). So this capability has been around for YEARS.

JavaME had also existed for years when Android was conceived ~2005, but it still took 3 years to get Android into production.

Also, 64-bit Java is not designed with any intent to run on mobile devices. It runs like crap on desktop PCs, making the platform only ever successful in server deployment.

Also: let me remind you about Adobe Flash, which similarly "existed" years before Google & Adobe decided to make it work on mobiles. After years of trying 2008-2011, they shipped something but then abandoned it because it made no sense.

You also forget that the technical "realm of possibility" needs a viable business model backing it up.

Hopes and dreams of Android fans haven't resulted in app sales, And it's not enough to replicate the work of a company making 75% of the profits of the mobile industry.
post #74 of 221
Another excellent article.

I have to laugh when the Fandroids inevitably show up here to stir the pot.

richl - Unless you have some solid evidence to back up your claims, its nothing more than conjecture. The reality is that Apple has 64bit hardware and software going to market THIS WEEK (including apps). Android is eating dust...
post #75 of 221
Quote:
Originally Posted by StruckPaper View Post
 

 

It won't *hard* to follow. It will just take engineering effort - effort that is well understood, and effort that has already begun.

Agree. What strikes me as interesting is that Samsung's JK Shin claimed that next year Galaxy S would sport 64-bit processing. They can't do this without Google's cooperation. So either Shin is speaking out of bravado or he is aware of Android's future timeline.

It also means that Samsung's Exynos 6 chips that include 64-bit cores are already designed and taped out. It takes a very long time, relatively speaking, to go from chip design completion to product availability (9 to 12 months), so if they anticipate a product out next year for the S5 in around June/July, that means the chip's designed now.

 

But Apple do have that chip in product now, and that is a massive achievement, far earlier than people expected. The experience in 64-bit processors that Apple got when they bought PA Semi will have proven invaluable here. ARMv8 is very PowerPC like in some aspects, just with a different ISA in front of it all.

post #76 of 221
Quote:
Originally Posted by StruckPaper View Post
 

Can't say I completely agree. The definition of a workstation is not merely centered around the CPU. Graphics has a lot to with it too. So does the A7 have the computing and graphics performance of a workstation of a decade ago? Not quite, AFAIK.

 

If it's PowerVR Rogue, then it's probably achieving around 80-100 GFLOPS and supports OpenCL.

 

That is quite competitive with what workstations could do a decade ago. Look at how many PowerMac G5s it took to achieve that 10 TFLOP supercomputer in Virginia Tech. 1100 computers (http://www.technewsworld.com/story/31997.html). 10000 GFLOPS/1100 computers = 10 GFLOPS/computer.

post #77 of 221
Quote:
Originally Posted by RichL View Post
 

 

More bullshit from you, Daniel. Even the long dead Symbian had a 64-bit roadmap.

 

A roadmap is only prediction which doesn't translate into execution.  There is no working version of 64 bit Symbian and never will. 

post #78 of 221
Quote:
Originally Posted by jragosta View Post


Interesting that your 'evidence' is nothing more than wishful thinking.

As soon as there's some evidence that Google has 64 bit Android ready, let us know. Until then, Apple has a big head start.

Oh, and btw, make sure you tell us how easy it is to convert Android apps to 64 bit. The benchmark is the simple recompile required by iOS.

 

Android apps will run on 64-bit without a recompile. They're targeting a bytecode intermediary instruction set, it is the task of the Dalvik VM to JIT compile that into something to run on the target hardware. That's how the same Android binary runs flawlessly on ARM, x86 and MIPS currently.

 

Also don't make the mistake of thinking that Apple's ObjectiveC runtime doesn't incur any overhead, it is a managed code solution itself, it's just that it compiles to native code rather than an intermediary bytecode.  Maybe one day Apple will ship LLVM intermediary object code... or another platform will.

 

(Well, NDK apps will require a recompile, of course).

post #79 of 221
What formosa said. I don't buy that the 32-64 bit distinction is important for smartphones. I do buy that Apple is in a unique position to have the whole lot work truly well in the long term -- decades forward -- on the same 64-bit system, and I buy the idea that having it all on the same system is a major advantage (although it really does beg the question of when Apple is going to incorporate touchscreens in their PCs). To take one example, the idea of being at an academic conference and being able to run serious statistical analysis on the fly on my cell phone to deal with a question in a panel is kind of cool, and the possibilities for seriously accelerating collaborative projects because of this are endless.
post #80 of 221
Quote:
Originally Posted by BigMac2 View Post
 

 

A roadmap is only prediction which doesn't translate into execution.  There is no working version of 64 bit Symbian and never will. 

 

Re-read what DED wrote. He said that no-one even predicted that there would be a move to 64-bit processors for smartphones.

 

EDIT: If you want proof, here's a presentation from ARM engineers written in 2011. ARM has been working on 64-bit CPUs since 2007 and one of the prime motivations is "a future need in ARM’s traditional markets" (e.g. smartphones, not servers).


Edited by RichL - 9/17/13 at 8:45am
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
AppleInsider › Forums › Mobile › iPhone › Inside Apple's 64-bit iOS 7 and the prospects for a 64-bit Android