Remove cached binaries on worker startup #1667
Conversation
|
If was looking at flushing the cache also after a worker update, but was somewhat confused by https://github.com/glinscott/fishtest/blob/52a42301c2214b5c8004362fcef95ec46f9596c0/worker/worker.py#L1282-L1283 will this always print the failure message? I might not know how exactly the worker update goes. |
|
No because a successful update does not return (as written in the comment…). |
|
OK, so for the purpose of this patch, a worker update can be treated as a fresh start of the worker. |
|
What if the user updates his system compiler while the worker is running? Not an unlikely scenario with auto updates… |
|
not impossible, but usually these are rare and patch level updates, i.e. wrong code bug fixes that have typically no real performance impact. I'm mostly worried about the clang / gcc switch that the user can access. We could look at the compiler version, but that wouldn't capture the assembler or the linker, or libc, or lpthreads, or anything else that might have an impact on the generated binary. |
ppigazzini
added
enhancement
worker update
ppigazzini
force-pushed
the
flush_cache
branch
from
fd45b00
to
e913abb
Compare
The worker update moves the |
as the user could change the compiler at worker startup time (e.g. clang vs gcc), the binary cache might contain binaries compiled with a different compiler than the ones generated by the worker. As different compilers lead to binaries of different speed, test results could be biased, unless we assure that the same compiler is used for both base and new test. This patch just clears the binary cache once at worker startup, leaving the caching mechanism unchanged otherwise. fixes official-stockfish#1666
ppigazzini
force-pushed
the
flush_cache
branch
from
e913abb
to
ad87dde
Compare
|
I triggered the workers update, I will keep on eye on noob's workers, last time they got stuck during the update. |
as the user could change the compiler at worker startup time (e.g. clang vs gcc), the binary cache might contain binaries compiled with a different compiler than the ones generated by the worker. As different compilers lead to binaries of different speed, test results could be biased, unless we assure that the same compiler is used for both base and new test.
This patch just clears the binary cache once at worker startup, leaving the caching mechanism unchanged otherwise.
Possibly the binary cache should also be flushed on worker update (e.g. the architecture selection logic might change). This is not implemented.
fixes #1666