SPEC ist schon seit Jahren ein Kasperletheater sondersgleichen, Apple
hätte das am besten einfach weggelassen und sich nicht an diesem
Kollektiv-Beschiss beteiligen sollen!
Sun kann nur dank exorbitanter Werte in 179.art/SpecFP konkurrieren,
IBM linkt alle L3-Caches eines CPU-Moduls auf eine CPU für den
SPEC-Test und Intel schreibt eben Fortran-Compiler explizit für die
SPEC-Suite, die auf optimierte Libs zurückgreifen, die dann aber eben
nicht mehr viel von Genauigkeit halten! Aber egal, hauptsache hohe
SPEC-Werte!
Schön, dass so auf Apples "laxer" IEEE-Math rumgeritten wird obwohl
wohl kein einziges Intel-System auf spec.org was anderes macht.
Schön fand ich an dem Artikel, dass dann doch nicht mit
spec.org-Werten verglichen sondern lieber selbst getestet wurde!
SPEC ist sowieso nur für Wissenschaftler interessant (oder bitte WER
setzt sonst FORTRAN ein, *die* Messlatte für Fliesskommaleistung??
Und ist M$VC nicht der mit Abstand populärste Compiler, auch
nicht-vektorisierend und mit SCHLECHTERM Code als GCC?), aber wenn
der P4 bei den Einstellungen, die für solche SPEC-Werte wie auf
spec.org notwendig waren dann im Gegenzug FALSCHE ERGEBNISSE liefert,
dann mögen das die Herren Wissenschaftler dann doch eher nicht!
Warten wir ab, bis sich IBM des "Problems" annimmt und sie
VisualAge-Werte für ihre P970-Systeme bei der SPEC einreichen -
schliesslich hat man einen Ruf zu verteidigen! ;-)
Falls die auch noch mit dem Altivec-autovektorisierenden Compiler
gemacht wurden, den Peter Sandon schon angekündigt hat werden wir
beobachten können, wie sämtliche PC-Advokaten plötzlich sehr schnell
in de Chrous "SPEC ist eh irrelevant" einstimmen werden! ;-)
http://news.zdnet.co.uk/story/0,,t271-s2136537,00.html
"Peter Glaskowsky, editor-in-chief of Microprocessor Report, said a
company could get better benchmark results using a Dell machine with
Intel and Microsoft compilers than with a Linux machine and GCC
compiler. However, he also noted that Intel's chips perform
disproportionately well on SPEC's tests because Intel has optimised
its compiler for such tests."
http://www.osnews.com/comment.php?news_id=3931&limit=no#117135
"I have been using Intel's C++ compiler for building my crypto apps
and I can say that ICC's (or ICL's) optimization can lead to UNFAIR
and inaccurate results.
In Schoondermark's benchmark test, the following ICL equivalent
options should have been used with gcc (also applicable with MinGW):
-O3 -march=pentium4 -ffast-math -mfpmath=sse2 -fforce-addr
-fomit-frame-pointer -funroll-loops -frerun-cse-after-loop
-frerun-loop-opt -malign-functions=4
ICL/ICC does a lot of optimizations behind your back, some even alter
the logic of your code, which is UNFAIR when used in benchmarks.
Currently when using -O3 with ICL 7.1, the following "unfair"
optimization is enabled:
-Qparallel
[...]
I find the compiler debate lame when people don't realise that GCC is
designed to generate reliable and accurate code, whereas ICC/ICL is
designed to generate faster code that makes unacceptable sacrifices
at times.
For example, STLport works reliably in GCC with all optimizations
turned on. For ICC/ICL, this isn't always the case!"
"Order of logic execution does change the meaning of code. Other
compilers don't do it because of the bad side effects that are a
result of this. Benchmarks should not only take speed into account
but reliability and accuracy as well. If not then the benchmarks are
unfair/unpractical.
Incorrect code generation by ICC/ICL has happened to me more than
once! Especially math operations that are floating point intensive.
-Magg"
"The code I use and write is not broken in anyway. ICC/ICL breaks the
code by making incorrect optimizations.
At times ICL/ICC can't even compile code that is plain correct.
Recently I helped a bunch of students to optimize their game code. We
tried optimizing SDL using it and it failed often that we dropped it
and used GCC instead.
Try compiling SDL_gamma.c (included in the SDL 1.2.5 sources) with
"all" optimizations turned on and tell me if it doesn't fail!"
DeeKay
hätte das am besten einfach weggelassen und sich nicht an diesem
Kollektiv-Beschiss beteiligen sollen!
Sun kann nur dank exorbitanter Werte in 179.art/SpecFP konkurrieren,
IBM linkt alle L3-Caches eines CPU-Moduls auf eine CPU für den
SPEC-Test und Intel schreibt eben Fortran-Compiler explizit für die
SPEC-Suite, die auf optimierte Libs zurückgreifen, die dann aber eben
nicht mehr viel von Genauigkeit halten! Aber egal, hauptsache hohe
SPEC-Werte!
Schön, dass so auf Apples "laxer" IEEE-Math rumgeritten wird obwohl
wohl kein einziges Intel-System auf spec.org was anderes macht.
Schön fand ich an dem Artikel, dass dann doch nicht mit
spec.org-Werten verglichen sondern lieber selbst getestet wurde!
SPEC ist sowieso nur für Wissenschaftler interessant (oder bitte WER
setzt sonst FORTRAN ein, *die* Messlatte für Fliesskommaleistung??
Und ist M$VC nicht der mit Abstand populärste Compiler, auch
nicht-vektorisierend und mit SCHLECHTERM Code als GCC?), aber wenn
der P4 bei den Einstellungen, die für solche SPEC-Werte wie auf
spec.org notwendig waren dann im Gegenzug FALSCHE ERGEBNISSE liefert,
dann mögen das die Herren Wissenschaftler dann doch eher nicht!
Warten wir ab, bis sich IBM des "Problems" annimmt und sie
VisualAge-Werte für ihre P970-Systeme bei der SPEC einreichen -
schliesslich hat man einen Ruf zu verteidigen! ;-)
Falls die auch noch mit dem Altivec-autovektorisierenden Compiler
gemacht wurden, den Peter Sandon schon angekündigt hat werden wir
beobachten können, wie sämtliche PC-Advokaten plötzlich sehr schnell
in de Chrous "SPEC ist eh irrelevant" einstimmen werden! ;-)
http://news.zdnet.co.uk/story/0,,t271-s2136537,00.html
"Peter Glaskowsky, editor-in-chief of Microprocessor Report, said a
company could get better benchmark results using a Dell machine with
Intel and Microsoft compilers than with a Linux machine and GCC
compiler. However, he also noted that Intel's chips perform
disproportionately well on SPEC's tests because Intel has optimised
its compiler for such tests."
http://www.osnews.com/comment.php?news_id=3931&limit=no#117135
"I have been using Intel's C++ compiler for building my crypto apps
and I can say that ICC's (or ICL's) optimization can lead to UNFAIR
and inaccurate results.
In Schoondermark's benchmark test, the following ICL equivalent
options should have been used with gcc (also applicable with MinGW):
-O3 -march=pentium4 -ffast-math -mfpmath=sse2 -fforce-addr
-fomit-frame-pointer -funroll-loops -frerun-cse-after-loop
-frerun-loop-opt -malign-functions=4
ICL/ICC does a lot of optimizations behind your back, some even alter
the logic of your code, which is UNFAIR when used in benchmarks.
Currently when using -O3 with ICL 7.1, the following "unfair"
optimization is enabled:
-Qparallel
[...]
I find the compiler debate lame when people don't realise that GCC is
designed to generate reliable and accurate code, whereas ICC/ICL is
designed to generate faster code that makes unacceptable sacrifices
at times.
For example, STLport works reliably in GCC with all optimizations
turned on. For ICC/ICL, this isn't always the case!"
"Order of logic execution does change the meaning of code. Other
compilers don't do it because of the bad side effects that are a
result of this. Benchmarks should not only take speed into account
but reliability and accuracy as well. If not then the benchmarks are
unfair/unpractical.
Incorrect code generation by ICC/ICL has happened to me more than
once! Especially math operations that are floating point intensive.
-Magg"
"The code I use and write is not broken in anyway. ICC/ICL breaks the
code by making incorrect optimizations.
At times ICL/ICC can't even compile code that is plain correct.
Recently I helped a bunch of students to optimize their game code. We
tried optimizing SDL using it and it failed often that we dropped it
and used GCC instead.
Try compiling SDL_gamma.c (included in the SDL 1.2.5 sources) with
"all" optimizations turned on and tell me if it doesn't fail!"
DeeKay