Author: Vincent Diepeveen
Date: 07:14:09 04/20/02
It has been some years that a compiler beated microsoft
dominated software, so that's why i post here the result i had
after a week of experimentations with intel c++.
Intel(R) C++ Compiler for 32-bit applications, Version 5.0.1 Build 010525Z
Copyright (C) 1985-2001 Intel Corporation. All rights reserved.
icl: NOTE: You have 17 days left in your evaluation period.
icl: Command line error: no files specified; for help type "icl -help"
Hardware used:
diep compiled single cpu run at dual K7 MP 1.2Ghz
Using P4s in this respect is utter nonsense, because at the
moment and in the coming future the K7 cpu will dominate
for computerchess the different tournaments. apart from that
they are also cheaper than P4 (not so important argument though),
and no matter how hard compiler teams work, the 8KB L1 datacache
from the P4 is such a big weak chain that their work will be
useless, right now the K7 is more than 70% faster than the P4
(both at the same clockrate). Only bad programmed software you
might get 70% or more speedup (or in a language that's very
inefficient such as fortran). Getting 70% out of my software
must be seen as impossible.
Comparision with msvc 6.0 sp4 + processor pack (at least 2% faster
than any other m$ product which one can buy in a shop).
VERIFICATION
Many options i tried and i found out that the P4 optimizations,
appear to have major bugs. This can also be caused because i run
my software on a K7 MP cpu, the competitor from the P4.
K7 cpu's aren't holy at all. I don't
doubt the K7 cpu's has more bugs than for example a P3 cpu has,
but no doubt the P4 optimizations use ways to optimize code which
are simply not legal at K7 cpu's, or they simply contain bugs.
Several other options i also found having bugs.
The first important thing of a compiler is that it produces RELIABLE
output. As mentionned above this is not the case with intel c++ with
all strings used. If their argument is that i should not use things
like 'IP optimizations' to produce correct code, then i would like to
see that in their documentation. It is not there though, but well
it's an EVALAUTION version, so let's not complain too loud, as
i managed to find options which did produce quick and correct code.
Default compile from intel c++ is very quickly producing an executable
which is about 0.5% slower.
However as ultimate speedfreak i'm more interested in the maximum speed
i can get out of it. So First thing to do was:
CFLAGS = -O3 -G6 -Qaxi -Qxi -Gr -Qprof_genx
That produces an executable which i ran for several minutes.
then i removed the object files and recompile with:
CFLAGS = -O3 -G6 -Qaxi -Qxi -Gr -Qprof_use
Now the executable is 3.5% faster than a quick compile with -O2 -G6 with
the msvc compiler.
SO MSVC FINALLY BEATEN!!!!
I assume they are beaten till they release at the end of this year
a new version of msvc, which is still a LONG TIME to go.
The interesting thing is that msvc gets beaten at a CPU manufactured
by the competitor of the company that produces the compiler that
is doing so well.
A PROFESSIONAL 3.5%
How much is 3.5%? That's a very good question. If i upgrade my K7
from 1.2Ghz to 1.4Ghz then i get a bit more than 10% faster. However
to all standards, programming of DIEP is very professionally done,
when compared to most software that's in specint testsets for example.
3.5% is a nearly impossible to get speedup by software rewrites.
Rewriting megabytes of
source code i still doubt i would get it. Only programming DIEP
in assembly (it's completely C code with only locking done inline
in assembly, note that this compile doesn't use any inline assembly
as it's the single cpu version) it is possible to get more than 3.5%
speedup i guess.
By any standard of well programmed software, 3.5% is a *major* speedup.
This page took 0.02 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.