tp2205 wrote on 11/25/17 at 13:54:12:

Indeed. 

brabo wrote on 11/25/17 at 17:33:02:


Very useful.

Keano wrote on 11/21/17 at 17:31:43:


Thanks. It looks as if for chessbase SSDs are indeed a good idea. My assumption that chessbase uses a well-designed database seems to have been incorrect.

Keano wrote on 11/20/17 at 13:07:28:

Do you mind elaborating. (what program? what kind of input (sample position in case of engines) etc)

dfan wrote on 11/16/17 at 13:48:00:

 
I never said they were incorrect. I said (or rather tried to say) it is difficult to find a good balance between searching and table lookups which is consistently faster than searching. But saying that I realized there is one scenario in which SSDs may indeed be significantly better than hard disk. The parameters for this balance are likely to be different for SSDs and for hard disks. Even if the results for good sets of parameters for those two cases give similar performance (which I believe) it is possible that chessbase's algorithms are optimized only for SSDs and then hard disk performance may be significantly worse. 

Again, I think we need concrete performance evaluations of different configurations.

proustiskeen wrote on 11/16/17 at 01:43:45:


My 'inconclusive at best' meant that the slowing down caused by looking up many positions in endgame tables (whether 5 or 6) tend to reduce the size of the tree which can be searched by the chess engine so much that the advantage of being able to have nodes with perfect evaluations is lost. Has this changed? Is the actual playing strength actually improved?

fling wrote on 11/15/17 at 15:08:27:


I doubt it. I don't want to get too technical but the main point is that it depends on how much you do withone set of data before needing the next batch. 

If you simply look for a fixed string (say the name of a player) then you would be right if the database would consist of a large pgn-file since in that case you would have to look through the whole file. But any database (worth its name) has indexes. So to find the locations referencing the name you would load the index, check the locations and load only the relevant data. The time needed for loading would be small compared to the time needed to display the search results so SSDs would not speed things up noticeably. If you do more complicated things with the data like checking if there is mate in one after each move in a game then again the load time would be negligible compared to the time needed for computation.
 
I am not 100% sure about the effect of the faster seek times of SSDs when integrating lookup in endgame tables with the usual search methods of chess engines. Last time I looked the results were inconclusive at best. And I doubt the better seek times will change much. But here my knowledge is a bit out of date.

Greenhaven wrote on 11/13/17 at 14:32:15:


In principle SSD's should be faster but don't be surprised if you don't notice any speed differences. It depends not only on the software you using but also on your usage pattern, the filesystem you are using, the amount of data you need to read each time, the data layout, cache size of the Hard disk, how likely successive request target the same block, the color of your laptop, ....

I write software for a living for quite a while now and I have not yet encountered a use case (similar to yours)  where I would say that SSDs were clearly better. Only if throughput matters and you have to read or write large sequential datasets then SSDs may be preferable.

Hello,

I'm wondering if investing in a solid state drive would noticeably improve the search speed within ChessBase.  Any other benefits from a chess software standpoint?

Thanks.