Unless the device has more than 4GB or memory - it is indeed just marketing fluff (yes the chip has other advantages, but that's not what's being pushed as being so great - it's just that it's a 64-bit chip).
But so what? Apple is the only company where marketing plays up their products to a simplistic consumer?
Apple pushed the message of the sheer speed difference 64 bit makes, a claim borne out in many benchmarks where the A7 excels even against those who cheat on the scores.
If Apple set itself up for people to not care about these specs (ex. how much RAM my iPhone has, etc.) then it should live by those expectations. I could care less that the new iPhone has 32 or 64-bit processor in it. Focus on showing me what this phone can do that others don't and don't even mention the 64-bit chip. I'm sure people will find out how many bits it is. But I guess when you only have so many updates to your mid-cycle, even Apple likes to make a big deal of specs.
10fps burst mode on the 5s camera vs HTC One 4fps and Galaxy S4 6fps.
There's one thing for starters.
So what you think of the minor iterative upgrade to the Note 2, the super expensive Note 3?
It's amazing how outdated those specs are now. I suppose, for me, part of it is that the G5 tower design is still be sold today and it'll still look great once the next Mac Pro launches.
It amazed me to see how near the A7 specs is from the first G5, keep in mind the G5 needed a 1 kilowatts power supply and never made into a mobile platform. This is why Apple have been "forced" to switch to Intel, their PowerBook at that time was stuck with G4 for too long and unable to evolve any further.
Actually "Cyclone" the A7 does both 32bit and 64bit address busses. It supports the ARM AAarch32 and ARM AArch64. Because of ARMv8's new ISA it can do both on one chip.
You're confused. AArch32 and AArch64 are ISA-- instruction set architectures. And yes, the A7 does support both. Which means it can run code built for 32 bit.
Completely irrelevant to my point. These are not "address busses". They are internal to the core. The Address lines are the physical connections off chip to address locations in RAM, which is offchip (Though it may be inside the same multi-chip package). It's unlikely these are 64 bit, which is why all the talk about the need to go to 64 bit only to address more RAM is asinine.
You're confused. AArch32 and AArch64 are ISA-- instruction set architectures. And yes, the A7 does support both. Which means it can run code built for 32 bit.
Completely irrelevant to my point. These are not "address busses". They are internal to the core. The Address lines are the physical connections off chip to address locations in RAM, which is offchip (Though it may be inside the same multi-chip package). It's unlikely these are 64 bit, which is why all the talk about the need to go to 64 bit only to address more RAM is asinine.
Very true. I believe that since A4 the internal data bus between memory and ARM cpu has been 64-bits wide. I also recall that even on 64-bit ARM core the address bus only goes up as far as 48 bits wide and can be configured for lower.
Speaking of stupid....obviously you missed where I said it's being marketed by keying in on the fact it's 64-bit as if by that very virtue it's all super awesome.
Speaking of stupid....obviously you missed where I said it's being marketed by keying in on the fact it's 64-bit as if by that very virtue it's all super awesome.
Like I said in a later post, many are confused between what Apple really said about the A7 during their keynote and how its been assimilated by the media.
Speaking of stupid....obviously you missed where I said it's being marketed by keying in on the fact it's 64-bit as if by that very virtue it's all super awesome.
Since we're talking about ARM the fact that it's 64-bit is super awesome. You really should read the info in the links BigMac2 supplied.
I am actually eagerly anticipating Android's transition to 64-bit computing, if only to see if the industry can pull it off as seamlessly as Apple supposedly is attempting to.
First, Google has to release a 64-bit version of Android.
Based on my understanding, OEMs and app developers have to support with 64-bit processors and apps of their own. This represents a catch-22 scenario. The various OEMs and telcos are already having a hard time ensuring that OS updates cascade down to the end user in a time fashion (if at all). After so many years, just under 50% of users are reportedly running 4.0 and above. Only Samsung seems like they have the resources and financial muscle to pull this off (their phones would be the first to run 4gb of ram, but I doubt their touchwiz would properly support it anyways).
Likewise, if I were an app developer, and I didn't think there are enough users on 4.4 (assuming it runs 64-bit) to justify me expending additional time and resources supporting 64-bit, then I simply won't. Why should I, when there are enough buyers still on 32-bit Android phones to market to? Nor am I going to actually code an app that requires the full 4gb of ram to run properly, because most phones would still be on 2gb of ram or less.
And you want to further fragment this with both 32-bit and 64-bit phones?
Apple may not be new with their 64-bit processor, but I think they are actually trying to force Android's hand here. Making OEMs rush to incorporate it into their phones, without first taking the time to ensure their products are properly optimised or think if it is really necessary.
Likewise, if I were an app developer, and I didn't think there are enough users on 4.4 (assuming it runs 64-bit) to justify me expending additional time and resources supporting 64-bit, then I simply won't.
You do realize that Java application code is completely independent of the processor architecture. As a developer there is nothing you need to do to support 64 bit. (Unless you have some very specific native interface code in your app, which is not very common)
All apps compile to machine independent java byte code.
Googles 64-bit Dalvik VM has the task at runtime to convert the byte code into 64-bit processor specific instructions.
Quote:
After so many years, just under 50% of users are reportedly running 4.0 and above
Form latest reports 48% of android users are on the latest android JellyBean (4.1+) which was released in July 2012. I'm not sure what you mean by "so many years"
You're not stupid, so what else drives your need to look stupid ?? Perhaps some pressure from a customer ... perhaps a company whose name starts with ... S ... a ... m ... s ... u ... n ... g ??
You know well that speaking to developers of high performance apps and games would illuminate your deceit. Surprised you'd put your personal rep at risk for something so transparent
You do realize that Java application code is completely independent of the processor architecture. As a developer there is nothing you need to do to support 64 bit. (Unless you have some very specific native interface code in your app, which is not very common)
All apps compile to machine independent java byte code.
Googles 64-bit Dalvik VM has the task at runtime to convert the byte code into 64-bit processor specific instructions.
Form latest reports 48% of android users are on the latest android JellyBean (4.1+) which was released in July 2012. I'm not sure what you mean by "so many years"
This is not entirely true, java source code is alway 32 bit. Dalvik byte code can run on any plateform compiled for sure, but this is where Qualcomm Rep is right about. Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm, and will have very little performance gain (about 3% according to this site).
This is not entirely true, java source code is alway 32 bit. Dalvik byte code can run on any plateform compiled for sure, but this is where Qualcomm Rep is right about. Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm, and will have very little performance gain (about 3% according to this site).
That is the same for pretty much any 32-64 bit transition where the chip architecture doesn't undergo a major transformation. With the vastly optimized instruction set of armV8 you are going to get a similar performance boost that A7 got, just by virtue of the streamlined instruction set.
That is the same for pretty much any 32-64 bit transition where the chip architecture doesn't undergo a major transformation. With the vastly optimized instruction set of armV8 you are going to get a similar performance boost that A7 got, just by virtue of the streamlined instruction set.
Not true, DalvikVM is a 32 bit register base virtual machine, even compiled on a 64 bit plateform Dalvik virtual processor registers are still 32 bit only. with a native compiled language like C or C++ for example when you declare an INT it will be 32 bit wide when compiled on a 32 bit platform and 64 bit wide on a 64 platform in java INT are always 32 bit. Mike Ash article explain where Apple being in control of their own hardware and IDE can squeeze all benefits the A7 can gives.
Not true, DalvikVM is a 32 bit register base virtual machine, even compiled on a 64 bit plateform Dalvik virtual processor registers are still 32 bit only. with a native compiled language like C or C++ for example when you declare an INT it will be 32 bit wide when compiled on a 32 bit platform and 64 bit wide on a 64 platform in java INT are always 32 bit. Mike Ash article explain where Apple being in control of their own hardware and IDE can squeeze all benefits the A7 can gives.
It's pretty much been established that moving from 32 to 64 bit compilation will only result in about a 6% performance improvement. It has been generally agreed here and in most of the tech press that the major improvement in A7 was not the 64-bitness per se, rather the move to a much more efficient instruction set and additonal core functions like crypto. Any application that compiles for that instruction set, even the DalvikVM can take advantage of that.
Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm, and will have very little performance gain (about 3% according to this site).
Wouldn't the VM itself be able to run faster once it's ported to ARMv8? I thought one of the main benefits of the abstraction layer afforded by the VM is that, at least in theory, the VM does all the hard work of tailoring programs to a specific architecture. For example, it's the VM's job to decide how to actually execute AES bytecode. Once Dalvik is ported to ARMv8 it should automatically run AES bytecode using the new AES hardware instructions with no input required of the program developers.
It's pretty much been established that moving from 32 to 64 bit compilation will only result in about a 6% performance improvement. It has been generally agreed here and in most of the tech press that the major improvement in A7 was not the 64-bitness per se, rather the move to a much more efficient instruction set and additonal core functions like crypto. Any application that compiles for that instruction set, even the DalvikVM can take advantage of that.
I wonder how an apps developed on a 32 bit VM can tap all benefit of a 64 bit platform. Apps running in a VM are stuck with the VM limits (8-16 bits opcode, 32 bits registers for DalvikVM).
Wouldn't the VM itself be able to run faster once it's ported to ARMv8? I thought one of the main benefits of the abstraction layer afforded by the VM is that, at least in theory, the VM does all the hard work of tailoring programs to a specific architecture . For example, it's the VM's job to decide how to actually execute AES bytecode. Once Dalvik is ported to ARMv8 it should automatically run AES bytecode using the new AES hardware instructions with no input required of the program developers.
True, the VM itself would run faster once ported to ARMv8 in either AArch32 or AArch64 ISA, but without major revision of the DalvikVM, virtualized apps is still running in a 32 bit environment only.
True, the VM itself would run faster once ported to ARMv8 in either AArch32 or AArch64 ISA, but without major revision of the DalvikVM, virtualized apps is still running in a 32 bit environment only.
Why a major revision? There are plenty of 64bit jvms out there, I imagine that the dalvik switch to 64bit would be a fairly straightforward engineering task. It would have to be done in any case.
As far as java code is concerned, an int is always 32 bits and and a long is always 64. It doesn't matter whether the jvm is 64/32.
Comments
Unless the device has more than 4GB or memory - it is indeed just marketing fluff (yes the chip has other advantages, but that's not what's being pushed as being so great - it's just that it's a 64-bit chip).
But so what? Apple is the only company where marketing plays up their products to a simplistic consumer?
Apple pushed the message of the sheer speed difference 64 bit makes, a claim borne out in many benchmarks where the A7 excels even against those who cheat on the scores.
If Apple set itself up for people to not care about these specs (ex. how much RAM my iPhone has, etc.) then it should live by those expectations. I could care less that the new iPhone has 32 or 64-bit processor in it. Focus on showing me what this phone can do that others don't and don't even mention the 64-bit chip. I'm sure people will find out how many bits it is. But I guess when you only have so many updates to your mid-cycle, even Apple likes to make a big deal of specs.
10fps burst mode on the 5s camera vs HTC One 4fps and Galaxy S4 6fps.
There's one thing for starters.
So what you think of the minor iterative upgrade to the Note 2, the super expensive Note 3?
It's amazing how outdated those specs are now. I suppose, for me, part of it is that the G5 tower design is still be sold today and it'll still look great once the next Mac Pro launches.
It amazed me to see how near the A7 specs is from the first G5, keep in mind the G5 needed a 1 kilowatts power supply and never made into a mobile platform. This is why Apple have been "forced" to switch to Intel, their PowerBook at that time was stuck with G4 for too long and unable to evolve any further.
Actually "Cyclone" the A7 does both 32bit and 64bit address busses. It supports the ARM AAarch32 and ARM AArch64. Because of ARMv8's new ISA it can do both on one chip.
You're confused. AArch32 and AArch64 are ISA-- instruction set architectures. And yes, the A7 does support both. Which means it can run code built for 32 bit.
Completely irrelevant to my point. These are not "address busses". They are internal to the core. The Address lines are the physical connections off chip to address locations in RAM, which is offchip (Though it may be inside the same multi-chip package). It's unlikely these are 64 bit, which is why all the talk about the need to go to 64 bit only to address more RAM is asinine.
You're confused. AArch32 and AArch64 are ISA-- instruction set architectures. And yes, the A7 does support both. Which means it can run code built for 32 bit.
Completely irrelevant to my point. These are not "address busses". They are internal to the core. The Address lines are the physical connections off chip to address locations in RAM, which is offchip (Though it may be inside the same multi-chip package). It's unlikely these are 64 bit, which is why all the talk about the need to go to 64 bit only to address more RAM is asinine.
Very true. I believe that since A4 the internal data bus between memory and ARM cpu has been 64-bits wide. I also recall that even on 64-bit ARM core the address bus only goes up as far as 48 bits wide and can be configured for lower.
Edit>> Corrected 48 bits PA size
Here is some good reading for you, please educate yourself on the matter before claiming anything stupid again.
http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html
http://www.anandtech.com/show/7335/the-iphone-5s-review/4
Speaking of stupid....obviously you missed where I said it's being marketed by keying in on the fact it's 64-bit as if by that very virtue it's all super awesome.
Speaking of stupid....obviously you missed where I said it's being marketed by keying in on the fact it's 64-bit as if by that very virtue it's all super awesome.
Like I said in a later post, many are confused between what Apple really said about the A7 during their keynote and how its been assimilated by the media.
Since we're talking about ARM the fact that it's 64-bit is super awesome. You really should read the info in the links BigMac2 supplied.
I am actually eagerly anticipating Android's transition to 64-bit computing, if only to see if the industry can pull it off as seamlessly as Apple supposedly is attempting to.
First, Google has to release a 64-bit version of Android.
Based on my understanding, OEMs and app developers have to support with 64-bit processors and apps of their own. This represents a catch-22 scenario. The various OEMs and telcos are already having a hard time ensuring that OS updates cascade down to the end user in a time fashion (if at all). After so many years, just under 50% of users are reportedly running 4.0 and above. Only Samsung seems like they have the resources and financial muscle to pull this off (their phones would be the first to run 4gb of ram, but I doubt their touchwiz would properly support it anyways).
Likewise, if I were an app developer, and I didn't think there are enough users on 4.4 (assuming it runs 64-bit) to justify me expending additional time and resources supporting 64-bit, then I simply won't. Why should I, when there are enough buyers still on 32-bit Android phones to market to? Nor am I going to actually code an app that requires the full 4gb of ram to run properly, because most phones would still be on 2gb of ram or less.
And you want to further fragment this with both 32-bit and 64-bit phones?
Apple may not be new with their 64-bit processor, but I think they are actually trying to force Android's hand here. Making OEMs rush to incorporate it into their phones, without first taking the time to ensure their products are properly optimised or think if it is really necessary.
In short, expect chaos.
Likewise, if I were an app developer, and I didn't think there are enough users on 4.4 (assuming it runs 64-bit) to justify me expending additional time and resources supporting 64-bit, then I simply won't.
You do realize that Java application code is completely independent of the processor architecture. As a developer there is nothing you need to do to support 64 bit. (Unless you have some very specific native interface code in your app, which is not very common)
All apps compile to machine independent java byte code.
Googles 64-bit Dalvik VM has the task at runtime to convert the byte code into 64-bit processor specific instructions.
Form latest reports 48% of android users are on the latest android JellyBean (4.1+) which was released in July 2012. I'm not sure what you mean by "so many years"
It's not fragmentation, it's progression.
You know well that speaking to developers of high performance apps and games would illuminate your deceit. Surprised you'd put your personal rep at risk for something so transparent
MK
You do realize that Java application code is completely independent of the processor architecture. As a developer there is nothing you need to do to support 64 bit. (Unless you have some very specific native interface code in your app, which is not very common)
All apps compile to machine independent java byte code.
Googles 64-bit Dalvik VM has the task at runtime to convert the byte code into 64-bit processor specific instructions.
Form latest reports 48% of android users are on the latest android JellyBean (4.1+) which was released in July 2012. I'm not sure what you mean by "so many years"
This is not entirely true, java source code is alway 32 bit. Dalvik byte code can run on any plateform compiled for sure, but this is where Qualcomm Rep is right about. Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm, and will have very little performance gain (about 3% according to this site).
This is not entirely true, java source code is alway 32 bit. Dalvik byte code can run on any plateform compiled for sure, but this is where Qualcomm Rep is right about. Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm, and will have very little performance gain (about 3% according to this site).
That is the same for pretty much any 32-64 bit transition where the chip architecture doesn't undergo a major transformation. With the vastly optimized instruction set of armV8 you are going to get a similar performance boost that A7 got, just by virtue of the streamlined instruction set.
That is the same for pretty much any 32-64 bit transition where the chip architecture doesn't undergo a major transformation. With the vastly optimized instruction set of armV8 you are going to get a similar performance boost that A7 got, just by virtue of the streamlined instruction set.
Not true, DalvikVM is a 32 bit register base virtual machine, even compiled on a 64 bit plateform Dalvik virtual processor registers are still 32 bit only. with a native compiled language like C or C++ for example when you declare an INT it will be 32 bit wide when compiled on a 32 bit platform and 64 bit wide on a 64 platform in java INT are always 32 bit. Mike Ash article explain where Apple being in control of their own hardware and IDE can squeeze all benefits the A7 can gives.
Not true, DalvikVM is a 32 bit register base virtual machine, even compiled on a 64 bit plateform Dalvik virtual processor registers are still 32 bit only. with a native compiled language like C or C++ for example when you declare an INT it will be 32 bit wide when compiled on a 32 bit platform and 64 bit wide on a 64 platform in java INT are always 32 bit. Mike Ash article explain where Apple being in control of their own hardware and IDE can squeeze all benefits the A7 can gives.
It's pretty much been established that moving from 32 to 64 bit compilation will only result in about a 6% performance improvement. It has been generally agreed here and in most of the tech press that the major improvement in A7 was not the 64-bitness per se, rather the move to a much more efficient instruction set and additonal core functions like crypto. Any application that compiles for that instruction set, even the DalvikVM can take advantage of that.
Since VM platform completely masqueraded the CPU ISA, developer can't got all benefits of 64 bit native code in a byte code vm, and will have very little performance gain (about 3% according to this site).
Wouldn't the VM itself be able to run faster once it's ported to ARMv8? I thought one of the main benefits of the abstraction layer afforded by the VM is that, at least in theory, the VM does all the hard work of tailoring programs to a specific architecture. For example, it's the VM's job to decide how to actually execute AES bytecode. Once Dalvik is ported to ARMv8 it should automatically run AES bytecode using the new AES hardware instructions with no input required of the program developers.
It's pretty much been established that moving from 32 to 64 bit compilation will only result in about a 6% performance improvement. It has been generally agreed here and in most of the tech press that the major improvement in A7 was not the 64-bitness per se, rather the move to a much more efficient instruction set and additonal core functions like crypto. Any application that compiles for that instruction set, even the DalvikVM can take advantage of that.
I wonder how an apps developed on a 32 bit VM can tap all benefit of a 64 bit platform. Apps running in a VM are stuck with the VM limits (8-16 bits opcode, 32 bits registers for DalvikVM).
Wouldn't the VM itself be able to run faster once it's ported to ARMv8? I thought one of the main benefits of the abstraction layer afforded by the VM is that, at least in theory, the VM does all the hard work of tailoring programs to a specific architecture . For example, it's the VM's job to decide how to actually execute AES bytecode. Once Dalvik is ported to ARMv8 it should automatically run AES bytecode using the new AES hardware instructions with no input required of the program developers.
True, the VM itself would run faster once ported to ARMv8 in either AArch32 or AArch64 ISA, but without major revision of the DalvikVM, virtualized apps is still running in a 32 bit environment only.
Why a major revision? There are plenty of 64bit jvms out there, I imagine that the dalvik switch to 64bit would be a fairly straightforward engineering task. It would have to be done in any case.
As far as java code is concerned, an int is always 32 bits and and a long is always 64. It doesn't matter whether the jvm is 64/32.