Author: Robert Hyatt
Date: 07:49:22 05/30/01
Go up one level in this thread
On May 30, 2001 at 09:02:22, Vincent Diepeveen wrote: > >>as very simple tests to answer questions like "here is a bitmap of my passed >>pawns, do I have an outside passer on one side, or do I have an outside passer >>on both sides of the board?" Ditto for "here is a bitmap of my candidate >>passers, ..." Right now, on the PC, those operations are pretty expensive > >As i mentionned this can be done very fast with good alternatives of >32 bits which are in fact FASTER as 64 bits alternatives. > >That is, at 32 bits machines! > >>and dig into the advantage of bitmap evaluations. But on the 64 bit machines, >>those operations lose _all_ of their penalties, and begin to look pretty good. > >Diep suffered bigtime when i converted all my 8 bits stuff to 32 bits, >because it all occupied more space > - more code size > - more data size Do you understand that some machines don't behave like a PC? IE take an IBM RS6000 workstation and convert every floating point value from 4 bytes to 8 byte doubles. The speed won't change one iota.. because the machine does all fp operations in 8 byte mode _anyway_. > >Diep became about 5% slower, and i need to mention that i didn't optimal >profit from 8 bits datastructures. The real penalty on P3 processors would >be around 10%. At K7 about 50%. > >So for 32 bits to 64 bits *everything* that's getting 64 bits which first >was 32 bits occupies more size. So i start losing like 10% to *start* with... Again, not necessarily. On the alpha the bus is 4x wider than on the PC. > >Unless there are very GOOD reasons to get to 64 bits in the future i'll stick >to 32 bits for quite a long time with at least 99% of the code! > >As 99% of all applications will be 32 bits hell sure processors will >take care they are very fast with 32 bits code, so no problems there either! > >there are quite some problems to convert windows applications to 64 bits >because 'int' in general is seen as a 32 bits thing! > >>I wouldn't suggest that anyone rewrite their working code. But I made the >>decision to do this several years ago. I haven't found it a disadvantage on >>32 bit machines, and I really doubt it will be a disadvantage on 64 bit >>machines. > >factor 2.5 at 32 bits machines for sure. If that is true, why is my nps value in line with everybody elses? bitboards are _not_ inherently 2.5 times slower. In fact, it is much less as it is easier to keep two int pipes busy. > >>you have to think "data density". Which is what made our move generator and >>some evaluations on the Cray so very fast. But not until you start "thinking >>outside the box" and asking "how can this architecture help me do things more >>efficiently?" rather than "How can I make my program run on this architecture?" > >>Those are two vastly different questions. With vastly different answers. > >Here we all agree, but for me putting things in general in a bitboard >means i have 1 bit worth of information about something. That's too little >information for me! > >So if i ever go use 64 bits then it's for those parts of my program where >i can profit. > >What i still do not understand is why crafty is so slow on 64 bits sun >machine. Everything is 64 bits there. For me a sun processor performs >the same as a PII processor at the same speed. First, the sun is a piece of trash. Even the current operating systems are not "64 bits". The sparc is a "psuedo-64bit machine" that is worthless. Try a real 64 bit machine from MIPS, HP, Compaq, Cray, etc. to see what a _real_ 64 bit machine can do. Don't base your opinion on a piece of trash. > >How is crafty performing at it? > >IMHO the only reason why crafty isn't so slow on intel processors is >because you have way less branches as i have in DIEP. No... it is because I can keep both scalar pipes busy a lot more. > >I am using complex patterns in DIEP's evaluation function, so everywhere >there are branches. In crafty the branches that are there are easier >to predict. Want me to count the branches in my evaluation function? They blow out the branch target buffer quickly. > >So at 64 bits processors where the branch misprediction penalty isn't >big, there crafty will perform very bad compared to DIEP. There is no such architecture, however. > >At an alpha the branch misprediction penalty is HUGE. > >So at a 21164 processor which had only 8kb L1 cache i did very bad with >DIEP. At a 4 processor 21264 processor DIEP probably is doing worse as on >a dual K7 1.5Ghz palomino which gets released next month hopefully. >Operating at 1.5Ghz. > >Now the branch misprediction penalty of the K7 isn't very good. But >the 21264 it's way worse. What 21264 has to prevent mispredictions >a bit is a clever system of 2 killertables that reference each other. > >However the size of those tables is so small compared to the number of >branches in DIEP, that it won't speed me up a single %! > >A 633Mhz 21164 processor performed for DIEP as a 380Mhz PII. If that is true, you have _serious_ program design problems. It should never be slower. The processor is better. > >Now that was some time ago of course. Nowadays DIEP would do worse on >that 21164 when compared to the PII, because code+data size has become >bigger. > >A similar thing is what i have in mind for the 21264. Where on paper >it can do very good because it does 4 instructions a clock, it's very >likely that a K7 of same Mhz is completely outgunning it for me. > >For crafty the 21264 is not so bad as it is for me, >because you relatively suffer less >from the HUGE branch misprediction >penalty as i do with DIEP! > >It's not that the 64 bits datastructure is so good at 64 bits, the >problem is that the 21264 design has a serious problem with branches! > >Best regards, >Vincent > No. It is _both_. However, I have far too many branches for the prediction stuff to work well, so I take the same hits. I get killed on the xeons for this same reason, as it is easy to count the mispredictions using the machine- specific registers built in to the cpu. > > >Best regards, >Vincent
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.