Moderator: Ras
Yes, please show us:bob wrote:Just factual. Want me to show you the volatile ints in the kernel source for spin locks?syzygy wrote:Your insight in these matters is just amazing.bob wrote:
Pretty funny discussion however, since the KERNEL uses volatile for its own spin locks among other things..
Yes, if you want to mess things up you can always mess things up.bob wrote:Correct. If you include the pthread_mutex_lock source into the compiled program, it will optimize right across it, because it can see all the side effects (or the lack thereof). And it is not JUST pthread_mutex_lock() where this is a problem.syzygy wrote:In so far as it was a factor in Lucas' question, the answer is that the use of volatiles in Senpai only slows down the engine. (I've tested and #define'ing volatile away gave a very slight speedup, just 0.5%.)bob wrote:I'd bet performance IS important for MOST of us in computer chess.
The one where you argued that the compiler won't reload non-volatiles after a pthread_mutex_lock()? Right...Hence my comment.
I never claimed that. I claimed: POSIX guarantees that it works. And indeed, it works.You claim the compiler has specific knowledge about that procedure.
Sure.Just factual. Want me to show you the volatile ints in the kernel source for spin locks?
I specifically mentioned spin locks. As far as the kernel, why don't you log on to a linux box, cd to /usr/src/kernels/-whatever-, and start recursively using grep to search for volatile?syzygy wrote:Yes, if you want to mess things up you can always mess things up.bob wrote:Correct. If you include the pthread_mutex_lock source into the compiled program, it will optimize right across it, because it can see all the side effects (or the lack thereof). And it is not JUST pthread_mutex_lock() where this is a problem.syzygy wrote:In so far as it was a factor in Lucas' question, the answer is that the use of volatiles in Senpai only slows down the engine. (I've tested and #define'ing volatile away gave a very slight speedup, just 0.5%.)bob wrote:I'd bet performance IS important for MOST of us in computer chess.
The one where you argued that the compiler won't reload non-volatiles after a pthread_mutex_lock()? Right...Hence my comment.
I never claimed that. I claimed: POSIX guarantees that it works. And indeed, it works.You claim the compiler has specific knowledge about that procedure.
That it works because posix_mutex_lock() is a function call to code that the compiler knows nothing about is irrelevant. That is merely how the standard is implemented. Users of a POSIX compliant system do not have to look under the hood of the system but can simply rely on the standard.
Again, to appreciate this requires an ability of abstraction that some are sorely lacking. This is the strcpy() story all over again.
Sure.Just factual. Want me to show you the volatile ints in the kernel source for spin locks?
Maybe you can also explain why the kernel does not use volatile for shared variables? How come it does not need to do that to force reloading from memory etc.?
See my reply to Ronald right below this post. I found a thousand just going a few levels deep in the directory structure for 3.13.6, the current fedora 20 kernel.Rein Halbersma wrote:Yes, please show us:bob wrote:Just factual. Want me to show you the volatile ints in the kernel source for spin locks?syzygy wrote:Your insight in these matters is just amazing.bob wrote:
Pretty funny discussion however, since the KERNEL uses volatile for its own spin locks among other things..
https://github.com/torvalds/linux/blob/ ... spinlock.h
https://github.com/torvalds/linux/blob/ ... spinlock.c
Code: Select all
Consider a typical block of kernel code:
spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);
If all the code follows the locking rules, the value of shared_data cannot
change unexpectedly while the_lock is held. Any other code which might
want to play with that data will be waiting on the lock. The spinlock
primitives act as memory barriers - they are explicitly written to do so -
meaning that data accesses will not be optimized across them. So the
compiler might think it knows what will be in shared_data, but the
spin_lock() call, since it acts as a memory barrier, will force it to
forget anything it knows. There will be no optimization problems with
accesses to that data.you probably never reached the paragraph immediately following it:syzygy wrote:For multithreaded programs using volatile is not necessary if you are properly using the synchronisation primitives of a thread library, e.g. pthreads or C++11 threads.
syzygy wrote:If you don't want to be restricted by a thread library, but (in addition) want to rely on how the compiler will map your code to the machine, then volatile is useful. Your program will be full of undefined behavior, but if that is a conscious choice that is not necessarily bad. It will just not be "standard C/C++ plus pthreads" or "standard C11/C++11".
You can safely remove the "volatile" from "volatile int *lock" in this code:bob wrote:The lock used in Crafty came from older kernel sources. Still works flawlessly.
Code: Select all
static void __inline__ LockX86(volatile int *lock) {
int dummy;
asm __volatile__(
"1: movl $1, %0" "\n\t"
" xchgl (%1), %0" "\n\t"
" testl %0, %0" "\n\t"
" jz 3f" "\n\t"
"2: pause" "\n\t"
" movl (%1), %0" "\n\t"
" testl %0, %0" "\n\t"
" jnz 2b" "\n\t"
" jmp 1b" "\n\t"
"3:" "\n\t"
:"=&q"(dummy)
:"q"(lock)
:"cc", "memory");
}
static void __inline__ UnlockX86(volatile int *lock) {
int dummy;
asm __volatile__(
"movl $0, (%1)"
:"=&q"(dummy)
:"q"(lock));
}Code: Select all
#define LOCK(lock) \
do { \
int dummy; \
asm __volatile__( \
"1: movl $1, %0" "\n\t" \
" xchgl (%1), %0" "\n\t" \
" testl %0, %0" "\n\t" \
" jz 3f" "\n\t" \
"2: pause" "\n\t" \
" movl (%1), %0" "\n\t" \
" testl %0, %0" "\n\t" \
" jnz 2b" "\n\t" \
" jmp 1b" "\n\t" \
"3:" "\n\t" \
:"=&q"(dummy) \
:"q"(lock) \
:"cc", "memory"); \
} while (0)
#define UNLOCK(lock) \
do { \
int dummy; \
asm __volatile__( \
"movl $0, (%1)" \
:"=&q"(dummy) \
:"q"(lock)); \
} while (0)
int variable; // shared variable with another thread
int smp_lock;
int i, j;
int funct(void) {
i = variable;
LOCK(smp_lock);
j = variable;
UNLOCK(smp_lock);
return 0;
}Code: Select all
funct:
.LFB0:
.cfi_startproc
movl variable(%rip), %eax
movl %eax, i(%rip)
movl smp_lock(%rip), %eax
#APP
# 37 "bla.c" 1
1: movl $1, %edx
xchgl (%eax), %edx
testl %edx, %edx
jz 3f
2: pause
movl (%eax), %edx
testl %edx, %edx
jnz 2b
jmp 1b
3:
# 0 "" 2
#NO_APP
movl variable(%rip), %eax
movl %eax, j(%rip)
movl smp_lock(%rip), %eax
#APP
# 41 "bla.c" 1
movl $0, (%eax)
# 0 "" 2
#NO_APP
xorl %eax, %eax
ret
.cfi_endprocCode: Select all
#define LOCK(x) \
do { \
__asm__ volatile ( \
"1:\n\t" \
"lock decl %0\n\t" \
"jne 2f\n\t" \
".subsection 1\n" \
"2:\n\t" \
"pause\n\t" \
"cmpl $0, %0\n\t" \
"jg 1b\n\t" \
"jmp 2b\n\t" \
".subsection 0" \
: "+m" (*(x)) : : "memory"); \
} while (0)
int variable; // shared variable with another thread
int smp_lock;
int i, j;
int funct(int v) {
i = variable;
LOCK(&smp_lock);
j = variable;
return 0;
}Code: Select all
funct:
.LFB0:
.cfi_startproc
movl variable(%rip), %eax
movl %eax, i(%rip)
#APP
# 26 "bla.c" 1
1:
lock decl smp_lock(%rip)
jne 2f
.subsection 1
2:
pause
cmpl $0, smp_lock(%rip)
jg 1b
jmp 2b
.subsection 0
# 0 "" 2
#NO_APP
movl variable(%rip), %eax
movl %eax, j(%rip)
xorl %eax, %eax
ret
.cfi_endprocFact is, MOST shared data in Crafty is not volatile. Big surprise? Volatile has a specific purpose.syzygy wrote:Ok, I will not check whether they all fall under one of the exceptions listed in https://www.kernel.org/doc/Documentatio ... armful.txt (prima facie most seem to do). And your "offer" related so spinlocks (and spinlock_types_up.h smells like uniprocessor), but never mind.
Fact is, most shared data in the kernel is not volatile.
Sorry, but no. Just as in Crafty, LOTS of data is shared but not modified. You only need locks where there is potential contention/races that need to be avoided.
The reason is pretty simple: most shared data is accessed under lock protection.
Those locks were not amateuristically written by Mr Hyatt, but include the necessary compiler and hardware memory barriers.
Note: If all the code follows the locking rulesCode: Select all
Consider a typical block of kernel code: spin_lock(&the_lock); do_something_on(&shared_data); do_something_else_with(&shared_data); spin_unlock(&the_lock); If all the code follows the locking rules, the value of shared_data cannot change unexpectedly while the_lock is held. Any other code which might want to play with that data will be waiting on the lock. The spinlock primitives act as memory barriers - they are explicitly written to do so - meaning that data accesses will not be optimized across them. So the compiler might think it knows what will be in shared_data, but the spin_lock() call, since it acts as a memory barrier, will force it to forget anything it knows. There will be no optimization problems with accesses to that data.
These "rules" do not allow you to roll your own amateuristic locks by randomly copying and pasting.
Senpai, which this thread is about, accesses all shared data under lock protection (well, not the tt table). Senpai declares this data as volatile (but not the tt table, I think, but I did not check).
Fact is, all these volatile declarations can be safely removed from Senpai. It would result in a small speedup.
Fabien has explained why he uses the volatile keyword. It is clear that speed is not his main concern at this stage in the development of his new engine.
Maybe I should just ask this question: can you explain why Senpai does not need to use volatile for its shared variables?
Btw, in the post where I wroteyou probably never reached the paragraph immediately following it:syzygy wrote:For multithreaded programs using volatile is not necessary if you are properly using the synchronisation primitives of a thread library, e.g. pthreads or C++11 threads.syzygy wrote:If you don't want to be restricted by a thread library, but (in addition) want to rely on how the compiler will map your code to the machine, then volatile is useful. Your program will be full of undefined behavior, but if that is a conscious choice that is not necessarily bad. It will just not be "standard C/C++ plus pthreads" or "standard C11/C++11".
You DO realize this program runs on other than X86? The alpha compiler from DEC had a software lock function that did what mine does above, but in C, using the interlocked exchange() mechanism their compiler used. Remove the volatile and the alpha would hang there.syzygy wrote:You can safely remove the "volatile" from "volatile int *lock" in this code:bob wrote:The lock used in Crafty came from older kernel sources. Still works flawlessly.The __volatile__ in "asm __volatile__" is important, though.Code: Select all
static void __inline__ LockX86(volatile int *lock) { int dummy; asm __volatile__( "1: movl $1, %0" "\n\t" " xchgl (%1), %0" "\n\t" " testl %0, %0" "\n\t" " jz 3f" "\n\t" "2: pause" "\n\t" " movl (%1), %0" "\n\t" " testl %0, %0" "\n\t" " jnz 2b" "\n\t" " jmp 1b" "\n\t" "3:" "\n\t" :"=&q"(dummy) :"q"(lock) :"cc", "memory"); } static void __inline__ UnlockX86(volatile int *lock) { int dummy; asm __volatile__( "movl $0, (%1)" :"=&q"(dummy) :"q"(lock)); }
Can you explain why the shared variable gets reloaded:
I didn't feel up to looking at what you are doing. But first things first. The volatile declaration on the inline asm is important. The compiler can't reorder across that, ever, nor can it change the location of the inline assembler by moving it up or down, before or after existing code.Code: Select all
#define LOCK(lock) \ do { \ int dummy; \ asm __volatile__( \ "1: movl $1, %0" "\n\t" \ " xchgl (%1), %0" "\n\t" \ " testl %0, %0" "\n\t" \ " jz 3f" "\n\t" \ "2: pause" "\n\t" \ " movl (%1), %0" "\n\t" \ " testl %0, %0" "\n\t" \ " jnz 2b" "\n\t" \ " jmp 1b" "\n\t" \ "3:" "\n\t" \ :"=&q"(dummy) \ :"q"(lock) \ :"cc", "memory"); \ } while (0) #define UNLOCK(lock) \ do { \ int dummy; \ asm __volatile__( \ "movl $0, (%1)" \ :"=&q"(dummy) \ :"q"(lock)); \ } while (0) int variable; // shared variable with another thread int smp_lock; int i, j; int funct(void) { i = variable; LOCK(smp_lock); j = variable; UNLOCK(smp_lock); return 0; }Compiled with -O3.Code: Select all
funct: .LFB0: .cfi_startproc movl variable(%rip), %eax movl %eax, i(%rip) movl smp_lock(%rip), %eax #APP # 37 "bla.c" 1 1: movl $1, %edx xchgl (%eax), %edx testl %edx, %edx jz 3f 2: pause movl (%eax), %edx testl %edx, %edx jnz 2b jmp 1b 3: # 0 "" 2 #NO_APP movl variable(%rip), %eax movl %eax, j(%rip) movl smp_lock(%rip), %eax #APP # 41 "bla.c" 1 movl $0, (%eax) # 0 "" 2 #NO_APP xorl %eax, %eax ret .cfi_endproc
edit: I think I messed up a bit in the above code. Obviously the address of smp_lock should be taken. Anyway, the point is that memory acccesses are not reordered across LOCK(). How come...
Feel free to show me how to declare a variable as volatile in asm... But I have to think a big "bigger" than you, because I also run my code on a half-dozen OTHER architectures, some that have a built-in locking mechanism that requires a volatile lock. Or actually requires a sort of lock_t declaration which turns into a "volatile int". For x86, since I reload the value each cycle through the spin loop, I am treating it as volatile automatically. There's no way to tell the assembler something is volatile because the assembly only takes the code you write and doesn't change anything.syzygy wrote:Instead of trying to get the above right, the same code with my spinlock implementation (yeah, I also think I know better than pthreads), leaving out UNLOCK for conciseness:With -O3:Code: Select all
#define LOCK(x) \ do { \ __asm__ volatile ( \ "1:\n\t" \ "lock decl %0\n\t" \ "jne 2f\n\t" \ ".subsection 1\n" \ "2:\n\t" \ "pause\n\t" \ "cmpl $0, %0\n\t" \ "jg 1b\n\t" \ "jmp 2b\n\t" \ ".subsection 0" \ : "+m" (*(x)) : : "memory"); \ } while (0) int variable; // shared variable with another thread int smp_lock; int i, j; int funct(int v) { i = variable; LOCK(&smp_lock); j = variable; return 0; }Again no reordering. No need to make "variable" volatile. How come?Code: Select all
funct: .LFB0: .cfi_startproc movl variable(%rip), %eax movl %eax, i(%rip) #APP # 26 "bla.c" 1 1: lock decl smp_lock(%rip) jne 2f .subsection 1 2: pause cmpl $0, smp_lock(%rip) jg 1b jmp 2b .subsection 0 # 0 "" 2 #NO_APP movl variable(%rip), %eax movl %eax, j(%rip) xorl %eax, %eax ret .cfi_endproc
Interestingly I also define the lock variables themselves as volatile, but that does not seem to be necessary (or do anything at all) if the variable is accessed only by asm __volatile__'s anyway. But maybe the compiler would otherwise be allowed to copy "smp_lock" to a local variable, apply the LOCK() to that, then copy the variabe back later. That's pretty unlikely to happen though. Anyway, making the smp_lock volatile won't hurt. Or better, just use pthread_mutex_lock() and never screw up.
Btw, for inlining my spinlock seems better than crafty's. Crafty's was written not to be inlined.