<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Philippe Marschall wrote:
<blockquote
 cite="mid:66666f210809271515g49f8cadw6f14929ac217637@mail.gmail.com"
 type="cite">
  <pre wrap="">2008/9/27 Joshua Gargus <a class="moz-txt-link-rfc2396E" href="mailto:schwa@fastmail.us">&lt;schwa@fastmail.us&gt;</a>:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Philippe Marschall wrote:

2008/9/26, Jason Johnson <a class="moz-txt-link-rfc2396E" href="mailto:jason.johnson.081@gmail.com">&lt;jason.johnson.081@gmail.com&gt;</a>:


On Thu, Sep 25, 2008 at 9:15 PM, Igor Stasenko <a class="moz-txt-link-rfc2396E" href="mailto:siguctua@gmail.com">&lt;siguctua@gmail.com&gt;</a> wrote:


2008/9/25 Chris Kassopulo <a class="moz-txt-link-rfc2396E" href="mailto:ckasso@sprynet.com">&lt;ckasso@sprynet.com&gt;</a>:


<a class="moz-txt-link-freetext" href="http://www.lesser-software.com/en/content/products/lswvst/lswvst.htm">http://www.lesser-software.com/en/content/products/lswvst/lswvst.htm</a>




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?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Such things happen automatically if you compile with only one
compiler. </pre>
</blockquote>
<br>
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?<br>
<br>
<blockquote
 cite="mid:66666f210809271515g49f8cadw6f14929ac217637@mail.gmail.com"
 type="cite">
  <pre wrap="">You can observe it every time a new GCC version comes out
that is more standard conformant a lot of software breaks. </pre>
</blockquote>
<br>
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" :-). <br>
<br>
<blockquote
 cite="mid:66666f210809271515g49f8cadw6f14929ac217637@mail.gmail.com"
 type="cite">
  <pre wrap="">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.
  </pre>
</blockquote>
<br>
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).<br>
<br>
Given this context (which is of course not necessarily what the
conversation meant to you, subjectively), what are we talking about
here?  :-)<br>
<br>
<blockquote
 cite="mid:66666f210809271515g49f8cadw6f14929ac217637@mail.gmail.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
But slower. </pre>
</blockquote>
<br>
Squeak compiled with GCC is faster when gnuify is used.  But Squeak
compiled with ICC is faster still.  On what do you base your assertion
that it is slower?<br>
<br>
<blockquote
 cite="mid:66666f210809271515g49f8cadw6f14929ac217637@mail.gmail.com"
 type="cite">
  <pre wrap="">You don't actually pay for this, do you?

  </pre>
</blockquote>
<br>
For my personal Squeaking, of course I wouldn't pay for ICC.  But if
someone is working for a company whose product is performance
sensitive, why wouldn't they spend a few hundred dollars to improve
performance as much as $10000s of engineering effort would, especially
if it reduces time-to-market?<br>
<br>
Cheers,<br>
Josh<br>
<br>
<br>
<blockquote
 cite="mid:66666f210809271515g49f8cadw6f14929ac217637@mail.gmail.com"
 type="cite">
  <pre wrap="">Cheers
Philippe

  </pre>
</blockquote>
<br>
</body>
</html>