Ridiculously Fast SSD's.. How good for chess?

[bob]

Hi!

Bitbases in RAM should *never* hurt.
Tablebases in RAM should *never* hurt.

Only if tablebases are in RAM we could expect a significant elo improvement.

kind regards
Bernhard

Tablebases in RAM _do_ hurt. You go thru the tablebase probe code, which takes time. You go through the operating system file system layer to access a file, even though it might be cached in RAM. The cost is still very high, just not nearly as high as doing an I/O...

[Dann Corbit]

it is interesting, but it is not a critical issue to most games. Very few reach the point where endgame table probes begin to be a problem, speed-wise. I have played lots of games recently on ICC with no tables at all, and have not noticed much difference at all, and might eventually just turn them completely off most of the time...

this has been around for 20 years now. Cray used to sell a SSD (solid state disk) that had incredible performance, but using DRAM it was not cheap. The new apple ultra-thin laptop has a SSD option already, as do some other laptops on the upper-end. They also use less power which is yet another laptop advantage...

But it will have zero effect on the NPS of a normal chess program except when it starts to heavily probe the endgame databases... otherwise, no advantage of any kind...

I see, Thank you! didn't figure they went this far back really.
But I'm glad I got the question answered it really made me wonder. But nonetheless could be a nice alternative to HDD's one day maybe. Hell I'd get one just for those Boot-times I bet it also feels snappier to work on a daily basis for day-to-day tasks.

BTW if wer'e already on the subject.. you guys should really check out what these guys claim..

http://www.fusionio.com/



http://blogs.zdnet.com/BTL/?p=6394

http://www.tgdaily.com/content/view/34065/135/

EEK!

SSD will never replace disk. Power failures can be partly turned aside by UPS, but UPS will eventually fail also when the batteries run out.

The figures they give for disk are totally slanted too. You notice their bar has a 40- on the label. The high figure they give is for a big raid array of striped volumes, I am sure. If you do the same thing with Ultra320 SCSI I guess the throughput will be about the same.

SSD volumes do have value. But don't imagine that they are going to replace disk farms.

[Dann Corbit]

Here is 637 MB/sec achieved with conventional disk in 1999:
http://findarticles.com/p/articles/mi_m ... i_54983579

[BBauer]

For the study by Averbach I got on a 3 GHz Xeon box
using my own built of crafty 21.6, 64-bit compile running on 4 procs.
3-4-5-men tablebases (when used) in a ram file system.

without tablebase access 12.0 Mnps
with tablebase access 10.9 Mnps

so I don't think use of table bases hurt.

The behavior of crafty is another issue. Results differ for different runs, fail highs don't lead to a higher score, analog with fail lows. Even for a 20 min run I couldn't get a mate score.
kind regards
Bernhard

[bob]

For the study by Averbach I got on a 3 GHz Xeon box
using my own built of crafty 21.6, 64-bit compile running on 4 procs.
3-4-5-men tablebases (when used) in a ram file system.

without tablebase access 12.0 Mnps
with tablebase access 10.9 Mnps

so I don't think use of table bases hurt.

The behavior of crafty is another issue. Results differ for different runs, fail highs don't lead to a higher score, analog with fail lows. Even for a 20 min run I couldn't get a mate score.
kind regards
Bernhard

that is more than a 10% performance hit. As I said, it does hurt _performance_. Whether 10% slowdown there offsets the gains from the table hits is a real question that would have to be answered by testing...

It is also important to note that Crafty's tablebase code is optimized for real disk drives. If I knew I was running directly out of RAM I would most likely probe deeper in the tree.

[BBauer]

Ok.
Is it possible to provide a parameter to steer the search depth
when using table base? Just like other programs do?
kind regards
Bernhard

[Nid Hogge]

SSD will never replace disk. Power failures can be partly turned aside by UPS, but UPS will eventually fail also when the batteries run out.
SSD volumes do have value. But don't imagine that they are going to replace disk farms.

Are you sure about that? I must disagree.

Here's a ercent article:

Solid State Drives May Become Popular in Three-Four Years – Seagate’s Chief Executive
http://www.xbitlabs.com/news/storage/di ... utive.html

“We do think that [for] enterprises it [SSD] makes some sense where you can get the performance. They’re not big volumes yet but three or four years from now, depending on how the technology, the cost-per-gigabyte, and the reliability issues get resolved, there will be other places for it,” said William Watkins, chief executive officer of Seagate Technology."

Bear in mind that this is coming from an HDD company, who highly resists this tech, and are very afreaid from SSD entrance to the market. This is just like the Oil companies (well, on a much samller scale) that will do everything and say everything to defend they're market and profits.

Also oppose to him I do think HDD's have a very high failure rate.. much more than CPU's or other things like he's trying to portrait. think about how many data youv'e lost in the last 5 years and how many HDD youv'e replaced, and how times you'r cpu died.

This is about 10 to 0 for me. I have ton of very old machines that work to this day and pretty much the only maintence I had to with them was to replace damaged\dead HDD's like every 2-3 years. My RAM died twice as well, and I had to replace my PSU only once for a newer GPU.

I don't think an SSD'd could do any worse than that. they will overcome the little glitches as things progress..

I think that as technology advances, and the the cost-per-gigabyte equals, you will start seeing HDD's being phased out.. ant he only place you'll see them, is in the history books, alongside the dodo's.

All in all, it's simply a logical step to do. Smaller, less heat\wattage, faster, no spinning disks.. this is where the industry and technology is heading.. smaller, more convient computing. nothing going to change that I'm afraid. last thing to do is to ditch the motherboard, in XX years from now.

[bob]

Ok.
Is it possible to provide a parameter to steer the search depth
when using table base? Just like other programs do?
kind regards
Bernhard

It is easy, but pointless. How would you have any idea what works best in each position? The scheme I use has been tuned/tested over tens of thousands of games, trying various EGTB probe depth limits, to find the setting that is best overalll...

[Dirt]

Ok.
Is it possible to provide a parameter to steer the search depth
when using table base? Just like other programs do?
kind regards
Bernhard

It is easy, but pointless. How would you have any idea what works best in each position? The scheme I use has been tuned/tested over tens of thousands of games, trying various EGTB probe depth limits, to find the setting that is best overalll...

Are you saying the speed of the medium the TBs are stored on doesn't affect the optimal depth, or does Crafty check the access time for a tablebase probe and adjust the depth dynamically? I would certainly think (perhaps naively) that things would change if I moved the TBs from a slow network drive to a ramdisk.

[Tony]

Ok.
Is it possible to provide a parameter to steer the search depth
when using table base? Just like other programs do?
kind regards
Bernhard

It is easy, but pointless. How would you have any idea what works best in each position? The scheme I use has been tuned/tested over tens of thousands of games, trying various EGTB probe depth limits, to find the setting that is best overalll...

Well, you could have a go with loading only the 4 pieces into memory.

I only wonder how much it will give in Crafty.

In XiniX, I have the "make qsearch as reliable as possible without too much cost" philosofy, where you have the "qsearch is unreliable anyway, so limit it without too much unreliability" philosofy.

This means that on average, my qsearch will be deeper, and this happens to be the place where most bitbase hits take place.

In addition I would think that if we both hit a bitbase on ply 3 in qsearch, it has more effect in an expensive qsearch (though this is more a feeling, I can't really prove it)

Tony