Myracle GUI

[Modern Times]

what happened was that Andres simply installed a new princhess over the old,

Ah - I have never done that in more than 20 years of running chess engines, and with greatest respect to Andres it is not a wise thing to do as he found out Always uninstall and re-install is best practice

[mar]

Ah - I have never done that in more than 20 years of running chess engines, and with greatest respect to Andres it is not a wise thing to do as he found out Always uninstall and re-install is best practice

well, my apologies to Andres

yes I also always create a new folder and install new versions as new engines - but people do all sorts of things with engines and GUIs
I'm simply trying to minimize possible user error, but it's impossible to catch everything.

which reminds me that I recently found some rogue crafty 25.2 binary, no idea where I got it from (660992 bytes, dates 29 oct 2016)
that when it receives the memory command (like memory 256) it allocates 48 gigabytes of RAM instead
(found it by accident in some test tournament with hash overrides enabled)
another 25.2 binary from Michael Byrne works fine however

no idea how to prevent this from happening (it can easily ruin any tournament it participates in) - while I do monitor process memory usage, it's not 100% reliable and may include cached memory mapped syzygy etc. - so I won't do anything about it.

ditto if an engine decides to spin all the available cores no matter what, can't prevent it either. or if someone packs a malware with the engine (which is btw why I refused to implement features like installing a folder of engines - seemed way too dangerous)

on a side note, ran 1m games (1sec sudden death) in a single go with build 141, it ran flawlessly,
producing 2.2gb uncompressed pgn and ~20mb tour file, so that's pretty efficient I think. peak GUI memory usage was around 300MB, that's good too with a schedule this huge, no memory leaks, no crashes. I think we're reaching pretty good stability now.

[Modern Times]

on a side note, ran 1m games (1sec sudden death) in a single go with build 141, it ran flawlessly,
producing 2.2gb uncompressed pgn and ~20mb tour file, so that's pretty efficient I think. peak GUI memory usage was around 300MB, that's good too with a schedule this huge, no memory leaks, no crashes. I think we're reaching pretty good stability now.

Amazing - yes you've nailed this

[mar]

build 143 is up:
- global engine memory overhead (fixed cost) can be set in settings/concurrency (base and per core in megabytes) - defaults to 224M base and 32M per core (SMP), because modern engines seem to be insane memory hogs...
- additional information can be shown in crosstable footer (must be enabled first in settings/tournament), like start and last update time, hash/thread overrides if any and GUI version/build (note: will be updated once next game finishes)
- GUI version and build saved in anomaly log to facilitate debugging

note that localizations had to be updated, so it's necessary to update both gui_data.zip and the GUI binary

[SSTATHIS]

Great!
Thanks Martin!

PS: Is it possible also to add to tournament footer when a tournament begins?

[mar]

Great!
Thanks Martin!

PS: Is it possible also to add to tournament footer when a tournament begins?

hi, not sure what you mean?

I prefer not to add anymore features since I consider the GUI finished at the moment, of course I still plan to continue fixing bugs if any.

[mar]

ah, if you mean to show tournament start time then it will be shown for new tournaments started with build 143,
for pre-143 tournaments start time is not shown

[Gabor Szots]

build 143 is up:
- global engine memory overhead (fixed cost) can be set in settings/concurrency (base and per core in megabytes) - defaults to 224M base and 32M per core (SMP), because modern engines seem to be insane memory hogs...
- additional information can be shown in crosstable footer (must be enabled first in settings/tournament), like start and last update time, hash/thread overrides if any and GUI version/build (note: will be updated once next game finishes)
- GUI version and build saved in anomaly log to facilitate debugging

note that localizations had to be updated, so it's necessary to update both gui_data.zip and the GUI binary

Hi Martin,

It seems I don't understand this overhead thing. What is overhead? Does it include hash tables and endgame caches?

[mar]

Hi Martin,

It seems I don't understand this overhead thing. What is overhead? Does it include hash tables and endgame caches?

hi Gabor,

it means you can set the estimated engine memory overhead globally, prior to 143 the GUI assumed the engine will only use Hash MB, but that's far from true.

so now you can set estimated overhead globally in concurrency settings, where base is base overhead in MB, defaults to 224
and per core overhead in MB, which is intended for SMP, to 32

this means that the defaults for 1CPU sum to 256M, for 2CPU 288M and so on; the defaults are very conservative

what this means: if you use Hash size of 256, the scheduler will assume one engine instance will consume 512M for 1CPU and 544M for CPU and so on

to get the old behavior, you can set both values to 0 (note that the "detect" button doesn't affect these parameters)

[Gabor Szots]

Hi Martin,

It seems I don't understand this overhead thing. What is overhead? Does it include hash tables and endgame caches?

hi Gabor,

it means you can set the estimated engine memory overhead globally, prior to 143 the GUI assumed the engine will only use Hash MB, but that's far from true.

so now you can set estimated overhead globally in concurrency settings, where base is base overhead in MB, defaults to 224
and per core overhead in MB, which is intended for SMP, to 32

this means that the defaults for 1CPU sum to 256M, for 2CPU 288M and so on; the defaults are very conservative

what this means: if you use Hash size of 256, the scheduler will assume one engine instance will consume 512M for 1CPU and 544M for CPU and so on

to get the old behavior, you can set both values to 0 (note that the "detect" button doesn't affect these parameters)

Thanks for the clarification, Martin.