Forgot your password?
typodupeerror
Intel Ubuntu Linux

PandaBoard ES Benchmarked 77

Posted by Unknown Lamer
from the entering-calendar-entries-was-never-so-fast dept.
An anonymous reader writes "Phoronix has benchmarked the Texas Instruments PandaBoard ES and compared its performance against Intel Atom N270, Atom Z530, Pentium M, and Core Duo T2400 processors. The OMAP4660 dual-core 1.2GHz ARM Cortex-A9 development board generally loses out to Intel's older competition, but does manage to win in ray-tracing and other tests, and is advantageous on a per-Watt basis."
This discussion has been archived. No new comments can be posted.

PandaBoard ES Benchmarked

Comments Filter:
  • by Anonymous Coward

    Still not as fast as it's power hogging competition, but pretty decent.

    I do a lot of work with Gumstix Overo's, and at home on the original Pandaboard. I am constantly amazed at how powerful those little systems are.

    To be sure my Quad Core Xeon that I cross compile on will eat them for lunch... but at 5x the cost and 50x the power consumption.

    • by Anonymous Coward

      I think the limitations of boards like the Panda force programmers and designers to be more efficient instead of brute-forcing like the competition.

  • by GreatBunzinni (642500) on Wednesday December 28, 2011 @10:55AM (#38514766)

    The benchmarks provided by Phoronix focus on computational power, which is a relevant criteria. Yet, ARM-based systems aren't targeted at the high performance computing field. In their domain of application, criteria such as power usage and price tends to be much more relevant than how fast it compresses files, encodes MP3s or runs synthetic benchmarks. In fact, if it is fast enough to play media then it's fast enough to do anything at all.

    So, how about comparing them where they need to be compared: power output and price?

    • Re: (Score:2, Insightful)

      by tsahil (921519)
      There's even more to it... In these benchmarks the accelerators of the OMAP4 were totally ignored. These would have improved things like x264 encoding to being a lot faster even than a Core i7 chip. The OMAP4 as do other ARM Cortex A9 chipsets, have a lot of accelerators to deal specifically with highly computational tasks - and when you develop you actually use them...
      • by pinkeen (1804300)
        I haven't heard the term 'accelerator' in a long time. I belive the more appriopriate one would be 'DSP'.
      • Re: (Score:3, Insightful)

        by Desler (1608317)

        These would have improved things like x264 encoding to being a lot faster even than a Core i7 chip.

        And yet you provide no actual evidence of this beyond an assertion. Please show your x.264 settings, which corei7 you used (there is more than one model), link to your source material, etc. so that you're results can be duplicated and verified.

      • These would have improved things like x264 encoding to being a lot faster even than a Core i7 chip

        Lol. No, they wouldn't have. Now you're just making stuff up.

      • by wagnerrp (1305589)

        In these benchmarks the accelerators of the OMAP4 were totally ignored. These would have improved things like x264 encoding to being a lot faster even than a Core i7 chip.

        And with just one misplaced letter, you show that you have no idea what you're talking about. The embedded platforms have ASICs dedicated to H 264 encoding, which can run much faster than comparable quality settings in x 264 running on a high end i7. If you actually tried running the software x 264 encoder on an ARM, you would be looking at days for a single TV show, and that's assuming x86-optimized x264 will even compile and run on the ARM architecture. If you want to compare apples to apples, you w

        • by tsahil (921519)
          That was what I meant. Trying to compare Intel Atom to TI OMAP4 by checking the performance of a software video codec is plain wrong. Both chips are headed towards mobility and consumer electronic devices, where things like power consumption (which was already mentioned) is a lot more important than number crunching. The TI OMAP4 was designed with multimedia in mind, and as such it includes hardware accelerators for things like H.264 encoding/decoding and a lot of other things (3D graphics comes to mind). T
    • You can find an ARM vs x86 power consumption at:

      http://www.brightsideofnews.com/news/2011/5/19/the-coming-war-arm-versus-x86.aspx?pageid=6 [brightsideofnews.com]

      "The chart below contrasts power consumption between the Intel Atom N450 and the ARM Cortex-A8 while running miniBench. The power curves were generated from system power usage adjusted downwards so that idle system power was discarded. For the Atom, idle power was 13.7W with the Gateway netbook’s integrated panel disabled while the idle power for the Pegatron system

      • Looking at the numbers very roughly, one could say that the ARM is about half slower than the Atom, but uses only one third of the power. So if we normalize either the processing speed or power consumption to the same level, it can be concluded that ARM is 50% more energy efficient while making the same amount of work than Atom.
  • by Anonymous Coward

    A lot of the tests are irrelevant when done between Atom and OMAP4.
    The OMAP4 has internal accelerators for voice and video coding - stuff like VP8 and x264 can be done a lot faster on the OMAP4 if you ditch the software itself and use the OMAP4's accelerators instead.
    We've been able to use OMAP4660 for encoding 720p at 30fps into H.264 while using only ~20% of the CPU. Try doing that in software on a Core i7 and see where it gets you.

    When doing benchmarking on ARM Cortex chipsets, there needs to be more car

    • by Desler (1608317)

      We've been able to use OMAP4660 for encoding 720p at 30fps into H.264 while using only ~20% of the CPU. Try doing that in software on a Core i7 and see where it gets you.

      It gets you doing multiple 720p streams at once. 720@30p is child's play.

      • by tsahil (921519)
        True. For us 720p means both encoding and decoding at the same time.
        • by Desler (1608317)

          And for me too. I can do 3-4 streams at realtime with ease. With faster settings even more.

    • by hattig (47930)

      To be fair, Sandy Bridge does include a video encoding accelerator/transcoder as well. However Atom doesn't at the moment, although Medfield will presumably include one.

      The thing about OMAP 44xx is that the accelerator is a programmable DSP, not fixed function hardware. The specs say it can do 1080p30 (at 30fps). That means it could do VP8, or presumably even your own custom DSP code.

      We should also be considering the quality of the output though.

  • TI (Score:5, Interesting)

    by Kagetsuki (1620613) on Wednesday December 28, 2011 @11:04AM (#38514870)

    As someone with experience doing embedded development on ARM I can tell you I found the OMAP architecture to be awful. I'll admit the only time I ever used it was on a demo board (the Beagle) vs a board with essentially identical specs from FreeScale, Renesas and a few others. TI was awful with support, their documents were awful, the hardware was flaky (overheating!?) and the sample sources and module sources they provided were absolute crap. On top of that when we did get the boards running and started comparing them the OMAP board was slow as tar on anything that involved a lot of memory operations in a small timeframe. Apparently the GLES subsystem was fantastic or something but after a few attempts we couldn't get the modules built correctly against the kernel we were using and just gave up. In the end we went with the FreeScale (not my choice) which was easily superior to the TI OMAP garbage.

    Sorry TI, I'm not even touching this one.

    • by gatkinso (15975)

      I am doing a lot of development on Gumstix Overos and am finding that platform to be pretty sweet. I think many of the problems you are encountering might be an artifact of the Beagle (who incidentally flat out state not to base an actual product on their hardware).

      • by tsahil (921519)
        Same here. We've used the TI Blaze tablet platform with the OMAP4660 chip. No such issues. And their support in Israel at least is top notch.
    • Could you give me some advice on building a standalone mixing pult/equalizer? I was considering a cheap dev board with plenty o' DSP and linux, but I don't know how to pick it up from there. I'm kinda on a shoestring budget (<$800).
      • Well even on the project where the OMAP was evaluated I wasn't the one making the final decisions and I haven't been doing much device development lately either, so at the moment I don't think I could give you much good advice. You're lucky looking for something like that now though, because with all the tablets and smart phones out now everyone seems to be offering really complete and capable ARM dev boards with well done reference designs. You may also want to check out the communities around those manufa

  • Where are the drivers and SDK for this?

  • A more interesting benchmark for me at the moment is performance per $, which is where Raspberry Pi is going to have a big impact soon I think.

    • by drinkypoo (153816)

      Amen. If you need the latest greatest fastest it's not a fit, but it solves very many problems. My first RISC machine had, I believe, a 16 MHz CPU, it had a ~500MB SCSI-fast-narrow disk on a very poky VME controller, and an 8 bit, fairly stupid frame buffer... a Sun 4/260. And I ran a browser on it...

    • Very true.
  • by Roman Mamedov (793802) on Wednesday December 28, 2011 @12:12PM (#38515714) Homepage
    I will ENJOY seeing this absolutely DESTROYED, BEAT INTO THE ASPHALT in terms of price to performance by the Raspberry Pi very soon. Days of $100-200 ARM boards are coming to an end, now dear Pandawhatever please set the sane price of $50 for your board, or die out of existence.
    • Why the hate? This has 4 times the memory, twice the clock speed and twice the cores of the Pi, of course it isn't going to be less then twice the price.
      Everything else being equal you might expect nearly 4 times the price (i.e. ~$130) but not only is this already actually available (and we don't know what it will cost once we can actually buy a Pi), but the Raspberry Pi is hoping to operate without profit and to short-cut the economies of scale with large government orders for education. If they achieve th

      • This has 4 times the memory, twice the clock speed and twice the cores of the Pi, of course it isn't going to be less then twice the price. Everything else being equal you might expect nearly 4 times the price (i.e. ~$130)

        So, $130 for a bare board with CPU and RAM?
        Yeah that would sound great, except when anyone can build a whole PC for $191, http://www.pcmag.com/article2/0,2817,2392163,00.asp [pcmag.com]
        With 2x the RAM and a CPU that rips the ARM on PandaBoard into a thousand of tiny teddy bears in terms of performanc

        • by Nadaka (224565)

          Economies of scale. The price is relatively high due to the low volume of production. These are hobby boards. The only reason you can build a $200 PC right now is because the hardware gets production runs in the millions or more.

          • Economies of scale. The price is relatively high due to the low volume of production. These are hobby boards. The only reason you can build a $200 PC right now is because the hardware gets production runs in the millions or more.

            Sure, and also maybe the chicken-and-egg problem?
            There won't be any scale until there's significant demand, and there won't be any demand while those boards cost so much, that even most ARM enthusiasts would find it difficult to justify the purchase.
            It's okay that the performance of

            • by goarilla (908067)
              I don't consider 130 $ to be much if you are a ARM enthusiast !
              Development boards used to cost a LOT more.
      • by Osgeld (1900440)

        I think he is more refering to the current selection of arm dev boards, like TI's offering which starts at 130$ for a 96k 75Mhz M3 and then wants another 100 bucks for a book, and god knows how much for a compiler that if you install it you get some douche salesman calling you once a month wanting to know if you need more software.

  • A lot of the tests that were done would have benefited from having Hard Float. Ubuntu ARM port does not have Hard Float. They should have used the Debian HardFloat port to get more accurate performance metrics of what the hardware can do.

    I'm not arguing over semantics or fractions of percentages - Hard Float would have given an easy 20% increase in performance for some tests! For example here's an engineer from Genesi showing off the Debain Hard-Float work a few months back... 300% increase in some places? [armdevices.net]

  • I would like to see a 12 hour benchmark that reported normalized results
    in terms of Kg of battery. All these processors are in the ball park for
    operations per second but many can NOT do it all day long.

    Twelve and 24 hour results are needed to be sure. But a smart phone with a three hour
    battery life is not a smart design. Simply from the safety point of view this is important.

    • Yes, but then the issue is that the device is only for people who need more than three hours at full operating capacity without access to any kind of powersource... and in reality that is not necessarily very many people... especially if you consider that a $100 device can compete with a $600 iPad for most people's needs. My laptop only gets about 4 hours on battery with dimmed screen and wifi and blue tooth off and I have never really found that to be a major limitation of its portability or usefulness.
      • Yes, but then the issue is that the device is only for people who need more than three hours at full operating capacity without access to any kind of powersource... and in reality that is not necessarily very many people... especially if you consider that a $100 device can compete with a $600 iPad for most people's needs. My laptop only gets about 4 hours on battery with dimmed screen and wifi and blue tooth off and I have never really found that to be a major limitation of its portability or usefulness.

        BUT a phone is a critical safety device. Dialing 911 or 999 for emergency services
        when stuck in a snow drift or calling to tell your safe and sound kids to stay put after a tornado has
        passed ... but wait the kids phone battery is exhausted because they were playing
        Angry Birds now you do not know....

        • In that case, I don't think it really makes sense to let children play Angry Birds on battery with your critical safety device. The problem seems to be that people expect a critical safety device to be useful as a toy, phone, computer, car battery and who knows what else.... which is of course rather a lot to ask from a retail device that you are literally risking your life on hoping it functions correctly in critical situations.
          • In that case, I don't think it really makes sense to let children play Angry Birds on battery with your critical safety device. The problem seems to be that people expect a critical safety device to be useful as a toy, phone, computer, car battery and who knows what else.... which is of course rather a lot to ask from a retail device that you are literally risking your life on hoping it functions correctly in critical situations.

            I am with you -- yet the parents that give their kids "smart" phones are not thinking
            about a quake or a regional power outage. My guess is they are thinking -- is
            my kid home yet, has he stopped at his GF house to neck blow smoke.

            It starts with the very young kids, too young to exercise personal restraint
            especially where Angry Birds is considered safe and blowing smoke and having
            sex at age 11 is not.

  • The compilers, libs and more for x86 and friends
    are so much more mature this is hardly a fair game.
    The best high school players paired against the
    winner of the superbowl....

    And it is not just the processor the comparison
    seemed to depend a lot on graphics drivers that are
    just now using graphics hardware.

We can predict everything, except the future.

Working...