Rybka Chess Community Forum
Someone could help to minimize errors of system memory when rybka access the endgame?
The screenshot is very small
¿Pero qué coño ha pasado aquí?
Es que tengo un monitor de los antiguos y la resolución de la pantalla es muy baja. aunque he probado de subir el archivo con otras resoluciones se ve así de mal. La cuestión es que de muchos errores en el sistema cuando rybka ACCEde a las tbs. El disco está debidamente desfragmentado y el sistema es estable.
Usa imprimir pantalla en el teclado, vete a Paint, dale Imagen > Atributos y pon 1 en ancho y 1 en alto, luego pega la imagen. Esto debe deshacerse de la gran parte blanca.
Por cierto, lo de ancho y alto solo se tiene que hacer una vez, las demás solo the fijas que no haya espacio en blanco cuando pegas la imagen y ya está.
> Someone could help to minimize errors of system memory when rybka access the endgame?
Translation error. "Hard faults" (as Windows calls them) or "Page faults".
They're not errors.
Can that be an effect of "garbage in the TLB" as it was discussed related to very big hash tables? It has been explained that this can cause a performance drop with big hash compared to smaller hash sizes. I am not sure, but if that's the case, maybe these faults are reduced if the hash size is significantly smaller (like 256 instead of 2048 MB)? But I need to admit that I don't know what these faults are, actually.
Anyway, it cannot harm to test this with different hash sizes, rest identical each (same position etc.). I'd start with 32 or 64 only, then 128 etc. up to the maximum which fits. But again, I do not know if less of these faults would mean better performance. My benchmarks would rather be depth in time x, or time for depth x, and/or time for move x in certain positions.
Yes, you will have more TLB misses with a big table. I'm not sure exactly why there would be more of them in the endgame, though.
The simplest solution, is, of course, to use huge pages.
/* Steinar */
512 hash and 128Mb of cache Tbs.
Windows Page faults are not (directly) related to the TLB cache. They mean that there is no physical mapping for a virtual address. The TLB caches the translation between the two addresses, and missing the TLB would not cause a page fault, but a page table walk.
You will fault the TLB to hell as soon as you use more than a few M hash anyway, so it's a bit silly to worry about that.
That is, we can say it is a paging file problem, related to the cache of Tbs. computer but can not be left to chance, nothing. And if that solves that problem, everything will be better. If the error persists, obviously not play for real strength, rybka.
>Can that be an effect of "garbage in the TLB" as it was discussed related to very big hash tables?
>maybe these faults are reduced if the hash size is significantly smaller (like 256 instead of 2048 MB)?
Even on Nehalem the TLB can only contain (64 + 512) * 4K pages, or about 2M of mapped memory. If you worry about TLB trashing, don't use hashtables of more than that.
Or better yet, don't worry about such issues at all :)
so, with total nalimov I and II better fix 96 of cache?
The difference between Rybka and Fritz 11 for example concerning access of the chess engine to the hard disk is that the errors persist Rybka paging and system memory, and Fritz are much lower. Although, it must be said much worse playing the late game than his opponent, Rybka.
Stop calling them errors, they're just page faults (memory accesses that go to the hard disk).
> Fritz are much lower.
This just means Fritz accesses the disk less frequently i.e. it either probes TBs less frequently or has a bigger tablebase cache.
It is recommendable to put the Nalimov tablebase files on a flash memory device (e.g. USB memory stick) or on a solid state disk, SSD. These have smaller access times than a normal harddisk.
Hello, i'm working with velociraptor and this hardisk is very good under raid 0 for writte acces to disk and read.... So if you see the errors is in fritz (chessprogram gui) not alot of errors.
Also, we work old time ago with scassi and not errors from Deepfritz6,7 and deepshreddeer 7.04 or Deepjunior7.
I think that these effects you describe, are absoutely insignificant for chess performance. I suggest to simply ignore and forget them. Just move on...
Using a flash drive could be a solution for faster access to TBS, but the problem is that writing is very slow and lose transfer speed.
Writing speed and transfer speed is unimportant for using
tablebases. That matters only once, when you are copying the data to the drive. In usage, the access times
matter because only tiny bits of data are being read, but maybe up to hundreds of times per second.http://www.jens.tauchclub-krems.at/diverses/schach/fritz9_benchmarks.html
(see table at the bottom of the page)
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill