bustapr:
"what instruction set does this atom have?"
x86
subasteve:
2 GHz? Sounds like they are using clock speed to make up for an IPC deficit. Doesn't bode well for battery life.
Nope! Just the opposite, in fact. The Atom outpaces the ARM designs by a wide margin and the Atom's FPU isnt crippled like in the ARM designs. We can expect FLOPS numbers in the GFLOPS range from Intel while ARM is still struggling to reach 1 GFLOP.
[citation][nom]Bloob[/nom]So I'm guessing apps using the Android NDK do not work on Intel chips ( unless there is a seperate version )?[/citation]
Last I checked, most of the Android stuff runs in Java. Intel chips shouldn't have a problem running most Android apps if that's true. There might need to be a minor emulation/translation layer or something like that for the little that isn't compatible Java code or some other clever trick(s), but it shouldn't be overly difficult to run Android on x86 CPUs with full compatibility. It is definitely possible, although I don't know for sure what method(s) would be used.
JustPosting23:
A wide margin? It's pretty small if none. Depending on the usage scenario, this is what you will get out of each architecture. If you want something done as close to real-time as you can, you cannot use x86 which only Intel supports.
This is like comparing a xbox360 to a ps3 cpu's.
At this point it all depends on the design and how well you utilize it on that one architecture you are targeting.
[citation][nom]MrDerp[/nom]JustPosting23:A wide margin? It's pretty small if none. Depending on the usage scenario, this is what you will get out of each architecture. If you want something done as close to real-time as you can, you cannot use x86 which only Intel supports.This is like comparing a xbox360 to a ps3 cpu's.At this point it all depends on the design and how well you utilize it on that one architecture you are targeting.[/citation]
Excluding Apple's custom design, Medfield's integer performance per core per Hz meets or beats the best of ARM-compatible CPUs. If Medfield uses a modern FPU, then as JustPosting23 said, the difference in floating point performance could be huge. If this is a dual-core 2GHz model that also has Hyper-Threading, then it could easily compete with even the top quad-core or better ARM CPUs. Furthermore, you claim that things can't be done anywhere near real-time with x86 which is just plain wrong.
This is not like comparing a Xenon to a Cell. This Intel CPU and/or the Android version that it runs would be specifically designed to natively support ARM-based Android apps and would also need to be optimized for them to run them properly. That's also assuming that given the focus on Java code, the apps wouldn't run properly even without additional compatibility layers. The Cell and the Xenon have no such compatibility intended in their designs that I'm aware about.
[citation][nom]amk09[/nom]First 2Ghz phone AWWWWW YEEEEEEEEEEE 2016 we will have phones that can run BF3 at 1080p, calling it.[/citation]
[citation][nom]Bloob[/nom]So I'm guessing apps using the Android NDK do not work on Intel chips ( unless there is a seperate version )?[/citation]
I am sorry to inform that you are incorrect. Android uses the Java with the Dalvik vm instead of the JVM.
Let me google it for you.
Dalvik is the process virtual machine (VM) in Google's Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers. Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed.
[citation][nom]blazorthon[/nom]Last I checked, most of the Android stuff runs in Java. Intel chips shouldn't have a problem running most Android apps if that's true. There might need to be a minor emulation/translation layer or something like that for the little that isn't compatible Java code or some other clever trick(s), but it shouldn't be overly difficult to run Android on x86 CPUs with full compatibility. It is definitely possible, although I don't know for sure what method(s) would be used.[/citation]
NDK is the native API, not the Java one. Most 3D games use NDK. Sure, it won't affect most apps.
[citation][nom]Bloob[/nom]NDK is the native API, not the Java one. Most 3D games use NDK. Sure, it won't affect most apps.[/citation]
Even for apps that aren't just Java or something like that, there could easily be compatibility in a wide variety of ways. All Android apps can be compatible if Intel makes appropriate designs and/or if Google's x86 Android is designed to translate the code as needed.
Atom consumes significantly more power, unless there is a tremendous breakthrough in battery tech, Intel is on downward trend. Like Sun Microsystems in the early 2000's.
-SK
[citation][nom]blazorthon[/nom]Even for apps that aren't just Java or something like that, there could easily be compatibility in a wide variety of ways. All Android apps can be compatible if Intel makes appropriate designs and/or if Google's x86 Android is designed to translate the code as needed.[/citation]
Perhaps, but they would most likely take a hit somewhere, either compute power, or the loss of x86-based native apps, or similar.
[citation][nom]Shinobi_III[/nom]If it ran Win 8 why not.. Using regular programs could've been really cool. But why the cpu switch? Isn't the intel a hotter and less efficient cpu?[/citation]
The CPU switch is because Intel decided that they wanted in on this market and they got some backing by Google. As for the heat and efficiency, we don't know about that yet.
Perhaps, but they would most likely take a hit somewhere, either compute power, or the loss of x86-based native apps, or similar.
Maybe, but maybe not. It wouldn't need to take any performance hit and we've already seen performance of the older Medfield CPUs and it was quite good. If necessary, the powerful FPU could be used to negate any performance impact by running emulation/translation on the FPU, but that'd also be assuming that Intel doesn't simply add other hardware acceleration for it. As for losing compatibility with native x86 programming, that's unlikely and even if it is true, it shouldn't be a big deal for CPUs that are intended to run Android.
My original post had 17 thumbs up 30 min ago, now it has 3! lol! I guess someone out there with their hordes of Tom's accounts didn't like the truth very much. hahaha.
[citation][nom]samkl[/nom]Atom consumes significantly more power, unless there is a tremendous breakthrough in battery tech, Intel is on downward trend. Like Sun Microsystems in the early 2000's.-SK[/citation]
That Atom that you're talking about was based on a cut-down Core 2 on 32nm and was hardly mroe than a proof-of-concept design. Even then, it didn't consume too much more power and even if it did, simply using larger batteries would solve that (many of us would welcome a slightly thicker phone than many of today's models anyway). Intel has far better architectures such as Nehalem, Sandy Bridge, and the upcoming Haswell as well as the 22nm die shrink and the supposedly upcoming 14nm die shrink in the next year or two to integrate into the next gen Atoms as well as many other tricks/optimizations that they could do.
hmm well this might totally not have the same performance as a 2GHz Athlon or Pentium cpu but desktops are becoming a joke, so large for that little extra performance 🙁 Good thing they are starting to up scale the single threading again 4GHz+