Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

HP/UX, Solaris, AIX support

bret675
Beginner
747 Views

I'm looking into the possibility of integrating the use of TBB into future versions of the product I'm working on here at IBM/Tivoli. I'm still in the early investigative phase and plan on doing some prototyping beforehand. My biggest concern from browsing the forums/etc is the lack of support for non-intel based platforms. Some of the forum/community searches show work was/has been done for other platforms; however, I've not seen any build support for any of the above platforms in the latest releases. AIX appears to have had some work done over a year ago by vonmatt, however it appears to have stalled and no future work appears from a year ago. Also the amount of low level work, assembly!, required to port is a bit intimidating!

For me to be able to use this package I'd have to support, at a minimum, Windows (you have good support for all these) 32/64bit, AIX 32/64bit, HP/UX 32/64bit, Solaris 32/64bit, and Linux 32/64bit. This is the minimum support I'd need today (minus 64bit which is likely coming very soon), though going forward linux PPC and Z/OS zlinux are high probabilities, as I've had to support them in past versions.

I'm not against doing the work to port TBB myself, however a lot of the code appears to be very platform and cpu implementation specific (assembly!) and porting to all these platforms at that level is quite a bit beyond my current skillset, though learning is not that difficult and would be very interesting, the time investment required is stretching it a bit.

What I'm asking I guess is how hard and how much community support would there be for porting to the above platforms? I'm very interested in cutting edge parallel programming to save me time and effort, right now I manage it myself through threads etc and while it works it's not very adaptive to the large variance in cpu's and cpu cores our customers have.

This is something I'd be interested in porting/using early/mid next year if that time line is even conceivable. Given that I have to Company approval to both contribute to the project AND use the library with our product the time line is very unpredictable.

Thoughts?

0 Kudos
1 Solution
ARCH_R_Intel
Employee
747 Views
Quoting - bret675

If it takes until retirement to have a standardized API for atomic operations then it'll be a sad day for the Software industry.

It's coming in the next C++ standard. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdffor the draft.

It's not all that hard to port the TBB to new hardware as long as the OS has pthreads. Look at tbb/include/machine/ibm_aix51.h and tbb/include/machine/mac_ppc.h for examples of minimal ports. The AIX port also involves an extra source file src/tbb/ibm_aix51/atomic_support.c . The minimum requiments are to define fences and compare-and-swap. Fancier ports define other operations.

View solution in original post

0 Kudos
14 Replies
RafSchietekat
Valued Contributor III
747 Views

"early/mid next year if that time line is even conceivable" Most of the work has already been done, so that's an easy time frame (as long as you don't want to use aCC with PA-RISC...).

0 Kudos
bret675
Beginner
747 Views
Quoting - Raf Schietekat

"early/mid next year if that time line is even conceivable" Most of the work has already been done, so that's an easy time frame (as long as you don't want to use aCC with PA-RISC...).

That's great news! When will there be makefiles available for those platforms or are you hinting I'd only need to write the makefiles? Also we use aCC on AIX so yea I'd need that. I'm new to TBB so I probably missed something related to aCC and PA-RISC.. I use the platform specific native compilers on all the platforms, we can't use GCC except on Linux because of the redistribution requirements of the GCC libraries. VC 2003 on windows, gcc 3.2 on linux, aCC on AIX, etc.

0 Kudos
RafSchietekat
Valued Contributor III
747 Views

"That's great news! When will there be makefiles available for those platforms or are you hinting I'd only need to write the makefiles?" I'm talking about the patch in the "Additions to atomic" thread (get the latest version), so you can start testing right now and find out for yourself what is still missing. It's also a good base for further ports. Note that many ports are for g++ only at this time because of assembler syntax (9 hardware architectures), but Studio 12 on Sun Solaris is supposed to understand it too. I can give you a few pointers on how to develop this further, but I've already had my bit of fun, so for anything more substantial you should probably contact me directly. I'm not sure what's cooking at Intel at this time or what their plans are.

"Also we use aCC on AIX so yea I'd need that." An HP compiler on an IBM operating system?

"I'm new to TBB so I probably missed something related to aCC and PA-RISC.." The issue with aCC is that HP seems to already have abandoned it on PA-RISC (if it doesn't give spurious errors, it outright crashes), so if you want modern C++ with a PA-RISC back end you need g++. HP has done substantial work on aCC for Itanium, but somehow didn't allocate the additional resources to make that work available elsewhere, even though g++ seems to continually manage to do so. Maybe it's possible to strip the atomics innovations from the patch, getting rid of the template metaprogramming, and succeed that way (the scalable memory allocator works on PA-RISC/HP-UX/aCC), but that didn't appeal to me.

"I use the platform specific native compilers on all the platforms, we can't use GCC except on Linux because of the redistribution requirements of the GCC libraries." How exactly is that a problem? If you use the patch, you'll be dealing with the GPL too (with runtime exception). But I thought that this meant that you only have to provide or point to the materials you used (including modifications), without any need to disclose your private code. A small burden, I would think.

"VC 2003 on windows, gcc 3.2 on linux, aCC on AIX, etc." I haven't tracked Microsoft compiler versions. You'll have to verify whether g++ 3.2 is suitable with the patch, which uses some fancy template metaprogramming to support its additional features and has been developed with 4.0.3. Don't you mean XL on AIX?

0 Kudos
bret675
Beginner
747 Views
Quoting - Raf Schietekat

"That's great news! When will there be makefiles available for those platforms or are you hinting I'd only need to write the makefiles?" I'm talking about the patch in the "Additions to atomic" thread (get the latest version), so you can start testing right now and find out for yourself what is still missing. It's also a good base for further ports. Note that many ports are for g++ only at this time because of assembler syntax (9 hardware architectures), but Studio 12 on Sun Solaris is supposed to understand it too. I can give you a few pointers on how to develop this further, but I've already had my bit of fun, so for anything more substantial you should probably contact me directly. I'm not sure what's cooking at Intel at this time or what their plans are.

"Also we use aCC on AIX so yea I'd need that." An HP compiler on an IBM operating system?

"I'm new to TBB so I probably missed something related to aCC and PA-RISC.." The issue with aCC is that HP seems to already have abandoned it on PA-RISC (if it doesn't give spurious errors, it outright crashes), so if you want modern C++ with a PA-RISC back end you need g++. HP has done substantial work on aCC for Itanium, but somehow didn't allocate the additional resources to make that work available elsewhere, even though g++ seems to continually manage to do so. Maybe it's possible to strip the atomics innovations from the patch, getting rid of the template metaprogramming, and succeed that way (the scalable memory allocator works on PA-RISC/HP-UX/aCC), but that didn't appeal to me.

"I use the platform specific native compilers on all the platforms, we can't use GCC except on Linux because of the redistribution requirements of the GCC libraries." How exactly is that a problem? If you use the patch, you'll be dealing with the GPL too (with runtime exception). But I thought that this meant that you only have to provide or point to the materials you used (including modifications), without any need to disclose your private code. A small burden, I would think.

"VC 2003 on windows, gcc 3.2 on linux, aCC on AIX, etc." I haven't tracked Microsoft compiler versions. You'll have to verify whether g++ 3.2 is suitable with the patch, which uses some fancy template metaprogramming to support its additional features and has been developed with 4.0.3. Don't you mean XL on AIX?

Sorry yes I meant aCC on HPUX and not AIX. I realized I'd gotten them confused a few hours after posting..

I was able to successfully compile the latest "stable" release on windows and linux, so it appears g++ 3.2 is suitable.

The product I work on has pieces of code developed 14 years ago so it was originally written and compiled with very old compilers, much like a vast majority of the software at Tivoli. It's rare, if ever, your able to just write a product from complete scratch. This means we build upon 100's of thousands, if not millions, of lines of code written with a specific build environment and compiler expectation which is weeks if not months of risky work to port forward to new or different compilers. If we don't develop on old code we integrate at link time or runtime with code built on very old compilers. This year I spent a month upgrading all of our code so we could use STL and IOStreams because our old code base predated the standard iostreams and STL. So we are now more current than usual, though still using compilers predating 2000 for most platforms.

We use to use g++ to cross compile for all unix platforms, however about 2 years ago we went back and moved every platform off of g++ in order to to use the native compiler. I wasn't involved in the decision and currently traveling so can't walk down the hall and find out why we moved off g++. I'm assuming it's either legal issues or the fact compiling with g++ causes a lot of distribution and interoperability problems with your product and other products compiled with g++ (usually different versions).

I use a lot of STL and template programming on HPUX with aCC so not sure what you are refering too above. It seems to run fine and work great so far. Moving from the old streams model to the new one required a lot of specific compile time and link time options to force aCC to use the new rogue wave implementation but once those were figured out it runs well and is very solid.

I am primarily interested in the parallel_for, parallel_while, pipelines and task scheduler etc code. I could do without the very optimized versions of the containers and atomic operations that require all of this specific platform dependent code. A very simple, but portable, implementation would be more useful for me. I realize the use of atomic operations give a much higher level of parallelism but it really introduces a lot of portability issues and compiler dependencies, all of which will reduce the adoption rate in the near term. I might just end up using the parallel patterns and ideas present in TBB to implement a small subset in house that is more portable and not reliant on assembly implementations of atomic operations. I'm not a huge fan of g++ for large projects because of the link time and runtime issues of integration multiple products built with different versions of g++. Getting an organization as large as IBM to "standardize" on a single version of a compiler is an exercise in futility. Native compilers are much more tolerant of linking and interoperating with other libraries compiled with different versions than gcc/g++ from my experience.

I just finished (except examples section at end which I'm still working on) reading the book "Intel threading building blocks" by James Reinders . Very useful book for learning TBB and the parallel patterns it employs. So even if the portability issues of TBB prevent me from using it I've still learned enough from it to model a small portable implementation after the patterns it used.

Thanks for your help. I might try porting TBB to AIX or HPUX native compilers and see how it goes. If it goes well I might look into doing more, otherwise wait for cross platform atomic operations to be more standardized. It'd really be nice if C/C++ had atomic operations in the standard.

0 Kudos
RafSchietekat
Valued Contributor III
747 Views

"Sorry yes I meant aCC on HPUX and not AIX. I realized I'd gotten them confused a few hours after posting.." The important thing is: PA-RISC (trouble at C++ level, negligeable assembler required because it does not have hardware support for atomic operations anyway) or Itanium (will probably require porting the Itanium assembler syntax, the most challenging of all architectures, from GNU inline to .s files)?

"I was able to successfully compile the latest "stable" release on windows and linux, so it appears g++ 3.2 is suitable." But can you compile TBB with the patch on the architectures not supported by a "stable" release? I've done it with 3.4.6 on PA-RISC, so it may work.

"I use a lot of STL and template programming on HPUX with aCC so not sure what you are refering too above." Just try the patch on PA-RISC and you'll see (make tbbmalloc works, but make tbb...). It may be salvageable, but that's not something I'd like to try for fun.

"Moving from the old streams model to the new one required a lot of specific compile time and link time options to force aCC to use the new rogue wave implementation but once those were figured out it runs well and is very solid." (When I had to write code without being able to decide about -AA, I just conditionally injected all the types into namespace std, and so my code was indifferent with regard to Classic or Standard Runtime.)

"I could do without the very optimized versions of the containers and atomic operations that require all of this specific platform dependent code." The high-level stuff builds on the low-level stuff, you cannot separate them.

"Thanks for your help. I might try porting TBB to AIX or HPUX native compilers and see how it goes." Bon courage.

"If it goes well I might look into doing more, otherwise wait for cross platform atomic operations to be more standardized." That probably won't just happen by itself.

"It'd really be nice if C/C++ had atomic operations in the standard." By the time C++0x gets to be the least common denominator in the environment you described, you may have retired already. :-)

0 Kudos
bret675
Beginner
747 Views
Quoting - Raf Schietekat

"Sorry yes I meant aCC on HPUX and not AIX. I realized I'd gotten them confused a few hours after posting.." The important thing is: PA-RISC (trouble at C++ level, negligeable assembler required because it does not have hardware support for atomic operations anyway) or Itanium (will probably require porting the Itanium assembler syntax, the most challenging of all architectures, from GNU inline to .s files)?

"I was able to successfully compile the latest "stable" release on windows and linux, so it appears g++ 3.2 is suitable." But can you compile TBB with the patch on the architectures not supported by a "stable" release? I've done it with 3.4.6 on PA-RISC, so it may work.

"I use a lot of STL and template programming on HPUX with aCC so not sure what you are refering too above." Just try the patch on PA-RISC and you'll see (make tbbmalloc works, but make tbb...). It may be salvageable, but that's not something I'd like to try for fun.

"Moving from the old streams model to the new one required a lot of specific compile time and link time options to force aCC to use the new rogue wave implementation but once those were figured out it runs well and is very solid." (When I had to write code without being able to decide about -AA, I just conditionally injected all the types into namespace std, and so my code was indifferent with regard to Classic or Standard Runtime.)

"I could do without the very optimized versions of the containers and atomic operations that require all of this specific platform dependent code." The high-level stuff builds on the low-level stuff, you cannot separate them.

"Thanks for your help. I might try porting TBB to AIX or HPUX native compilers and see how it goes." Bon courage.

"If it goes well I might look into doing more, otherwise wait for cross platform atomic operations to be more standardized." That probably won't just happen by itself.

"It'd really be nice if C/C++ had atomic operations in the standard." By the time C++0x gets to be the least common denominator in the environment you described, you may have retired already. :-)

Ok sounds like I need to roll my own portable enterprise solution. Too bad when I first read about TBB being STL based for compatibility I got excited because I thought it meant I just needed a standard C++ compiler,it turns out the devil is in the details. Instead it's relies on "language extensions" implemented as assembly modules to support atomic operations.

If it takes until retirement to have a standardized API for atomic operations then it'll be a sad day for the Software industry.

Thanks for all the clarification.

0 Kudos
ARCH_R_Intel
Employee
748 Views
Quoting - bret675

If it takes until retirement to have a standardized API for atomic operations then it'll be a sad day for the Software industry.

It's coming in the next C++ standard. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdffor the draft.

It's not all that hard to port the TBB to new hardware as long as the OS has pthreads. Look at tbb/include/machine/ibm_aix51.h and tbb/include/machine/mac_ppc.h for examples of minimal ports. The AIX port also involves an extra source file src/tbb/ibm_aix51/atomic_support.c . The minimum requiments are to define fences and compare-and-swap. Fancier ports define other operations.

0 Kudos
RafSchietekat
Valued Contributor III
747 Views

Of course, in this tough economic climate, a little company like IBM cannot afford to sponsor outside development... :-)

0 Kudos
RafSchietekat
Valued Contributor III
747 Views

Arch: "The minimum requiments are to define fences and compare-and-swap. Fancier ports define other operations."

"bret675", I should have made clear(er) that I'm only interested in "fancy" ports based on the "Additions to atomic" patch (with additional memory semantics capabilities etc.), which taxes the compiler more by its use of some template metaprogramming techniques, but that porting a "stable" release (without these additions) might very well be doable on PA-RISC/aCC. I'm not interested to do this just for fun, but I would not want to discourage you from trying this, and you're welcome to reuse some code from the patch according to its license (GPL with runtime exception). Other targets can still use the patch directly, or you can repeat the same exercise.

0 Kudos
bret675
Beginner
747 Views
It's coming in the next C++ standard. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf for the draft.

It's not all that hard to port the TBB to new hardware as long as the OS has pthreads. Look at tbb/include/machine/ibm_aix51.h and tbb/include/machine/mac_ppc.h for examples of minimal ports. The AIX port also involves an extra source file src/tbb/ibm_aix51/atomic_support.c . The minimum requiments are to define fences and compare-and-swap. Fancier ports define other operations.

Excellent. I think I can manage to do those items for the platforms I want to use. For the near future a simple portable moderate solution is desireable. Fancier and thus faster solutions I can wait for.

0 Kudos
bret675
Beginner
747 Views
Quoting - Raf Schietekat

Arch: "The minimum requiments are to define fences and compare-and-swap. Fancier ports define other operations."

"bret675", I should have made clear(er) that I'm only interested in "fancy" ports based on the "Additions to atomic" patch (with additional memory semantics capabilities etc.), which taxes the compiler more by its use of some template metaprogramming techniques, but that porting a "stable" release (without these additions) might very well be doable on PA-RISC/aCC. I'm not interested to do this just for fun, but I would not want to discourage you from trying this, and you're welcome to reuse some code from the patch according to its license (GPL with runtime exception). Other targets can still use the patch directly, or you can repeat the same exercise.

Thanks. Personally the entire platform could of been implemented with Standard Mutex's and Semaphores and I'd be happy to use it. The scalable parallelism itself would of been worth the extra locking overhead for the short term. Fancier solutions are desireable but not at the expense of portability. The biggest challenge I personally have is designing software that performs well on 1-2 cores but also scales very well to 8 or 32 cpu's and cores. We have several 16+ cpu customers using our software, but we also have many end user "desktop" style machines with only 1-2 cores.

Task based programming seems like a good approach to solving this challenge.

Are these fancier solutions going to cause a problem for me when the next release is intergated into the main branch? I'd hate to port over a standard release and then the next release is not usable because it requires g++ and contains other non-portable solutions?

0 Kudos
RafSchietekat
Valued Contributor III
747 Views

"Are these fancier solutions going to cause a problem for me when the next release is intergated into the main branch?" The patch is an independent effort, any integration is unsure.

0 Kudos
Alexey-Kukanov
Employee
747 Views
Quoting - bret675
Are these fancier solutions going to cause a problem for me when the next release is intergated into the main branch? I'd hate to port over a standard release and then the next release is not usable because it requires g++ and contains other non-portable solutions?

Let me assure you that, when working on integration of Raf's patch into the main trunk, we will make every effort to maintain the non-advanced ports developed for 2.1 applicable; though possibly some little changes might be required.

0 Kudos
bret675
Beginner
747 Views

Let me assure you that, when working on integration of Raf's patch into the main trunk, we will make every effort to maintain the non-advanced ports developed for 2.1 applicable; though possibly some little changes might be required.

Excellent. I'll be diving in head first soon.

0 Kudos
Reply