That is my speculation, yes.  On a decent dual 6-core nehalem box at the last CCT I saw speeds of 30M-50M nodes per second.  For a single CPU, you have two choices.  You can take a single FPGA and let it be the "chess board" giving you a very fast Make/Unmake/Evaluate as Ken Thompson did in Belle prior to the 1980 version.  Or you can do as he did later, and implement the entire search in the FPGA.  That is problematic for lots of reasons.  It is a finite state machine.  Variable length operations are not good.  And you can't access a large RAM memory efficiently which wrecks hashing.  The first FPGA search, 1980 belle, searched at 160K nodes per second.  We beat Ken searching around 10-20K nodes per second.  And we did a lot of comparisons since we were good friends, and we discovered that his huge gain in speed came at a big cost.  No hash tables.  No killer moves.  All he could do for move ordering was MVV/LVA for captures, and that was it.  We actually found problem solutions faster than Belle, even though we were running at 1/16th to 1/8th the speed.  And in endgames it got _much_ worse since we had hashing and he did not.

The real gains come from multiple FPGA cards, ala Hsu and hydra, where you take those very inefficient searches done in the FPGA, and run 'em in parallel from a more usual software search, except the software search stops at some remaining depth (8, 10, would vary by program) and hands that position off to one of the many FPGA cards and says "give me a score for this branch".  There is a lot lost in terms of efficiency.  But not as much as a pure FPGA solution because the software part of the search can still do all the move ordering tricks.  And we all know that move ordering near the root is _much_ more important than move ordering out near the tips where the FPGAs would be searching.

It is pretty easy to be impressed until you get over the "what kind of speed can I see" and get to the "what do I have to give up to get that kind of speed?"  And when you start listing killer moves, SEE, hash tables you begin to get a sinking feeling.  Somewhat akin to a new Indy car showing up that has a motor that turns 30K rpm.  But so little torque that you have to gear it to the point it has a 150mph top speed.  Then that 30K doesn't look so hot.  Sounds impressive when it goes by, like a Honda S2000 winding out, but it doesn't go anywhere.

That's my take.  If I had one per CPU, I would certainly take the make/unmake/evaluate/generate/etc operations and move 'em out to the FPGA as I would gain a ton in terms of speed, without giving up hashing and the good things that make us efficient today.  That's no good for multiple CPUs if you only have one FPGA, as you would need one FPGA per cpu so that each could have its own board.

>> isn't one of the issues with IDeA the need to have the same, reproducible, analysis each time?
> No.

Well there are SOME advantages to it Vempele. I had to re-do some analysis recently due to the endless power cuts I get at my home and it was nice to see things progressing pretty much like they did the time before.

lol Lukas would make 2 clusters and tie them together if someone paid him $1 million US

I'd like to see the match Rybka Cluster 60 v Rybka Cluster 236, perhaps the strength added by the other 236 cores isn't significant.

You'd rent the whole cluster for ten seconds just to screw with everybody else's analysis?

Hmmm... That shrinks the target audience dramatically...

there are always jealous people around ;)

Well goodluck to anyone renting that "Rybka Cluster 100" or even the 40 package, (am laughing now really). But anyway I'll be honored if someone i played pays $100 an hour and I make sure that game last for ages just for the lulz

a "free" $2 espresso with every  cluster purchase :) LOL!!!!!!!!!!

Actually by 2015 highends will be running @ 128-256 cores equaling Lukas's hardware.

Ill just wait a few more years and buy my own "cluster strength" desktop then for $2000 or less. Good time to buy since we will be at the heels of the theoretical core efficiency of the cpu t i.e. adding more cores beyond this is traded off for heat dissipation. speedup = NIL Although superconducting cores could change all of this!

So one can just flood the server traffic with 1 terabyte of bandwidth because it is free? I really think you should mention how much % of the cost goes into the software and to the hardware,software licenses and other cost to be more transparent to your customers.

For example, you need to buy one of this: http://www.newegg.com/Product/Product.aspx?Item=N82E16832116806&cm_re=Windows_server-_-32-116-806-_-Product

For each of your nodes, so if you have 50 nodes it can cost you 33k for the OS license alone. So what % of the renting scheme goes into this?

we or at least I understand you are just laying the groundwork here Vas. You can't be expected to go live @ 100% full bore in 1 cpu incriments all at once that is a lot of server overhead.

> The current rental options are just the starting point. We do realize that they are
> suitable for maybe 0.1% of the chess engine using population. I'll be happy with
> one good new user in the next month. Cheaper and more flexible options will be added later.
>
> Vas.

Yes. With a little luck you will soon have renting options for 0.5% of the chess engine
using population, while 99.5% of the chess engine using population are still waiting for a
R4 bugfix.