[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] OT?, Performance
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
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.
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/