Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: How do you represent chess boards in your chess programms

Author: Ricardo Gibert

Date: 21:47:44 09/25/99

Go up one level in this thread


On September 25, 1999 at 23:20:02, Robert Hyatt wrote:

>On September 25, 1999 at 12:47:38, Christophe Theron wrote:
>
>>
>>
>>I think we agree here. That's why I prefer not to use them, as they require 64
>>processors. I like the idea that my program can take advantage of any processor
>>I compile for, even if it's not a 64 bits one.
>>
>>There are hundreds of millions of 16 and 32 bits PCs in the world today. How
>>many 64 bits PCs? NONE, ZERO, NIL, NADA.
>>
>
>
>this is wrong.  Ask bruce as he owns a PC with a 533 mhz alpha in it, made
>by Polywell.  There are several such machines.  PC magazine has even covered
>them in detail.
>
>
>>It will take several years (maybe 10) before the number of 64 bits PCs becomes
>>larger than the number of 16 and 32 bits ones.
>>
>
>folks were saying that about the 386 not replacing the 286 for most businesses
>too.  Care to guess how many 286's are left?  :)
>
>
>>
>>
>>>And whether you like/believe it or not, 64 bit machines
>>>are coming.
>>
>>
>>The problem is not if I like it or not.
>>
>>It's crazy to ask millions of people to change their computers to exploit a 64
>>bits chess program, when they already have a superb 300 or 400MHz PC that in
>>many countries costs much more than a month of salary, and that is able to give
>>them master-level analysis...
>>
>>And it is misleading to tell them that they will have better chess programs when
>>64 bits processors are out just because bitboard programs will exploit it. Non
>>bitboard programs will be stronger too on this architecture and you won't make
>>the difference just with bitboards.
>>
>>
>>
>>>And they will be the standard PC in a few more years.  10 years
>>>ago, people were using your same words, with the target divided by 2:  "Why
>>>would I ever throw away my 16 bit 286 cpu?  Those 32 bit machines are only
>>>useful for high-end applications..."
>>
>>
>>You live in a country where only a fraction of your monthly salary is enough to
>>buy a new powerful personal computer.
>>
>>Of course you know it's not the case everywhere in the world.
>>
>>So maybe you can easily erase 16 and 32 bits computers from your memory as soon
>>as Intel produces a 64 bits processor, but there are many people in the world
>>who will stick to 16 and 32 bits for 10 years or more.
>
>
>
>that is crazy.  How many people do you know with 286 computers?  they are
>10 years old. How many do you know with 486 computers? They are 5 years old.
>How many do you know with p5 pentium machines?  they are 4 years old.  How
>about pentium pros?  3 years.  Pentium II?  1.5, pentium III?  < 1 year.
>
>People replace technology _all_ the time.  I don't know of _anybody_ that
>doesn't have at least a pentium CPU.    Which means _no_ machines I know of are
>over 3 years old.  These are home computers.  Office computers.  Business
>computers.  Game computers. Etc.

Vast majority of the machines at my job are 486s, which are getting replaced
gradually. There are about 100 PCs hooked up on our WAN. With the the exception
of a few "hotrods" (P2s, P3s) , which we have because they are sometimes useful
(graphics processing by marketing, special long running reports & database
rebuilds), only the servers & citrix boxes use the latest and the greatest
hardware (like quad xeons, etc). Unlike what you would like to think, businesses
are not fond of throwing away money for nothing.

>
>Sticking to 16 bits won't be possible if the new software releases don't support
>it.  Care to boot up windows 2000 on a 286?  That's only a 10 year old processor
>so it ought to work right?
>
>
>>
>>I'm not saying that we should target the smallest platform available just
>>because of this.
>>
>>I'm saying that my data structure works on the most recent computer as well as
>>the older PCs, and that's why I think it is much more elegant than bitboards.
>>
>>By far.
>>
>>
>>
>>>  64 bits are here to stay.  Programs
>>>that use such architectures will gain more from them than those that don't.
>>>Just look at all the programs and programmers that had to convert to "32 bit
>>>programming" to avoid the less efficient 16 bit stuff on new processors.  Do
>>>you think that won't happen _again_ soon?  :)
>>
>>
>>Funny you mention this. I was recently thinking that I could produce a 16 bits
>>version of Chess Tiger.
>>
>>In 1997 I rewrote everything to port from 16 to 32 bits. In fact, the rewrite
>>was essentially optmizing my algorithms for efficiency. I have used my older 16
>>bits version as a laboratory. I was very flexible, so I could try many different
>>things, but because of this was not optimized.
>>
>>So I rewrote everything with the algorithm I was targetting for in mind.
>>Additionnaly, I thought I would take advantage of 32 bits processing where it
>>would make sense.
>>
>>Recently I realized that I needed 32 bits integer very unfrequently. In fact I
>>could use 16 bits integer in 99% of my program. The 32 bits integer processing
>>is needed only for hash keys calculations and hash table access, and a 16 bits
>>processor can emulate them with only a very small speed penalty.
>>
>
>
>From a performance perspective, you are thinking wrongly.  You don't want
>to think "How can I reduce my data sizes so that 16 bits works?"  You do
>want to ask "How can I increase my data sizes to 64 bits so that I can use
>the increased data density in a 64 bit cpu?"
>
>As a challenge, I'll get you time on a Cray.  Let's see how well you run on
>that machine compared to a program that is optimized for it.  My eyes were
>opened years ago to this problem...
>
>
>
>
>
>>I think a 16 bits version of my program would be as efficient as the current 32
>>bits one. If the processor itself is not lousy at executing 16 bits code, it
>>could even be faster because of less L1 cache overloading.
>>
>>And so I don't expect to have any kind of trouble in porting to 64 bits anyway.
>>
>>
>>
>>>I think (my opinion) that 'evaluation-heavy' programs will like bitmaps better
>>>than just fast searchers will...  because the bitboard approach makes a lot of
>>>evaluation pattern matching turn into a single AND or OR instruction.  But
>>>until you try it for at least a couple of years, you won't ever see the
>>>advantages (and learn how to work around the occasional problem).  It requires
>>>a new type of thinking.  But not necessarily a bad type of thinking.
>>
>>
>>I understand the advantages and I agree that you can more easily evaluate
>>complex things with bitboards.
>>
>>The question is:
>>1) do you really need these more complex terms?
>
>if you want to beat GM players, yes.  If you only want to beat other
>computers, maybe not.
>
>
>
>>2) would it be really slower to evaluate them without bitboards?
>>
>>And you know what I think about it.
>>
>
>Some are definitely better with bitboards.  Some will work well without
>bitboards.  And some may even be better without them.  Time will tell...
>
>
>
>
>>
>>
>>>I don't recommend this as a first approach to computer chess, because it is a
>>>good bit more complex to get off the ground quickly.  However, I used to think
>>>it was an unworkable idea until I tried it.  And stuck with it long enough to
>>>start thinking in bitmaps.  It took time.  And it works just fine.  When I
>>>made the big step to convert to bitboards, I made a mental committment to stick
>>>with them for at least 3 years to give them a chance, because at first, they are
>>>'different' feeling. And it takes time to "think bitmaps".  But once you get
>>>there, they work just as well as any other approach, and if you intend on doing
>>>a lot of eval work, they become _very_ efficient...
>>
>>
>>Maybe.
>>
>>
>>
>>    Christophe



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.