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. You can observe it every time a new GCC version comes out
that is more standard conformant a lot of software breaks. 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.

> To me, it seems like FUD to disparage a compiler for inability to compile
> non-standard code.
>
> Maybe even Squeak thanks to gnuify.
>
> No, gnuify transforms the code to make it run faster on GCC, but if you
> don't apply gnuify, it will compile fine with other compilers.

But slower. You don't actually pay for this, do you?

Cheers
Philippe