Re: [microblaze-uclinux] OT?, Performance

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Emanuel,

emanuel stiebler wrote:

>> On Wed, 12 May 2004, emanuel stiebler wrote:
>>
>>> Anybody had some thoughts already, why there is such a BIG
>>> difference between the numbers on xilinx web, and the dhrystones
>>> we measure here ?

> Between the "grades" there is a difference of few percent.
> I'm talking about a difference bewteen 600 KMIPS and 50 KMIPS ...

I'm speculating, but the benchmarks posted on the xilinx website will be 
for bare metal implementations, just the benchmark code running directly 
on the microblaze (no OS), probably from BRAM memory space, and probably 
utilising the microblaze's native harvard-style split instruction/data 
bus topology.  It is likely that the interrupt pin is not even 
connected...

On the other hand, the dhrystone application running under uclinux is 
being scheduled alongside any other processes, there are at least 4 
devices capable of interrupting the processor (including the timer which 
does so every 10ms), there is interrupt dispatch code that must run 
every time, we tie the instruction and data buses together (von-neumann 
architecture), run from external DDR using BRAM only as cache, and so on.

Basically, it's the computational efficiency penalty of using a full 
operating system.  As embedded systems designers, it's our job to assess 
the performance tradeoff against whatever it is we gain from using 
something like uClinux (interoperability, standard development platform, 
application portability etc etc).

However, as Matthew R. has noted, doing this in the FPGA domain gives us 
much greater flexibility in terms of hardware acceleration.  So, a major 
point of doing this microblaze uClinux thing is the design and 
implementation flexibility to help us get the best of both worlds.. or 
at least the flexibility to find a feasible mixed SW/HW solution where 
purely SW or purely HW might be impossible (simply not enough processor 
cycles), or impractical (build a webserver purely from logic?  Why?!)

That said, there's still plenty of room for optimisation in the 
microblaze-specific parts of the kernel port.

Regards,

John

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/