tooling quality and some random rant
retard
re at tard.com.invalid
Mon Feb 14 13:58:25 PST 2011
Mon, 14 Feb 2011 13:00:00 -0800, Walter Bright wrote:
> In particular, instruction scheduling no longer seems to matter, except
> for the Intel Atom, which benefits very much from Pentium style
> instruction scheduling. Ironically, dmc++ is the only available current
> compiler which supports that.
I can't see how dmc++ is the only available current compiler which
supports that. For example this article (April 15, 2010) [1] tells:
"The GCC 4.5 announcement was made at GNU.org. Changes from GCC 4.4,
which was released almost one year ago, include the
* use of the MPC library to evaluate complex arithmetic at compile time
* C++0x improvements
* automatic parallelization as part of Graphite
* support for new ARM processors
* Intel Atom optimizations and tuning support, and
* AMD Orochi optimizations too"
GCC has supported i586 scheduling as long as I can remember.
[1] http://www.phoronix.com/scan.php?page=news_item&px=ODE1Ng
> > or whole program
>
> I looked into that, there's not a lot of oil in that well.
How about [2]:
"LTO is quite promising. Actually it is in line or even better with
improvement got from other compilers (pathscale is the most convenient
compiler to check lto separately: lto gave there upto 5% improvement
on SPECFP2000 and 3.5% for SPECInt2000 making compiler about 50%
slower and generated code size upto 30% bigger). LTO in GCC actually
results in significant code reduction which is quite different from
pathscale. That is one of rare cases on my mind when a specific
optimization works actually better in gcc than in other optimizing
compilers."
[2] http://gcc.gnu.org/ml/gcc/2009-10/msg00155.html
In my opinion the up to 5% improvement is pretty good compared to
advances in typical minor compiler version upgades. For example [3]:
"The Fortran-written NAS Parallel Benchmarks from NASA with the LU.A test
is running significantly faster with GCC 4.5. This new compiler is
causing NAS LU.A to run 15% better than the other tested GCC releases."
[3] http://www.phoronix.com/scan.php?
page=article&item=gcc_45_benchmarks&num=6
> > and instruction level optimizations the very latest GCC and LLVM are
> > now
> slowly adopting.
>
> Huh? Every compiler in existence has done, and always has done,
> instruction level optimizations.
I don't know this area well enough, but here is a list of optimizations
it does http://llvm.org/docs/Passes.html - from what I've read, GNU GCC
doesn't implement all of these.
> Note: a lot of modern compilers expend tremendous effort optimizing
> access to global variables (often screwing up multithreaded code in the
> process). I've always viewed this as a crock, since modern programming
> style eschews globals as much as possible.
I only know that modern C/C++ compilers are doing more and more things
automatically. And that might soon include automatic vectorization +
multithreading of some computationally intensive code via OpenMP.
More information about the Digitalmars-d
mailing list