dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

GCC 4.0 has just been released, including a completely new optimizer and other features. Now, I don't understand the import of these features vis-a-vis perl, mod_perl, Apache, and other OSS projects. Would someone more versed in these arcane incantations please explain?

My wife's blog

Replies are listed 'Best First'.
Re: New optimizations in GCC 4.0 and Perl
by samizdat (Vicar) on Apr 22, 2005 at 14:25 UTC
    I don't see anything scary in the changelog, but IMHO this is a case of "Never, EVER buy a first year car!" This is a completely new branch dot-zero release, and it just came out Wednesday.

    I'd suggest setting up a mule machine and seeing how your base system responds to a make build/installworld using the new GCC. Until you have the system and kernel compiling well, I would say that Perl and mod_perl should be considered of lesser importance. Certainly it would be criminally stupid to swap out your system's supplied gcc for 4.0 in any kind of an environment that you depend on for either your workstation or a production environment. Many of the improvements are in the speed of the optimizer. There are some goodies that I'd be interested in benching, but, like any optimization, YMMV. Nothing here is worth risking a nickel for.

    What I do see -- besides the optimizer and threading improvements -- is the inclusion of more standard containers. I think this will add power to future programming, but, of course, it's a matter of having code that _uses_ them. :D
[reply]
      Until you have the system and kernel compiling well, I would say that Perl and mod_perl should be considered of lesser importance.
      I messed a bit with Linux From Scratch in the past, and I remained impressed by the fact that GCC 3.x hasn't ever been officially supported for kernel compilation. In LFS, in fact, they suggest installing a parallel GCC 2.95.3, which is officially supported by the kernel guys.

      While I don't know if this still holds true currently (as I said, I did it some 4-5 months ago), I would certainly be VERY concerned to compile the base system with a brand newly-versioned compiler; I'd rather begin with less pervasive stuff such modules or Perl itself, reversing the path you suggest, using a compiler located in an ad-hoc, out-of-standard paths and probably installing this newly-compiled Perl itself into an isolated branch of the filesystem.

      Just my 2c worth tip, anyway.

      Update: corrected English syntax in one sentence, thanks blyman.

      Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))')

      Don't fool yourself.
[reply]
        That's why I specified a 'mule' system, Flavio. For any system other than a raw throwaway, I agree heartily.

        My compatriot who has bee nworking his way up through the 3's on SPARC/Solaris is going to start working with it (4.0) and let me know. He will, of course, use your approach, because the systems he admins have too many $millions riding on them. :D
[reply]
      Then again, they're already on to 4.1, which I've been building Perl for a while, and its compiler is a good deal smarter in finding C problems.

      I understand the fear of x.0.0, but it's not as if it's fresh.

      xoxo,
      Andy

[reply]

      In the slashdot discussion someone mentioned the new Mac OS X, Tiger, as compiled with GCC 4.0. Though that looks pretty unbelievable to me at first glance, if that proves to be true it would mean that GCC 4.0 is certainly "production quality".

      I very much doubt Apple would release such a blockbuster, with resounding trumps, bells and whistles if it wasn't.

[reply]

        Had to do look it up. I think they meant built including GCC 4.0 and not built using 4.0. Apple, in this article says this about it.

        The compiler version matters because changes to the Application Binary Interface since Mac OS X v10.0 have rendered C++ and Objective-C++ executables incompatible with earlier releases. However, C and Objective-C programs still run the same. To build for 10.1 and earlier you must use version 2 of GCC for C++/Obj-C++ applications and kernel extensions; version 2.95.2 was the GCC final release that shipped with Mac OS X v10.1. GCC version 3.1 shipped with Mac OS X v10.2 Jaguar, and 3.3 with Mac OS X v10.3 Panther. Note that if you mix languages in the application you should rebuild using the appropriate compiler version: 2.95.2 for Mac OS X v10.0 and v10.1, 3.1 for v10.2 Jaguar, and 3.3 for v10.3 Panther.
        Addendum:
        Further research turned up a more direct reference.
        Along with improvements to the GUI, Xcode 2.0 will ship with GCC 4.0 which features a new C++ Parser and several code generation improvements including auto-vectorization. While hand-tuning Velocity Engine code can get you the maximum performance from the G4 and G5 processors, now you can have GCC do the heavy lifting for you. You'll benefit from this without any extra effort, with auto-vectorization in GCC bringing anywhere between a 4X and 14X performance improvement to code that works with arrays of data.
        Note, the article specifically refers only to the XCode toolset. Although I guess we can't infer from that anything about how the binaries were built.
        s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}
[reply]
Re: New optimizations in GCC 4.0 and Perl
by Anonymous Monk on Apr 22, 2005 at 13:41 UTC
[reply]
Re: New optimizations in GCC 4.0 and Perl
by starbolin (Hermit) on Apr 22, 2005 at 15:41 UTC

    I can't speak to Apache or mod_perl but I have had to deal with cross_version compatibility issues with GCC and other modules.

    Of course the GCC developers try for backwards compatability and many modules compile fine with any version of the compilers. Compiler optimization are, by nature, machine dependant and often an optimization that works on one platform will break another platform. I've been working with the ATLAS libraries. These use a very agressive optimzation strategy. Turns out the strategy has been shown to only works with GCC 2.4. When I upgraded my OS my GCC got upgraded to 3.4.2 which broke ATLAS for me:-{

    Many modules should see little difference between GCC versions but those that are compiled using optimizations can see version dependence. As to the new features of GCC 4.0, as dwildesnl says: "it's a matter of having code that _uses_ them. :D"

    s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}
[reply]
Re: New optimizations in GCC 4.0 and Perl
by samizdat (Vicar) on Apr 25, 2005 at 14:20 UTC
    Further update. According to Alan, both 3.4.3 and 4.0 have problems on non-Linux systems. Evidently, they are expecting functions in the base system libc that do not exist on numerous OSen. More details as I connect with him today.
[reply]
Re: New optimizations in GCC 4.0 and Perl
by samizdat (Vicar) on Apr 25, 2005 at 16:16 UTC
    According to my compatriot, when linking in libstc++, the linker generates an error message saying that __eprintf() is linking to a hidden symbol in libgcc.a. If said symbol is defined in libc, the program is fine. What makes it appear that this is a deeply-embedded kludge is that this is not uncommon across various environments and that there are other symbols that cause the same error, sometimes even when using the supposedly-correct completed compiler to compile other programs. Alan has been sifting lists for several months now trying to uncover a solution for 3.4.3, and the problem seems to have continued unsolved in 4.0. He's working on Solaris 5.6, but reports that others have similar problems in other environments.

    Alan is experienced enough (far more than I) that he would not be making silly mistakes. He's devoted quite a few solid days of work to the problem.
[reply]

Back to Seekers of Perl Wisdom