Rodent 0.12

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Rodent 0.12

Post by syzygy »

diep wrote:Add to that, usually they give support for hardware and software that they simply do not have themselves. Try to give support for a hardware component you have never ever seen in your life :)
Reminds me of the North Korean software developers writing iPhone apps ;)
So i have 2 confirmations of it working very accurate, to the millisecond accurate :)
Ok, but that doesn't yet imply that gettimeofday() in Linux is less accurate "because the Linux kernel is written in C". Anyway, I just googled a bit and it seems that clock_gettime() should be very accurate on kernel 2.6.18 and later. And since that kernel, gettimeofday() also uses clock_gettime(). On recent kernels the overhead seems to be low as well:
The only benefits to gettimeofday() is that on powerpc, ia64 and x86_64, it is implemented with a userspace-only vsyscall/vdso, which avoids the syscall overhead. However, recent x86_64 kernels have added support for vsyscall clock_gettime() as well.
Link (almost 4 years old already)

It seems the timing source used might depend on intel/amd and power saving settings... The technical issues mentioned should apply to both Windows and Linux, though.
diep
Posts: 1822
Joined: Thu Mar 09, 2006 11:54 pm
Location: The Netherlands

Re: Rodent 0.12

Post by diep »

syzygy wrote:
diep wrote:Add to that, usually they give support for hardware and software that they simply do not have themselves. Try to give support for a hardware component you have never ever seen in your life :)
Reminds me of the North Korean software developers writing iPhone apps ;)
So i have 2 confirmations of it working very accurate, to the millisecond accurate :)
Ok, but that doesn't yet imply that gettimeofday() in Linux is less accurate "because the Linux kernel is written in C". Anyway, I just googled a bit and it seems that clock_gettime() should be very accurate on kernel 2.6.18 and later. And since that kernel, gettimeofday() also uses clock_gettime(). On recent kernels the overhead seems to be low as well:
The only benefits to gettimeofday() is that on powerpc, ia64 and x86_64, it is implemented with a userspace-only vsyscall/vdso, which avoids the syscall overhead. However, recent x86_64 kernels have added support for vsyscall clock_gettime() as well.
Link (almost 4 years old already)

It seems the timing source used might depend on intel/amd and power saving settings... The technical issues mentioned should apply to both Windows and Linux, though.
Look in both windows as well as linux, you have more accurate ways of timing, yet GetTickCount() if it doesn't overflow loses you less system time from the kernel as it's assembler optimized.

The whole problem nowadays is not so much the measurement; it's the fact that these 2 operating systems both are total outdated in the same way.

Both are single processor OS-es in their core and both do all sorts of stupid locking things to get even the simplest thing done. In linux you can see this easy in the sourcecode: every packet to and from the machine gets central locked, even udp/raw data you send and receive.

This is so total outdated - i have no words for it.

From recent postings of Linus i understand he wants to keep it like that...
(but never say never)

As a result of this total being outdated, all the manufacturers have their own solution to hack the kernel and integrate their drivers into it; especially in linux of course - forget HPC with windows - i bet some marketeer has written once a great story about windows and HPC (high performance computing). Of course nearly all supercomputers are linux nowadays as a result.

This huge bottleneck of the kernel, which even in the realtime kernel is there, makes it tougher to modify linux to a HPC environment. Not impossible of course, all the sysadmins will manage in the end doing exactly that - yet look around - clustering hasn't made it into the mainstream.