Author: Slater Wold
Date: 17:19:21 04/20/02
Go up one level in this thread
On April 20, 2002 at 15:31:02, Eugene Nalimov wrote: >I would not tell "However to all standards, programming of DIEP is very >professionally done" about the programmer who needlessly duplicates tens of >megabytes of data only because he did not figured out how to efficiently use >threads instead of processes. > >Or about the programmer who included others' code into his program without the >permission. > >Eugene Ouch. I guess it was only a matter of time......... >On April 20, 2002 at 10:14:09, Vincent Diepeveen wrote: > >>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.01 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.