[AT] NVIDIA Denver performance

[Nothingness]

How can a CPU be so good at Kraken and yet be utterly mediocre in Sunspider? This is hard to believe, there must be some error in benchmarking procedures.

Is this something to do with single-threaded versus multi-threaded performance? Anyone willing to speculate what is going on?

As I keep on saying, Sunspider is horrible: it's made of very short synthetic loops that run for a very short amount of time. So if your browser Javascript JIT engine tries to aggressively optimize the loops, a lot of time will be wasted for the translation for code that will run for a tiny amount of time.

So it's possible it's a Google v8 tuning issue, where it's been set to aggressively optimize JS code too early.

 

[NTMBK]

As I keep on saying, Sunspider is horrible: it's made of very short synthetic loops that run for a very short amount of time. So if your browser Javascript JIT engine tries to aggressively optimize the loops, a lot of time will be wasted for the translation for code that will run for a tiny amount of time.

So it's possible it's a Google v8 tuning issue, where it's been set to aggressively optimize JS code too early.

I doubt it's just V8- probably more to do with the nature of Denver. It relies on code-morphing to extract good performance, and if Sunspider is (like you say) lots of snippets of code which are only executed a handful of times then it's almost a worst case scenario for Denver. Time is wasted by V8 JITting the code to ARM machine code, then time is wasted by Denver re-ordering and optimizing the ARM machine code, and then the whole thing gets run once before it gets tossed.

 

[witeken]

Also an oddly subjective one that is not very easily verifiable. For the record, web browsing is a pure pleasure on all of the iOS devices that I use. I can't say the same for the choppy scrolling on all of the Android devices that I've used, but that's just my experience...

Also note that the touchscreen input lag of iApple in general is superior, so it has nothing to do with the CPU (smoothness != fast).

 

[Headfoot]

I'll wait until reviewers can confirm its running 64-bit applications on release firmware. Optimization is typically near the end of the design phase so I wouldn't be surprised by a respectable uplift.

 

[Lepton87]

Also note that the touchscreen input lag of iApple in general is superior, so it has nothing to do with the CPU (smoothness != fast).

I remember someone doing that test and the myth was dispelled, it was done on an iPhone 6 against some Android phones, and the iPhone placed in the top but wasn't the best. It didn't include tablets though.

 

[Nothingness]

I doubt it's just V8- probably more to do with the nature of Denver. It relies on code-morphing to extract good performance, and if Sunspider is (like you say) lots of snippets of code which are only executed a handful of times then it's almost a worst case scenario for Denver. Time is wasted by V8 JITting the code to ARM machine code, then time is wasted by Denver re-ordering and optimizing the ARM machine code, and then the whole thing gets run once before it gets tossed.

I certainly agree, both technologies have the same shortcomings/benefits 🙂

I wonder if some updates to either the JS JIT engine or the firmware will show improvements.

 

[Lepton87]

Is this a CPU where a driver update can increase performance akin to a new GPU driver increasing performance in games? Is the software for this CPU similar to GPU drivers or do they differ in significant ways?

 

[MisterLilBig]

Is this a CPU where a driver update can increase performance akin to a new GPU driver increasing performance in games? Is the software for this CPU similar to GPU drivers or do they differ in significant ways?

I'm pretty sure its possible and it wouldn't be something unique to Denver. As long as the hardware has the capability or feature to do it already, it should be possible.

 

[TrulyUncouth]

Is this a CPU where a driver update can increase performance akin to a new GPU driver increasing performance in games? Is the software for this CPU similar to GPU drivers or do they differ in significant ways?

I fear we will get a patch that addresses benchmark performance 🙂

Assuming NV has enough manpower to optimize even the top 200 apps this could be an acceptable way to get good enough performance.

 

[Lepton87]

I fear we will get a patch that addresses benchmark performance 🙂

Assuming NV has enough manpower to optimize even the top 200 apps this could be an acceptable way to get good enough performance.

Optimized for benchmarks, real world app performance be damned, certainly NV isn't above that. I was expecting Denver with bated breath but this reliance on software just doesn't sound good. NV loves benchmarks tricks. Anyone remembers swapping entire shaders to lower precision ones in 3dmark 2003 for FX series or the missing dragon in 3Dmark2001? The list goes on and on... Or how about measuring fps during loading screens and adding that to the average? That was ingenious. NV must have had practice with the Stasi on how to cheat. They are good at it! :thumbs up:

 

[Arachnotronic]

I fear we will get a patch that addresses benchmark performance 🙂

Assuming NV has enough manpower to optimize even the top 200 apps this could be an acceptable way to get good enough performance.

It's interesting to see that NVIDIA approached its very first CPU design as it did a GPU with a heavy dependence on a software engine being optimized for specific programs (i.e. drivers). Also, Intel's Gen. GPU architecture reeks of a "CPU-oriented" mindset.

Interesting times we live in.

 

[Lepton87]

It's interesting to see that NVIDIA approached its very first CPU design as it did a GPU with a heavy dependence on a software engine being optimized for specific programs (i.e. drivers). Also, Intel's Gen. GPU architecture reeks of a "CPU-oriented" mindset.

Interesting times we live in.

It only makes sense to leverage one's area of expertize. Benchmarks cheating included. 😉

 

[monstercameron]

that isnt quite fair to accuse nvidia of future 'cheating'...still this is a great move by nvidia, now we'll see what transmeta could've been!

 

[Arachnotronic]

now we'll see what transmeta could've been!

Good point!

 

[tviceman]

So in some dystopian future where AMD doesn't exist and the courts rule that Intel must license out x86 at a reasonable price to anyone who wants to design their own x86 CPU's, from a hardware engineering standpoint, is the Denver CPU capable of running x86 code as is (with the proper firmware / software translation layer) since, according to my understanding from what I've read, Denver is merely translating instructions and isn't necessarily an "ARM" processor?

 

[Lepton87]

that isnt quite fair to accuse nvidia of future 'cheating'...still this is a great move by nvidia, now we'll see what transmeta could've been!

I'm not really accusing them, just acknowledging their past performance in the area. I really like ecology, how could I make fun of a company that uses wooden screws in its cards?

 

[Nothingness]

So in some dystopian future where AMD doesn't exist and the courts rule that Intel must license out x86 at a reasonable price to anyone who wants to design their own x86 CPU's, from a hardware engineering standpoint, is the Denver CPU capable of running x86 code as is (with the proper firmware / software translation layer) since, according to my understanding from what I've read, Denver is merely translating instructions and isn't necessarily an "ARM" processor?

Yes, it could probably be made run to x86 code. In fact, it's likely this CPU was first designed to translate x86 code years ago.

 

[simboss]

Yes, it could probably be made run to x86 code. In fact, it's likely this CPU was first designed to translate x86 code years ago.

Denver does have a native ARM decoder and no x86 one, so even if in theory you could update the translation layer from ARM to x86, you would not get a usable x86 directly from it, it would be far too slow to translate each instruction each time.

 

[Nothingness]

Denver does have a native ARM decoder and no x86 one, so even if in theory you could update the translation layer from ARM to x86, you would not get a usable x86 directly from it, it would be far too slow to translate each instruction each time.

You are right, I had forgotten that "detail" :$

 

[beginner99]

That sunspider score is totally whacked. I'm assuming they got somebody working on it, it seems like an obvious place to look for a rather simple bug. (Simple to the guys who designed this cpu anyway.)

One would think the most common benchmarks were already looked at and optimized for...This makes me doubt the product very much? In which other applications might it terribly suck? my favorite game?

 

[Cerb]

One would think the most common benchmarks were already looked at and optimized for...This makes me doubt the product very much? In which other applications might it terribly suck? my favorite game?

All of them, most likely. That may change. Or not.

It's Transmeta all over again, but without all their business problems.

As it improves over time, we'll see what real potential it may have. Given the state of mobile benchmarks, though, I'd prefer a plain Linux dev board, or something like that, to be able to have tested programs which we can make more normal comparisons with.

 

[krumme]

One would think the most common benchmarks were already looked at and optimized for...This makes me doubt the product very much? In which other applications might it terribly suck? my favorite game?

This is s good argument. As it is, you dont need stellar performance sometimes / a lot of the time with a few dips. You want consistently good performance every single time.
Its a bit like gaming and frametime variances.

It reminds me of one of my kids ss tab3 with clovertrail+ processor. As it is the proceesor is actually okey fast for a kid but app loading times takes extremely long time. It just feels irritating.
What we expect is predictable performance.

 

[III-V]

The benches are in...

Courtesy of AT's review: http://www.anandtech.com/show/8670/google-nexus-9-preliminary-findings

Looks like Geekbench may have overstated Denver's performance. It's a solid core, but it doesn't seem to be anything to write home about.

I'm just excited for a fresh new take on computing.

 

[jdubs03]

Looking at the geekbench browser, there are some single-core scores getting 2k+ on 32-bit software. There is just so much inconsistency it's hard to tell Denver's performance, but it seems like with pre-release software (as Anandtech was benching on), it doesn't do too bad of a job. Sunspider almost seems like a joke now; but yeah these benchmarks paint a very strange picture.

 

[MisterLilBig]

Looking at the geekbench browser, there are some single-core scores getting 2k+ on 32-bit software.

Just checked, there's no Nexus 9 scores there. If you mean the "HTC Volantis" scores, those are clearly not the Nexus 9. (2.5GHz vs 2.3GHz, respectively)

Engadget had this to say about Geekbench scores on the Nexus 9:
" Curious, I pitted the K1-toting Nexus 9 and Shield tablet against each other in a few more tests -- the 9 boasted a stronger single-core score than the Shield in Geekbench 3 (1,643 vs. 1,074), but the multi-core score definitely skewed in the Shield's favor."

PCWorld had this to say about Geekbench scores on the Nexus 9:
"In GeekBench 3, the Nexus 9 scored 3358 in the multi-core test"





A lot of reviews are out already, its quite clear that the selling point is 64-bit Android 5. Which really won't get much use or benefit considering the mount of RAM.

This feels like a repeat of the Tegra 3 Surface RT.