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