Jay Carlson [mailto:nop at place.org] writes:

> OK.  First item in the "do..." menu in shrink4.image is tinyBenchmark now
> :-)
>
> ~1,480,000 bytecodes/sec
> ~41,500 sends/sec
>
> So that's 10-20 times slower than the P2/300, and in the same
> speed class as
> a 25MHz SPARCstation IPX.
>
> I guess that's not so horrible.  I mean, it's driving a monochrome 160x160
> screen, and runs on two AAA batteries.  And based on previous experience,
> there's probably a lot of tweaking that can be done to optimize the build;
> MIPS optimization, especially on Linux on handhelds, is kinda funny.

I started to do a round of compiler flag tweaking, but first I decided to
actually read the object code the compiler was spitting out for typical
executables.

As usual, there were a lot of nops in the stream, mostly in load delay
slots. Both the Linux VR processor families have load pipeline interlocks,
so those nops aren't doing anything useful except providing R3000 backwards
compatibility.  I told gcc and gas to build for the MIPS II architecture,
which has no mandatory load delays.  Then I reread the object code
disassembly.

Huh? There were still lots of nops in the stream, in load delay slots!  gcc
wasn't generating them.  Turns out that gas was unconditionally inserting
nops in the macro expansion of PIC symbol references, whether the target
processor needed a delay slot or not.  Grrrr.  One binutils patch later, the
vast majority were gone.

So now I'm seeing numbers more like ~2,650,000 bytecodes/sec and ~60,000
sends/sec.  I'd go back and compare to the swiki benchmark numbers but
minnow is down again.  (Is there some way I can help with minnow stability?
Donate hardware? Colocation?)

I'm going to recode for wallclock benchmarks shortly to make sure that there
aren't any lingering Linux timer issues in my port.

Jay