Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: There is huge potential to improve further

Author: Vincent Diepeveen

Date: 13:37:39 07/10/03

Go up one level in this thread


On July 09, 2003 at 13:57:06, Gerd Isenberg wrote:

you can get all the spec benches easily online.

what i do usually is like:

http://www.specbench.org/cgi-bin/osgresults?conf=cint2000

then i fill in 'processor' and i write down AMD or INTEL or whatever
manufacturer i want and i see all the processors of the guys and all benches.

Can be long lists.

Don't focus too much upon this bench though.

It is like saying chessprogram A is better than chessprogram B because at 15
preselected positions it finds the best move sooner.

Everyone knows the positions and goes tune for it. that's what happens there.

add to it that most programs are clumsy programmed. Take the public Gzip. that's
a matter of really sick bad programming. It still is good compared to other
horrors.

Take crafty, it's not even deterministic single cpu if i understood bob well
here (perhaps there is again a new viewpoint onto this) :)

Crafty is cool to watch though at specbench as it is more IPC based than the
other software and it is a chessprogram so in general when crafty scores better
then the cpu is doing better for me in general.

Of course by now all the dudes have optimized for the crafty code too and they
use some dead old version and cannot use inline assembly of course.

As a result of that for example some fortran code at specfpu, the loops were
done very dumb inside the program.

If we have an array in memory of 0..n bytes where this is a big array
and we loop from n-1 to 0 backwards and read from memory then we can imagine
that this is not so smart.

So there is huge potential for clever compiler programmers to improve their
specint/specfpu by better compiler software.

Seems HP did a good job there for some Itanium2-Madison systems.

>On July 09, 2003 at 12:54:49, Vincent Diepeveen wrote:
>
>>On July 09, 2003 at 07:02:01, Gerd Isenberg wrote:
>>
>>>
>>>Current Opterons use so called "DirectPath Double" decode type for most SSE/SSE2
>>>128-bit instructions, internally they do two 64-byte macroops. But AMD already
>>>mentioned "Future" Processors with 128-bit "DirectPath" SSE/SSE2 instructions:
>>>(Software Optimization Guide for AMD Athlon™ 64 and AMD Opteron™, Chapter 9
>>>Optimizing with SIMD Instructions).
>>>
>>>That's a boost to floating point and also SIMD integer algorithms like
>>>KoggeStone. But when will it be?
>>>
>>>Like Athlon, Bitscan (bsf, bsr) and Bittest (btx) instructions are still Vector
>>>path pipe-blockers (but of course 64-bit). Same for moving data between gp- and
>>>xmm- or mmx- registers.
>>>
>>>Still no popcount and instructions for "reverse" arithmetics (radd, rsub, rneg),
>>>where the overflow passes from high to low :-(
>>>
>>>Cheers,
>>>Gerd
>>
>>And already 1562 in specint with crafty using 64 bits crafty.
>
>No idea what it means - i guess it's fast.
>What's the specint for 32-bit crafty on Opteron or Athlon?
>Do you have any site where i can read the current specints?
>
>>
>>Please compare what the opteron can do for crafty with the itanium2 and you'll
>>know which is the better CPU in the future.
>
>My Sympathy is with AMD.
>
>I currently write KoggeStone-routines for hammer with mmx0-7 for propagators and
>xmm0-15 for white/black generators. I'm a bit disappointed, that there are these
>double directpath instructions for 128-bit xmm registers.
>
>>
>>Itanium2 doesn't have bsf/bsr even if i understand well. You need to do it
>>indirectly at the itanium2!!!!
>
>I don't know the itanium2 instructions set - may be there is some "leading" zero
>count or some fast int to float conversion, where you can pass a single isolated
>bit as int and get the position from the float exponent.
>Anyway there is still Walter Faxon's magic c-routine.
>
>Regards,
>Gerd



This page took 0 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.