Running multiple instances of Laser at once

[jeffreyan11]

The lastest master is indeed broken on > 1 core. I can't give an exact time as to when a fixed version will be put onto Github, but hopefully in the next month. In the mean time, if you want the latest working version, take anything from July 22nd or before.

Peter Osterlund found the bug for Nemorino, although Laser's bug is somewhat similar (but much worse, since it affects more than just speed). I accidentally made some evaluation tables global instead of wrapping them in per-thread class objects. I don't understand why the slowdown only seems to occur on NUMA machines, though. I would expect it to be slower on all machines.

[AndrewGrant]

The same thing happens in Laser1.2, so I'm not sure your July22nd comment will help me

My problem is with running 20 copies of your engine, with Threads=1 on each copy.

My problem is NOT running one copy of your engine, with Threads=20

[mar]

(but much worse, since it affects more than just speed). I accidentally made some evaluation tables global instead of wrapping them in per-thread class objects.

Why would you do that?! Reading same location from multiple threads is perfectly fine, it's writing + reading at the same time that causes problems.

[Ras]

Reading same location from multiple threads is perfectly fine

Depends. The compiler may not be able to determine whether some unrelated write access has aliased to the tables.

[mar]

Reading same location from multiple threads is perfectly fine

Depends. The compiler may not be able to determine whether some unrelated write access has aliased to the tables.

this is not a task for the compiler, but for the programmer. if you're obsessed, cache-align your tables (or use dumb padding)

initialized data is usually grouped in a separate section, so unless your tables are generated on the fly, the probability should be literally zero

[jeffreyan11]

Andrew: Ah, I see. Sorry for misunderstanding. I'm not sure what the problem is then, but I'll look into it.

Martin: By evaluation tables, I meant attack map tables for the eval that are calculated on the fly, so they're both written and read. But I agree that read-only data shouldn't be a problem.

[petero2]

Andrew: Ah, I see. Sorry for misunderstanding. I'm not sure what the problem is then, but I'll look into it.

I used git bisect on my 24 core computer to find when the slowdown (when using 24 threads) started, and got:

Code: Select all

8863ee8844b9832e754066dc88d30fafcd81f95a is the first bad commit
commit 8863ee8844b9832e754066dc88d30fafcd81f95a
Author&#58; Jeffrey An <jeffreyan07@gmail.com>
Date&#58;   Sun Jul 23 19&#58;12&#58;42 2017 -0700

    Move evaluation code to a new file eval.cpp. No functional change.

That commit is pretty big though so I have not tried to determine what part of it is causing the slowdown.

If don't know if the slowdown when running 24 processes is related to this problem.

[jeffreyan11]

Yes, that is the guilty commit, although that problem is solved. The 24 process problem is unrelated.

Unfortunately, I haven't been able to reproduce the problem on my Threadripper. I tried Laser, Stockfish 8, and Ethereal 8.28, and they all showed similar amounts of slowdown from 1 -> 8 cores (about 20-30%).

[AndrewGrant]

The 24 process problem is very likely specific to that one machine I have, so don't lose any sleep over it.

If you push the fix I will try the new version.