Be Aware of Running Crafty Exe. In Console Mode!

[geots]

Most everyone will catch this I am quite sure if they run the executables in console mode to see if Ablett's is faster than the one from the Crafty site. I don't imagine there would be a lot of difference- they will both be ok to use. But there are some who are adamant about always using the fastest of the 2. In console mode, Jim's shows 3.8M nps. The one from the Crafty site shows 7.1M nps. But Jim's is on 1 Core, and the other is running the count on 2 Cores. Multiply or divide- whatever- but if you double Jim's for 2 Cores, you then get 7.6M nps. So Ablett's is actually the faster of the 2. Doesn't in any way mean the other you should not use- they are both fine. But it is what it is- and Jim's is the faster of the 2. Will that translate into more elo? I haven't a clue.


Best,

george

Note that dividing the dual-core speed by 2 is not a good comparison to 1-core speed in many cases. There are bottlenecks to perfect scaling in SMP boxes. Some processors share more levels of cache, some don't. Some have 3 levels of cache, some only 2. Some have slower memory cycle times. Etc...

I'm not quite sure why you mentioned "console mode" since Crafty always runs in console mode, it just sometimes "talks" directly to a user, sometimes it talks indirectly through a GUI. Same exact code and compiled executable, however...

Only reason I even mentioned console is because lots of times I will see which compile is faster, and use that exe when I install the engine. It can be a way of determining the fastest BEFORE installation.


Best,

george

[geots]

What I don't want to get lost in all this is that I would feel very comfortable here using either Pete's or Jim's. I have a lot of confidence in both of them. That for sure I want them to understand.


All the best,

george

[mvk]

If you go to comparison section you will see the following table: (...)

Btw, the tables with many-decimal values in the DTS paper are not actual measurements but were reconstructed from the single decimal values.

Be reminded that it caused quite an uproar when Vincent uncovered that reconstruction must have taken place for the times for processor counts 1 to 8. The time table was found to have been fabricated as time[cpu] = trunc(time[16]*speedup[16]/speedup[cpu]). There was something fishy with the node count table as well. Nowadays on Hyatt's site there is clear a warning about the origin of those numbers (see Note from the author).