Good day Martin,
GCC is a *very* bad compiler.
Clang is not really 'future music' we can build a bootable FreeBSD
kernel and 99% of the userland using it.
As I said, C++ support needs improvement but that is where Sun's
participation can help.. and the solaris kernel does not have any C++
code so it does not matter here..
I think switching from GCC to Clang/LLVM for shadow compiling and
static analysis is a very sane idea, analysis and diagnosis is where
Clang shines and GCC is totally useless.
I'll give you a really clear easy example:
bash-3.2$ cat t.c
int main() {
int i=5;
if(i == 6); {
return 6;
}
return 5;
}
bash-3.2$ gcc -W t.c
t.c: In function 'main':
t.c:5: warning: empty body in an if-statement
bash-3.2$ clang t.c
t.c:5:11: warning: if statement has empty body [-Wempty-body]
if(i == 6); {
^
1 diagnostic generated.
In fact, Sun is already investing time in LLVM for a similar project:
http://research.sun.com/projects/parfait/
Using the full Clang compiler suit and contributing code back to a
*worthwhile* compiler with a future is far more worth the time of both
the community and Sun.
Clang/LLVM is the future, GCC is the past !
Best Regards,
Edward.
2009/9/13 Uros Nedic <urosn at live.com>:
> I completely agree that Clang/LLVM is alternative, but
> also I disagree that GCC should take over Sun Studio
> space. From my perspective GCC would never achieve
> performance level as Sun Studio has. It is just about
> architecture and design of compilers.
>
> Clang/LLVM, as I said is alternative but only in performance
> tuning and optimizing code during development process.
> I do not see it as a final compiler solution, to be honest.
> This position is reserved for Sun Studio.
>
> Uros
>
>
> -----------------------------------------------
> "Every kind of peaceful cooperation among men
> ?is primarily based on mutual trust and only
> ?secondarily on institutions such as courts of
> ?justice and police."
>
> ?- Albert Einstein (1879 - 1955)
>
>
>
>> Date: Sun, 13 Sep 2009 05:33:42 +0300
>> From: martin at martux.org
>> To: victoredwardocallaghan at gmail.com
>> CC: Nicolas.Williams at sun.com; xwin-discuss at opensolaris.org;
>> LSARC-ext at sun.com; PSARC-ext at sun.com; Bart.Smaalders at sun.com
>> Subject: Re: [xwin-discuss] Consolidations (Re: Obsolescence of /usr/X11)
>>
>> On Sun, Sep 13, 2009 at 12:25 AM, Edward O'Callaghan
>> <victoredwardocallaghan at gmail.com> wrote:
>> > You guys,
>> >
>> > Who cares about GCC..
>> >
>> > We have Clang/LLVM now.. Which is *much* faster then GCC in any way
>> > that I can at least think of.
>> > Sure it needs some more work and C++ support is not quite there yet
>> > however its come a long way and its a great bit of software both in
>> > code quality and what it can do in contrast to GCC..
>> >
>> > Please *do* try it out !
>> >
>> > Cheers,
>> > Edward.
>>
>>
>> *** Sorry for being on lists, where this post might seem semi-OT ***
>> *** But I dont want to drop out without this (at least for now
>> concluding?) response ***
>>
>>
>> Hello Edward, my friend.
>> Very interesting.
>> But to me this looks more like future music, if you talk about the
>> compiler with which OpenSolaris gets built.
>>
>> Look: gcc support *is* inside OS/Net for a long time already.
>> All the problematic port, ARC and integration stuff has been done for
>> it (mostly by Keith Wesolowski!!!) long ago in 2005 and finally spring
>> 2006.
>>
>> Saying, Solaris gets built with Studio, was not entirely right.
>> In fact all which Studio happens to be by default, is the primary
>> compiler, while gcc is then the shadow compiler. You can inverse this
>> by putting a single variable into the build environment:
>>
>> __GNUC=""; export __GNUC
>>
>> And furthermore: No shadow compilation is required at all (at your
>> local computer). You can also disable the Debug build, lint and other
>> options.
>>
>> To disable shadow compilation:
>>
>> CW_NO_SHADOW=1; export CW_NO_SHADOW
>>
>> In other words: Everything is functional (exclusively with a gcc that
>> has sfw consolidation? csl-sol210-3_4-20050802 diffs patched in!!). So
>> that is the difference:
>> While you suggested something completely cool and amazing (yet quite
>> experimental), I spoke about something that can be changed in an
>> ultra-short period (Obviously: plus more testing and debugging
>> afterwards, plus later performance enhancements [maybe]).
>>
>> Plus: When Solaris 10 FCS, err GA came out, it was the first public
>> release with native amd64 support. And there gcc had been used to
>> compile the amd64 kernel, and it was not just something like a shadow
>> compiler with all object files being discarded. Instead they had been
>> linked and then shipped in a major Enterprise production release.
>>
>> SUNWspro did not yet support amd64 at that time.
>>
>> Octave: Your other points look reasonable, but you probably didnt
>> perform these tests with a patched GCC4.4, did you? Certainly even
>> better gcc-results then ...
>>
>> And a few other questions which I have (as of how you have benchmarked
>> what) . But before we continue the compiler discussion, I perform a
>> few new tests myself. Then let us just compare and see.
>> Anyway: I think Sun should rather engage in gcc and make it FASTER.
>> And drop Studio. Campare it to having EOLed Xsun vs. actively
>> contributing to Xorg.
>>
>> Just my opinion.
>>
>>
>> regards,
>> %martin
>>
>>
>> > 2009/9/12 Octave Orgeron <unixconsole at yahoo.com>:
>> >> Hi,
>> >>
>> >> I've seen this as the case with the following types of applications:
>> >>
>> >> 1. HPC applications where Sun Studio optimization can help out
>> >> considerably. This is the same in Linux/x86 shops who use non-gcc
>> >> compilers
>> >> for better optimizations.
>> >> 2. Financial applications that process TB's of data for analysis. Would
>> >> usually see about 20-30% improvement here.
>> >> 3. Web Applications and tools. A few years back I use to work for a web
>> >> hosting company and found that apache, perl, mysql, and qmail worked
>> >> faster
>> >> when compiled with Sun Studio.
>> >> 4. SPEC benchmarks. These benchmarks do perform better with the Sun
>> >> Studio compiler. Use to run these benchmarks to compare different server
>> >> models and platforms.
>> >>
>> >> Now on a more practical side..
>> >>
>> >> 1. Solaris itself is compiled with Sun Studio.
>> >> 2. Take something like Quake 3 Arena and compare the performance
>> >> between it being compiled on Sun Studio vs GCC, you'll see a difference
>> >> while playing.
>> >> 3. Just 3 years ago I recompiled all the open source tools (compilers,
>> >> interpreted languages, xml tools, numerical libraries, etc.) we were using
>> >> at a investment company. The question was posed if Sun Studio would make
>> >> faster binaries and libraries. We did tests against some of the key tools
>> >> and found that at least a 10-20% performance improvement was seen.
>> >>
>> >> So from my experience, I've seen a difference since Sun Studio 10
>> >> onwards and use it for all the software I compile. I think there is a lot
>> >> of
>> >> value in it.
>> >>
>> >> Now, I've seen the same kinds of results on other non-x86 platforms
>> >> where the vendor compiler or a 3rd party compiler performed better than
>> >> GCC.
>> >> While it works on many platforms, it is not highly optimized on them.
>> >> Obviously, Sun Studio is only on Solaris SPARC/x86 and Linux x86. It would
>> >> be interesting to see Sun Studio on Power to support the OpenSolaris port
>> >> there. But I don't know how difficult it would be to open source Sun
>> >> Studio
>> >> and do something like that. Of course, Sun was wise to buy Forte years
>> >> ago,
>> >> which I remember since I was in IT/Ops back then in the bay area. It may
>> >> not
>> >> seem like it on the surface, but it was a great investment and helped
>> >> Sun's
>> >> development tools and at the end of the day the performance increases in
>> >> Solaris 9 considerably.
>> >>
>> >>
>> >> ?*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>> >> Octave J. Orgeron
>> >> Solaris Virtualization Architect and Consultant
>> >> Web: http://unixconsole.blogspot.com
>> >> E-Mail: unixconsole at yahoo.com
>> >>
>> >> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>> >>
>> >>
>> >>
>> >> ----- Original Message ----
>> >> From: Martin Bochnig <martin at martux.org>
>> >> To: Octave Orgeron <unixconsole at yahoo.com>
>> >> Cc: Nicolas Williams <Nicolas.Williams at sun.com>;
>> >> xwin-discuss at opensolaris.org; Alan Coopersmith <Alan.Coopersmith at
>> >> sun.com>;
>> >> Bart Smaalders <Bart.Smaalders at sun.com>; LSARC-ext at sun.com;
>> >> PSARC-ext at sun.com
>> >> Sent: Friday, September 11, 2009 4:13:45 PM
>> >> Subject: Re: Consolidations (Re: [xwin-discuss] Obsolescence of
>> >> /usr/X11)
>> >>
>> >> On Fri, Sep 11, 2009 at 7:53 PM, Octave Orgeron <unixconsole at yahoo.com>
>> >> wrote:
>> >>> I disagree on the points about the sun studio compilers. I've seen
>> >>> better binary and optimization results with sun studio than with GCC.
>> >>> I've
>> >>> worked with GCC on other platforms, Power and Alpha.. and needless to say
>> >>> it's a dog. All the development on GCC is really focused on x86 and most
>> >>> optimizations for other platforms come from the vendors. Sun Studio on
>> >>> the
>> >>> other hand has a great tool set and the fact that it is free should make
>> >>> the
>> >>> idea of using GCC dead in my opinion. If anything, just more work around
>> >>> dealing with GCC-isms would help compile and build FOSS apps. However,
>> >>> the
>> >>> bigger issue on that front is that many of those FOSS apps are starting
>> >>> to
>> >>> loose site of the UNIX philosophy of being easily portable between
>> >>> platforms. So even if you use GCC, it may not work.
>> >>>
>> >>>
>> >>> ?*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>> >>> Octave J. Orgeron
>> >>> Solaris Virtualization Architect and Consultant
>> >>> Web: http://unixconsole.blogspot.com
>> >>> E-Mail: unixconsole at yahoo.com
>> >>>
>> >>> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>> >>
>> >>
>> >>
>> >>
>> >> Octave, this was true 20 years ago.
>> >> Which kind of benchmark did you perform yourself?
>> >> Yes, also on SPARC?
>> >>
>> >> The results might surprise you.
>> >>
>> >>
>> >> But whatever, if nobody believes me, I will prove it.
>> >> I dont like to fight with / against community fellows.
>> >> When we have some precise numbers, we can continue our discussion.
>> >>
>> >>
>> >> Until then, regards,
>> >> %martin
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> xwin-discuss mailing list
>> >> xwin-discuss at opensolaris.org
>> >>
>> >
>> >
>> >
>> > --
>> > All Documents adhered to the ISO/IEC 26300 ?standard file format for
>> > electronic office documents, such as spreadsheets, charts,
>> > presentations and word processing documents from this email address.
>> > The author does not take responsibility of the recipients inability to
>> > read international standards and who use proprietary products such as
>> > MS Office.
>> > See: http://www.openoffice.org/
>> > Edward O'Callaghan.
>> > --
>> > http://fedoraproject.org/wiki/EdwardOcallaghan
>> > http://moonshine.opn4.org/
>> > http://www.pcbsd.org/
>> > _______________________________________________
>> > xwin-discuss mailing list
>> > xwin-discuss at opensolaris.org
>> >
>> _______________________________________________
>> xwin-discuss mailing list
>> xwin-discuss at opensolaris.org
>
> ________________________________
> check out the rest of the Windows LiveT. More than mail-Windows LiveT goes
> way beyond your inbox. More than messages
--
All Documents adhered to the ISO/IEC 26300 standard file format for
electronic office documents, such as spreadsheets, charts,
presentations and word processing documents from this email address.
The author does not take responsibility of the recipients inability to
read international standards and who use proprietary products such as
MS Office.
See: http://www.openoffice.org/
Edward O'Callaghan.
--
http://fedoraproject.org/wiki/EdwardOcallaghan
http://moonshine.opn4.org/
http://www.pcbsd.org/
