Axolotl 1.3 uses 2 cores of my PC, is there a way to restrict it to just 1 core?
Also, only the ancient version of Winter 0.3 run on my AMD, the problem is no more than one instance of it could play at the same time (I run one core tournaments with 3 instances of Winboard at the same time.)
I have added a release calendar as a new spreadsheet to the XB/UCI chronology.
(may be this will lead to a rating diagram over a long time scale in the future...)
Currently only the latest data is in. Time is divided in monthly chunks.
For programs with continouus dev versions I will only add the last one per month.
Those have a preceding '#' for the version number.
Fridolin 3.00 was released a few days ago still in 2018.
I will open a new thread for engine releases in 2019 next time for avoiding a too huge thread.
The binary doesn't run here though and I don't know if it is a dotnet problem, or because of my hardware not supporting popcount
Please report back if you can run this version. Thanks!
Shatranj 1.18 had an ep fix in 2016-04 which was merged in 2017-01, this one slipped through too.
(version remained unchanged just replace the py file)
Also, only the ancient version of Winter 0.3 run on my AMD, the problem is no more than one instance of it could play at the same time (I run one core tournaments with 3 instances of Winboard at the same time.)
Thank you for the information!
Could you tell me which AMD cpu you are using? If its a newer one, I should probably make an executable that runs on those machines. Iirc "Old" expects SSE4.1 and SSE4.2, which is from 2008 or so. It's possible AMD adopted these instruction sets later than intel. Perhaps I should also rename the executable, don't want to offend anyone's systems =).
Regarding the multiple instance issue, I will try to reproduce this on my Core i5.
In the meantime, I was wondering if you could also give me some information which might help find the issue. How many cores does your system have and how many threads is it running on? Is Winter stable as long it's only running in one instance?
I am able to reproduce the Winter crashes by creating indefinite numbers of concurrent instances and calling go infinite in each (so no GUI interaction needed and it isn't system dependent). I have ideas where to look and should be able to fix it.
Most likely I will be able to fix it and release Winter 0.4 sometime this month. Development version is already a solid 70+ Elo above Winter 0.3 on one core at bullet time controls, so I feel calling the new version 0.4 and not 0.3.1 or something of the sort seems reasonable.
I want to thank Graham Banks for the useful log files and apologize to everyone who has been inconvenienced by this. Hopefully you have now experienced Winter at its least stable point =)
jorose wrote: ↑Thu Jan 03, 2019 8:29 pm
Quick update.
I am able to reproduce the Winter crashes by creating indefinite numbers of concurrent instances and calling go infinite in each (so no GUI interaction needed and it isn't system dependent). I have ideas where to look and should be able to fix it.
Most likely I will be able to fix it and release Winter 0.4 sometime this month. Development version is already a solid 70+ Elo above Winter 0.3 on one core at bullet time controls, so I feel calling the new version 0.4 and not 0.3.1 or something of the sort seems reasonable.
I want to thank Graham Banks for the useful log files and apologize to everyone who has been inconvenienced by this. Hopefully you have now experienced Winter at its least stable point =)
Good news! I am looking forward to the new version.
Jesse Gersenson wrote: ↑Wed Dec 12, 2018 2:00 am
Vajolet 2.6.2 is a Linux file. It is a bug fix to 2.6.1 and it runs great.
Vajolet2 2.6, 2.6.1 and 2.6.2 are more or less the same version with very small bugfix to problem that have arisen in TCEC and CCC testing
2.6.1 fix a crash that has happened in TCEC
2.6.2 was a rebuild of 2.6.1 linux executable that was mistakenly shipped with some debugging code turned on.
