looking for performance statistics (native JAVA processors) - Embedded

This is a discussion on looking for performance statistics (native JAVA processors) - Embedded ; hey. Does anyone have references to performance stats or whitepapers about performance of native java processors vs. software jvm for embedded apps? I read the hardware specs on a couple of 100mhz processors and they didn't seem very impressive, even ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: looking for performance statistics (native JAVA processors)

  1. looking for performance statistics (native JAVA processors)

    hey.

    Does anyone have references to performance stats or whitepapers about
    performance of native java processors vs. software jvm for embedded apps?
    I read the hardware specs on a couple of 100mhz processors and they didn't
    seem very impressive, even for running bytecode in hardware. One spec
    showed a benchmark of copying a 10,000 byte array in 64ms. On the surface
    that seems fast but consider that 10000/0.064secs=1.25mbits/sec. and they
    include an ethernet tranceiver on the eval board. I haven't used a 1mb/s
    ethernet in nearly 15 years!

    I guess what I'm really wondering is whether there are java native
    processors out there that can approach risc mips levels. I
    understand that there will be emulation overhead even in hardware but my
    requirements will be to keep up with 802.11b wireless speeds: 11bm/s.
    Anyone know of java native processors that can deliver that kind of
    thru-put and support the FULL J2ME specs?


    tanks



  2. Re: looking for performance statistics (native JAVA processors)

    noone wrote:
    >
    > Does anyone have references to performance stats or whitepapers about
    > performance of native java processors vs. software jvm for embedded apps?
    > I read the hardware specs on a couple of 100mhz processors and they didn't
    > seem very impressive, even for running bytecode in hardware. One spec
    > showed a benchmark of copying a 10,000 byte array in 64ms. On the surface
    > that seems fast but consider that 10000/0.064secs=1.25mbits/sec. and they
    > include an ethernet tranceiver on the eval board. I haven't used a 1mb/s
    > ethernet in nearly 15 years!


    640 cycles per iteration. Running interpreted on my desktop machine
    gives around 200 cycles per iteration. However, CLDC (and even RTSJ)
    have block copying methods which will presumably be written natively.

    > I guess what I'm really wondering is whether there are java native
    > processors out there that can approach risc mips levels. I
    > understand that there will be emulation overhead even in hardware but my
    > requirements will be to keep up with 802.11b wireless speeds: 11bm/s.
    > Anyone know of java native processors that can deliver that kind of
    > thru-put and support the FULL J2ME specs?


    ARM processors with Jazelle can execute Java byte code directly at a
    reasonable pace. They also support Ahead-Of-Time (AOT) compilation for
    speed critical parts.

    http://www.arm.com/products/esd/jazelle_home.html
    http://www.arm.com/linux/

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/

  3. Re: looking for performance statistics (native JAVA processors)

    On Sun, 05 Mar 2006 12:31:28 -0500, noone wrote,
    quoted or indirectly quoted someone who said :

    >I guess what I'm really wondering is whether there are java native
    >processors out there that can approach risc mips levels.


    the intent of a Java processor would to conserve RAM. It could run as
    an interpreter without chewing up megabytes of RAM with the machine
    language equivalents.

    Sun abandoned its PicoJava chips when it turned out they ran too hot.
    You need a low power chip for a hand held.

    Have a look at http://mindprod.com/jgloss/picojava.html

    I have always wanted to see a machine with a cached stack with a
    mindless little processor that worked in parallel using spare memory
    cycles to keep the stack from overflowing and to keep it filled.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.

+ Reply to Thread