This discussion is archived
7 Replies Latest reply: Nov 15, 2012 1:12 PM by Steve_Clamage RSS

g++ compatibility / STL / boost and Qt / OpenMP

919808 Newbie
Currently Being Moderated
Hello everyone.

I am currently evaluating several compilers to maybe speed up an existing project that does heavy number crunching. Amongst others, I also gave the compiler suite that comes with the Oracle Solaris Studio a try and I am having a few questions that I'd kindly like to ask here. Thanks for any suggestions/informations/hints in advance.

1]
Since I do not want to recompile all dependencies (amongst others Qt, boost, ...) for the project, I was trying to use the new -compat=g flag but CC spit out more errors than one would imagine. It was unable to find the appropriate pathes and all and even after setting them accordingly with the appropriate -I flag, it choked on most of what it found. What is the correct way of using the -compat=g flag and what environment variables/flags do I have to set as well? I guess gcc 4.6 (which is the version I have installed) is not yet supported and won't really work?

2]
Am I assuming correctly that if I use -compat=g or use stlport4, I cannot make use of the optimized math library that comes with the compiler suite as a replacement for the regular libm?

3]
The project I am trying to compile, makes heavy use of the STL and boost. The standard libCstd does not support every feature - which also goes for some of the project's dependencies as well. Is the stlport4 or the native g++ stl the only way to solve this?

4]
With every compile, I get "CC: Warning: failed to detect system linker version, falling back to custom linker usage". I was unable to figure out what the actual repercussions are and how I could eventually fix this. If someone could please shed any light on this, it would be greatly appreciated.

5]
I have a small test program which basically is a loop that iterates UINT32_MAX times and does some calculation. I use OpenMP's parallel for without any hint to scheduling, number of threads or such. All compilers (g++, icc, path64) I tried, correctly put out 8 threads to handle the load. Except for the version compiled with solaris studio compiler. It only launched two threads and came in last. After manually forcing it to 8 threads (OMP_NUM_THREADS=8), it worked like a charm and even took the lead. Again, it is a simple and stupid test. But I wonder what I am missing because it should not be the user's job to set the right number of thread for his machine.

By the way, all tests have been performed on a x86_64 Linux system (Gentoo) w/ gcc 4.6.2 and Studio 12.3 (tar).

Thanks again and have a nice weekend,
matthias.
  • 1. Re: g++ compatibility / STL / boost and Qt / OpenMP
    SFV Newbie
    Currently Being Moderated
    x86_64 Linux system (Gentoo) w/ gcc 4.6.2 and Studio 12.3 (tar).
    Sorry, Gentoo is not a supported system (though something might still work).

    And gcc 4.6.2 is definitely not supported for -compat=g. Actually anything higher than 4.3 is very likely not to work.
    Its headers contain alot of gcc'isms and Studio 12.3 is not able to handle it all.
    I do not believe it is possible to workaround these problems.

    We gradually move towards being able to work with modern gcc's, but our main target is gcc version installed by default on supported Solarises.
    And Solaris is not that quick in adopting latest gcc versions either.
    Am I assuming correctly that if I use -compat=g or use stlport4, I cannot make use of the optimized math library that comes with the compiler suite as a replacement for the regular libm
    Math stuff is not C++ specific, so it does not matter what -compat mode or STL do you use.
    heavy use of the STL and boost. The standard libCstd does not support every feature - which also goes for some of the project's dependencies as well. Is the stlport4 or the native g++ stl the only way to solve this?
    We claim support for Boost with -compat=5 -library=stlport4 mode only.
    With every compile, I get "CC: Warning: failed to detect system linker version, falling back to custom linker usage".
    Old Linux linkers (GNU ld, versions predating 2.20) are not able to properly handle C++ objects generated by Studio.
    We ship slightly modified GNU ld which has these problems fixed, for C++ to work on RedHat5/OracleLinux5.
    However that custom linker is an old one (version 2.17.90), so it wont work with system libraries on modern Linuxes.
    On RH6/OL6 we were able to force system linker (2.20) to work properly.
    Hence CC tries to detect system linker version and apply a workaround.
    It seems that your system linker has --version output that CC cant match, so it runs old linker shipped with Studio.
    Its not going to do anything good :(
    I have a small test program which basically is a loop that iterates UINT32_MAX times and does some calculation. I use OpenMP's parallel for without any hint to scheduling, number of threads or such. All compilers (g++, icc, path64) I tried, correctly put out 8 threads to handle the load. Except for the version compiled with solaris studio compiler. It only launched two threads and came in last. After manually forcing it to 8 threads (OMP_NUM_THREADS=8), it worked like a charm and even took the lead. Again, it is a simple and stupid test. But I wonder what I am missing because it should not be the user's job to set the right number of thread for his machine.
    Wonder what kind of hardware do you have?
    Starting number of threads is a "static" decision performed by OpenMP runtime at the start of the paralllel region and is implementation-defined (thus any choice is ok wrt OpenMP standard).
    I dont remember whats our heuristics for this decision is right away, but it should be something proportional to the number of CPUs.
    It is nearly impossible to make an efficient decision for every program/hardware combo.
    Either our heuristics happens to not match your test program, or the runtime fails to detect the number of CPUs on your system.

    regards,
    __Fedor.

    Edited by: SFV on Feb 24, 2012 4:22 PM
  • 2. Re: g++ compatibility / STL / boost and Qt / OpenMP
    919808 Newbie
    Currently Being Moderated
    Sorry, Gentoo is not a supported system (though something might still work).
    I know. That goes for most software, actually... and one gets used to it, if you do not use one of the major distros. But on the other hand, it rarely causes any problems that cannot be solved.
    And gcc 4.6.2 is definitely not supported for -compat=g. [...]
    Ah, okay. Thanks for that information. That explains a lot and I will stay clear of it in the future until I read otherwise in the release logs. :)
    Math stuff is not C++ specific, so it does not matter what -compat mode or STL do you use.
    At least that door for a good speed up is still open. Nice to hear.
    We claim support for Boost with -compat=5 -library=stlport4 mode only.
    -library=stlport4 implies -compat=5, if I am not mistaken? Or -compat=5 is the default anyways. I remember having read something about it.
    It seems that your system linker has --version output that CC cant match, so it runs old linker shipped with Studio.
    Its not going to do anything good :(
    Is there any way I can workaround that or force the compiler to use my linker nevertheless?
    Wonder what kind of hardware do you have?
    Core i7 860 (4 real cores + 4 HT).
    Either our heuristics happens to not match your test program, or the runtime fails to detect the number of CPUs on your system.
    I would guess it is most likely the latter. Is there any way I can force debug information about this?

    Thanks for your swift answer by the way, it is very much appreciated.

    So long
    matthias
  • 3. Re: g++ compatibility / STL / boost and Qt / OpenMP
    SFV Newbie
    Currently Being Moderated
    -library=stlport4 implies -compat=5,
    Yes, that was somewhat ambiguous.
    We claim the support for Boost with -library=stlport4 only.

    You might get a reasonable set of Boost libraries working fine with -compat=g. But then again, -compat=g does not work for you..
    Is there any way I can workaround that or force the compiler to use my linker nevertheless?
    I cant see non-cumbersome workarounds currently. Will get back to it later.

    regards,
    __Fedor.
  • 4. Re: g++ compatibility / STL / boost and Qt / OpenMP
    919808 Newbie
    Currently Being Moderated
    I cant see non-cumbersome workarounds currently. Will get back to it later.
    For now, I've replaced the bundled "ld" with a symlink to the system one. :)

    By the way, doing a strace revealed nothing interesting. 27796 was the pid of the system ld which simply processed the version option. But still, you can see the version string which maybe not quite to the liking of suncc:

    <... setregid resumed> ) = 27796
    --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=27796, si_status=0, si_utime=0, si_stime=0} (Child exited) ---
    [ Process PID=27791 runs in 32 bit mode. ]
    open("/tmp/gnuld_version.1330099288.27791.03", O_RDONLY) = 3
    fstat64(3, {st_mode=S_IFREG|0644, st_size=266, ...}) = 0
    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff718f000
    read(3, "GNU ld (GNU Binutils) 2.22\nCopyr"..., 4096) = 266
    read(3, "", 4096) = 0
    write(2, "CC: Warning: ", 13CC: Warning: ) = 13
    write(2, "failed to detect system linker v"..., 76failed to detect system linker version, falling back to custom linker usage
    ) = 76

    Hope that helps.

    Thanks again for your help.

    So long,
    matthias
  • 5. Re: g++ compatibility / STL / boost and Qt / OpenMP
    974389 Newbie
    Currently Being Moderated
    khaos wrote:
    write(2, "failed to detect system linker v"..., 76failed to detect system linker version, falling back to custom linker usage
    A hack (and it's just that) is to edit bfd/configure, changing PKGVERSION="(GNU binutils) " to "*PKGVERSION="version "*. That changes the version text from GNU ld (GNU Binutils) 2.23 to simply GNU ld version 2.23 which is recognized by CC as a valid version string. Rebulld and install that modified version of the binutils package.

    Edited by: user1398506 on Nov 15, 2012 1:03 AM
  • 6. Re: g++ compatibility / STL / boost and Qt / OpenMP
    SFV Newbie
    Currently Being Moderated
    That changes the version text from GNU ld (GNU Binutils) 2.23 to simply GNU ld version 2.23 which is recognized by CC
    Indeed, CC matches version text with "GNU ld version" string. This is what linker on our supported platforms reports.

    A good news is that we might drop shipping modified linker (and thus there will be no need for linker detection) in a future release.

    regards,
    __Fedor.
  • 7. Re: g++ compatibility / STL / boost and Qt / OpenMP
    Steve_Clamage Pro
    Currently Being Moderated
    [posted by mistake]

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points