Support for Cell processor
Several boost libraries compile without any problem on the cell BE processor in PPU and SPU mode like most of the preprocessor or meta-programming one. However, it's impossible to use any C++ code that include *any* part of std cause it makes the resulting binary too big for the spu linker. For some boost libraries, the std include is merely used for some optionnal display. For others, large parts of functionnalities is made useless. As I've been toying with this architecture for quite a bit now, I'm on the verge to patch my local boost with a way to detect compilation on Cell SPU and to remove inadequate include from some libraries. Considering the potential interest in supporting this architecture, would libraries developpers mind if I submit ticket with patches for this support integration when the actual pacthes is aimed at making the core of the libraries to be used on Cell BE SPU and to add things like #error or #warning that explicitely states that this library or features is disabled ? What's the current stance on adding new architectural support into boost ? Regards -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On Mon, Oct 13, 2008 at 1:14 PM, Joel Falcou <joel.falcou@u-psud.fr> wrote:
Several boost libraries compile without any problem on the cell BE processor in PPU and SPU mode like most of the preprocessor or meta-programming one.
However, it's impossible to use any C++ code that include *any* part of std cause it makes the resulting binary too big for the spu linker. For some boost libraries, the std include is merely used for some optionnal display. For others, large parts of functionnalities is made useless.
As I've been toying with this architecture for quite a bit now, I'm on the verge to patch my local boost with a way to detect compilation on Cell SPU and to remove inadequate include from some libraries.
Considering the potential interest in supporting this architecture, would libraries developpers mind if I submit ticket with patches for this support integration when the actual pacthes is aimed at making the core of the libraries to be used on Cell BE SPU and to add things like #error or #warning that explicitely states that this library or features is disabled ? What's the current stance on adding new architectural support into boost ?
It is up to individual library developers to accept patches or not. But I think you will find most developers are receptive if the patches are complete and reasonable and don't have a lot of negative impact on the code.
For some boost libraries, the std include is merely used for some optionnal display.
I've toyed with the idea of proposing a standard BOOST macro form to deal with that. Using the filesystem library as an example, BOOST_FILESYSTEM_LOG would be used like this: #ifdef BOOST_FILESYSTEM_LOG # include <iostream> // needed only if logging enabled #endif --Beman
Beman Dawes a écrit :
It is up to individual library developers to accept patches or not. But I think you will find most developers are receptive if the patches are complete and reasonable and don't have a lot of negative impact on the code.
That's what I thought indeed. So i'll see and review which patches are actually not too intrusive. Is adding a new element to config/ acceptable tough ?
I've toyed with the idea of proposing a standard BOOST macro form to deal with that. Another solution would eb to provide a lightweight implementation of std for the Cell, with silent default behavior for unsupportable features. This way, code will compile. But I think that's out of the scope of Boost ?
___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Joel Falcou wrote:
Several boost libraries compile without any problem on the cell BE processor in PPU and SPU mode like most of the preprocessor or meta-programming one.
However, it's impossible to use any C++ code that include *any* part of std cause it makes the resulting binary too big for the spu linker. For some boost libraries, the std include is merely used for some optionnal display. For others, large parts of functionnalities is made useless.
As I've been toying with this architecture for quite a bit now, I'm on the verge to patch my local boost with a way to detect compilation on Cell SPU and to remove inadequate include from some libraries.
While I very much agree with the goal of this proposal, I also believe that boost is, for the most part, unsuitable for serious SPU code. I have been writing Cell algorithms (mixed PPU and SPU) for the last year and a half, and code-size was a serious issue. While we have been using C++ on the SPU side, too, we were extremely careful not only not to use the standard library, but also about whether to use templates, and template instances. FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Joel Falcou wrote:
However, it's impossible to use any C++ code that include *any* part of std cause it makes the resulting binary too big for the spu linker. For some boost libraries, the std include is merely used for some optionnal display. For others, large parts of functionnalities is made useless.
How does including a header generate bigger executables? I would say it's linking against the standard library that is a problem or not. Ideally, a good compiler should also be able to remove unused symbols at link-time, making that a non-issue.
Stefan Seefeld a écrit :
While I very much agree with the goal of this proposal, I also believe that boost is, for the most part, unsuitable for serious SPU code. I have been writing Cell algorithms (mixed PPU and SPU) for the last year and a half, and code-size was a serious issue. While we have been using C++ on the SPU side, too, we were extremely careful not only not to use the standard library, but also about whether to use templates, and template instances.
Well I do the same and I never felt oppressed by the overhead of template instanciation. I use MPL, Proto and function_traits all day long in various DSEL for the Cell and never encountered such problems. Mathias Gaunard a écrit :
I would say it's linking against the standard library that is a problem or not. Ideally, a good compiler should also be able to remove unused symbols at link-time, making that a non-issue.
Yes sorry of course. Seems in fact that it's linking with iostream that cause most of the problems. Concerning the quality of the compiler, well ... I won't anything :s
On Tue, Oct 14, 2008 at 2:40 AM, Joel Falcou <joel.falcou@u-psud.fr> wrote:
Stefan Seefeld a écrit :
Mathias Gaunard a écrit :
I would say it's linking against the standard library that is a problem or not. Ideally, a good compiler should also be able to remove unused symbols at link-time, making that a non-issue.
Yes sorry of course. Seems in fact that it's linking with iostream that cause most of the problems.
IIRC, <iostream> is the only standard library header that costs something to include even if the translation unit doesn't actually use it. That's because of the standard stream objects, cin, cout, etc. --Beman
Beman Dawes a écrit :
IIRC, <iostream> is the only standard library header that costs something to include even if the translation unit doesn't actually use it. That's because of the standard stream objects, cin, cout, etc.
Exactly and that's those only objects that skyrocket SPE binary size it seems.
2008/10/15 Joel Falcou <joel.falcou@u-psud.fr>:
Beman Dawes a écrit :
IIRC, <iostream> is the only standard library header that costs something to include even if the translation unit doesn't actually use it. That's because of the standard stream objects, cin, cout, etc.
Exactly and that's those only objects that skyrocket SPE binary size it seems.
I've noticed on another embedded platform that including the iostream libraries the binary more than doubles, in part because the linker only links in whole objects and each object refers to other parts that aren't functionally used, but are used based on the object references. In particular, it includes a lot of locale stuff that won't have any use on an embedded platform (since it's usually logging) but it'll be linked in anyway. On an embedded system with 1M of memory, eating 80k with iostreams is unacceptable, especially when it uses most of it for unused references. Using a better linker sounds great, but most embedded systems are hardlocked to whatever the system vendor gives you. In case of elf objects, they don't contain enough information to leave out unused symbols unless your compiler separates all symbols into a section per symbol, which it doesn't do by default. Given that the logging is optional (and probably pointless on an embedded system) #ifdeffing out the iostream header seems right.
On Wed, Oct 15, 2008 at 4:13 AM, Peter Bindels <dascandy@gmail.com> wrote:
Given that the logging is optional (and probably pointless on an embedded system) #ifdeffing out the iostream header seems right.
What macro? It seems to me there are really two cases: * Logging is desired. Perhaps BOOST_ALL_LOG and BOOST_libname_LOG (where libname is FILESYSTEM or whatever. * Avoiding <iostream> is desired if it can be done without crippling the library. Use cases are embedded systems and GUI systems. Perhaps BOOST_AVOID_IOSTREAM. Or should there be both overall and library specific versions? But this macro (or macros) isn't worth documenting if no libraries will actually use it. Are there cases other than when not logging where it is possible to avoid <iostream>? --Beman
Beman Dawes wrote:
On Wed, Oct 15, 2008 at 4:13 AM, Peter Bindels <dascandy@gmail.com> wrote:
Given that the logging is optional (and probably pointless on an embedded system) #ifdeffing out the iostream header seems right.
What macro?
It seems to me there are really two cases:
* Logging is desired. Perhaps BOOST_ALL_LOG and BOOST_libname_LOG (where libname is FILESYSTEM or whatever.
Being as how there are several proposed boost logging libraries I don't think this name is appropriate. BOOST_DISABLE_IOSTREAM or something similar would be more appropriate, wouldn't it? -- Michael Marcin
On Wed, Oct 15, 2008 at 11:11 AM, Michael Marcin <mike.marcin@gmail.com>wrote:
Beman Dawes wrote:
On Wed, Oct 15, 2008 at 4:13 AM, Peter Bindels <dascandy@gmail.com> wrote:
Given that the logging is optional (and probably pointless on an
embedded system) #ifdeffing out the iostream header seems right.
What macro?
It seems to me there are really two cases:
* Logging is desired. Perhaps BOOST_ALL_LOG and BOOST_libname_LOG (where libname is FILESYSTEM or whatever.
Being as how there are several proposed boost logging libraries I don't think this name is appropriate. BOOST_DISABLE_IOSTREAM or something similar would be more appropriate, wouldn't it?
That was the second case, which you didn't quote. But BOOST_DISABLE_IOSTREAM only deals with the case where <iostream> is present by default. There needs to be a way to enable logging or other <iostream> related activities that are off by default. --Beman
In message <a61d44020810141802p1960e717y7862680d72c00cc9@mail.gmail.com>, Beman Dawes <bdawes@acm.org> writes
On Tue, Oct 14, 2008 at 2:40 AM, Joel Falcou <joel.falcou@u-psud.fr> wrote:
Stefan Seefeld a écrit :
Mathias Gaunard a écrit :
...
Yes sorry of course. Seems in fact that it's linking with iostream that cause most of the problems.
IIRC, <iostream> is the only standard library header that costs something to include even if the translation unit doesn't actually use it. That's because of the standard stream objects, cin, cout, etc.
Perhaps <iosfwd> might be useful for some of the problems here? Alec -- Alec Ross
participants (7)
-
Alec Ross -
Beman Dawes -
Joel Falcou -
Mathias Gaunard -
Michael Marcin -
Peter Bindels -
Stefan Seefeld