NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Hmmm (Score:1)
A for the Sun pro compiler vs. gcc. The only code that I have encountered that compiles on gcc and not on Sun pro is code that uses gcc specific 'enhancements'. In my experience, Sun pro compiled code is at least as fast as code compiled with gcc, and often faster. Some years ago I benchmarked perl (compiled with Sun pro vs compiled with gcc). The Sun pro compiled perl was 10 to 20 procent faster.
As for gcc being more actively maintained, that may be, but does that help people running Sun hardware? Sun hardware had gone 64 bits (even for their low level stuff) for quite some time before gcc was able to generate 64 bit binaries on a Sun platform. The Sun compiler had no problems with it of course.
Given the choice, I'd pick Sun pro over gcc.
And in general, I would pick a native compiler over a general compiler. I remember Mereijn doing tests on AIX, comparing gcc vs the IBMs native compiler, and finding the perl compiled with gcc significantly slower.
Reply to This
Re: (Score:2)
It's been a while since I last used Solaris, but I never have encountered the problems you describe. Unlike most of the Linux distros I've worked with, Sun comes a long way of insuring that its own Perl dependent utilities still work if you change the default installation of perl. The main idea being that /usr/bin/perl is a link to someplace else. All the OSses scripts use the path of where /usr/bin/perl links to, leaving the admin free to replace /usr/bin/perl. It won't break any of the OSses scripts.
T
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers