Tegra K1 “Denver” Will Be First 64-bit ARM Processor for Android
blogs.nvidia.com
blogs.nvidia.com
So the in-order design they have now allows them to scale up to 2.5 GHz which is very high for such a constrained chip. They also have this weird "code optimizer" that appears to sacrifice some RAM and a CPU core to dynamically reorganize processor instructions to run better on this in-order design. It seems as though they want to have their cake and eat it too, but at the same time they appear to paradoxically introduce complexity to achieve simplicity.
I wonder if someone more knowledgable about chip design could comment on this design?
Saying "When an in-order CPU stalls on memory, it's still burning power while waiting, while an OOO processor is still getting work done" seems deceptive, though. The OOO processor is (often) doing speculative work, which may be unneeded, and a stalled in-order CPU won't be using quite the same amount of power as if the execution units were actually switching.
Though I'm pretty sure the NVIDIA design must speculative prefetch and hoist memory reads aggressively to be performance competitive (see the huge cache sizes!), which also burns power.
"Denver is just one of the variants in that line. T50 was going to be a full 64-bit x86 CPU, not ARM cored chip, but Nvidia lacked the patent licenses to make hardware that was x86 compatible."
Another "what's different this time" point: compared to Transmeta era, CPUs now typically have idle core(s) waiting for work to do. This may enable more ambitious optimizations as you're not constantly stealing cycles from the app.
Does anyone have a link to the paper?
Not sure why I'm being downvoted:
> The big paradigm-shift that ART brings, is that instead of being a Just-in-Time (JIT) compiler, it now compiles application code Ahead-of-Time (AOT). The runtime goes from having to compile from bytecode to native code each time you run an application, to having it to do it only once, and any subsequent execution from that point forward is done from the existing compiled native code.
http://www.anandtech.com/show/8231/a-closer-look-at-android-...
That sounds like native code compilation to me.
Google has been very quiet about ART generated code quality. I haven't found any benchmarks that would compliment its performance either. It's probably better than Dalvik but worse than mature optimizing compilers.
Nowadays calling a .so/.dylib/.dll function, or accessing a thread-local variable also generates lots of cruft code that could possibly get optimized once the data is loaded. It won't always work (shared libraries can't be unloaded, but with enough hints, or assumptions that this would never be done, one can gain some benefits). On the negative this may reduce the code-sharing across processes.
The fact that ART makes use of dex bytecode as portable executable format[0] complicates the matter for those not versed in compiler design.
So people see bytecode and think managed, when a bytecode format doesn't have anything to do with being interpreted or compiled to native code.
[0] An old idea that goes back to the mainframe days and used by quite a few other languages.
http://www.tiriasresearch.com/downloads/nvidia-charts-its-ow...
In general CPUs have idle cores, but this looks like it's supposed to be a dual core setup so that's going to be less of a factor. I think the main idea is that you only have to do the optimization once but you run the code many times, which is an improvement from Transmeta where you threw out your optimizations when the process ended.
The only detail I remember from it was :
"Linus, what Linux distribution do you use?"
"Debian, of course"
I wonder if he still uses that on his Mac Book Air
Also remember John Carmack joining Intel to work on Larrabee.
These aren't $1500 desktops with user upgradable components. They are sealed, non upgradable, relatively disposable devices that are intentionally obsoleted by their manufacturers every 12-18 months. It makes for a nice marketing bullet point, but are we actually getting anything besides a bigger number to impress the impressionable customer with?
"In short, the improvements to Apple's runtime make it so that object allocation in 64-bit mode costs only 40-50% of what it does in 32-bit mode. If your app creates and destroys a lot of objects, that's a big deal." [1]
One example: in 64bit NSNumber and (short) NSString objects on iOS can be stored completely in a pointer (tagged pointers) on the stack without having to create anything on the heap. That's possible because the size of a 64bit pointer is large enough to contain the required information. Creating and accessing one of these objects becomes far faster. Based on what I gathered at WWDC this year, Apple is also inclined to move as many various objects there as possible (as long as they can be stored in a 64 bit pointer).
[1] https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
Furthermore, nothing has been said (AFAIK) about similar tricks Google is doing with Android on AArch64 or 64 bit architectures in general. From what I've heard they just made the Android runtime capable of emitting AArch64 (and x64, MIPS64) instructions instead of 32-bit ARMv7 ones.
That alone gives plenty of a performance boost as AArch64 instructions are supposedly quite a bit faster than the old 32-bit ones. It remains to be seen though whether Google can make as much use of clever allocation tricks as much as Apple can: Android is much more platform agnostic and uses a garbage collector for some of these tasks.
ART also brings a new GC, which is quite improved compared to the fossilized Dalvik version that has barely changed since Android 2.3.
AArch64 has a better instruction set and more general purpose registers (31 vs 16), so applications recompiled to target AArch64 should see performance benefits even if it only uses 1 MB of RAM and never encounters integers greater than 2^32.
Also, besides the correct points made in sister comments, there is the issue that virtual address space is used for things other than simply mapping physical memory. There was a time, for example, when Linux mapped all of physical memory into the kernel's virtual address space. This was simple. These days, on 32-bit systems, it splits the 4GB address space into 3GB for the user and 1GB for the kernel, and maps physical memory in and out of a 128MB window in kernel space, as needed. This is obviously more complicated.
One thing that Mike missed though is that you can do large bandwidth operations faster. You can blend two pixels at a time with 64bit, so your graphical blend can be twice as fast (of course, if you're really worried about the speed of these types of operation, you go SIMD - but that's a pain in the butt and requires in line assembly language to get the biggest boosts. In particular, ARM Neon's C function wrappers on SIMD instructions generally gives you a much smaller boost than if you hand code the assembly language calls. With 64bit, you can get some of the advantage without the hassle).
My practical experience using intrinsics is quite the opposite. Using C + NEON or SSE intrinsics yielded a lot better performance than what my hand written assembly could.
I've heard similar stories to yours from others but they were from years ago. Later versions of compilers seem to be a lot better at this.
In particular, the C compilers (GCC, Clang) were able to further optimize code written using intrinsics, where using assembler code practically inhibits all compiler optimizations.
While I am able to do pretty good instruction selection by hand (which the compiler wasn't very good at), what blew me away was the compiler's ability to do instruction scheduling and register allocation. I could not have matched that without spending a huge amount of time reading architecture specific optimization manuals.
So I got pretty neat, readable and portable code (x86+SSE and ARM+NEON) using a single code base where I had only written some "primitive" functions using low level intrinsics. I could write nice high level code and the compiler would inline my primitive function calls and then further optimize and re-organize the instructions.
I imagine the additional cpu registers (general purpose and floating point) are handy for crypto and encoder/decoder stuff.
Quite useful when moving away from C into languages like Objective-C, Swift, Java, C#, ... as the ones with first class treatment on the vendor SDKs
But ultimately it isn't about memory in the near-term. ARMv8 offers more, larger registers, instructions, a higher hardware baseline, and in the future higher memory.
http://linuxgizmos.com/nvidia-opens-tegra-k1-driver-wins-tor...
Or am I misunderstanding?
Intel 3D hardware is crappy anyway.
Good enough goes a long way when the competition is made of high-performance temperamental sports cars that tend to catch fire when you least want them to. Sometimes, all you need is a Honda Accord.
And eventually "good enough" will catch up.
http://richg42.blogspot.de/2014/05/the-truth-on-opengl-drive...
A bicycle requires less maintenance and is easier to build repair and operate than an F1 car. Taken a step further. The complex nature of the F1 car and competitive nature of F1 races gives far greater advantages to secrets which may give the team/car the competitive edge.
I don't like the fact that this is where the graphics industry is and I wish that they would simply compete on hardware and the tech was all open. but I do prefer nvidia on linux to any other GPU because they have the performance I'm looking for. Also their linux drivers are far better than AMD's.
Note anymore. Their 14nm mobile chips should be competitive and with open drivers will enable Linux + Wayland on them.
In fact the most recent version of OpenCV already leverages this on ARM platforms that support CUDA. http://code.opencv.org/projects/opencv/wiki/CARMA_platform_c...
Of course there's no device using Denver in the wild either.