Author: Vincent Diepeveen
Date: 09:44:28 10/11/02
Go up one level in this thread
On October 11, 2002 at 12:17:32, Robert Hyatt wrote: This even more focusses attention upon the fact that Hsu was out for number of nodes a second instead of a good quality chessprogram. >On October 11, 2002 at 11:25:01, Jeremiah Penery wrote: > >>On October 11, 2002 at 11:07:52, Vincent Diepeveen wrote: >> >>>On October 11, 2002 at 10:38:12, Jeremiah Penery wrote: >>> >>>>Hmm, let's see. If DB gets 'upgraded to 2002 standards", that would mean they >>>>can make a fully custom .13 micron chip running at 300MHz, able to do a full >>>>evaluation every clock cycle. It will also have 20GB/s memory bandwidth to >>>>256MB of RAM for the hash tables on the board. So one single chip will search >>>>300M positions/second, and they can do whatever evaluation they want. Yes, yes, >>>>obviously a 'complete joke'. >>> >>>I'm more afraid for Brutus in like 30Mhz FPGA than i am for a >>>deep blue at 0.13 micron. >> >>Only because the latter will never exist. :) >> >>>First of all, deep blue wasn't written in verilog or any 'high level' >>>language. It was simply cut'n pasting the logics to each other. >>> >>>So it would require an entire new design to make something for 0.13 >>>in verilog or whatever. >> >>I was just using that as an example of what is possible. It could be done >>today. Obviously, we know it won't be. The whole argument is theoretical. >> >>>Secondly, that 0.13 process technology including the big salary from Hsu >>>would be around 20 million of investments. >> >>That's true, but if IBM were still sponsoring it, I doubt they'd have much >>problem providing that kind of money. After all, DB made them WAY more money >>than that in marketing terms. >> >>>This versus a FPGA board with some tools you can get for a couple of thousands >>>of euro's (1 euro = 1 dollar at the moment about). >>> >>>Further, Hsu would have to proof a number of things >>> being capable of implementing all kind of things like >>> nullmove, efficient move ordering, and a lot of evaluative >>> things in hardware. it's not trivial to add ram to the >> >>Nullmove should not be all that hard, since they already used it for threat >>detection. Does anyone know how they did move ordering in DB? We can't say >>whether it was efficient or not without knowing. As far as evaluation, they >>already did a lot of things according to Hsu's paper about it. I'm sure if they >>were going to do another redesign with today's hardware, they could find a lot >>more things to add. > >If vincent would just shut up and read Hsu's book, he would be _amazed_ to >discover that the current DB processors already have the ability to do a >null-move >search. Hsu just chose not to. But he designed the option into the chips. Of >course, >reading anything is not Vincent's strong point. Making ridiculous statements is >really his forte'. > > > > >> >>> chip, because a single cacheline from RAM is a lot slower than >>> processing a bunch of nodes in hardware. If you run at 300Mhz >>> with say 10 clocks a node on average, you can achieve about >>> 30 million nodes a second. >> >>Yep. >> >>> However you can't do 30 million random word lookups a second in >>> the RAM. latency is too big for that. It's not trivial to combine >>> the 2 things. >> >>Yep. But if they don't have hashtables you complain how they can't possibly get >>some depth without it. :) >>If price is not the object, they should be able to use at least some very fast >>SRAM, even if it's not very big. > >Again, had vincent read Hsu's book, he would _know_ that the DB chess chips had >included a shared transposition table facility. Hsu simply did not have time to >design >the necessary memory and have it put together in time for the 1997 match. But >the >chips _could_ do this. In fact, at the speeds they operated at (20-24mhz) there >would >be no problems interfacing to DRAM rather than having to resort to pricey/big >SRAM. > >1mhz = 1000 nanoseconds per cycle. 10mhz = 100 nanoseconds / cycle. 20mhz = >50ns >per cycle. Since a node took 10 clocks, or 500ns, interfacing to DRAM would be >absolutely >trivial. > > > > >> >>> In fact crafty with 1 million nodes a second can't even do all requests >>> to a hashtable. >>> >>>An important point in the end is the price where this all gets produced for, >>>because you need to sell a bunch of these processors, or you won't get >>>back that $20 million of investments. >> >>If you're talking about selling it to the general public, it would never get >>done. >> >>>And in the end, when the cpu hits the market after say a year or 5, >>>then i'll be having a 4 processor 10Ghz intel/amd machine delivering >>>millions of nodes a second for DIEP :) >> >>And?
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.