TalkChess.com

It's a good question. I don't have the answer. In my pea-brain I conceptualize it as the engine being tuned to be too aggressive at pruning/reducing. For a single thread this means it needs higher depths before it exposes incorrect prunes/reductions, but on SMP some of the "search inefficiency" can ...

I think about this very simply, and let me exaggerate just a little here for illustration purposes. Say we have an algorithm that searches very narrowly by searching only the first move in the list for 4 ply before adding a second branch, and every 4 ply it adds another branch somewhere in the tree....

Personally, I'd buy more RAM and then mount a filesystem in memory for whatever tables I could get in there. With 16 GB of ram, you should be able to get all of the 5-man tables in there and have plenty of room for a nice sized hash table.

Bob, I appreciate your comments and certainly respect your research. I generally agree with your assessment of hyperthreading. I want to note a simple example though, citing published benchmarks of Fritz from Tom's Hardware's 2012 CPU charts: Intel Core i7-2600K 3.4 Ghz 4c/8t = 12,986 nps We have to...

But it worked as expected in version 4.4.4. It was only after updating to 4.5.2 did the memory usage change to an unexpected value. That's what spurred me to start this thread. It seems like an odd problem to have and a pretty big coincidence.

To preface this, I have 16 GB of RAM and I run Mint 12 64-bit (Linux). Ok, in this example I use the command line and it shows "-defaultHashSize 4096" here is a partial output of the Debug file: 348 <first : feature option="Polyglot BookRandom -check 1" 348 >first : accepted option 348 <first : feat...

I recently updated from 4.4.4 to 4.5.2 and now all of my engines allocate exactly half of the RAM listed in the interface. i.e. if I set the hash size to 2,048 MB, only 1,024 will actually be allocated by the engine. I had no issues in version 4.4.4. Anyone else see this?

Its not a specific game. I've split the offending pgn file into 9 files each containing approximately 90,000 games. Regardless of what order you import them it will error on the third import (game number 2^18). the error happens in both windows and Linux. My best guess is that there is a variable si...

Why would I not then also get that error when importing a 900,000+ game pgn file sourced from CEGT? It seems to me that if it were an issue with the size of a variable at 2^18 then it would be repeatable regardless of pgn source so long as it surpassed the limit. Its odd that it only happens with CC...

I've been getting an error saving to database when I try to import a CCRL sourced pgn. The error occurs at about 260,000 games and states exactly: "Error saving game in database." Also, after the error the index is corrupt. I've had no problems importing similarly sized pgn files from CEGT and have ...