Processador nVidia Denver

Nemesis11

Power Member
Some of Nvidia's CPU architects gave a talk at the Hot Chips symposium today, and they revealed some long-awaited details about Nvidia's first custom CPU design. We weren't able to attend the talk, but the firm evidently pre-briefed some analysts about what it planned to say. There's a free-to-download whitepaper at Tirias Research on the Denver CPU core, and I've been scanning it eagerly to see what we can learn.

We already know Denver is a beefier CPU than ARM's Cortex-A15, since two Denver cores replace four A15 cores in the Denver-based variant of the Tegra K1. We also know Denver is, following Apple's Cyclone, the second custom ARM core to support the 64-bit ARMv8 instruction set architecture. We've long suspected other details, but Nvidia hasn't officially confirmed much—until now.

Here are some highlights of the Denver information revealed in the whitepaper and presumably also in the Hot Chips presentation:

Binary translation is for real. Yes, the Denver CPU runs its own native instruction set internally and converts ARMv8 instructions into its own internal ISA on the fly. The rationale behind doing so is the opportunity for dynamic code optimization. Denver can analyze ARM code just before execution and look for places where it can bundle together multiple instructions (that don't depend on one another) for execution in parallel. Binary translation has been used by some interesting CPU architectures in the past, including, famously, Transmeta's x86-compatible effort. It's also used for emulation of non-native code in a number of applications.

Denver's binary translation layer runs in software, at a lower level than the operating system, and stores commonly accessed, already optimized code sequences in a 128MB cache stored in main memory. Optimized code sequences can then be recalled and replayed when they are used again.
Execution is wide but in-order. Denver attempts to save power and reap the benefits of dynamic code optimization by eschewing power-hungry out-of-order execution hardware in favor of a simpler in-order engine. That execution engine is very wide: seven-way superscalar and thus capable of processing as many as seven operations per clock cycle. Denver's peak instruction throughput should be very high. The tougher question is what its typical throughput will be in end-user workloads, which can be variable enough and contain enough dependencies to challenge dynamic optimization routines. In other words, Denver's high peak throughput could be accompanied by some fragility when it encounters difficult instruction sequences.

denverblock1407807841.jpg


Impressively, Nvidia is claiming instruction throughput rates comparable to Intel's Haswell-based Core processors. That's probably an optimistic claim based on the sort of situations Denver's dynamic optimization handles well. Nonetheless, Nvidia has provided a quick set of results from a handful of common synthetic benchmarks. These numbers are normalized against the performance of the 32-bit version of the Tegra K1 based on quad Cortex-A15 cores. They show Denver challenging a Haswell U-series processor in many cases and clearly outperforming a Bay Trail-based Celeron. Another word of warning, though: we don't know the clock speeds or thermal conditions of the Tegra K1 64 SoC that produced these results.

relativeperformance1407807848.jpg


Nvidia has built the expected power-saving measures into the Denver core, with "low latency power-state transitions, in addition to extensive power-gating and dynamic voltage and clock scaling based on workloads," according to a blog entry Nvidia has just posted on the SoC. As a result, they claim, "Denver's performance will rival some mainstream PC-class CPUs at significantly reduced power consumption." That sounds like a bold claim, but one wonders if they're comparing to something like Kaveri rather than Broadwell.

We should know more soon. Nvidia says Tegra K1 64 devices should be available "later this year" and alludes to its new SoC as an Android L development platform. I can't wait to put one of these things through its paces.

http://techreport.com/news/26906/nvidia-claims-haswell-class-performance-for-denver-cpu-core

Binary translation, mas em software, in order e ultra wide seven-way superscalar.
Que processador mais estranho para os tempos actuais. Mesmo comparado com o Transmeta é muito estranho e não há nada no mercado que seja parecido.

A comparação a nível de performance é com um Celeron U, quando se fala de comparar com um Haswell, mas não deixa de ser interessante, visto serem os dois dual core.
Cada vez está mais interessante este Denver, nem que seja pela sua estranheza.
 
Alguém me pode simplificar o que traz esta Nvidia Denver de novo para o mercado e a sua importância/qualidade ?
Que special features é que a coisa traz?
 
Por enquanto os detalhes ainda são só sobre a arquitectura. Temos ali uns benchmarks, mas não é de alguém independente.
Na prática o que promete é mais velocidade num processador mobile, possivelmente com muito baixo consumo, mas isso é algo a confirmar no futuro.

A nível de arquitectura é que ele apresenta algo que actualmente não existe nada comparavel no mercado. Não estou a dizer que seja para melhor ou pior. Simplesmente é completamente diferente.
Faz lembrar em parte os Transmeta, pelo binary translation, por outro lado o Itanium, por ser in order, sendo o software a reorganizar as instruções.

PDF sem o paywall com um pouco mais de detalhe:
http://www.filedropper.com/nvidia-project-denver-white-paper
 
Última edição pelo moderador:
Sim, mas acho que pode haver outro motivo. Em loads single threaded, o segundo core funciona como um "optimizador" na reoganização de instruções. Basicamente out of order via software, estando o segundo core a fazer esse trabalho.
O que pode indicar que em loads multithreaded pode não se conseguir a mesma optimização e assim a performance sofrer com isso.
 
Última edição pelo moderador:
É realmente chato e esperemos que seja corrigido.

Para quem não sabe o Denver tem uma forma peculiar de funcionamento onde transforma e optimiza as operações em microoperações e isto é feito através do dynamic code optimizer (DCO) que é parte software e parte hardware. Ele usa 128MB da RAM para guardar as optimizações e pelo que percebi quando ocorre alguns tipos de operações (mencionam explicitamente multiplicações de vírgula flutuante de dupla precisão - 64-bits) ele invalida os tais 128MB de cache que faz perder todas as optimizações feitas até ao momento. Dado que o processador não é de execução fora de ordem faz com que de tempos a tempos perca o seu trunfo que lhe dá a alta performance.
 
Ou seja, quando aparecem operações em variáveis "double", as optimizações perdem-se? Isso realmente parece bastante indesejável, ainda que possivelmente não seja a coisa mais comum do mundo.
 
Hum... duvido q vejamos o hipotético TP1 num tablet ou algo do género. Tanto core grande com caches razoáveis, complexidade da arquitectura e tanta feature de virtualização isto mais parece ir para outros mercados imho.
 
Esta apresentação (os vídeos das apresentações só devem ser carregados mais tarde), parece ter apenas focado o caso do PX2, o tal módulo que trás ainda 2 GPU para o mercado automóvel, e provavelmente outros mercados embedded (flight sistems, medical, etc).
 
Back
Topo