Apple will likely beat Denver in CPU performance with A8, but having it 20nm is a significant advantage and it's not entirely of Nvidia's concern since no one besides Apple uses Apple's SoC's.
I wonder if this Transmeta binary code translation is the real deal, the "secret sauce" that might be Nvidia's edge in a very competitive market, where its competitors in the CPU field are far more equipped/experienced to produce custom designs. If it works so well, why isn't anyone else doing it? Or is this a one-off, niche type design that won't serve Nvidia well in the long-term?
Anyone capable of explaining the binary code translations to a laymen like me? Based upon my readings of the whitepaper and other sites, the Transmeta method failed because years ago when Transmeta implemented its technology, hardware was not fast enough to take advantage of the method. That is, the software overhead to translate resulted in a net efficiency loss. But now hardware is much more powerful but power-efficient, and the (according to Nvidia), the Transmeta method, refined, now results in a positive efficiency gain.
Interesting stuff. I look forward to Anandtech's analysis.
I don't understand why this dynamic recompilation is necessary. Most Android apps already run in the Dalvik VM, which should be able to do similar dynamic recompilation. The only exception would be if the ARM instruction set is just poorly designed for high performance.
That said, being that the cores are in-order, they should be pretty power efficient, and maybe nvidia was able to add some extra hardware to speed up the recompilation. Still, it seems like they're duplicating effort to be going from Dalvik -> ARM -> nvidia ucode.
Maybe an out-of-order implementation once they get to node shrinks? To get even more performance out those cores without so much worry about power dissipation.
Maybe an out-of-order implementation once they get to node shrinks? To get even more performance out those cores without so much worry about power dissipation.
That kinda goes against the idea of such an architecture - tailor the code to the architecture via pre-compiling such that out of order execution isn't even necessary.
I think the IPC is less than a lot of people expected. Not comparable at all with Core or Cyclone. Although it makes up for the lower IPC with a higher clock speed, Core M has a turbo that is comparable to that, but compared to Krait, Cortex A and Atom it seems very good, like its GPU performance. Power remains to be seen and I don't expect very low prices either. Design wins and TTM are also unclear to me.
I don't understand why this dynamic recompilation is necessary. Most Android apps already run in the Dalvik VM, which should be able to do similar dynamic recompilation. The only exception would be if the ARM instruction set is just poorly designed for high performance.
That said, being that the cores are in-order, they should be pretty power efficient, and maybe nvidia was able to add some extra hardware to speed up the recompilation. Still, it seems like they're duplicating effort to be going from Dalvik -> ARM -> nvidia ucode.
Any word whether the optimization engine can be patched/updated after the SoC has shipped? I wonder whether we will see GPU-style driver updates, with specialised code paths for high profile software/commonly benchmarked games.
I don't understand why this dynamic recompilation is necessary. Most Android apps already run in the Dalvik VM, which should be able to do similar dynamic recompilation. The only exception would be if the ARM instruction set is just poorly designed for high performance.