Re: Computer speed

[Vincent Diepeveen <diep@xxxxxxxxx>]

At 06:26 AM 8/6/99 -0000, Clay Chipsmith wrote:

Some numbers:

memory lookups in L1 cache,L2 cache hardly get a penalty.
at maximum 3 instructions a clock can be processed.

A misprediction gives *at least* 9 clock delay up to 25 cycles,
so in that time you might as well execute 75 instructions.

My chessprogram is the most knowledgeable in the world, so
at blitz the major problem is tactics.

Most grandmasters look ahead tactical around 6 moves (12 ply).

Now processing all that knowledge that is using
  'if then else'

gets covered by the intel processors with just 512 entry 
BTB (branch target buffer), which remembers previous branches.

However, with thousands of patterns, this gives major delays.

Just imagine that the average branch gets a 15 penalty delay (according
to intel that's the average delay)!

That equals 45 instructions!

Now the good news is of course that this penalty only occurs one time
when talking about conditions like:

if( (A && B) || (X && Y) || (A && C) ... bla bla )

Yet good branch prediction at intel processors is a major problem.
The 512 entry BTB clearly doesn't cover the demand of game playing
programs that try to incorporate more knowledge!

What we in fact need is a very dumb RISC processor that's simply
not having these huge penalties.

A major problem from the K6 RISC architecture is however that 32
bits is way slower than 8 bits, and assuming everyone hopefully has
at least started converting their old applications to new cool
32 bits applications, this is not a very fine thought either.

Secondly most RISC processors don't get that speed of 3 instructions
a clock... 

Greetings,
Vincent

>Some of the memory stalls are really branch misprediction.
>Improving branch prediction would help reduce effective latency.
>Unfortunately, branch prediction for Go is ineffective at best,
>as nonstochastic behavior seem inevitable in Go.
>So, I hold little hope for branch prediction in Go.
>Perhaps, predication (executing both sided of the branch) has promise?
>
>Best Wishes, Clay ChipSmith ><>
>
>>When I look into a Go program,  most of the excution time is spent on
>memory
>>access related operations. Next important operations are the logical
>>operations involing 'if(...)' type of commands. Arithmatic operations are
>>only a small part of a Go program (in influence calculations). Here the
>cache
>>memory of a computer apparently helps a lot.
>...
>>Thus, the question of the day is that how can one significantly improve the
>>memory access from the hardware point of view?
>>Dan Liu
>
>
>
>