Marcus G. Daniels wrote:
Marcus G. Daniels wrote:
Mike Houston wrote:
The main issue with this, and addressed at the end
of the report, is that the code size is going to be a problem as data
and code must live in the same 256KB in each SPE. They mention dynamic
overlay loading, which is also how we deal with large code size, but
things get tricky and slow with the potentially needed save and restore
of registers and LS.
I did some checking on this. Apparently the trunk of GCC and the
latest GNU Binutils handle overlays. Because the SPU compiler knows of
its limits address space, the ELF object code sections reflect this, and
the the linker can transparently generate stubs to trigger the
loading. GCC also has options like -ffunction-sections that enable the
linker to optimize for locality.
So even though the OpenMPI shared libraries in total appear to have a
footprint about four times too big for code alone (don't know about the
typical stack & heap requirements), perhaps it's still doable without a
big effort to strip down OpenMPI?
But loading an overlay can be quite expensive depending on how much
needs to be loaded and how much user data/code needs to be restored. If
the user is trying to use most of the LS for data, which is perfectly
sane and reasonable, then you might have to load multiple overlays to
complete a function. We've also been having issues with mixing manual
overlay loading of our code with the autoloading generated by the compiler.
Regardless, it would be interesting to see if this can even be made to
work. If so, it might really help people get apps up on Cell since it
can be reasonably thought of as a cluster on a chip, backed by a larger
address space.
-Mike
