in reply to New optimizations in GCC 4.0 and Perl

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
  • Comment on Re: New optimizations in GCC 4.0 and Perl

Replies are listed 'Best First'.
Re^2: New optimizations in GCC 4.0 and Perl
by polettix (Vicar) on Apr 22, 2005 at 16:46 UTC
    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]
Re^2: New optimizations in GCC 4.0 and Perl
by petdance (Parson) on Apr 23, 2005 at 01:57 UTC
    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]
Re^2: New optimizations in GCC 4.0 and Perl
by wazoox (Prior) on Apr 22, 2005 at 23:48 UTC

    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]
        OK, thanks for the details.
[reply]

In Section Seekers of Perl Wisdom