|
Message
From: Justin Young<fuzz22@i...>
Date: Thu Jul 15 16:05:20 CEST 2004
Subject: [oc] Why open processors are so much slower than commercial ones?
Thank you for pointing that our Austin.
You are right, what I meant by markup was that it goes faster! I worded that
quite badly! Sorry everyone!
> Actually, this, in my experience, is not true. It is rare, these days,
> that you can hand compile code that runs
>faster than a compiler can, especially code of any size. Compilers have
>come a very long way over the past few decades.
You are right, but I recently compared a matrix multiply program (hence my
reference earlier) assembled by hand and compared it with gcc, and hand
compiled code ran a lot faster. But do note, it is only a small program.
But as you very correctly mentioned, its up to the writer of the code to
understand the architecture and the compiler to get the most out of it. For
a very complex system like hardware compilers it's hard for developers
describing hardware in the language to really know how the interpretation
stage and hardware compiler stages actually work.
I've been working with modifying a MIPS processor to suit my needs of late,
and I've found that the closest a developer can get to a hand optimizing
your VHDL compilation is to edit make sure the compiler understands what you
mean by looking at the Fitter Equations, and you can optimize speed
(sometimes) by looking at the floorplan and trying to make the clocks
propagation length smaller. It's a difficult task!
So I guess in closing, it may be for these reasons that a Xilinx written
MicroBlaze will work best for a Xilinx FPGA. Xilinx know the quirks of their
system, and the way their hardware compilation works.
I wonder if Xilinx (or Altera) go to the extend of analyzing the compilers
of their competitors, and find out what how to make the MicroBlaze code
compile to run slower/less efficient on the other brand FPGA's as to keep
their competitive advantage???
-----Original Message-----
From: Austin Franklin [mailto:austin@d...]
Sent: Thursday, 15 July 2004 10:06 PM
To: Discussion list about free open source IP cores
Subject: RE: [oc] Why open processors are so much slower than commercial
ones?
Hi Justin,
> Similar to if you try to compile a matrix multiple program (for example)
> with the C compiler GCC, compared to by hand, you'll find that you get a
> HUGE markup in execution time doing it by your self. Compilers aren't very
> smart!!
Not quite sure what you are saying here, it seems to be contradictory. You
say "you get a HUGE markup in execution time doing it by your self" which,
to me, means it runs slower... I think you meant to say the opposite, that
you believe it will run faster if you hand compile it, as you then say
"Compilers aren't very smart". Actually, this, in my experience, is not
true. It is rare, these days, that you can hand compile code that runs
faster than a compiler can, especially code of any size. Compilers have
come a very long way over the past few decades.
> So I suggest that maybe they have closed to hand compiled the core, making
> sure all the blocks are laid out very cleverly to reduce clock delay and
> skew.
You are probably correct, but keep in mind, software does not have
placement/routing, and FPGA hardware does...what this means, is there is yet
another level of complexity beyond compilation that attributes to FPGA
hardware performance. The hardware compilers are in fact reasonably good
these days, but there have been no real improvements in placement/routing,
algorithmically that is.
The saving grace is that FPGA manufacturers are making faster chips with
more resources. Kind of the same reason the PC runs so fast, even with bad
C code. And speaking of bad code, it is really essential, for using any
compiler, that the code writer understand what the compiler does with what
constructs, as some will compile more "efficiently" than others. It helps
to run a few test cases of different methods of writing the same algorithm
and seeing what the compiler does.
Regards,
Austin
|
 |
Browse
