Author: Gerd Isenberg
Date: 13:35:17 11/24/05
Go up one level in this thread
On November 24, 2005 at 16:16:40, Eugene Nalimov wrote:
>On November 24, 2005 at 14:41:16, Gerd Isenberg wrote:
>
>>...
>>>A sunken itanium ship with a price of like 8000 dollar a chip, for a chip not
>>>yet there, but only if you buy a 1000 of them, otherwise it'll be more like
>>>20000 dollar a chip, is not a good compare. Despite intel giving masses of those
>>>chips for free to SGI, SGI despite all that still has been removed from the New
>>>York Stock Exchange. It's no longer there.
>>>
>>>x64 is more interesting.
>>
>>Agreed.
>
>You can buy dual-CPU Itanium2 system with SCSI disk drives and several gigabytes
>of RAM for less than $5k, so single Itanium2 CPU probably costs less than $8k
>even in smaller quantites. But I undersand that for most needs AMD64/EM64T is
>more cost effective solution.
Yes those prices are not within my budget.
I'm happy with some dual core amd64 in the near future.
>
>>...
>>
>>Hehe, yes - with zillions branches you will pollute your btb and other branch
>>prediction ressources.
>>
>>What about some cmovs enabled by pogo - if profiler claims too many
>>mispredictions for jxx.
>>
>>If you have a lot of code in your eval and elsewhere, where you simply do some
>>conditional add or sub - and the condition is rather random and therefor likely
>>to produce some mispredictions with this very short bodies - you are free to use
>>the boolean*int multiplication on C level. For Less/greater compares you are
>>able to convert the compare expression to (arithmeticExpression < 0) and to do a
>>shift arithmetic right with arithmeticExpression and (sizeof(int)*8-1), to get
>>a {-1,0}-range - a mask to apply the boolean multiplication by bitwise and.
>>
>>From the initial conditional statement ...
>>
>>if ( distance1 < distance2 )
>> eval += bonus;
>>
>>... via < 0 ...
>
>Oops, here is problem. Transformation is not legal for some input values.
>Programmer can do it if range of values is known not to cause overflow during
>subtraction. Compiler (usually) cannot be sure, so we cannot do this
>transformation.
>
>Thanks,
>Eugene
Oups yes - implicitly assumed appropriate value range, which is usually the case
in the intended code. I did not claim compiler should do that - may be only if
second operand is already zero - or with some special range pragmas involved ;-)
Thanks,
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.