Slashdot Mirror

← Back to Stories (view on slashdot.org)

Benchmarks for Embedded Processors?

Posted by Cliff on from the beating-the-baseline dept.

shill asks: "I am interested in working on an embedded linux application, but I'm having difficulty choosing a processor. Is there somewhere I can find benchmarks or technical comparisons of various embedded processors, like the Trasmeta Crusoe 5400, Intel StrongARM 1110, and National Geode GX1? I am looking for performance information as well as power requirements, etc."

4 of 12 comments (clear)

  1. Google finds it again by jpt.d · · Score: 5, Insightful

    http://www.eembc.org/

    Specific:
    http://www.eembc.org/Benchmark/score/ScoreFindSt ep 1.asp?BenchmarkType=PRO

    To slashdot: Can we please keep these questions out that can be found with keyword search in google within first three results?

    Regards,
    jptd

    --
    What we see depends on mainly what we look for. -- John Lubbock Now search for that bug slave!
  2. Lies, dammed Lies and Benchmarks by pagercam2 · · Score: 4, Insightful

    It all depends on what you want to do. Benchmarks are generally pretty useless and the power estimates even more so, what is the processor supposed to be running when the power estimate is taken. Small applications, running entirely out of cache will use less power than those that must use external memory, and then how do you decide if the power taken by the memory is part of the processor or not. The processor is driving the address lines and data lines when writing, but how do you issolate the power contribution between the two???? Chips like the Transmeta require support chips which adds a second number to the power contribution for the processor. As far as performance is you are doing floating point a processor with floating point will be better even if the clock speed is higher on an integer processor, inversely a simple processor that does only fixed point math is generally smaller and more power efficient. These processors each have different capabilities as far as peripherals, the StrongARM has a lot, the Transmeta relies of support chips, the Geode has some. Bench marks are only helpful in very general relative terms you really need to understand your application and match it to the processor to make a valid decision.

  3. seems like an oxymoron... by boopus · · Score: 4, Insightful

    I've had very little experience with embedded processors, but generaly embeded processors are expected to get their work done, at whatever rate is required. If the processor can do the task that it's being imbedded for, any extra speed is wasted. So define your problem, and find the cheapest way to get it accomplished.

    Once example of this is a parking garage system i've had the bad fortune to work on a couple of times. It consists of multiple 486's running linux. (these things have uptimes measured in years) Each machine spits out tickets or calculates times/rates or reads monthly-pass cards, and none of them need anything more than a 486, even the one with the wireless link to the accounting system, as changing the microsecconds to nanosecconds that they take to do their task wouldn't help anyone...

  4. Wrong question by bluGill · · Score: 4, Informative

    Morre's law applies, so if you choose a processor that turns out to not be fast enough, you can install one twice as fast when you ship, and if that isn't fast enough, then none of today's current processors are fast enough either. Of course if you depend on one feature a lot, then you should choose a processor that has it, but normally this isn't an issue)

    Where I work we use the strongArm (SA110) a nice chip overall. However the diagnostics people estimate that we lost an year of devolpment because there is (or was?) no in circuit emulator. however the StrogArm has some nice supporting hardware, so it took us less time to design the hardware.

    x86 is an ugly instruction set. You should reject all x86 thoughts just based on that. Any assembly programers can learn whatever you choose, and most work is done in something else (C/C++ normally), so those who are not assembly experts should have a nice binary to look at for the rare times they do have to look at a disassembled output. RISK is really nice for that reason.

    It is all a trade off. However speed isn't important. How nice it is to design the hardware, and how nice it is to program (and debug!) for your application are important. Don't forget power consumption/cooling requirements.

    I have no doupt that there are some things I didn't mention because it isn't a problem for the things I work with, but you should look.