2008/9/28 Joshua Gargus <schwa at fastmail.us>:
> Philippe Marschall wrote:
>
> 2008/9/27 Joshua Gargus <schwa at fastmail.us>:
>
>
> Philippe Marschall wrote:
>
> 2008/9/26, Jason Johnson <jason.johnson.081 at gmail.com>:
>
>
> On Thu, Sep 25, 2008 at 9:15 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>
>
> 2008/9/25 Chris Kassopulo <ckasso at sprynet.com>:
>
>
> http://www.lesser-software.com/en/content/products/lswvst/lswvst.htm
>
>
>
>
> It would be nice to look at it (LSWV).
> So many cool features. Too bad its proprietary. :(
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
> Is the cost prohibitive?  Dolphin wasn't free, but it was really cheap
> and a quality product.  Keep in mind that while programming languages
> have been largely "commoditized"  the best implementations of many
> languages still cost money.  E.g. you want the best C compiler?  It's
> not GCC.  Buy the Intel compiler and watch your code run twice as
> fast.
>
>
>
>
> Let me preface this by saying that I support free software, and use it in
> preference to proprietary software when possible.  However, I disagree with
> much of what you say.
>
> If you define best best as "longest bar in some benchmark".
>
> I define best as "producing the best performance for the program that I am
> interested in compiling".
>
> Intel doesn't manage to charge serious money for their compiler because it
> is better on some synthetic benchmark but worse in the real world.  Maybe
> GCC has mostly caught up with 4.3, but there's no doubt that ICC has
> traditionally generated faster code.  I don't have extensive/varied personal
> experience with ICC, but if you compile Squeak with it on Intel, you'll see
> a 20% speed-up on macro benchmarks.
>
> If you
> want to run your software only on Intel chips, no AMD, no Motorola, no
> Sun, no ....
>
> First, it's simply not true that Intel's compiler doesn't work for AMD.
> After surfing around for 15min or so, I learned:
> - at various times in the past, AMD chose ICC as the compiler they used to
> generate SPEC benchmarks.
> - there are numerous personal accounts where ICC generates the fastest code
> for AMD for their pet application.
>
> Typically, Intel CPUs have a higher percentage improvement by using ICC
> instead of GCC, but AMD CPUs also benefit.
>
> Also, many applications don't target PowerPC, Sparc, or ARM.  For desktop
> apps, x86 is the name of the game.  I don't feel limited by using an
> x86-only compiler, especially since I can write my code to compile with a
> different compiler for other platforms.
>
> If you want to put up with all kinds of trouble and
> issues compiling software that was written with GCC in mind like all
> the GNU/Linux software.
>
> That's an interesting angle.  Many Free software lovers would consider code
> that uses specific features of Microsoft's C compiler to be broken.  I
> generally agree with them; unless there is a good reason for it (and there
> sometimes is, just as it sometimes makes sense to write x86 assembly),
> compiler-specific code is a bug.  Why should it be any different for
> GNU-specific code?
>
>
> Such things happen automatically if you compile with only one
> compiler.
>
> Right, but that doesn't make it a good thing.  We do agree that it's not a
> good thing to accidentally make choices that limit Squeak to a single
> compiler, don't we?  If not, why is taking choice away a good thing?
>
> You can observe it every time a new GCC version comes out
> that is more standard conformant a lot of software breaks.
>
> We're not talking about the steady improvements in standard C/C++
> compliance.  We're talking about intentional, compiler-specific extensions
> that are not part of the C/C++ standards.  That's why it's called "gnuify"
> not "standardize" :-).

I was talking about unintentional use of of compiler-specific
extensions that are not part of the C/C++ standards or reliance on
implementation specific behavior. That happens a lot and often results
in breakage in never GCC releases. For example the current vitualbox
does not compile with the current release of GCC (4.3) and qemu does
not build with any version 4 of GCC.

> You can
> also see it with Squeak. A lot of code has empty statements and temps
> declared in a too wide scope. Once we get a new compiler that supports
> closures or you compile it with a more standard conformant compiler,
> that code has to be updated.
>
>
> I'm not sure what we're talking about any more.  I initially responded to a
> message from you that seemed very dismissive of Jason's point, namely that
> in particular circumstances, it may make sense to pay for your language
> implementation.  For some reason, I felt compelled to argue that despite
> your somewhat glib dismissal, there exist real situations where it makes
> sense to use ICC (therefore lending support to Jason's more general claim).

Suddenly we have a much more more differentiated statement that it's
much easier to a agree on than "ICC is the best compiler, it makes
your code run twice as fast".

Cheers
Philippe