A new chess engine : m8 (comming not so soon)

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Posts: 793
Joined: Sun Aug 03, 2014 2:48 am
Location: London, UK

Re: A new chess engine : m8 (comming not so soon)

Post by matthewlai » Mon Feb 02, 2015 7:05 pm

mar wrote: Compiler barriers tells the compiler to not reorder instruction it outputs (asm volatile("" ::: "memory") in gcc), which is different from memory barrier instructions that do something similar on CPU (EDIT: wrt. memory access - for nitpicks).
I would assume though that C++11 barriers are hw barriers (or nothing on some architectures), implying compiler barrier automatically.
Yes, they are different things. But we don't usually specify them separately from C/C++. We just tell the compiler we want a barrier, and it will make sure it doesn't reorder across the barrier, and also make sure the CPU doesn't.

POSIX synchronization primitives guarantee both kinds of barriers as well. Otherwise there would be no way to write safe multithreading code.

Is there a situation where it's preferable to only have software barriers?
What do you want from me anyway? :) If you want to imply that my code is crap, do it straight. I can take it.
I don't need anything from you :). I just wanted to point out that using volatile for sync is undefined behaviour by the standard, in case you didn't know that already. If you do already know, then all is well.

I haven't seen your code, so I'll give you benefit of doubt and say it's probably not crap :).
Disclosure: I work for DeepMind on the AlphaZero project, but everything I say here is personal opinion and does not reflect the views of DeepMind / Alphabet.

Post Reply