Slashdot Mirror

← Back to Stories (view on slashdot.org)

NVIDIA Tegra X1 Performance Exceeds Intel Bay Trail SoCs, AMD AM1 APUs

Posted by Soulskill on from the comparative-advantage dept.

An anonymous reader writes: A NVIDIA SHIELD Android TV modified to run Ubuntu Linux is providing interesting data on how NVIDIA's latest "Tegra X1" 64-bit ARM big.LITTLE SoC compares to various Intel/AMD/MIPS systems of varying form factors. Tegra X1 benchmarks on Ubuntu show strong performance with the X1 SoC in this $200 Android TV device, beating out low-power Intel Atom/Celeron Bay Trail SoCs, AMD AM1 APUs, and in some workloads is even getting close to an Intel Core i3 "Broadwell" NUC. The Tegra X1 features Maxwell "GM20B" graphics and the total power consumption is less than 10 Watts.

57 comments

  1. nice, but they remove your games if you update by electrosoccertux · · Score: 0

    no thanks...

    1. Re:nice, but they remove your games if you update by Anonymous Coward · · Score: 0

      Who really cares? I own the portable and really couldn't care any less that they removed some useless games with an update.

    2. Re:nice, but they remove your games if you update by Anonymous Coward · · Score: 0

      What should they have done?

      Never update?

      Update but leave the broken, unplayable games there wasting space?

    3. Re:nice, but they remove your games if you update by Anonymous Coward · · Score: 0

      no thanks...

      So we should cater to games that don't update to match the current version of android. That is your take on this. Seriously, how often do you stab yourself in the face with a fork in an effort to eat?

    4. Re:nice, but they remove your games if you update by epyT-R · · Score: 2

      Actually, the point of having stable APIs and ABIs is so that other dependent binaries and code continue to work and compile even when changes are made to the underlying software.

    5. Re:nice, but they remove your games if you update by Junta · · Score: 3, Informative

      The more troubling question is why an application should feel forced to do anything in the face of a platform upgrade in order to work at all. A modern Windows desktop can still run 10 year old software without a hiccup. Going back 20 years you start needing something like dosbox to use a lot of the applications, though still doable. I haven't tried firing it up in a while, but last time I tried the commercial package of quake 3 under linux, it still worked on a modern distribution. Same for linux neverwinter nights. As an application maintainer for some linux stuff, the only things that I can recall forcing my hand to change something for things to work were systemd and python changes.

      Android (and to a significant, but somewhat lesser extent Apple) are not doing that good with respect to application and/or hardware compatibility into the past. It's a tiring situation for developers to have to follow an upgrade treadmill in order to cater to new system sales, just to keep the current applications workable as-is.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    6. Re:nice, but they remove your games if you update by electrosoccertux · · Score: 1

      why did they need to remove them? android updates aren't that large. Can you redownload them? So they're gone forever?

  2. Not an AMD CPU by Guspaz · · Score: 4, Interesting

    The X1 uses a standard ARM Cortex A57 (specifically it's an A57/A53 big.LITTLE 4+4 config), so this says more about ARM's chip than anything nVidia did...

    Now if you compared nVidia's Denver CPU, their in-house processor... The Denver is nearly twice as fast as the A57, but only comes in a dual-core config, so it's probably drawing a good deal more power. When you compare a quad-core A57 to a dual-core Denver, the A57 comes out slightly ahead in multicore benchmarks. Of course, single core performance is important too, so I'd be tempted to take a dual-core part over a quad-core if the dual-core had twice the performance per-core...

    Why the X1 didn't use a variant of Denver isn't something that nVidia has said, but the assumption most make is that it wasn't ready for the die shrink to 20nm that the X1 entailed.

    1. Re:Not an AMD CPU by Guspaz · · Score: 2

      Sorry, I meant not an *nVidia* CPU.

    2. Re:Not an AMD CPU by mcrbids · · Score: 1

      I'm bully on ARM, with the (almost) collapse of AMD as a "first rate" processor, it's good to see Intel get some serious competition in a significant market space.

      My only beef with ARM is that comparing CPUs is harder than comparing video cards! the ARM space is so fragmented with licensed cores and seemly random numbers indicating the "version" that I have no idea how, for example, a SnapDragon 808 processor compares to a Cortex A9 or an Apple A7.

      Really, I'm lost. But the $40 TV stick with the 4x core A9 works pretty well...

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    3. Re:Not an AMD CPU by robi5 · · Score: 1

      > I'm bully on ARM

      Is it some new slang, or you meant bullish?

    4. Re:Not an AMD CPU by MrBingoBoingo · · Score: 1

      I'm feeling rather sad. AMD graphics still have completely open drivers. Nvidia relies on blobs at a level higher than on device firmware.

    5. Re: Not an AMD CPU by chill · · Score: 1

      Actually it is old slang, dating back as far as 1609 , to Merriam-Webster. It enjoyed being in the popular lexicon during the latter part of the 19th Century and was a commonly used expression by U.S. President Theodore Roosevelt.

      --
      Learning HOW to think is more important than learning WHAT to think.
    6. Re: Not an AMD CPU by robi5 · · Score: 1

      Interesting, even a literal 'bully on' search didn't turn up anything (m-w.com doesn't describe this usage either), I've only heard 'schoolyard bully' and 'bully for you' in the past, and of course, somebody is 'bullish on' or 'bearish on' something.

    7. Re:Not an AMD CPU by BitZtream · · Score: 1

      No, it says more about the bad benchmark than anything else.

      I'm not impressed that ARM can NOP as fast as an i3 to put it bluntly.

      I say this because if you look at the bench marks and the way they did it. They compile arm variants in fully optimized mode, and x86 variants generic x86 code. From that point on, reading is a waste of time. Might as well compile with debugging on from a bench mark perspective.

      Its intentionally skewed.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    8. Re:Not an AMD CPU by mattsqz · · Score: 2

      AMD has Jim Keller back, the guy behind alpha 21164/21264, athlon64, apple A4/A5, broadcom's cool SoC's (WRT54G)..he's designing their next x86-64 chip. don't count AMD out just yet.

  3. Awesome by Anonymous Coward · · Score: 0

    OMG, that video card is like, totally awesome! Less than 10 watts is super for that crazy power!

    How does it compare to like PCI express cards?

  4. Interesting, but compiler settings aren't optimal by the_humeister · · Score: 4, Insightful

    Look here at the compiler settings. The x86 processors are somewhat hampered by non-optimal settings. For example the i3 5010U is set to -mtune=generic. In my experience, that's basically going to default to AMD K8 optimization with no AVX/AVX2 support. The better option would be using -mtune=native or better yet -march=native, which would detect the CPU and produce a more optimized binary.

  5. Re:Windows 10 Sucks by Anonymous Coward · · Score: 0

    I commend the troll effort here. You've got most of the themes woven into one post.

  6. SoC GPU compared to discreet GPU? by Anonymous Coward · · Score: 0

    SoC ain't shit.

  7. NUC? by robi5 · · Score: 1

    What incompetence led Intel to use a temporally relative name. It's on par with 'new' in the product name. Seems to work OK until it doesn't and looks idiotic in retrospect.

    1. Re:NUC? by drinkypoo · · Score: 1

      What incompetence led Intel to use a temporally relative name. It's on par with 'new' in the product name. Seems to work OK until it doesn't and looks idiotic in retrospect.

      What looks idiotic in retrospect is your comment. The name only has to make sense long enough to sell a bunch of units. Then they're on to the next product.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:NUC? by robi5 · · Score: 1

      don't forget your meds, man

    3. Re:NUC? by drinkypoo · · Score: 1

      don't forget your meds, man

      Don't forget to leave a comment worth reading, man

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  8. VDPAU support? by tji · · Score: 2

    Do VDPAU ( Nvidia video decode hardware acceleration API) drivers exist for this platform? In the past, I believe only the x86 binary blob drivers supported VDPAU.

    If they exist, this would make an excellent MythTV DVR frontend device.

    1. Re:VDPAU support? by Blaskowicz · · Score: 1

      It should run about the same driver as a graphics card under a linux PC (which shares much with the Windows driver too).
      When nvidia first showed off Tegra K1, it was Ubuntu 12.04 with a screenshot of nvidia-settings along a few things.

  9. Availability of Ubuntu by Melkhior · · Score: 1

    How "modified" was the Shield to run Ubuntu? Can I buy a Shield and get Ubuntu on it today? Or is this benchmarking an exercise in futility?

  10. Bullshit by melted · · Score: 0

    10 times out of 10 NVidia non-GPU chip benchmarks are paid for by NVidia and are complete bullshit, designed to get fanboys to buy their latest chip. There have been no exceptions with Tegra to date.

    1. Re:Bullshit by jaklode · · Score: 1

      Oh, the problem just always has been that the benchmarks were done on prototype hardware, which ran at higher frequencies than final products, had better cooling, and a power supply. But the Shield Android TV is a final product that has all this, so the benchmarks are accurate.

  11. So using a 20 year old subset of the instructions by Cafe+Alpha · · Score: 1

    it does worse? You just found out that the benchmark is bullshit.

  12. Re:Interesting, but compiler settings aren't optim by Anonymous Coward · · Score: 0

    Where are you finding the compiler flags? I can't see -mtune anywhere on that page.

  13. Re:Interesting, but compiler settings aren't optim by Bert64 · · Score: 1

    Well with the possible exception of those running gentoo, 99% of end users will be running precompiled software that has to be compiled for a generic cpu as the distributor doesn't know exactly what type of processor its going to end up running on.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  14. Re:So using a 20 year old subset of the instructio by mtippett · · Score: 1

    This is exactly why the benchmarks include

        1) a way to repeat the benchmarks as described in the article see page 4 - 'phoronix-test-suite benchmark 1507285-BE-POWERLOW159'.
        2) The compiler options are included

    Armed with those two pieces of information, you can go and "prove" that the benchmark is, as you called it - bullshit. Although rarely, if ever that I am aware of, does anyone respond to an article with those two pieces of information and say - "here, if you run it in this mode, you will see a marked difference in performance".

    As Bert64 says in the response to the grandparent, 99% of end users will be running the software - either pre-compiled by their distribution vendor in this way, or compiled by the benchmark author's defaults. If you really want to prove that the benchmark is crap, then by all means make meaningful suggestions to _any_ of the existing machine benchmarks.

    Michael (Phoronix) and I had some interesting discussions with Sun (pre Oracle) about 64 vs 32. They argued that the benchmarks were misleading because they did not use the Sun Studio (IIRC) compiler for 64 bit. In the discussions, it became clear to even the Sun people that it was quite difficult for even the Sun people to configure and use the platform in the way they wanted Phoronix to. Out of the box, gcc compiling for 32 bit - was how they configured the systems. And guess what, the './configure;make;make install' triplet would compile the same way we did.

    Full disclosure, I have a long history with Phoronix, and have been involved in work that they have done in the past.

  15. 10W is hellish hot by mtippett · · Score: 3, Insightful

    10W is incredibly hot for any sort of passively cooled, enclosed device.

    The machine would be quite warm (almost hot) to the touch unless they use some inventive cooling. The current Gen Apple TV is about 6W, and your typical smartphone is around 2-3 W.

    There is a reason that NV has only really been able to get a foothold in tablets, android TV, cars and their own shield product. Quite simply put, they have historically been fast and hot. Great as a SOC within certain markets.

    1. Re:10W is hellish hot by Anonymous Coward · · Score: 1

      You are correct only if comparing in the same form factor. For me, I think this race to 10-20W for plugged in computing is crazy -- power isn't that expensive as long as it doesn't consume much during idle, I don't really care how much it uses during operation as long as it isn't >300W or so, or 100W in a mostly enclosed space or 50-80W in a fully enclosed space.

      Give me the better performance please.

    2. Re:10W is hellish hot by nvm_my_comment · · Score: 1

      It's not doesnt have passive cooling ( http://www.tomshardware.com/ga... ) look at that fan. So you comment is pointless.

    3. Re:10W is hellish hot by Anonymous Coward · · Score: 0

      The units for current are Amperes. Watts are the units for power ...

    4. Re:10W is hellish hot by Barbecue911 · · Score: 1

      A 5W SOC gets you down to passive cooling territory. With small form factor desktops, replacing whiny or dead fans are a bother since the fans are special parts that you need to hunt down online.

    5. Re:10W is hellish hot by tlhIngan · · Score: 1

      10W is incredibly hot for any sort of passively cooled, enclosed device.

      The machine would be quite warm (almost hot) to the touch unless they use some inventive cooling. The current Gen Apple TV is about 6W, and your typical smartphone is around 2-3 W.

      There is a reason that NV has only really been able to get a foothold in tablets, android TV, cars and their own shield product. Quite simply put, they have historically been fast and hot. Great as a SOC within certain markets.

      Actually, it isn't too hot. ARM typically goes for 100mW/MHz and it looks like this thing has 4 cores running at 1.9GHz or so, or basically, 1.9W/core. Four cores is a little under 8W, which leaves about 2W for the GPU.

      The only reason ARMs are getting hot is even at 100mW/MHz, stuffing in a lot of cores with a lot of speed eventually catches up with you.

      (The 100mW/MHz figure dates back to early ARM processors, too, so it's been remarkably consistent).

  16. AMD did well! by serviscope_minor · · Score: 2

    Interesting take-home from the benchmark: the AMD desktop processors did prtty respectably well compared to the i7s. Ususally a bit slower, sometimes actually faster and we know an AMD setup is certainly cheaper.

    Interesting that in the open source, repeatable, examinable benchmarks the difference between Itel and AMD is a lot less pronounced.

    --
    SJW n. One who posts facts.
  17. Re:Windows 10 Sucks by amalcolm · · Score: 1

    .. and succeeded at being un-funny

    --
    Time for bed, said Zebedee - boing
  18. Re:Interesting, but compiler settings aren't optim by skiminki · · Score: 2

    I run Gentoo!!!

    Besides that, I did some very recent Intel CPU benchmarking as I tried to figure out IPC gains over CPU generations. I ran my benchmarks on GCC 4.8/4.9/5.2 and LLVM 3.6 on Nehalem and Ivy Bridge. I also included march=generic vs march=native. Quick summary: For generic integer/floating-point code, the Intel Core-i7 CPUs don't actually benefit much from optimizations for newer architectures, especially on x86-64. The exception here is that 32-bit generic FPU x87 code is slower than SSE2, but the latter is always available in x86-64. Actually, sometimes GCC even produced worse code for march=native on Ivy Bridge.

    The above actually makes sense to me. Starting from Nehalem, the internal CPU microarchitecture hasn't changed that much and the new instructions tend to be quite specific. Of course the newer generations have lots of small optimizations, more op execution units, bigger reorder buffers and caches, a bit faster ALUs and other units, and so on. But nothing drastic that would require a new instruction scheduler, for example. Pentium 4 was, of course, a completely different beast that tends to perform badly if the code is not targeted properly due to its excessive pipeline length.

    OTOH, for specialized things such as video decoding/encoding, the libraries tend to do run-time CPU detection and use different code paths based on what is available. For example, FFmpeg does this (or at least mplayer did), and AFAIK OpenSSL does this for AES, too.

    Bottom line: So, even if I'm a Gentoo user, I wouldn't worry too much about march=generic.

  19. Re:So using a 20 year old subset of the instructio by ShakaUVM · · Score: 1

    >If you really want to prove that the benchmark is crap, then by all means make meaningful suggestions to _any_ of the existing machine benchmarks.

    That's a bit facetious. If you've been around the benchmarking world as long as you say you have, you'll know that the compiler settings are *always* a cause of controversy.

    Nobody is happy when compiler settings are made that don't favor their side (whatever it is).

  20. No ARM for me by Anonymous Coward · · Score: 0

    To say a ARM beats a Atom or Celeron is not saying that much. Even coming close to a core i3 is just saying it can hold its own with basic chips.
    These days if you want a enjoyable notebook,tablet or desktop experience. You have to go core i5 or above. Especially if your talking low powered chips.
    Nothing against ARM in small screen tablets, readers, or specific task OS like a game console. Even a Chromebook sucks more with a ARM chip then a Intel one.

    1. Re: No ARM for me by Anonymous Coward · · Score: 1

      Carrots on sticks for gamers notorious for being baited.

  21. Re: Interesting, but compiler settings aren't opti by Anonymous Coward · · Score: 0

    Gentoo users are funny. Doing cpu benchmarks... No recent CPUs...

  22. Re:Interesting, but compiler settings aren't optim by Anonymous Coward · · Score: 0

    on this page is a iframe (http://www.phoronix.com/scan.php?page=article&item=nvidia-tegra-x1&num=2)
    to https://openbenchmarking.org/e...

  23. Re:Windows 10 Sucks by ArcadeMan · · Score: 1

    No mention of Bitcoin, 3D printing, Arduino or Raspberry Pi.

    Lame.

    --
    Get free satoshi (Bitcoin) and Dogecoins
  24. Re:Interesting, but compiler settings aren't optim by Junta · · Score: 1

    The problem being they didn't do the same to ARM. Either that argument applies to both sides or neither. They need to be held to same standard.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  25. Re: Interesting, but compiler settings aren't opti by skiminki · · Score: 1

    Well, these just happened to be on my Gentoo boxes, and therefore, of interest.

  26. Tegra sucks by thsths · · Score: 1

    NVidia should have spent more money on engineering and less on advertising. All the Tegra chip sets overpromised and underdelivered. I see no reason why this one should be different.

  27. Re:Interesting, but compiler settings aren't optim by Anonymous Coward · · Score: 0

    It was the stock compiler on each OS.... Thus it's the upstream distro not doing that.