TWO can play this 64-bit mobile game, says Samsung, crossly Samsung's next smartphone will feature a 64-bit processor, according to co-chief executive Shin Jong-kyun: he's keen to prove it's not only Apple who can stuff more register bits into a chip. Apple's latest flagship iThing, the iPhone 5S, features a 64-bit ARMv8 processor labelled the A7. The performance boost may not be …
Because the instruction set is more efficient and more compiler friendly than 32 bit ARM. Even if you're only doing 32 bit things, your code recompiled in 64 bit mode should be faster.
That and ARMv8 is much better at floating point math than its predissesor, which is worth having in many 32 bit program's also.
your code recompiled in 64 bit mode should be faster.
Normally 64bit stuff runs slower not faster.
Programs handle lots of pointers.
64bit pointers are twice as big as 32bit pointers
therefore the dataset for 64bit code is bigger than the dataset for 32bit.
Since we spend a lot of time moving shit around, moving bigger shit is slower and moving smaller shit.
Hence 64bit code is slower than 32bit code.
However, having 64bit datapaths mean you can move data faster.
The new 64bit architecture sounds like it has many advantages.
I don't know, but I suspect you can probably compile the code into 32bit mode while still getting the architecture advantages of the new chip. Therefore the new 64bit chip might prove fastest running new 32bit code.
I don't thins your suspicion is correct. Otherwise I do agree.
Most benefit is with graphic. What everyone seems to have missed is that Apple claims 2x speed gain with A7 compared to what's in iPhone 5 (A6). 2x GPU and 2x CPU activities.
But when Epic came up demonstrating their new game, at the same event, they said they got 5x the speed of iPhone 5. And they attributed that only to the 64-bit architecture. I'm not exactly sure how graphic calculations benefit from more bits. But the PowerPC G4 had a 128-bit altivec unit. And I don't remember so much about Altivec 2 if it ever was used or ever got to be 256-bit.
But for sure more bits, means better calculation possibilities.
"But when Epic came up demonstrating their new game, at the same event, they said they got 5x the speed of iPhone 5. And they attributed that only to the 64-bit architecture. I'm not exactly sure how graphic calculations benefit from more bits."
I suspect this was less to do with the bit count than with the increased register space (more and bigger registers), allowing for faster memory transfers.
But in terms of moving raw data, if a register is twice as wide, it can hold more in it (8 bytes vs. 4). Since the busses are also twice as wide, it shouldn't take twice as long to load 8 bytes onto a 64-bit register vs. 4 bytes onto a 32-bit one. Plus, 64-bit CPUs tend to have more registers than their 32-bit counterparts, meaning more transfer space, potentially meaning faster memory transfers.
But in terms of moving raw data, if a register is twice as wide, it can hold more in it
That's just the issue. When moving data a 64bit register can move 1 64bit pointer or 2 32bit pointers at the same time. That is why the 64bit code is slower. Note that I didn't say 64bit CPUs were slower. It used to be common practice on 32bit CPUs with 64bit FP units and 64bit datapaths to use the FP registers to do data moves, again because you could move twice as much data in a single operation.
I've not looked at the ARM instruction set, but if it can execute code in either 32bit addressing mode, or 64bit addressing mode and still use all the new CPU registers, it should be able to do lots of things faster than the old 32bit CPU, but it still doesn't necessarily need to be running in 64bit addressing mode (where you get pointer bloat). Again, I've no idea of the organisation of the ARM CPU's cache, but typically copying works faster when you vectorise the load and store operations and load a couple of cache lines into the CPU then store those cachelines out again. The increase in the register count will definitely help here.
My argument wasn't against using 64bit HW, it was against unnecessarily increasing the size of pointers, which you get when you use 64bit addressing but less that 4GB of address space.
No Druck, but I've written a lot of code on other 64bit CPUs, both PA and Itanium. I've also written code to use 64bit FP registers in 32bit processor to boost memory bandwidth of apps bottlenecking there. Back before 64bit CPUs became common place.
A quick glance at the ARM instruction set shows they've increased the number of available registers without increasing the size of the instructions. So at least one persons' theory as to why I might be wrong doesn't hold any water. I've not checked the addressing modes. So I don't know whether ARM has the equivalent of the W bit in the PSW.
But where you've got a 64bit CPU that can run in both 32bit address mode and 64bit address mode, you should try benchmarking application that fit inside the 4GB VAS and seeing what runs faster. My experience is that optimising pointer size is a valuable technique.
64 bit apps are faster, usually 20-30%. That however is one side of the double-edged sword. 64 bit apps require more memory to run, so we should expect to see RAM jumps in specifications in the future (bearing in mind there's been a fire at one of the fabrication plants expect memory to cost more too)
A very valid point with ARMv8 however.
It's not just a case of adding 64bit here. To get a solid speed boost out of the ARM processor, apple would want to move to the new ARMv8 instruction set. That has double the number of registers, which helps a lot. It's also 64bit, which helps in many cases too (ignore anyone saying it only benefits anything with >4GB of RAM, they're arse talking).
So it's more a case of them wanting ARMv8 and getting 64bit as part of the bundle I suspect.
It benefits not much in many cases presuming you have the same number of registers etc in both modes.
If you cannot use all the registers in 32 bit / thumb / 64 bit then it goes against everything arm has ever tried to do. (And makes it worse than mips or sparc and I think powerpc).
The whole thing was you write the none performance critical stuff in thumb and the performance critical stuff in arm code.
(If you can do that but they choose not to due to wanting backwards compatibility then that is ok.)
This post has been deleted by its author
"does a mobile phone need a 64 bit processor? Someone? Anyone?"
It probably doesn't need to be 32 bit either. For that matter, it doesn't need a big colour screen, just a line or two of text and some buttons.
But then, none of the fancy other toys would work and it would just be a phone.
People want toys in their phone. Like a camera, a flash light, some games to pass the time while on the big white chair, something to check facebook on, etc.
The benefits of the iPhone 5S 64-bit environment (64-bit A7 processor, running 64-bit apps, on 64-bit iOS 7) are HUGE!!!
There is an article on All Things D today that explains what a radical improvement this is. Here are a few quotes from the article:
“The fact that the A7 has twice as many processor registers means that more operations can occur without the processor using main memory, which is slower to access,” Carl Howe, VP of research and data sciences at the Yankee Group toldAllThingsD. “This means for that, for some codes, the A7 will be twice as fast (or faster, depending on how many memory accesses the original code had) to run code, because the processor doesn’t have to use main memory as much.”
“The ARMv8 instruction set is clean-slate approach with many improvements. Even without 4GB of RAM, the A7 should make it easier to build larger applications like PC-class games and programs. Apps can now become real desktop-class programs and games.”
"with the 64-bit A7, Apple has made it possible for developers to take the 64-bit apps they’re written for the Mac and bring them to iOS 7 with relative ease. And that is a huge benefit"
“This will not be true with Android, by the way. The Android Java app and native app environment will need support from Oracle, who owns the Java environment as well as 64-bit support from the Android kernel. Android has a lot more moving pieces to coordinate, and will take longer to go to 64-bit.”
So much wrong with the masses of text you copy and pasted .. but let's bash the silliest parts to save time.
"with the 64-bit A7, Apple has made it possible for developers to take the 64-bit apps they’re written for the Mac and bring them to iOS 7 with relative ease. And that is a huge benefit"
Those 64bit apps on OSX being for AMD64 and not ARMv8..
“This will not be true with Android, by the way. The Android Java app and native app environment will need support from Oracle,"
Dalvik isn't a JVM. It doesn't run Java byte code.
"who owns the Java environment"
Dalvik isn't a JVM. It doesn't run Java byte code. Android's class library is based on Apache Harmony...
"as well as 64-bit support from the Android kernel."
Oracle are the main developers of Linux? Who's this Linus guy that the register like write multi page articles on when he uses "naughty words" in a single paragraph email then?
"Android has a lot more moving pieces to coordinate, and will take longer to go to 64-bit.”
I bet the original author couldn't name the pieces that would take time to coordinate...
“This will not be true with Android, by the way. The Android Java app and native app environment will need support from Oracle, who owns the Java environment
I'm not sure where you've been for the last few years while Snorable and Google fought this out in court but the Java in Android has nothing to do with the Java from Snoracle. This has mightily pissed off Larry the yachtsman, but the judge through out their case. Pity because if Oracle had proved that you can own an API, then they'd have owned every cent they ever earned to Big Blue.
This is horse manure. Twice the registers doesn't mean twice the speed. What's happened with past architectures is a 20-30% increase in speed. Also I don't see how Oracle need to get involved as Google run dalvik which is it's own VM and Java->Dalvik compiler.
Out of interest is there a 64-bit compile of Android?
Concerning the quotation from the article giving the advantages, why so many down votes? Do they reflect Android bigotry, knee-jerk anti-Applism or reasoned disagreement with the arguments, that the voters are unable to express in clear, reasoned replies in this thread?
One can assume that Apple has not wasted time and money on pointless hardware design and manufacture, plus consequent software work, the time of expensive, highly skilled staff and so on just to put out some sales line that all the brilliant engineers reading The Register will poo-poo at once because they all know so much better.
I shall be fascinated to read the real reviews once the 5s is available to genuine engineers for benchmarking, new app programmes and so on. Till then, to use an Americanism, put up or shut up.
If you are a Samsung fan, I can see your problem; but again, I doubt that Samsung would be so quick to promise their own version if they too could not justify it in engineering terms and could not achieve it realistically using either Android or this fabled new Linux O/S they are said to be developing. They clearly believe in the benefits of Apple's development and I have more faith in and respect for their judgement than that of the nay-sayers in these columns. After all, they appreciated the cleverness and achievement of Apple with the iPhone and paid it the highest compliment, then went on to use that experience to develop their own ideas. This is a genuinely sensible and good strategy followed by every successful business.
"Apps can now become real desktop-class programs and games."
As if Apple would allow for their tablets and phones to fight with their already struggling desktop-computers/market. Oh please.
This will have no advantage to the usual app-crazed zombie who will stare themselves blind on the new psychedelic colour palette.
Hmmm... I which Harmattan was still around. A true innovative OS on a true innovatie UI. This is all smoke and mirrors.
Why oh why do people need to complain about any kind of progress?
have you also asked the following at some point?
Why oh why do people need to fly when they can get on a boat?
Why oh why do people need to drive faster than 5 miles an hour?
Why oh why do people need a flat screen TV when they could go to the cinema?
Why oh why do people need to send an email when they could use the post or telephone?
Why oh why do people need to a camera, email, colour screen on their portable telephone?
It does smack of ignorant playground computer/console bragging.
Like the megadrive printing '16 BIT' on the front. Or the argument that the N64 was better because it was 64 bit (but utterly clobbered by the storage limitation of cartridges).
The 64bit ARMv8 core's that the A7 chip uses is licensed from ARM. Samsung don't need to "copy" Apple because they will do the same as every other ARM licensee and license the cores for use in future Exyonis SOC's or use whatever Snapdragon chip also uses ARMv8 cores. You clearly are a moron.
WRONG. Apple licensed the ARMv8 architecture, the core is their own design. It is NOT an A53 or A57 core.
Samsung is also working toward designing their own ARM cores like Apple (and Qualcomm) are doing. The current Exynos CPUs are using ARM designed cores so they are comparable to the Apple A4 and A5, where Apple designed the SoC but dropped in ARM cores licensed from ARM, Ltd. It is quite possible Samsung's 64 bit ARM will be their own core, rather than using the A53 or A57.
"Samsung is also working toward designing their own ARM cores like Apple (and Qualcomm) are doing. The current Exynos CPUs are using ARM designed cores so they are comparable to the Apple A4 and A5, where Apple designed the SoC but dropped in ARM cores licensed from ARM, Ltd. It is quite possible Samsung's 64 bit ARM will be their own core, rather than using the A53 or A57."
No argument there. Odds are Samsung's 64-bit CPU will be an ARMv8-based Exynos SoC.
>lets face the facts; Apple user's are not smart people
Yeah, judging how smart people are for their aptitude in a specific area of knowledge... that's clever. There's a fair chance that your father knows more about tuning motorcycles for speed, or carpentry perhaps, than you do - that doesn't by itself make you a moron.
I'd rather my doctor be smart at medicine, I certainly won't consider her to be an imbecile for choosing an easy-to-use phone. Messing around with Android ROMs might be fun and all, but I can appreciate that it not to everybody's taste. Some people paint, create beautiful gardens, bake great delicious cakes or play musical instruments instead.
4G Byte direct addressing and 16G Byte via PAE.
Even a 64G byte phone / PC / Tablet probably only needs 4G byte direct addressing. The rest can be "filesystem".
64 bit in some circumstances increases code size and no real increase in performance. Any performance increase is usually other changes not the increased addressing (which isn't physically much more than PAE can do on a 1998 32 bit PC).
Really twice the battery life would be better.
P.S. It's not about better Floating point but 64 bit Integers, which often means you can avoid slower less accurate Floating point. 80bit floating point has rounding errors, hence the "currency" type in VB which was really a 64 bit integer.
64 bit ints would help Android a lot, thanks to the casual use of longs all over the Java framework and apps. ARM8 also has double the registers and that should also boost the JIT, especially on virtual register heavy Java/Dalvik bytecode. Sounds well worth adding to Android, even if you ran Dalvik VM 64bit and everything else 32bit it would still give a significant boost.
Not sure there's a problem with code size, 64bit mode still uses 32bit wide instructions so there shouldn't be much code inflation to hurt bandwidth or cache.
Have to check how improved Neon is, that could make a difference to AV and in turn battery life.
There is concern when it comes to pointers, which would have to be twice as big. Also, data alignment could be more costly for small values, as not accessing an aligned memory space usually incurs an access time penalty. So there are tradeoffs.
Another thing I've been thinking about is the increased address space could play into increased memory mapping of devices and so on. Would there be any benefit to, say, mapping the internal flash or some of the other internal devices (I suspect many of them are already mapped in the 32-bit space as few devices go beyond 2GB RAM).
>> n their Atrix Android phone a couple of years ago.
>Clearly an astounding, robust and popular success.
Nah, Motorola used a shitty Authentec scanner - they're hopeless - scratch a finger, do the washing up and you're not yourself.
Apple's scanner will have been painstakingly developed by world class innovateers in the labs of cuppawotsit, they won't make the same mistake as Moto...
They have all the source for Android so there is no need for them to wait for Google to do anything.. In the past vendors have donated bits to Android (I.e. NXP donating the NFC stack..) so it's not like Samsung couldn't donate any changes they do for ARMv8 support back to AOSP. There are unofficial ports of Android like the one to the SuperH chips which were done without Google too.
Or.. they could just ship a 64bit kernel with a 32bit userland running on it for now.
Independently adding their own code to the underlying OS would mean it was no longer Google certified (or approved, or whatever they call it) which would mean in turn that they couldn't bundle the google play app and other google toys, which would then mean they no longer have that google ecosystem to offer to the punters.
>Independently adding their own code to the underlying OS would mean it was no longer Google certified
That's not how the certification works. There is a test kit.. if your Android build passes the test kit you can ship the Google proprietary apps like the Play store.
If "adding their own code" to the underlying OS would mean they couldn't pass the test kit then there would be no Android device in existence with Google's apps as every single one needs some changes to the code ( changing some baked in properties, fixing bugs that are triggered by the hardware, adding support for hardware that AOSP doesn't have support for internally, replacing all of the graphics with horrible custom versions)... oh and Google don't ship a standard Android kernel that just works magically on every different SoC out there.
Ay, ay - I spy more Android fragmentation in the offing. Google have their priorities, and (even though they have motorola now) they don't extend to consumer electronics, really.
If Samsung are underhanded enough to put always-on binaries in place to fool benchmarks, they're stupid enough to make a 64 bit hardware architecture and only run a 32-bit OS on it.
No, that 640K was always stupid. The competing "real" 16 bit platforms had 1M to 16M. The 8088 wasn't a "real" 16 bit chip as it could only address 64 K byte without changing the segment register.
The PC Memory map could have been done better too. Purely IBM / Intel / MS stupidity. It's not comparable between 32bit CPUs able to address physical 4G to 16G byte and 64 bit CPU with up to 48 Gbyte physical memory.
Of course virtual memory isn't the same thing.
Also there is no direct connection between general CPU bit width and addressing as otherwise 8 bit CPUs could only address 256 bytes but they use 16 bit to 20 bit addressing registers for 64K to 1M byte of RAM.
The Intel 80286 used in the AT was the first "real" 16 CPU in IBM PC, but DOS still used it much like an 8 bit CPU. You needed to run UNIX on it to address more than 640K or 1M Byte, 24-bit address andup to 16 MB of RAM without segment registers. With 8088 and 8086 you had 16 bit address and overlapping 16 bit segment register for 20 bits (1M)
now I'm curious: if the 8088 wasn't a real 16 bit chip due to it's need to change the segment in order to address it's full 1MB, how did the 'real' 16 bit chips address 1-16MB with only 16 bits of register space? is the 8088's segment register really that different from RISC style register-offset addressing?
I think you should apply to Apple for a job as their head of engineering design and architecture. You are clearly so much more knowledgeable, experienced and simply better than they are.
I look forward to your razor sharp critiques of Samsung, HTC and the rest as they follow suit.
Oh, where can I buy the mobile that you designed? I enjoy a good laugh.
While there is a lot of debate as to whether Apple needs or can justify a 64bit ARM chip in their smartphone it is obvious that this will soon be replicated in the iPads on their next rollout.
While there is the argument that you need more than 4 gig of RAM to see the benefit of a 64bit chip which is unheard of for a phone or tablet I just wonder if they are doing this to test it before putting it into their Macbook Airs in the future. There are rumours that they are testing a bigger sized iPad, so maybe it's a 13 inch Macbook Air running a 64 bit chip that dual boots OS X and iOS with a retina display and a touch screen?
Maybe they've seen what Microsoft were attempting with the surface and have thought hmmm we can refine this. I honestly wouldn't put it past them
Thank you Larry, I'm glad some people here actually come here to speculate about where things might be heading in the future, rather than just bashing one brand or another.
Personally, I'd like a headless laptop in small form factor that use a tablet (or two, why not?!) as its display, but I don't think something like that will come from Apple.
But it's not like the ipads are pushing the RAM limits of 32-bit now, so if RAM is so important and you're expecting them to whip out a 4GB device, why don't they have 3GB devices out now? An ipad mini is on 0.5GB, compared to the Nexus 7's 2GB. If this news is important because it could allow more RAM, why isn't there the praise and media hype for the devices already shipping with 2-3GBs today, I wonder?
They might put it in their tablets or laptops in future, but it's just as true that we'll see 64-bit on Android devices when they ship with more RAM.
It would be interesting if they try a switch to ARM, but they have the same problems of breaking compatibility that MS has had - and with the increased battery of Haswell, and the upcoming increased performance of low cost Bay Trail, one can already get 64-bit with Intel just fine. Indeed, I was wondering whether the existing Intel Atom CPUs are 64-bit - surely there have already been Android phones and tablets that have 64-bit CPUs, namely the x86 ones? Again it's a bit irrelevant with 32-bit software and lower amounts of RAM, but that's true of the iphone too.
But it's not like the ipads are pushing the RAM limits of 32-bit now, so if RAM is so important and you're expecting them to whip out a 4GB device, why don't they have 3GB devices out now?
They might put it in their tablets or laptops in future, but it's just as true that we'll see 64-bit on Android devices when they ship with more RAM.
It would be interesting if they try a switch to ARM, but they have the same problems of breaking compatibility that MS has had - and with the increased battery of Haswell, and the upcoming increased performance of low cost Bay Trail, one can already get 64-bit with Intel just fine. Indeed, I was wondering whether the existing Intel Atom CPUs are 64-bit - surely there have already been Android phones and tablets that have 64-bit CPUs, namely the x86 ones? Again it's a bit irrelevant with 32-bit software and lower amounts of RAM, but that's true of the iphone too.
Apple went from PPC to Intel with ease and I'm sure Jobs said they'd always had a version of OS X running on Intel all through it's life. Yes there are performance increases with Intel and power saving benefits, but that leaves Apple at the mercy of the Intel road map and purchasing from intel...
The beauty of ARM is it's their design specifications made to their criteria and if they start shipping ARM processors in the Macbook Air they will save a lot more money due to the cost of dealing with Intel and getting someone in the far east to ramp up production of chips they are already making for the iPad and iPhone....
There is no real reason for the iPhone to have the 64 bit chip other than the fact that the iPad will have it and Apple wouldn't want the iPhone looking 'weaker' with a 32bit chip when the iPad has 64bit.
I honestly think the cost benefits will see it in the Macbook Airs in the near future and even if the new iPad doesn't have 4 gig of RAM or anywhere near it it makes sense for Apple to get the production process going and iron out all the kinks. I've no doubt they'll be testing this 64bit ARM processor on OS X already. Sooner or later they will do a hybrid and a dual boot Macbook air makes sense. The iAir maybe?
First off, it appears that whatever happens, the fanbois will only ever praise something if Apple does it first, which in this case, is the 64-bit thing. Should Samsung have done it first, they would have derided it as unnecessary. Now that Apple HAVE done it first, everyone else will now 'merely be copying them'.
He's been dead a long enough time, but it appears Old St. Steve is still spinning fast enough in his grave to keep the RDF fully powered up for another 5-6 years.
So... 64-bit CPUs in a phone. Practical? Who knows. Nice to have? Probably. Essential to the modern world? Not really, no. When all the world+dog seems to do on these things is text, call, peruse Farcebook and the like, and listen to music... very few people will ever seen any real-world benefits to this. That said, progress happens in odd ways. Just because it's no good to us right now, doesn't mean we won't be seeing things taking advantage of it later on. I'm just not convinced we're at a point where we need full desktop power in a battery limited device.
About the only real benefit to anyone is the manufacturer of these chips. If they can shift more of their designs to 64-bit, and drop the older architectures, they'll have less variants to keep track of, and can focus more on improvements and the like.
>There was a time when people didn't see the need for mobile phones outside of very specialized areas.
I saw someone wearing a pager in the pub last week- I didn't realise those networks were still running! (He was on-call; should a British nuclear power station produce an 'unrequested fission surplus', he will be part of the team that comes up with solutions - it being assumed the engineers and scientist on the affected site might be in headless-chicken mode.)
Another drinker in the pub, now retired, used to have pager when he was a GP on-call. He welcomed the advent of mobile phones, because unlike pagers they didn't get reception in the pub in the next village!
Doesn't Samsung make the iphone CPUs, anyway? Someone that isn't Apple. And it's ARM who design them. I'm sure the Android manufacturers will add 64-bit CPUs when it's required - they're going to be the devices hitting 4GB RAM long before the iphone devices.
Obviously 64-bit is a useful next step, but it hardly matters if one company is first a few months early, when none of the devices are taking advantage of it. If in a few years' time, Apple devices are all on 4-8GB, with Android crippled at less than that, it will be a problem - but there's no evidence this will happen. Why aren't Apple being criticised now, when their devices have far less RAM than the competition? (My Nexus 7 has 2GB RAM compared to the Ipad Mini's 512MB.)
I don't see what there is to brag about - what about first phone with 1GB RAM, or 2GB RAM, or Full HD screen? Android devices get a hardware "first" with every release, but it's simply not news. Meanwhile, we have an iphone "first" that happens once every 6 years, and it's treated as revolutionary.
"but Samsung is dependent on Google to push Android along and the world's biggest advertising agency has shown no inclination to go that way."
So with 3GB devices already here, Google have no plans to move to 64-bit? I doubt it. They just don't make a big fuss about it, that's all.
AFAIK, most if not all of them are designed by Apple hence the 'A' numbering on them. Samsung is just one of the fabs used to produce them. ARM produce a reference design and companies like Samsung, Apple etc take that and then add bits to it that turnes them into the SOC designs that then get made and put into your phones/tablets.
At the risk of being down voted into Micronokia hell, we seem to have
1) Apple Innovating again - but it is pretty small step but at least they seem to be the 1st to put a 64bit cpu into a phone which will be galling to the die-hard fandroids that predominate here these days.
2) Samsung saying - I want some of that, let me copy it or maybe they are just jealous?
Whatever happens we will still have
Fan type 1 saying, my 64bit CPU is better than your's
Fan type 2 saying, no it isn't.
Reminds me of the playground at school a wee bit...
Perhaps a bit of growing up should happen.
now I'm off for a beer and a wedding.
You're correct that all the 'A' ones are designed by Apple, but the A4/A5 are different than the A6/A7. In the former, Apple used standard ARM cores and only designed the SoC. In the latter, they designed the core themselves as well, rather than using a standard ARM core (i.e. A9, A15, etc.)
Apple is now beyond the point of "take that [ARM core] and add bits to it", they have no use of for ARM designed cores any longer. Qualcomm similarly designs their own ARM cores (Krait) Samsung has not yet done so, but they have ARM architectural license that enables them to do this, and have been assembling a team capable of designing CPU cores so I wouldn't be surprised if when they do produce a 64 bit ARM it will be their own design rather than using ARM's A53 or A57 core.
Samsung does fab all of Apple A* CPUs (the A7 isn't confirmed for certain yet, but it is likely) The relationship is similar to if Apple engraved printing plates for $1 bills and left it to Samsung to operate the presses that use their plates to put ink to paper.
Just pondering here for a moment, the art of the possible. If Sammy adds 64bit to their CPU range, but the Android OS stays with 32 bit for the time being; given enough time and resources, could it be possible to make the underlying hypervisor split two 32bit instances and run separately with access to their own 'virtual' resources like RAM? A dual identity phone has been mooted for some time to allow separation of work and home life - I wonder if this is even slightly feasible.
As a smartphone user, I couldn't give a stuff about all of this "my bus is bigger than yours" marketing guff. Just give us more battery life. Please. I don't care if you do it with 64 bits of a bus or fragrant tufts of camel hair, just make the damn phone function for a week between charges like the good old days of Nokia. (Kids: You won't remember)
As I'm also an agnostic, I'm bitching at Apple, Samsung, Google and everyone else. Please just get your act together. Copy each other for all I care. Just do it.
Where's Ballmer when you really need him? "Battery Life, Battery Life, Battery Life ....."
(And if you're wondering, I currently get 2+ days out of my smartphone. It's simply not good enough)
They did provide improved battery life, which is quite amazing given the additional performance the A7 delivers.
Having said that, if you want battery life of over 2 days, then your expectations need to be managed. Not going to happen until battery technology improves significantly, or the weight of your phone doubles.
"Didn't Motorola have a range of phones, with some variants having big batteries? (US-only, IIRC)"
Not just US. Back in the 90s, in Islington (during Islington's brief but doomed experiment in being the media luvvie coolest place in the galaxy) I had a V series flip phone (66 IIRC), which had two backplates - one for the bog standard 'It'll last about a week on one charge' slim battery, the other for the 'How many weeks will you be in the wilds of Borneo without access to leccy?' giant scary one.
I seem to remember that if you used the bigger one it would no longer fit in the cute little leather belt pouce and you had to resort to keeping it in your pocket.
Ahhh happ days
I get two days from a two year old 4s, in normal use. If I waste several hours of my day using it to browse the internet, read news, send emails, SMS, photos and so on, then I knock it down to a day and a half. If I am taking part in real life, e.g. when busy at work, on an active holiday (or simply abroad where data roaming would cost more than the holiday) I get three or even four days out of it. Perhaps I have just got a freak battery.
""“This will not be true with Android, by the way. The Android Java app and native app environment will need support from Oracle, who owns the Java environment as well as 64-bit support from the Android kernel. Android has a lot more moving pieces to coordinate, and will take longer to go to 64-bit.”""
This is nonsense, though. Oracle does no work on Dalvik, despite it being basically Java. This is a clean room implementation of (basically) Java. Nothing in Java itself ties it to 32-bit, and in fact there are 64-bit Java implementations shipping right now. Dalvik will need work, since it uses some JIT (Just In Time) compiler tech, it will not currently emit ARMv8 code even if recompiled for ARMv8 (although the compiler and such itself would run a little faster.) The Linux kernel supports 64-bit ARM too. Even if Dalvik was kept 32-bit, each app runs in it's own copy of Dalvik, so you'd be limited to 3GB or so per app rather than 3GB for the complete system (although presently the point of a 64-bit CPU is not for more RAM.)
As for userland, other than Dalvik, basically everything else on the phone is not CPU intensive (and only runs at bootup or special circumstances) so it wouldn't hurt if it stayed 32-bit (although rebuilding it for 64-bit should be trivial.) For NDK (native development kit), there are very few libraries included with Android so having to have both 32-bit and 64-bit versions is not a big deal.
64bit was expected to be on mobile phones in 2014. Apple just came in ahead of the predictions and of course Samsung and others will follow.
"ARM goes 64-bit. (October 31 2012)
The Cambridge-based chip designer has shown is 64-bit architecture that will power the next generation (and beyond) of smartphones and tablets, while also providing Intel Corporation with competition in the servers market."
(October 30 2012)
"The Cortex A53 and A57 are ARM's latest and greatest mobile chipset designs, another important leap in its quest to get its mobile chipsets closer in performance to desktop CPU. Designed for single core or multi-core configurations, the products made from these designs will be the first mobile chipsets to support 64-bit processing. This puts ARM in a prime strategic spot as tablet devices are popping up with the intention of replacing a laptop. Apple, Texas Instruments, NVIDIA, Samsung, and plenty of other companies use ARM's reference designs for their own CPUs. While both are powerful, the A53 is designed with efficiency in mind, while the A57 is all about performance. The added power, along with ARM's experience in optimizing the power consumption of its chips could give the company an advantage over the likes of Intel, who is relatively new to the mobile CPU game. But don't get too antsy: these things ain't comin until 2014. "
Since SAmsung is making apple's chip, they'll obviously be able to make a copy and put it in a smartphone but just like you can drop an 800-horsepower engine into a VW Beetle but if you don't upgrade everything around it, what's the point, The ONLY software that will be 64-bit in the next samsung phone will the benchmarking software that runs at super clock 64-bit speed - nothing else. (pretty much the same as their current smartphones - only the special benchmarking software runs at an overclock speed - everything else runs on java based android).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
