Open nguyencongminh090 opened 3 years ago
I've seen that AG 5.6.1 supports Yixin protocol, so I've tried to run AG 5.6.1 under YixinGUI ( "protocol": "yixinboard"
) :
YixinGUI 1.6 (the older one which comes with Yixin):
YixinGUI 2.1 (the newer one which comes with Rapfi):
Received : board
Received : 13,5,2
Move 13,5 is outside of 0x0 board
Answered : ERROR Move 13,5 is outside of 0x0 board
Received : done
Answered : UNKNOWN 'done'
Received : end
AlphaGomoku successfully exits
other times YixinGUI 2.1+ AG 5.6.1 won't run and will crash to desktop immediately at runtime
also it doesn't seem to support "unlimited time" mode at (will crash YixinGUI to desktop at runtime), which sucks badly as it makes this great engine useless for playing long time games
Regarding 'ERROR Move 13,5 is outside of 0x0 board" then it is indeed a bug, probably easy to fix.
However for the rest of issues (crashes), are you sure that it is caused by interaction with YixinBoard? Maybe AG just don't work on its own? Try running a selfcheck, by either:
Both methods will test few potentially problematic parts of code and produce selfcheck.txt file. Attach it here so I can see what went wrong.
However for the rest of issues (crashes), are you sure that it is caused by interaction with YixinBoard? Maybe AG just don't work on its own?
I'm able to reproduce the problem. To me it looks like YixinBoard launches AG process then starts sending commands, but until AG actually starts processing input from std::cin there are a lot of commands that have been lost and never got to the engine. I'm not sure what I can do about it right now.
All right, I think I solved the problem(s):
Things that are not a bug but still not ok:
It seems good. But could you also implement message to allow the engine "show" the move is thinking during analyze? (MESSAGE REALTIME BEST x,y <---- Show the best move from the current position). Thanks
First of all, AG search algorithm works differently than alpha-beta search in Yixin so I don't have many of the informations (namely POS and REFRESH). Besides, the current implementation does not allow the search engine to return some message on its own. This would require some workaround.
I've tested the new version, and it finally works in YixinBoard.
I know it's best to use GPU binary, but still worth to report that CPU binary refuses to use more than 1 cpu thread in YixinBoard :
"search_threads": 1, // number of threads used by the program. This setting can be changed at runtime (depending on protocol).
I don't know... But I tested AlphaGomoku on YixinBoard of Dblue and it worked (numberOfThread) (checked by watch task manager)
I've checked again and it still refuses to use more than 1 core in YixinBoard 2.1 of Dblue.
The problem with number of threads was tirvial - a typo in the implementation. I guess @nguyencongminh090 was talking about setting number of threads directly in the config file, which worked but it should also be customizable via YixinBoard.
Note: You still need to add more devices in the configuration file in order to use multiple threads. You should have at least as many elements in the list as the max number of threads you want to use. For example:
"devices": [ { "device": "CPU", "batch_size": 12}, { "device": "CPU", "batch_size": 12}, { "device": "CPU", "batch_size": 12}, { "device": "CPU", "batch_size": 12} ],
will allow up to 4 threads.
Thanks for all findings. In the newest release I think I fixed all of them. I'm not closing this issue in case you'll find other problems or have more suggestions.
MaciejKozarzewski : I guess nguyencongminh090 was talking about setting number of threads directly in the config file, which worked. Note: You still need to add more devices in the configuration file in order to use multiple threads. (...)
Nope, I was talking about the same, I already had my config.json
file properly adapted for multithreads, (I used --benchmark
+ --configure
to create it so no human error here), and with this same config.json
, it uses multiple threads everywhere except in YixinBoard GUI.
Now I've tried to run AG 5.7.1 in YixinBoard GUI with the same config.json
from 5.7.0, but as soon as YixinBoard GUI shows up, it closes itself immediately.
Then I've auto-generated a new config.json
file in 5.7.1 with --benchmark
+ --configure
, and the YixinBoard GUI doesn't close itself anymore, but still using only 1 core.
Even pasting your example from your above comment into config.json
file, altogether with setting "search_threads": 4
, still using 1 core.
Attaching the both autogenerated configs : 5.7.0 config.json, 5.7.1 config.json By the way, if you compare the both autogenerated configs in some compare tool, you will find some differencies : https://www.diffchecker.com/0zqvwRXi/
nguyencongminh090 would you keen to share your config.json
so that I can check whether it will make multithreads working for me.
EDITED: it seems it's finally fixed in 5.7.1 (and 5.7.0 was bugged). I'm not sure (I don't remember) how it happened that 5.7.1 was using only 1 core, one of the 2 possibilites :
config.json
uses only 1 core, then I rerun it with config.file
set to 8 threads, but it was still using only 1 core, once I set the slider back to 8 threads manually, and now it worksI have another idea : some users are novice and don't know how to install AG into YixinBoard GUI :
All that might be too hard for noobs to handle, maybe it would be a good idea, to provide also additional package for them (YixinBoard 2.1 + AG installed), just like Dblue does with Rapfi, so that novice users just unzip on their desktop and run and it works for noobs out of the box.
Additional benefit is that such additional distribution, given how easy is to use for noobs, will make AG more user friendly and thus more popular, and noobs who were limited to use Rapfi-Yixin package will also start using AlphaGomoku-Yixin package.
Regarding number of threads in 5.7.0: AG didn't send info about max supported number of threads, in which case YixinBoard assumed 1 and send such setting. But AG does properly respond to this message and overrides whatever you set in the config file. This is why it didn't work.
Regarding easier installation, I understand @garry-ut99 reasoning. But YixinBoard protocol is inconsistent, has no documentation, and in many ways violates the internal logic of AG. I don't want to invest time in implementing more support for it. I'd rather spend this time on writing my own GUI.
I'd rather spend this time on writing my own GUI.
Ok, are you thinking about modifying/adapting YixinBoard, QPiskvork, Piskvork, or building your own GUI from scratch? Building from scratch is investing much time too, isn't any of them suitable/easy for modifying?
The idea of Lizzie GUI or Gomocalc seems to be good. I'd like a GUI with can view each branch of move or display winrate in real-time. QPiskvork is not good in analysis because of no option for analysis, just for engine tournaments. Besides that, QPiskvork GUI is not nice. Piskvork is the same as QPiskvork, it doesn't support real-time analysis and unlimited time settings. I think the best one is to create a new GUI from scratch with a modern style and satisfy those needs.
The idea of Lizzie GUI or Gomocalc seems to be good. I'd like a GUI with can view each branch of move or display winrate in real-time.
Yes I forgot about Go GUIs like LizzieGUI, but maybe because they support only GTP protocol, while AlphaGomoku supports only Gomocup/Piskvork protocol, so they are not protocol-compatible, if it's not a problem, to make them protocol-compatible, then choosing LizzieGUI can be a good idea.
Piskvork / QPiskvork is not good
At least they "are good" because they already support the same protocol AlphaGomoku uses, while LizzieGUI you've mentioned "is not good" because it isn't protocol-compatible with AlphaGomoku, Protocols can be implemented, but the features you've mentioned are missing, can be implemented either. You seem to have forgotten about a fact we are speaking about modifying a GUI, or even building from scratch, not about simply using/choosing a GUI. Depends on what is really useful and what is easier to implement. But if GTP protocol is better for analysis for AG, and easier to implement, then we can go with LizzieGUI.
QPiskvork (...) because of no option for analysis, just for engine tournaments.
I know, it doesn't even support engine tournaments, only engine matches, which I already mention here : https://github.com/MaciejKozarzewski/AlphaGomoku/issues/8#issuecomment-1802073381
Besides that, QPiskvork GUI is not nice.
Given a fact it uses the same bitmaps like Piskvork, and looks same like Piskvork, you're basically saying that Piskvork doesn't look nice either, or maybe because the default selected bitmap in QPiskvork is different than in Piskvork, maybe try to change skins, some skins look better than others, also you can always create your own custom bitmaps/skins. For me Q or Piskvork doesn't look neither bad nor good, it's more a matter of choosing or creating a good skin.
No, I didn't mean we will make AG to run on LizzieGUI but create a GUI with same function there, still use Gomocup protocol.
I think the best one is to create a new GUI from scratch with a modern style and satisfy those needs.
I'm not saying about reuse a possible GUI. If choosing Piskvork, and make it able to analysis, then it seems need to change a lot of part and GUI, not only add function.
QPiskvork is not nice
I remembered that the pixel image of the board has a low resolution. And duplicate line after each move. the author seems divided each part of pieces.bmp of piskvork by slice only. Piskvork GUI is okay, it's easy to create a bitmap and import to piskvork. But anyway, choosing Piskvork or QPiskvork are same (about function), I still prefer Piskvork.
You can take a look at Piskvork (modified by my friend)
No, I didn't mean we will make AG to run on LizzieGUI but create a GUI with same function there, still use Gomocup protocol.
I think the best one is to create a new GUI from scratch with a modern style and satisfy those needs.
I'm not saying about reuse a possible GUI.
I know that you meant to build from scratch, but when I mentioned about adapting/modifying (not building from scratch), it was just my separate alternative proposition to your proposition.
If choosing Piskvork, and make it able to analysis, then it seems need to change a lot of part and GUI, not only add function.
My reasoning was that actually I was thinking that building from scratch requires more work/time than adapting/modifying something which already exist, like I already said :
Building from scratch is investing much time too, isn't any of them suitable/easy for modifying?
Because I was thinking that buliding a car from scratch requires more work/time than adapting an already existing car to a new engine, or already existing engine to a new car, but I'm not sure about it, so if it turns out that it's easier/faster to build GUI from scratch than to convert/adapt it, then I'm fine with it.
QPiskvork is not nice
I remembered that the pixel image of the board has a low resolution. And duplicate line after each move. the author seems divided each part of pieces.bmp of piskvork by slice only.
I didn't notice it for the first time, but I've looked now again and indeed, board and pieces are pixelisated, then I've noticed that the default grid size in QPiskvork is 36, but HGarden2 skin bitmap's default size in Piskvork is 32, so I have changed grid size from 36 to 32 but still pixelisated, then have changed to 26 and still pixelisated. It seems bitmap rendering in QPiskvork is broken somehow, I've reported it on QPiskvork bug tracker.
I think about time consume problem will depend on the purpose and target of the program. If it require to change a lot of from original then it's better to write a new one from scratch. And anyway, I'm here just to give some suggestion, I can't decide the product because I'm not author so of course I just mention about idea only. I understand your opinion as well, but thinking again and make a small analysis about Yixin and Piskvork. Currently, Yixin is the most suitable and able to develope more. The only problem appears is protocol to connect/ communicate between engine and GUI. Analyze code may help but will cost a time. Another reason is Yixin GUI was too old (about design), some modern application recently such as Lizzie seems nicer (Of course, this is just a small factor that we don't need to be serious). At this time, Yixin still good with it first purpose so keep using is no problem. My ideas about function are above, what is your idea about function that you want to add? (include modify or from scratch)
Protocol
Same as Gomocup protocol, just a little different
yxboard
yxstop
Another protocol such as turn, board, ... is the same as Gomocup protocol
Rule Standard
The first command for choice "Program play as black" usually is
The first command for choice "Program play as black" usually is
After it maybe the same with Piskvork
Swap / Swap2 rule
Some command:
1. yxswap2step2 (Program choose color or add 2 more stones)
Example:
After it, engine will choose color or add 2 more stones.
1.1. Add 2 more stones:
Engine will return:
a) Opponent choose white:
It mean the manager will send include 3 stones from begin, 2 stones from engine and 1 stones from opponent.
b) Opponent choose black:
It mean the manager will send include 3 stones from begin, 2 stones from engine.
1.2. Engine choose black:
Then after taht, the manager will send
then the game continue
1.3. Engine choose white:
Then after that, the manager will send
and engine return the next move.
2. yxswap2step1 (Program put 3 stones)
The manager will ask the opponent choose color then maybe also send "BOARD" command then continue the game.
Notice:
Support analyze mode
MESSAGE REALTIME BEST x,y <---- Show the best move from the current position MESSAGE REALTIME POS x,y <---- Show the position is analyzing MESSAGE REALTIME REFRESH <---- Refresh, maybe it mean clear all spot MESSAGE REALTIME DETAIL ... (print output)