Toon Knapen wrote:
Greg Lindahl wrote:
http://www.openib.org/docs/oib_wkshp_022005/mpi-abi-pathscale-lindahl.pdf
mostly talks about why we need an ABI, who wins and loses as a result
of having one, and the pieces that could be in it. Please give it a
look.
The presentation ignores the issue of instruction set. Even within the
x86 family
we have IA-32, EMT 64, and AMD-64.
Beyond that, there are IA-64 and PowerPC clusters with interesting
market share, plus the
odd PlayStation MIPS machines.
Beyond that, we have the situation where toolchains have incompatible
formats and
calling standards, even for the same architecture. Shall we standardize
on GCC? On
IFC? (I note EKOPATH is GNU compatible.)
Beyond that, an ABI stifles performance. The compiler (in principle at
least)
could do interprocedural optimizations between the application and MPI
libraries.
Or inlining.
Even just shipping code as binary forces the vendor into poorly
optimized code, in order
to assure functionality on different models of machines. RPMs are not
usually compiled
with -O3 -pipe -fomit-frame-pointer, for example. And what about -g?
Take a look
at the way gentoo systems regularly trounce other distributions in
performance.
Optimization makes a difference.
Use the source.
-Larry
