ICCA rules
Martin Zentner
>I vote for a strict interpretation of the ICCA rules for computer
>chessplayers.
Agreed ! So do I.
>1) Each should be played under the same conditions regardless of the
>different tournament directors' "liberal" interpretations. This will
>help ensure comparability among different events.
Especially time controls shouldn't change. 40/2h all/60 is just ok.
Why have a 30/60 40/60 all/60 or even repeatedly 40/60 after move 70 ?
>2) It is generally impossible for a director to distinguish between a
>hung program and one that is in a long search. Programmers are
>thereby encouraged to make sure their programs observe time control
>requirements.
This is already handled that way.
See: WMCCC95 Gandalf-Stobor(1-0 time), Gromit-XXXX(0-1 time)
>3) In cases where a program crashes and returns to the command prompt,
>the program is no longer running (and is obviously not searching) and
>so a restart and a reload should be permitted. However, all of this
>must be done on the clock of the crashed program. Furthermore, to
>encourage crash resistant programming, a time penalty of five minutes
>should be added. The exception is if it can be determined if the
>crash was due to operator error; in this case the clocks should be
>stopped.
A crash could be a result of a hardware failure, with all possible
outcomes:
- automatic machine reboot or system halt
- program termination
- clock over-/underflow resulting in wrong thinking time.
- wrong memory contents resulting in illegal moves.
- (your imagination...)
Where do you want to draw the line and allow a restart or not?
In my opinion, crash is crash, and hardware failures are bad luck.
This would make decisions easy and clear. Otherwise it's almost always
possible to argue that something was due to an unpredicateble hardware
failure, and that the program has to be restarted. And who tells you,
that the opponent won't use a different version then ?
[... uncommented points deleted ...]
>6) In cases where the internal representation is obviously different
>from the external (true) representation of the game, this can be
>considered operator error unless there is compelling evidence to the
>contrary. Since we are testing the program and not the operator, the
>problem should be resolved with the clocks stopped.
Why have an operator at all ? Just for the spectators ?
OK, then you have all kinds of possibilities:
- changing time controls
- hotkeys for "wanted abort", "force move", etc.
An operator should only be there to transfer the moves on a board for
the spectators, but he shouldn't be allowed to even touch the machine after
the match has started !
Just have the computers play with an autoplayer, that gives them the correct
time information and moves from the opponent. No other input is needed. As soon
as one program doesn't reply with a move before the next time control, the
supervising machine announces a winner. Cases where the supervisor machine
crashes, should be handled as a restart for both programs, that is done
automatically as well.
(In fact both playing programs could continue to run, only the supervisor has
to be resetted, and reconnect to both playing machines, but this can be
handled
by some sort of underlying autoplayer protocol.
That way both chess machines could preserve their memory content, and the
autoplayer protocol overhead for a reconnect of the supervising machine
could be handled in a few seconds, even if you have to connect a backup
supervisor hardware. This mysterious supervisor hardware could be an
"intelligent" special chess-clock with a serial interface so that a hot-swap
of such a supervisor could always be done in less than a minute.)
Conclusion: Supervisor crashes can be handled directly.
Any crash of a playing program should be a loss.
If both operators agree, a new match may be started.
Advantage: Clear and easy ruling. No cheating possible. Operators can relax.
>
>-- Steven (s...@mv.mv.com)
-Martin Zentner
Robert Hyatt
-->I vote for a strict interpretation of the ICCA rules for computer
-->chessplayers.
-->
-->1) Each should be played under the same conditions regardless of the
-->different tournament directors' "liberal" interpretations. This will
-->hep ensure comparability among different events.
-->
-->2) It is generally impossible for a director to distinguish between a
-->hung program and one that is in a long search. Programmers are
-->thereby encouraged to make sure their programs observe time control
-->requirements.
-->
-->3) In cases where a program crashes and returns to the command prompt,
-->the program is no longer running (and is obviously not searching) and
-->so a restart and a reload should be permitted. However, all of this
-->must be done on the clock of the crashed program. Furthermore, to
-->encourage crash resistant programming, a time penalty of five minutes
-->should be added. The exception is if it can be determined if the
-->crash was due to operator error; in this case the clocks should be
-->stopped.
-->
-->4) The program display is an integral part of the program, so if the
-->display gives a move that was not what the search produced, the
-->displayed move should be used as it's generally impossible for the
-->director to know about the internals of the display/search connection.
-->This is really no different than touch/move rules in human events.
-->
-->5) If a program is unable to accept a legal move (assuming that the
-->program has the correct internal representation of the game), then it
-->should be forfeited. This sounds harsh, but move I/O is a long
-->resolved topic and programmers should get this working (as also with
-->the display) well before entering a tournament.
-->
-->6) In cases where the internal representation is obviously different
-->from the external (true) representation of the game, this can be
-->considered operator error unless there is compelling evidence to the
-->contrary. Since we are testing the program and not the operator, the
-->problem should be resolved with the clocks stopped.
-->
-->7) Time-outs may be used only for equipment failures and problems
-->beyond the control of the operator (or the programmer). These should
-->be done with the clocks stopped. However, if the total time out for a
-->side is deemed excessive (exact amount announced in advance) by the
-->director, the program should be forfeited. The exception to this rule
-->would be if a later restart or resume can be arranged without impeding
-->the other tournament participants. Instead of having a limit on the
-->number of time-outs, there should be a limit on the length of the time
-->used for all time-out time in a game.
-->
-->8) The one hour limit to start play observed in human events should be
-->suspended. Instead, the available time-out period should be used.
-->
-->9) If possible, a program whose opponent is in time-out should have
-->the waiting program suspend ponder searching so as not to take
-->advantage of a problem beyond the control of the opponent's operator
-->or programmer.
-->
-->10) Obviously, recompiling the program or switching to a different
-->version should be forbidden. Switching to a different machine or
-->network should be permitted only in the case of equipment failure or
-->communications problems.
-->
-->11) Currently, ICCA events require that the program's display be
-->visible to the opponent. This was enacted, I think, to help prevent
-->unfair tinkering by less than totally honest operators. But there is
-->a problem if the display includes a predicted variation or an
-->expectation score: this could be used by the opponent to unfairly
-->offer or reject draws. I'm not sure what the solution should be for
-->this difficulty. Perhaps draw offers and draw acceptences/rejections
-->should be permitted only if explicity done by the programs and not the
-->operators.
-->
-->-- Steven (s...@mv.mv.com)
This last has not been an issue, as draw offers have to be approved by
the TD under all circumstances, excepting for repetition cases. Since
the human can't influence repetition logic, and draw offers require
approval anyway, your last point should not be a problem. It does provide
a "nice" conversation tool, as well as making "operator" flim-flams a little
harder to enact.
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
Oxford Softworks
> Path:
cpsoft.demon.co.uk!news.demon.co.uk!dispatch.news.demon.net!demon!tank.news.pipex.net!pipex!newsf
eed.internetmci.com!chi-news.cic.net!uwm.edu!cs.utexas.edu!utnut!nott!bcarh189.bnr.ca!bmerhc5e.bn
r.ca!bcrkh13.bnr.ca!muniacke
> From: muni...@bnr.co.uk (Mark Uniacke)
> Newsgroups: rec.games.chess.computer
> Subject: Re: ICCA rules
> Date: 2 Nov 1995 14:02:25 GMT
> Organization: BNR Europe, New Southgate, London.
> Lines: 44
> Message-ID: <47aj1h$6...@bcrkh13.bnr.ca>
> References: <DHAtI...@mv.mv.com> <475cl2$1...@news.rz.uni-passau.de>
> NNTP-Posting-Host: bnsgs161.bnr.ca
>
> At present the quality of an operator can have a definite influence on the
> outcome of certain games. For example in the World Micro Championship HIARCS
> lost on time (at move 70) to Chess System Tal despite HIARCS having a won
> position. Such results can affect the outcome of a tournament.
> Apparently, HIARCS' operator had had to leave the board a number of times
> meaning the internal and real chess clocks went out of sync.
> Had the internal clock been reset correctly the problem could have been avoided.
>
Sorry to disagree but Hiarcs was rather soundly beaten by Chess System Tal in the middlegame.
Hiarcs simply used up too much time during this stage of the game trying to find a way out,
without success.
CSTal entered the endgame with an extra pawn and a strong centre, a clear technical win, as even
Hiarcs evaluation function would readily agree.
But, as was the way with CSTal in this tournament, if a way could be found to lose the endgame,
CST could be guaranteed to do so (note game CSTal v. XXXX, subject of other postings). The
losing move being e5 (game listing available from this user group for those interested).
My information is that the Hiarcs operator stayed at his post and performed diligently. My
information is also that Hiarcs was set with adequate operator time allowance as per Mark's
instructions.
Hiarcs has an interesting time controller, when in trouble it thinks, but, unfortunately this
trouble-thinking can go on for too long.
It was a good game, both programs played interesting moves, but please Mark,
don't blame your operator.
As a direct result of this (and other weak endplay games) we have spent much time in
improving our endgame play. Presumably Mark will now spend some time fixing his time controller.
As for affecting the result - this game was round 2 or 3 in an eleven round Swiss. If you lose
early, you get to play weaker opponents. Losing an early game can even be an advantage.
After the tournament was over I spoke with Richard Lang, and asked if the CSTal-Genius win had
affected his chances of winning the tournament, no, he replied, its a Swiss, lose and you get
easier opponents.
chris whittington
--
--
<A HREF="http://www.demon.co.uk/oxford-soft/">
Mark Uniacke
Oxford Softworks <po...@cpsoft.demon.co.uk> wrote:
>In article: <47aj1h$6...@bcrkh13.bnr.ca> muni...@bnr.co.uk (Mark Uniacke) writes:
>> At present the quality of an operator can have a definite influence on the
>> outcome of certain games. For example in the World Micro Championship HIARCS
>> lost on time (at move 70) to Chess System Tal despite HIARCS having a won
>> position. Such results can affect the outcome of a tournament.
>> Apparently, HIARCS' operator had had to leave the board a number of times
>> meaning the internal and real chess clocks went out of sync.
>> Had the internal clock been reset correctly the problem could have been avoided.
> Sorry to disagree but Hiarcs was rather soundly beaten by Chess System Tal in the middlegame.
> Hiarcs simply used up too much time during this stage of the game trying to find a way out,
> without success.
By soundly beaten you mean a pawn up in a knight and pawn ending. An ending
which Chess System Tal clearly misplayed horribly and at move 70 when the game
was stopped due to time Chess System Tal had a completely lost position.
From playing over the game it seems HIARCS had the better of the opening, Chess
System Tal the middlegame and HIARCS the endgame.
I don't think either program could be said to have "soundly beaten" the other.
> CSTal entered the endgame with an extra pawn and a strong centre, a clear technical win, as even
> Hiarcs evaluation function would readily agree.
> But, as was the way with CSTal in this tournament, if a way could be found to lose the endgame,
> CST could be guaranteed to do so (note game CSTal v. XXXX, subject of other postings). The
> losing move being e5 (game listing available from this user group for those interested).
This is the problem when a program has a weak endgame.
> My information is that the Hiarcs operator stayed at his post and performed diligently. My
> information is also that Hiarcs was set with adequate operator time allowance as per Mark's
> instructions.
An operator allowance of 10 seconds a move was given which is normally more
than adequate to play a move or enter one with the mouse.
Thorsten Czub who was operating your program told me that the HIARCS operator
had to leave the board to go for some calls. This obviously meant some time was
lost in making/entering moves. At the time of the loss HIARCS believed it still
had significant time left on its clock. The real chess clock and the programs
were clearly out of sync.
I'm sure you'll agree Chris that it is a pity to see games resolved in this
way, I would much prefer to see the game played out on the board.
> Hiarcs has an interesting time controller, when in trouble it thinks, but, unfortunately this
> trouble-thinking can go on for too long.
What HIARCS does with timecontrol is to try to expend extra time when
it is clear that to play the currently best move would likely lose the game.
It is usually the case that once a mistake is made spending extra time is
pointless. Therefore it makes sense to spend the extra time as early as
possible to see if there is a way out.
I have seen HIARCS countless times find a way out of difficult situations
using this method. I believe its time control algorithm (as well as
alot of chess knowledge of course) has helped it achieved the very high
position of 3rd on the Swedish rating list.
> It was a good game, both programs played interesting moves, but please Mark,
> don't blame your operator.
> As a direct result of this (and other weak endplay games) we have spent much time in
> improving our endgame play. Presumably Mark will now spend some time fixing his time controller.
No fix is required as HIARCS played its moves within the time control as
indicated by its clock. Clearly HIARCS has no control over the speed at
which the operator makes/enters moves, therefore no "fixing" is required.
> As for affecting the result - this game was round 2 or 3 in an eleven round Swiss. If you lose
> early, you get to play weaker opponents. Losing an early game can even be an advantage.
> After the tournament was over I spoke with Richard Lang, and asked if the CSTal-Genius win had
> affected his chances of winning the tournament, no, he replied, its a Swiss, lose and you get
> easier opponents.
Clearly HIARCS would have at least played different opponents maybe even
Chess Genius in the next round (4) as Chess System Tal did. Such games would
have affected the tournament. Of course the end result may have been the
same.
Occassionally losing in an early round of a short Swiss tournament (like 5
rounds) can be an "advantage", but this was probably not the case here.
The purpose of my original post was to give my backing to having future
computer-computer tournaments played by autoplayer to avoid operators
influencing results and to increase the number of rounds.
Don't forget the programmers/operators can still discuss the games free of the
burden of operating the programs.
Whats your view on this Chris?
Did you ever consider entering Chess System Tal into the Uniform Platform
Events Don Beal ran?
Would you support such a format in the future?
Cheers,
Mark
--
The opinions and comments expressed herein are my own and do not in anyway
represent those of BNR Europe or Northern Telecom.
hia...@acc-ltd.demon.co.uk
Stefan Meyer-Kahlen
>
>In article <475cl2$1...@news.rz.uni-passau.de>, Martin Zentner <zentner> wrote:
>[much deleted]
>>s...@mv.mv.com (Steven J. Edwards) wrote:
>>Just have the computers play with an autoplayer, that gives them the correct
>>time information and moves from the opponent. No other input is needed. As soon
>>as one program doesn't reply with a move before the next time control, the
>>supervising machine announces a winner. Cases where the supervisor machine
>>crashes, should be handled as a restart for both programs, that is done
>>automatically as well.
>>
>>
>>Conclusion: Supervisor crashes can be handled directly.
>> Any crash of a playing program should be a loss.
>> If both operators agree, a new match may be started.
>>
>>Advantage: Clear and easy ruling. No cheating possible. Operators can relax.
>
>approach to future World Championships.
>
>Don Beal did run a couple of similar tournaments in 93 and 94 which were both
>attended by HIARCS and MChess. It means we can have many more rounds (perhaps
>a double round-robin) and much less chance (almost 0) for operator error. I
>hope more authors of the strongest programs would support such events.
>
>At present the quality of an operator can have a definite influence on the
>outcome of certain games. For example in the World Micro Championship HIARCS
>lost on time (at move 70) to Chess System Tal despite HIARCS having a won
>position. Such results can affect the outcome of a tournament.
>Apparently, HIARCS' operator had had to leave the board a number of times
>meaning the internal and real chess clocks went out of sync.
>Had the internal clock been reset correctly the problem could have been avoided.
I think the operator wasn't allowed by the TD to correct the internel clock,
because HIARCS didn't ask him to do so.
That's why many programmers put a stupid
printf("Do you want to correct my clock?\n");
after every move.
I don't want to say that the programmers behaved stupid by doing so, I did it myself,
I just want to say that there might be another way to allow the operators
to sync internal and external clocks.
Anyway, I agree totally that this game was lost because of the operating wandering
around in the tournament hall during the game.
>
>Autoplaying would irradicate such result anomalies.
>
>
>Best wishes,
> Mark
>
>--
>The opinions and comments expressed herein are my own and do not in anyway
>represent those of BNR Europe or Northern Telecom.
>hia...@acc-ltd.demon.co.uk
cheers
Stefan
Thomas Kerrigan
affect his winning chances. On the other hand, I lost a great deal, and I
didn't place well. Odd, eh? ;)
I heard that the HIARCS operator was awful. I didn't see any specific
games lost to operator error. On the other hand, I played HIARCS, the
Mephisto board, and a Russian program, and I can confirm that the
operators (they often switched around) were awful. In fact, HIARCS was
set to 30 moves in 50 minutes in our game, and I almost had a chance to
flag because the operator was drinking, talking with friends, and looking
at girlie magazines.
Autoplaying at these tournaments would be excellent. In fact, John
Stanback wrote up a protocol ("SCIP") and I think life would be wonderful
if everybody followed it. A chess engine reads one file, parses SCIP
commands, and writes to another file. Thus, writing a program to connect
two SCIP programs is quite easy, and this may be the format of future
tournaments. SCIP is also cool because porting to a platform with a SCIP
interface is trivial.
Anyway, getting back to my first post on this thread, I thought something
was wrong with the current tournament rules and thought a bit of debate
might clear things up. Evidently I was wrong, so I'd like to issue a huge
"NEVER MIND". :)
Cheers,
Tom
------------------------------------------------------------------------------
Never try to outstubborn a cat.
-- Lazarus Long, "Time Enough for Love"
Peter Gillgasch
|> I would be much more interested in trying to ensure that WMCCC was uniform platform.
|> The original rules for Paderborn involved 10 (or 12?) free Pentium 120, with the remainder
|> getting Pentium 90. The 120's were going to commercial entrants first and then on a first-come
|> first-served basis. These ICCA rules effectively froze an advantage/disadvantage throughout the
|> tournament.
I am puzzled. The ICCA made some systems available to the contestants (as a service
free of charge) and now someone cries "unfair"...
The point in "preferring" commercial entries is IMHO fully justified
because those tourneys are basically financed by the entry fees collected from
the commercial teams.
And BTW if you really believe that your chess engine can play significantly
better because of a mere 30% increase in clock then getting such a system cannot be
that hard, or? Pentiums are cheap and if you believe in the performance increase
you can rent one.
|> Better would be to spread the 120's, so that if your opponent had a 120+ (or a Sparc or whatever)
|> you got a 120, any left over could be spread between high ranking pairs.
Ooops. Workstation bashing time again ;). First let me tell you that a Sparc (or
Alpha) based chess program will nearly always be significantly slower than a Pentium
based program simply because workstation programmers write portable C code while
on the PC you can use assembly without the nagging thought whether this investment in
time and labour will be invalidated by the next revision of the architecture.
No "assembly on risc machines is not faster than C" myths please. I could
easily prove you wrong.
|> In the event 120's were made available to everybody so there was less problem.
I didn't see any problem at the tourney. No one complained about
this. But now that the tourney is over everybody comes around and
complains... The rules were bad, the TD was strange, the machine
power favoured some unfairly... Jeez...
If somebody from the ICCA or the local organizers reads this:
DarkThought and the Dark Thinkers enjoyed the tourney. Really.
-- Peter
------------------------------------------------------------
Peter W. Gillgasch
Klosterweg 28/I-113 email gil...@ira.uka.de
76131 Karlsruhe/Germany Phone ++49/(0)721/6904255
Thomas Kerrigan
of times your program would switch moves given 10% extra time. In my
case, this is probably 0. Even if the program *did* switch moves, how
many times would it affect the game? A few people at the tournament
pointed out that my SPARC gave me an unfair advantage, and I replied that
I'd be very happy on a 486.
I really enjoyed the tournament myself. Its operation was brillant. Every
round was on time, the pairings were quick, and the company was
excellent. :) I just thought there were a few weird TD rulings, 'tis all.
Cheers,
Tom
------------------------------------------------------------------------------
The shortest distance between two points is under construction.
-- Noelie Alito
Mark Uniacke
In article <222703...@cpsoft.demon.co.uk>,
Chris Whittington <po...@cpsoft.demon.co.uk> wrote:
[talk about operator times deleted]
>Agreed, my point is that it is a shame to see games resolved by time loss, bugs,
> crashes....
I believe that IF the problem is of the program's making then it should
forfeit the game. This includes time loss where the program has overstepped
the timecontrol because it thought too long (not because the programs
clock goes out of sync with the real chess clock through operator slowness).
For example if program X thinks it has 5 minutes left for the last move and
the real clock only shows 2 minutes you should not penalise the program for
taking 4 minutes over its move.
This can be helped by allowing correction of a program's clock when it is
not correct.
I believe program bugs and crashes should also cause the game to be forfeit
IMHO. Exceptions would be events outside of the programs control, like power
failure, hardware faults etc.
>Hiarcs time usage (as recorded by CSTal) was:
>Opening book to move 5
>Moves 5 to 30 played at c. 1.96 minutes a move
>Moves 31 to 40 played at c. 2.90 minutes a move
>Moves 41 to 50 played at c. 1.70 minutes a move
>Moves 51 to 60 played at c. 1.50 minutes a move
>Moves 62 to 70 played at c. 1.80 minutes a move
>It still looks to me that the Hiarcs time over-usage was in its 'difficult' period from moves 30
>to 40.
You don't seem to understand, this is how it should be. Once the time control
is reached at move 30 and the next one is not until move 70, it would not make
much sense to move quickly between moves 30-50 because that is where most
games will be resolved.
A poor time time control allocation would be:
Moves 5 to 30 played at c. 1.96 minutes a move
Moves 31 to 40 played at c. 1.50 minutes a move
Moves 41 to 50 played at c. 1.70 minutes a move
Moves 51 to 60 played at c. 1.80 minutes a move
Moves 62 to 70 played at c. 2.90 minutes a move
This is where a program moves quickly until the game is really lost then thinks
of a way out.
I prefer HIARCS to have a good think as early as possible even if the evaluation
is only dropping by a fraction of a pawn. In this way the later problems
are usually avoided.
As for an operator time of 10 seconds being inadequate, I use an operator
time of 5 or 6 seconds when I am operating HIARCS and then I am usually typing
the moves in! I know of a number of operators who are also able to use
considerably less than 10 seconds.
The information I have seen on the net about the HIARCS operator in the WMCCC
(who I was assured was going to be reliable) is not good:
In article <47cjl9$d...@news.rz.uni-passau.de>, Stefan Meyer-Kahlen wrote:
"Anyway, I agree totally that this game was lost because of the operating
wandering around in the tournament hall during the game."
In article <47ev4o$m...@alpha.pr1.k12.co.us>, Thomas Kerrigan wrote:
"I heard that the HIARCS operator was awful. I didn't see any specific
games lost to operator error. On the other hand, I played HIARCS, the
Mephisto board, and a Russian program, and I can confirm that the
operators (they often switched around) were awful. In fact, HIARCS was
set to 30 moves in 50 minutes in our game, and I almost had a chance to
flag because the operator was drinking, talking with friends, and looking
at girlie magazines."
That is an operator time of 20 seconds (1/6th of the time available given
to allow the operator to move the pieces!).
This clearly says to me that circumstances outside of HIARCS' control lead to
the loss on time!
Robert Hyatt
The rule about time has *always* been that if a program, of it's own accord,
asks "how much time do I have left" that it is acceptable to respond with the
correct chess clock time. Just like a blind player can ask how much time he
has left if the hands on the clock are not exposed so he can touch them.
Some say this leads to potential cheating, and I have to agree. However,
there's probably a way to cheat without getting caught anyway, so it is
probably not worth the worry (such as entering the opponent's move, with one
space after it meaning "be careful, this is complicated, search a little longer
than usual" ....)
I got over the paranoia years ago, and simply don't worry about it. Cray
Blitz (and now Crafty) play "on their own" and do reasonably well at time
management. Personally, I feel a sense of accomplishment when Crafty uses
it's time "wisely" and reacts to many different circumstances correctly. If
I were manually "tweaking" it during a game, I wouldn't feel quite so good
about it. I can't speak for everyone, but the feeling of accomplishment
comes from "within" and not from "without." I have been aware of at least
one operator regularly "cheating" at computer chess tournaments for several
years. He regularly helps the program by pressing a key to say "move now"
as an example. Seems that there's always going to be such a case. If they
feel good about it, let 'em. Take the high moral ground, you'll feel better
about the outcome should it be "good."
I still feel that if a program elects to "not move" due to bug, algorithm
or whatever, it should lose. Should it make an illegal move, ditto, should
it refuse to accept an opponent's (legal) move, ditto. Operator errors
should be corrected, with whatever fudging is needed to make things right.
Example: you "ponder" for 30 minutes and find a crushing move. Your opponent
makes a different move on the board, you enter it, losing the information
you found for the crushing move. Then your opponent says "oops" it really
played this move, my mistake. The move it made was the move you were
thinking about for 30 minutes. The game should be backed up, and you should
get 30 minutes to "ponder" before entering the correct move. Your opponent
should stop his program completely for the 30 minute recovery period. If you
write an accurate log of the game, this is easy to re-construct. However,
any other case should get the axe immediately. Remember, the game is between
two machines, not between two machines and their operators. Operator error
can be corrected, machine errors should simply end the game, unless it's a
hardware error of course.
Robert Hyatt
Thomas Kerrigan <kerr...@alpha.pr1.k12.co.us> wrote:
-->There's an easy way to answer the performance question. Count the number
-->of times your program would switch moves given 10% extra time. In my
-->case, this is probably 0. Even if the program *did* switch moves, how
-->many times would it affect the game? A few people at the tournament
-->pointed out that my SPARC gave me an unfair advantage, and I replied that
-->I'd be very happy on a 486.
-->
-->I really enjoyed the tournament myself. Its operation was brillant. Every
-->round was on time, the pairings were quick, and the company was
-->excellent. :) I just thought there were a few weird TD rulings, 'tis all.
-->
-->Cheers,
-->Tom
-->
-->------------------------------------------------------------------------------
-->The shortest distance between two points is under construction.
--> -- Noelie Alito
And don't forget Peter's Alpha was at least 2x as fast as your sparc. Just
points out something that has been pointed out countless times in the past:
There's no equality in such an event. With today's "standard" being a PC,
a uniform platform competition makes a lot of sense, as opposed to years past
with 68000's, 80x86's, as well as other lesser-known micros like the 650x, etc...
Both you and Peter (and others using the sparc or alpha processors) had a really
significant performance advantage. However, unfair? Hardly. The rules did not
require a specific machine. In fact, Lang is probably faster than you are since
he's eschewed portability for speed and gone "assembler". For fairness, everyone
should enter the uniform platform tournament. Then program vs program will
provide useful info.
Robert Hyatt
Ernst A. Heinz <hei...@ira.uka.de> wrote:
-->Bob Hyatt wrote:
-->
-->> And don't forget Peter's Alpha was at least 2x as fast as your sparc.
-->> [...]
-->>
-->> Both you and Peter (and others using the sparc or alpha processors) had a really
-->> significant performance advantage.
-->
-->After having read and heard these fairy tales about "giant" performance
-->advantages of workstation processors as compared to PC Pentiums much too
-->often, I hope to be able to clarify this point once and for all.
-->
-->The following table shows the official SPECint92 ratings of some DEC Alpha,
-->Intel Pentium, and Sun Sparc microprocessors.
-->
-->+------------------+-----------+-------------+
-->| Microprocessor | Clock | SPECint92 |
-->+------------------+-----------+-------------+
-->| | | |
-->| Alpha (21064) | 175 MHz | 100 |
-->| (21064) | 200 MHz | 133 |
-->| (21066a) | 233 MHz | 161 |
-->| (21066a) | 266 MHz | 190 |
-->| (21064a) | 275 MHz | 194 | <== DarkThought ran on this
-->| (21164) | 300 MHz | 330 |
-->| | | |
-->+------------------+-----------+-------------+
-->| | | |
-->| Pentium | 90 MHz | 100 |
-->| | 120 MHz | 140 |
-->| | 133 MHz | 155 | <== most PC programs used this
-->| | | |
-->+------------------+-----------+-------------+
-->| | | |
-->| Sparc (Hyp-b) | 100MHz | 103 | <== Sparc programs ran on these
-->| (Sup-2) | 90MHz | 135 | <== (or on comparably fast CPUs)
-->| (Hyp-c) | 125MHz | 159 |
-->| (Ultra) | 167MHz | 275 | <== not available yet
-->| | | |
-->+------------------+-----------+-------------+
-->
-->As you can see, most of them fall into the range 100 - 200 SPECint92. The same
-->holds for other microprocessor families like MIPS R4xxx, IBM POWER-2, Motorola
-->PowerPC, HP-PARISC 7xxx etc.
-->
-->Hence, current top-of-the-line workstation processors are *at most* 30% faster
-->than current top-of-the-line Pentiums. When taking into account that most PC
-->programs contain carefully handcoded assembler parts, I feel that workstation
-->programs actually seem to have a performance disadvantage because they are
-->mostly written in ANSI C in a portable fashion. Consequently, the fastest
-->programs as for nodes searched per second all ran on Pentiums in Paderborn ...
-->
-->Moreover, the new P6 = Pentium-Pro family features SPECint92 performances in
-->the range of 250 - 366(!) that should be fully exploitable by the handcoded
-->PC programs. Any workstation will thus have a hard time beating Pentium-Pro
-->powered PCs!
-->
-->Cheers.
-->
First, the above numbers mean exactly nothing. The right test is to take your
chess program and run it on all three machines. I have. I have seen the
following test results by personal experience:
same position, same hash table size, etc.:
Pentium 90: 10K nodes per second.
Sparc-20 75mhz: 15K nodes per second
HP735 99mhz 30K nodes per second
Dec ALpha/290mhz 50K nodes per second.
Your specint figures are useless. They don't measure what a chess program
is doing. In particular, they overlook the memory bandwidth problem, which
is where the alpha and HP machines kill the pentium. If anyone has a pentium
133 or whatever and wants to run the test let me know. Just beware of specint
figures. If your entire program is 16kb or less and fits into the pentium
on-chip cache, yep, it can be fast. However, this is where the cray burns the
transistors off the P5 class machines, it's clock speed is only 2x as fast,
yet it's memory bandwith is maybe 1000 times as high. The cray is not often
"starved" for data, as a PC often is. We can argue specint, specfp, linpak,
bcopy, and a zillion other benchmark figures. I have yet to find one that
reliably predicts chess program performance. As a result, this is the *only*
place where I worry about nodes per second... and that is the only benchmark
I would use to choose the machine to run on. You also overlook one other
important factor. A Sparc or HP has a truly significant architectural advantage
also, in that it has a very large set of registers that can allow much better
optimization of the executable code, where the pentium inherited the lousy
80x86 architecture. Yeah, I know about register renaming and what the intel
guys did to get the performance of the pentium up to where it is, but it's
still nowhere as good as the above workstation processors I mentioned, and I
didn't even touch the 64bit MIPS chip nor the HP PA8000 that is at about the
same developmental point as the P6.
I agree that hand-coding is good, but Ferret is an ANSI C program, running on a
PC, and is as fast as the hand-coded programs you mentioned. Were he not using
Windows libraries, he could certainly find a faster platform and improve his
already fast search speed. I suspect that assembly coding is easily worth a
factor of 2, and maybe more, but the risk is coding for a architecture that is
undeniably the worst design on the planet. I suspect that many wish that
they had a better architecture to work with.
At least we have an easy to obtain "chessmark" benchmark that anyone can run
on their favorite machine to compare speeds: Crafty. Get the source, compile
(probably you will have to tweak with optimization parameters some) and run
a "standard" problem from the probs file. My favorite: "in probs ACC4"
then "sd=9" and "st=99999" and "go". Will take a while to run, but the
analysis is interesting as the PV's are quite long and complicated. This will
give a good "chessmark" that we can compare for many different machines. I
have only tried "genius 2.0" but it seems to scale from one machine to another
exactly as Crafty does. I can't compare nodes per second, but I can compere
times to search a specific position to a specific depth, and if Crafty is 2x on
a new machine, genius is also about 2x faster. Regardless of what the specint
or whatever suggests.
Note: This is *not* intended to be a flame, just a rejection of the notion that
any type of benchmark *other than the intended application* can accurately
predict machine performance. We've been arguing numbers like "livermore loops"
and Linpack for years. All to no avail.
Bob
Ernst A. Heinz
> And don't forget Peter's Alpha was at least 2x as fast as your sparc.
> [...]
>
> Both you and Peter (and others using the sparc or alpha processors) had a really
> significant performance advantage.
After having read and heard these fairy tales about "giant" performance
advantages of workstation processors as compared to PC Pentiums much too
often, I hope to be able to clarify this point once and for all.
The following table shows the official SPECint92 ratings of some DEC Alpha,
Intel Pentium, and Sun Sparc microprocessors.
+------------------+-----------+-------------+
| Microprocessor | Clock | SPECint92 |
+------------------+-----------+-------------+
| | | |
| Alpha (21064) | 175 MHz | 100 |
| (21064) | 200 MHz | 133 |
| (21066a) | 233 MHz | 161 |
| (21066a) | 266 MHz | 190 |
| (21064a) | 275 MHz | 194 | <== DarkThought ran on this
| (21164) | 300 MHz | 330 |
| | | |
+------------------+-----------+-------------+
| | | |
| Pentium | 90 MHz | 100 |
| | 120 MHz | 140 |
| | 133 MHz | 155 | <== most PC programs used this
| | | |
+------------------+-----------+-------------+
| | | |
| Sparc (Hyp-b) | 100MHz | 103 | <== Sparc programs ran on these
| (Sup-2) | 90MHz | 135 | <== (or on comparably fast CPUs)
| (Hyp-c) | 125MHz | 159 |
| (Ultra) | 167MHz | 275 | <== not available yet
| | | |
+------------------+-----------+-------------+
As you can see, most of them fall into the range 100 - 200 SPECint92. The same
holds for other microprocessor families like MIPS R4xxx, IBM POWER-2, Motorola
PowerPC, HP-PARISC 7xxx etc.
Hence, current top-of-the-line workstation processors are *at most* 30% faster
than current top-of-the-line Pentiums. When taking into account that most PC
programs contain carefully handcoded assembler parts, I feel that workstation
programs actually seem to have a performance disadvantage because they are
mostly written in ANSI C in a portable fashion. Consequently, the fastest
programs as for nodes searched per second all ran on Pentiums in Paderborn ...
Moreover, the new P6 = Pentium-Pro family features SPECint92 performances in
the range of 250 - 366(!) that should be fully exploitable by the handcoded
PC programs. Any workstation will thus have a hard time beating Pentium-Pro
powered PCs!
Cheers.
=Ernst=
--
+--------------------------------------------------------+-------------------+
| Ernst A. Heinz (email: hei...@ira.uka.de) | |
| Institut fuer Programmstrukturen und Datenorganisation | Make it as simple |
| Fakultaet fuer Informatik, Universitaet Karlsruhe | as possible, but |
| Postfach 6980, D-76128 Karlsruhe, F.R. Germany | not simpler. |
| (Voice: ++49-(0)721-6084386, Fax: ++49-(0)721-694092) | |
+--------------------------------------------------------+-------------------+
"It has recently been found out that research causes cancer in rats!"
John Tromp
> "starved" for data, as a PC often is. We can argue specint, specfp, linpak,
> bcopy, and a zillion other benchmark figures. I have yet to find one that
> reliably predicts chess program performance. As a result, this is the *only*
> place where I worry about nodes per second... and that is the only benchmark
> I would use to choose the machine to run on. You also overlook one other
> important factor. A Sparc or HP has a truly significant architectural advantage
> on their favorite machine to compare speeds: Crafty. Get the source, compile
> (probably you will have to tweak with optimization parameters some) and run
> a "standard" problem from the probs file. My favorite: "in probs ACC4"
> then "sd=9" and "st=99999" and "go". Will take a while to run, but the
> analysis is interesting as the PV's are quite long and complicated. This will
> give a good "chessmark" that we can compare for many different machines. I
> have only tried "genius 2.0" but it seems to scale from one machine to another
> exactly as Crafty does. I can't compare nodes per second, but I can compere
Hi Robert,
Have you found any decent correlation between chessmarks and the
"Fhourstones" benchmark? It solves positions in the game of connect-4
using a 5Mb hashtable, and is available at
ftp://ftp.nosc.mil/pub/aburto/c4.shar (36025 bytes)
For instance, you could check whether the chessmark ratio of the
Alpha vs. the PC is comparable to the Fhourstones ratio. I'd be
very interested to see any numbers on that.
regards,
%!PS % -John Tromp (http://daisy.uwaterloo.ca/~tromp/)
42 42 scale 7 9 translate .07 setlinewidth .5 setgray/c{arc clip fill
setgray}def 1 0 0 42 1 0 c 0 1 1{0 3 3 90 270 arc 0 0 6 0 -3 3 90 270
arcn 270 90 c -2 2 4{-6 moveto 0 12 rlineto}for -5 2 5{-3 exch moveto
9 0 rlineto}for stroke 0 0 3 1 1 0 c 180 rotate initclip}for showpage
Peter Gillgasch
|> In article <47gefm$2...@alpha.pr1.k12.co.us>,
|> Thomas Kerrigan <kerr...@alpha.pr1.k12.co.us> wrote:
|> -->There's an easy way to answer the performance question. Count the number
|> -->of times your program would switch moves given 10% extra time. In my
|> -->case, this is probably 0. Even if the program *did* switch moves, how
|> -->many times would it affect the game? A few people at the tournament
|> -->pointed out that my SPARC gave me an unfair advantage, and I replied that
|> -->I'd be very happy on a 486.
[ snip ]
|> And don't forget Peter's Alpha was at least 2x as fast as your sparc. Just
|> points out something that has been pointed out countless times in the past:
|> There's no equality in such an event. With today's "standard" being a PC,
|> a uniform platform competition makes a lot of sense, as opposed to years past
|> with 68000's, 80x86's, as well as other lesser-known micros like the 650x, etc...
When I see a PC I got to puke...
|> Both you and Peter (and others using the sparc or alpha processors) had a really
|> significant performance advantage. However, unfair? Hardly. The rules did not
|> require a specific machine. In fact, Lang is probably faster than you are since
|> he's eschewed portability for speed and gone "assembler". For fairness, everyone
|> should enter the uniform platform tournament. Then program vs program will
|> provide useful info.
As one of my team mates pointed out the Alphas are *not* much
faster than the Pentia. Running DarkThought on a Pentium is
no good idea however, since that version was a hybrid design
that used both bitboards (read: Alpha registers!) and move tables
(somehow similar to Ferret or Gnu). We tweaked the code so much
for the Alpha that it is a really sad sight on 32 bit machines...
It sucks even on 32 bit risc machines like the Sparc or the PowerPC.
Now to the "performance advantage". We were doing about 20-30 KNPS
at Paderborn. Many of you will sneer now at this modest number, but
we outsearched higly selective programs that did 60 KNPS by a ply
(Nimzo comes to mind) *and* we had a full endpoint evaluation in the
tree... The next version will be a little faster ;-)
I am sure that our machine "power" was not a crucial factor
for the outcome of the tourney. It was however a crucial factor for
the way the basic DarkThought design was changed over the time.
BTW Bob, how about entering Cray Blitz (old Fortran version
of course) on a PeeeCeee ;-) I am sure that you could tell us
some nice stories about "performance boosts when talking straight
to the machine" ?!
-- Peter
P.S.: If *I* could trade the "workstation + C" platform for
DarkThought against "common hardware + assembly" I'd
know what to choose... Or even not so common hardware
+ assembly.
Robert Hyatt
John Tromp <tr...@daisy.uwaterloo.ca> wrote:
-->In article <486m27$5...@pelham.cis.uab.edu>, hy...@willis.cis.uab.edu (Robert Hyatt) writes:
-->> "starved" for data, as a PC often is. We can argue specint, specfp, linpak,
-->> bcopy, and a zillion other benchmark figures. I have yet to find one that
-->> reliably predicts chess program performance. As a result, this is the *only*
-->> place where I worry about nodes per second... and that is the only benchmark
-->> I would use to choose the machine to run on. You also overlook one other
-->> important factor. A Sparc or HP has a truly significant architectural advantage
-->> At least we have an easy to obtain "chessmark" benchmark that anyone can run
-->> on their favorite machine to compare speeds: Crafty. Get the source, compile
-->> (probably you will have to tweak with optimization parameters some) and run
-->> a "standard" problem from the probs file. My favorite: "in probs ACC4"
-->> then "sd=9" and "st=99999" and "go". Will take a while to run, but the
-->> analysis is interesting as the PV's are quite long and complicated. This will
-->> give a good "chessmark" that we can compare for many different machines. I
-->> have only tried "genius 2.0" but it seems to scale from one machine to another
-->> exactly as Crafty does. I can't compare nodes per second, but I can compere
-->
-->Hi Robert,
-->
-->Have you found any decent correlation between chessmarks and the
-->"Fhourstones" benchmark? It solves positions in the game of connect-4
-->using a 5Mb hashtable, and is available at
-->
--> ftp://ftp.nosc.mil/pub/aburto/c4.shar (36025 bytes)
-->
-->For instance, you could check whether the chessmark ratio of the
-->Alpha vs. the PC is comparable to the Fhourstones ratio. I'd be
-->very interested to see any numbers on that.
-->
-->regards,
-->
-->%!PS % -John Tromp (http://daisy.uwaterloo.ca/~tromp/)
-->42 42 scale 7 9 translate .07 setlinewidth .5 setgray/c{arc clip fill
-->setgray}def 1 0 0 42 1 0 c 0 1 1{0 3 3 90 270 arc 0 0 6 0 -3 3 90 270
-->arcn 270 90 c -2 2 4{-6 moveto 0 12 rlineto}for -5 2 5{-3 exch moveto
-->9 0 rlineto}for stroke 0 0 3 1 1 0 c 180 rotate initclip}for showpage
No, although this has come up before. If I could only switch to daylight
savings time every night (so I could add 1 hour to *every* day, not just
the last sunday in October...) I would have time to try more stuff. As
it is, I'm keeping busy answering questions about how to do this and that,
as well as trying to continually improve this thing. :)
Peter Mysliwietz
"I heard that the HIARCS operator was awful. I didn't see any specific
games lost to operator error. On the other hand, I played HIARCS, the
Mephisto board, and a Russian program, and I can confirm that the
operators (they often switched around) were awful. In fact, HIARCS was
set to 30 moves in 50 minutes in our game, and I almost had a chance to
flag because the operator was drinking, talking with friends, and looking
at girlie magazines."
Marc Uniacke wrote:
>>That is an operator time of 20 seconds (1/6th of the time available given
>>to allow the operator to move the pieces!).
>>This clearly says to me that circumstances outside of HIARCS' control lead to
>>the loss on time!
I just want to mention that the operators for Hiarcs and Mephisto and
the mentioned Russian program have not
been supplied by the organizers of the event. These teams have been
resposible for there operators themselves.
Peter Mysliwietz
Robert Hyatt
Peter Gillgasch <gil...@ira.uka.de> wrote:
-->In article <485sup$4...@pelham.cis.uab.edu>, hy...@willis.cis.uab.edu (Robert Hyatt) writes:
-->|> In article <47gefm$2...@alpha.pr1.k12.co.us>,
-->|> Thomas Kerrigan <kerr...@alpha.pr1.k12.co.us> wrote:
-->|> -->There's an easy way to answer the performance question. Count the number
-->|> -->of times your program would switch moves given 10% extra time. In my
-->|> -->case, this is probably 0. Even if the program *did* switch moves, how
-->|> -->many times would it affect the game? A few people at the tournament
-->|> -->pointed out that my SPARC gave me an unfair advantage, and I replied that
-->|> -->I'd be very happy on a 486.
-->
-->[ snip ]
-->
-->|> And don't forget Peter's Alpha was at least 2x as fast as your sparc. Just
-->|> points out something that has been pointed out countless times in the past:
-->|> There's no equality in such an event. With today's "standard" being a PC,
-->|> a uniform platform competition makes a lot of sense, as opposed to years past
-->|> with 68000's, 80x86's, as well as other lesser-known micros like the 650x, etc...
-->
-->When I see a PC I got to puke...
-->
-->|> Both you and Peter (and others using the sparc or alpha processors) had a really
-->|> significant performance advantage. However, unfair? Hardly. The rules did not
-->|> require a specific machine. In fact, Lang is probably faster than you are since
-->|> he's eschewed portability for speed and gone "assembler". For fairness, everyone
-->|> should enter the uniform platform tournament. Then program vs program will
-->|> provide useful info.
-->
-->As one of my team mates pointed out the Alphas are *not* much
-->faster than the Pentia. Running DarkThought on a Pentium is
-->no good idea however, since that version was a hybrid design
-->that used both bitboards (read: Alpha registers!) and move tables
-->(somehow similar to Ferret or Gnu). We tweaked the code so much
-->for the Alpha that it is a really sad sight on 32 bit machines...
-->It sucks even on 32 bit risc machines like the Sparc or the PowerPC.
-->
-->Now to the "performance advantage". We were doing about 20-30 KNPS
-->at Paderborn. Many of you will sneer now at this modest number, but
-->we outsearched higly selective programs that did 60 KNPS by a ply
-->(Nimzo comes to mind) *and* we had a full endpoint evaluation in the
-->tree... The next version will be a little faster ;-)
That's not what I meant. Just that the 275mhz alpha is significantly
faster than a 120 mhz pentium. *significantly* faster. Potentially
a factor of at least 2x if not more, were you to take hand-coded
pieces and benchmark on both machines.
There are plenty of other fast chips around. I see 2x or a little more
on a HP 735/99, and there's a 133mhz version already out. They are near
shipping their PA8000 64bit chip that will be significantly faster. Crafty
is hitting 25K-30K on the PA7100/99, should reach 40K on the 133, probably
>60K on the PA8000. Lots of hot things to run on, *every* one of which
is faster than the pentium, both due to design as much as architecture.
(count x86 registers, then count sparc or HP or whatever registers, then
decide which one *you* had rather optimize for. :) ) Makes me want to
puke too... :)
-->
-->I am sure that our machine "power" was not a crucial factor
-->for the outcome of the tourney. It was however a crucial factor for
-->the way the basic DarkThought design was changed over the time.
-->
-->BTW Bob, how about entering Cray Blitz (old Fortran version
-->of course) on a PeeeCeee ;-) I am sure that you could tell us
-->some nice stories about "performance boosts when talking straight
-->to the machine" ?!
Totally hopeless... :) It is *so* optimized for the cray, with lots
of vectorizable loops, that it simply dies on any other platform. On
my Sparc, Crafty is 5x faster in NPS, maybe 100 times faster overall.
On the cray, it's another story.
-->
-->-- Peter
-->
-->P.S.: If *I* could trade the "workstation + C" platform for
--> DarkThought against "common hardware + assembly" I'd
--> know what to choose... Or even not so common hardware
--> + assembly.
Exactly. Me too... although uniform platform stuff is still interesting,
it does let you tweak for one machine over another.
Robert Hyatt
Peter Gillgasch <gil...@ira.uka.de> wrote:
-->In article <222703...@cpsoft.demon.co.uk>, Chris Whittington <po...@cpsoft.demon.co.uk> writes:
-->
-->|> I would be much more interested in trying to ensure that WMCCC was uniform platform.
-->|> The original rules for Paderborn involved 10 (or 12?) free Pentium 120, with the remainder
-->|> getting Pentium 90. The 120's were going to commercial entrants first and then on a first-come
-->|> first-served basis. These ICCA rules effectively froze an advantage/disadvantage throughout the
-->|> tournament.
-->
-->I am puzzled. The ICCA made some systems available to the contestants (as a service
-->free of charge) and now someone cries "unfair"...
-->
-->The point in "preferring" commercial entries is IMHO fully justified
-->because those tourneys are basically financed by the entry fees collected from
-->the commercial teams.
-->
-->And BTW if you really believe that your chess engine can play significantly
-->better because of a mere 30% increase in clock then getting such a system cannot be
-->that hard, or? Pentiums are cheap and if you believe in the performance increase
-->you can rent one.
-->
-->|> Better would be to spread the 120's, so that if your opponent had a 120+ (or a Sparc or whatever)
-->|> you got a 120, any left over could be spread between high ranking pairs.
-->
-->Ooops. Workstation bashing time again ;). First let me tell you that a Sparc (or
-->Alpha) based chess program will nearly always be significantly slower than a Pentium
-->based program simply because workstation programmers write portable C code while
-->on the PC you can use assembly without the nagging thought whether this investment in
-->time and labour will be invalidated by the next revision of the architecture.
-->
-->No "assembly on risc machines is not faster than C" myths please. I could
-->easily prove you wrong.
-->
-->|> In the event 120's were made available to everybody so there was less problem.
-->
-->I didn't see any problem at the tourney. No one complained about
-->this. But now that the tourney is over everybody comes around and
-->complains... The rules were bad, the TD was strange, the machine
-->power favoured some unfairly... Jeez...
-->
-->If somebody from the ICCA or the local organizers reads this:
-->DarkThought and the Dark Thinkers enjoyed the tourney. Really.
-->
-->-- Peter
-->
-->Peter W. Gillgasch
-->Klosterweg 28/I-113 email gil...@ira.uka.de
-->76131 Karlsruhe/Germany Phone ++49/(0)721/6904255
Peter: did you post this again, or is our News server somehow screwing
up? I *know* I am seeing articles that I responded to a week ago or more
and am trying to figure out where they are coming from. Sort of like
Deja vu, only repeated... :)
Stefan Meyer-Kahlen
>
>In article <47g51b$5...@nz12.rz.uni-karlsruhe.de>,
>Peter Gillgasch <gil...@ira.uka.de> wrote:
>I didn't see any problem at the tourney. No one complained about
>
I also have to agree with Peter. Noone at the tournament was
complaining about the differences in machine speed between some
programs. Compared to former events the difference between the
fastest and slowest machine was rather small.
There could be endless discussion (actually there is an endless
discussion) weather the Alphas are 21 or 22% faster than the Sparcs,
and the P120 are 13 or 14% slower than the Sparcs etc.
If you are complaining and you are convinced that the Alphas are that
much faster, ok, try to port your program to thoses machines.
Everyone in Paderborn was happy with his machine ( I hope I didn't miss
someone).
The tournament was great (thanks Rainer), and we (at least the teams of
XXXX, AmyII, Ferret, Stobor, Francesca, Gromit and Shredder) were
having a great time!
cheers
Stefan
>
>-- Peter