bupticybee / TexasSolver

🚀 A very efficient Texas Holdem GTO solver :spades::hearts::clubs::diamonds:
https://bupticybee.github.io/texassolver_page
GNU Affero General Public License v3.0
1.65k stars 294 forks source link

Why does the console_solver take so long to load up on linux? #120

Closed 1nclusion closed 1 year ago

1nclusion commented 1 year ago

If I compile it, it starts quickly but I get memory access errors. Maybe it is because I don't execute it as root.

bupticybee commented 1 year ago

If I compile it, it starts quickly but I get memory access errors. Maybe it is because I don't execute it as root.

Sorry I don't have a linux machine, so no idea what happened here.

But I suggest you follow the README in console branch here: https://github.com/bupticybee/TexasSolver/tree/console#compile-from-source

It guide you through the compile process for console version in linux (yes, gui is not offically supported in linux), you might be able to find something useful there.

1nclusion commented 1 year ago

edit: I am happy that you made the solver, but its so frustrating that nothing works for me.

1nclusion commented 1 year ago

So executing from file takes about 30 seconds in the console_solver. What does build-AppImage.sh do from the master branch? It seems to build a much faster commandline_solver but it did not work when I tried it (memory access error).

If I do a testrun with "./console_solver -i resources/text/output_parameters.txt" as it is in your link the solve is much slower than in the GUI with the same input file.

The file is

set_pot 110
set_effective_stack 1950
set_board Qs,Jh,2h
set_range_oop 87o:0.0003,J7s:0.0061,AJs:0.0838,98o:0.103,A4o:0.1039,JTs:0.1965,Q9o:0.2008,T6s:0.2457,42s:0.2545,KJo:0.2796,99:0.2826,KTo:0.2913,K3s:0.3445,T9s:0.3853,A5o:0.4338,K9o:0.524,T7s:0.5246,J4s:0.5526,A7o:0.606,K6s:0.6524,77:0.663,J8s:0.6667,J5s:0.6738,QTs:0.6759,52s:0.6808,QJo:0.6907,T9o:0.6947,A5s:0.709,AJo:0.721,ATo:0.7244,J9o:0.7346,88:0.7417,Q8s:0.7461,KQo:0.756,QJs:0.7673,JTo:0.7726,J6s:0.7905,QTo:0.8075,55:0.8082,K2s:0.8192,76s:0.8237,Q3s:0.828,A8o:0.83,96s:0.8316,T8s:0.8723,Q6s:0.878,66:0.9069,K7s:0.914,54s:0.9387,65s:0.9394,K5s:0.9675,Q5s:0.9852,63s:0.9946,53s:0.9964,Q7s:0.999,A2s:0.9993,K4s:0.9999,A6s:0.9999,22,Q2s,33,43s,A3s,44,64s,74s,Q4s,A4s,75s,85s,86s,87s,97s,A7s,98s,K8s,A8s,Q9s,K9s,A9s,A9o,KTs,ATs,KJs
set_range_ip J8o:0.1175,J4s:0.394,K7o:0.4317,T8o:0.4858,96s:0.7169,22:0.8455,K8o:0.8855,54s:0.9026,75s:0.9272,Q3s:0.959,K2s,A2s,33,K3s,A3s,A3o,44,Q4s,K4s,A4s,A4o,55,65s,J5s,Q5s,K5s,A5s,A5o,66,76s,86s,T6s,J6s,Q6s,K6s,A6s,A6o,77,87s,97s,T7s,J7s,Q7s,K7s,A7s,A7o,88,98s,T8s,J8s,Q8s,K8s,A8s,A8o,99,T9s,T9o,J9s,J9o,Q9s,Q9o,K9s,K9o,A9s,A9o,TT,JTs,JTo,QTs,QTo,KTs,KTo,ATs,ATo,JJ,QJs,QJo,KJs,KJo,AJs,AJo,QQ,KQs,KQo,AQs,AQo,KK,AKs,AKo,AA
set_bet_sizes oop,flop,bet,35
set_bet_sizes oop,flop,raise,85
set_bet_sizes ip,flop,bet,35
set_bet_sizes ip,flop,raise,85
set_bet_sizes oop,turn,bet,85
set_bet_sizes oop,turn,raise,100
set_bet_sizes oop,turn,donk,50
set_bet_sizes ip,turn,bet,85
set_bet_sizes ip,turn,raise,100
set_bet_sizes oop,river,bet,85
set_bet_sizes oop,river,raise,100
set_bet_sizes ip,river,bet,85
set_bet_sizes ip,river,raise,100
set_bet_sizes oop,river,donk,50
set_allin_threshold 0.67
set_raise_limit 2
build_tree
set_thread_num 8
set_accuracy 4
set_max_iteration 100
set_print_interval 10
set_use_isomorphism 1
start_solve
set_dump_rounds 2
dump_result output_result.json

command not recognized: set_raise_limit

I now tried to get it to work a couple of times. One time it did not terminate as told at 4%. Now it is not even printing anything and I am not sure it does anything. Now it printed something after 5 minutes. So far I did not get an output file from console_solver. edit: It took like 20 minutes to do the solve. In the GUI version it takes a couple of seconds, but its not including all the partial hands.

Why is it slower than the GUI version? I will try it on windows another day.

edit: I have an 50mb json outputfile and I don't know how to read it.

bupticybee commented 1 year ago

87o:0.0003

some range in your input file is too small and get filtered by the GUI logic, that's why I think

bupticybee commented 1 year ago

So executing from file takes about 30 seconds in the console_solver. What does build-AppImage.sh do from the master branch? It seems to build a much faster commandline_solver but it did not work when I tried it (memory access error).

If I do a testrun with "./console_solver -i resources/text/output_parameters.txt" as it is in your link the solve is much slower than in the GUI with the same input file.

The file is

set_pot 110
set_effective_stack 1950
set_board Qs,Jh,2h
set_range_oop 87o:0.0003,J7s:0.0061,AJs:0.0838,98o:0.103,A4o:0.1039,JTs:0.1965,Q9o:0.2008,T6s:0.2457,42s:0.2545,KJo:0.2796,99:0.2826,KTo:0.2913,K3s:0.3445,T9s:0.3853,A5o:0.4338,K9o:0.524,T7s:0.5246,J4s:0.5526,A7o:0.606,K6s:0.6524,77:0.663,J8s:0.6667,J5s:0.6738,QTs:0.6759,52s:0.6808,QJo:0.6907,T9o:0.6947,A5s:0.709,AJo:0.721,ATo:0.7244,J9o:0.7346,88:0.7417,Q8s:0.7461,KQo:0.756,QJs:0.7673,JTo:0.7726,J6s:0.7905,QTo:0.8075,55:0.8082,K2s:0.8192,76s:0.8237,Q3s:0.828,A8o:0.83,96s:0.8316,T8s:0.8723,Q6s:0.878,66:0.9069,K7s:0.914,54s:0.9387,65s:0.9394,K5s:0.9675,Q5s:0.9852,63s:0.9946,53s:0.9964,Q7s:0.999,A2s:0.9993,K4s:0.9999,A6s:0.9999,22,Q2s,33,43s,A3s,44,64s,74s,Q4s,A4s,75s,85s,86s,87s,97s,A7s,98s,K8s,A8s,Q9s,K9s,A9s,A9o,KTs,ATs,KJs
set_range_ip J8o:0.1175,J4s:0.394,K7o:0.4317,T8o:0.4858,96s:0.7169,22:0.8455,K8o:0.8855,54s:0.9026,75s:0.9272,Q3s:0.959,K2s,A2s,33,K3s,A3s,A3o,44,Q4s,K4s,A4s,A4o,55,65s,J5s,Q5s,K5s,A5s,A5o,66,76s,86s,T6s,J6s,Q6s,K6s,A6s,A6o,77,87s,97s,T7s,J7s,Q7s,K7s,A7s,A7o,88,98s,T8s,J8s,Q8s,K8s,A8s,A8o,99,T9s,T9o,J9s,J9o,Q9s,Q9o,K9s,K9o,A9s,A9o,TT,JTs,JTo,QTs,QTo,KTs,KTo,ATs,ATo,JJ,QJs,QJo,KJs,KJo,AJs,AJo,QQ,KQs,KQo,AQs,AQo,KK,AKs,AKo,AA
set_bet_sizes oop,flop,bet,35
set_bet_sizes oop,flop,raise,85
set_bet_sizes ip,flop,bet,35
set_bet_sizes ip,flop,raise,85
set_bet_sizes oop,turn,bet,85
set_bet_sizes oop,turn,raise,100
set_bet_sizes oop,turn,donk,50
set_bet_sizes ip,turn,bet,85
set_bet_sizes ip,turn,raise,100
set_bet_sizes oop,river,bet,85
set_bet_sizes oop,river,raise,100
set_bet_sizes ip,river,bet,85
set_bet_sizes ip,river,raise,100
set_bet_sizes oop,river,donk,50
set_allin_threshold 0.67
set_raise_limit 2
build_tree
set_thread_num 8
set_accuracy 4
set_max_iteration 100
set_print_interval 10
set_use_isomorphism 1
start_solve
set_dump_rounds 2
dump_result output_result.json

command not recognized: set_raise_limit

I now tried to get it to work a couple of times. One time it did not terminate as told at 4%. Now it is not even printing anything and I am not sure it does anything. Now it printed something after 5 minutes. So far I did not get an output file from console_solver. edit: It took like 20 minutes to do the solve. In the GUI version it takes a couple of seconds, but its not including all the partial hands.

Why is it slower than the GUI version? I will try it on windows another day.

edit: I have an 50mb json outputfile and I don't know how to read it.

The way to read the output json file is in the readme here:

https://github.com/bupticybee/TexasSolver/tree/console#reading-the-solvers-output-strategy

1nclusion commented 1 year ago

The File is too large. It is not rendered in firefox or chromium. So I can not do it like in the link. Can you tell something on the speed of console solver vs gui solver and on if they give the same output? I prefer to just use the console solver.

bupticybee commented 1 year ago

Console version is 30% faster in my tests. You really should write a program to read the output strategy file.

SynAckFin commented 1 year ago

The console version loads the files here https://github.com/bupticybee/TexasSolver/tree/master/resources/compairer and parses the contents. This is for the compairer. That is what takes the time. The gui version compiled from the master branch does the same, but the gui version in the gui branch has the tables pre compiled so dosen't take long to startup.

bupticybee commented 1 year ago

The console version loads the files here https://github.com/bupticybee/TexasSolver/tree/master/resources/compairer and parses the contents. This is for the compairer. That is what takes the time. The gui version compiled from the master branch does the same, but the gui version in the gui branch has the tables pre compiled so dosen't take long to startup.

Yes, I havn't get the latest code to console branch.

silentdiverchris commented 1 year ago

The console version loads the files here

Hi, could you please tell me if is there is a way to load these once, then generate multiple solutions without reloading the compairer data each time ? - this is with the console_solver, I mean.

After some pondering on how to run the console_solver but make the initial load much faster, I thought of the possibility of instead of one large card5_dic_sorted.txt, it could have many(, many, many) much smaller ones that only contained the combinations including cards that are in the (known) board cards, so for example for board Ac Ad As it could load Ac_Ad_As_dic_sorted.txt, which would only contain the subset of the big file that included those 3 cards, which would take a fraction of the time.

Would this approach work ? - I'm assuming I understand the content of the big file, maybe I don't as it seems far smaller than a full set of all possible 5 card boards - if there needed to be a small file for every single possible flop/turn/river combination it'd be a horrific number of small files, but if the full set is 2.6 million that's more manageable.

This the reason I'm trying to get my head around what the 2.6 million lines in that file are, whether this many-smaller-files approach might be a good way to reduce the startup time of the console_solver (thus my issue https://github.com/bupticybee/TexasSolver/issues/124).

bupticybee commented 1 year ago

The console version loads the files here

Hi, could you please tell me if is there is a way to load these once, then generate multiple solutions without reloading the compairer data each time ? - this is with the console_solver, I mean.

After some pondering on how to run the console_solver but make the initial load much faster, I thought of the possibility of instead of one large card5_dic_sorted.txt, it could have many(, many, many) much smaller ones that only contained the combinations including cards that are in the (known) board cards, so for example for board Ac Ad As it could load Ac_Ad_As_dic_sorted.txt, which would only contain the subset of the big file that included those 3 cards, which would take a fraction of the time.

Would this approach work ? - I'm assuming I understand the content of the big file, maybe I don't as it seems far smaller than a full set of all possible 5 card boards - if there needed to be a small file for every single possible flop/turn/river combination it'd be a horrific number of small files, but if the full set is 2.6 million that's more manageable.

This the reason I'm trying to get my head around what the 2.6 million lines in that file are, whether this many-smaller-files approach might be a good way to reduce the startup time of the console_solver (thus my issue #124).

Yes, this is already implemented, set up the console solver in a subprocess, feed config as stdin, and read results from stdout, in that case the resource will be ready each time you running a solving situation.

silentdiverchris commented 1 year ago

Yes, this is already implemented, set up the console solver in a subprocess, feed config as stdin, and read results from stdout, in that case the resource will be ready each time you running a solving situation.

That sounds great, thanks very much. I'm not sure what you mean by a sub-process though, I should write a wrapper that calls it ?

bupticybee commented 1 year ago

Yes, this is already implemented, set up the console solver in a subprocess, feed config as stdin, and read results from stdout, in that case the resource will be ready each time you running a solving situation.

That sounds great, thanks very much. I'm not sure what you mean by a sub-process though, I should write a wrapper that calls it ?

Let me find a way to explain. First, write another program(Let't call it A) , in that prograrm ,start solver in a subprocess(Let't call it B), and wait there. When a solving is needed, directly write from A to B's stdin the config file. In this way the loading time is saved. Because when the subpross is initized, dict file is auto loaded, and when calling it later, loading is already done.

silentdiverchris commented 1 year ago

Hi and thanks, I understand the concepts, I was just asking what you meant by a 'sub-process' in case it meant something special in this particular context. Got you yep, just start it with no parameters and it will wait for input on stdin and direct the output to stdout, cool, thanks.

I'd actually stumbled on this before when accidentally calling it parameterless, I assumed it had got stuck in some way as it initialised and didn't return, now I get what it's doing.

1nclusion commented 1 year ago

Console version is 30% faster in my tests. You really should write a program to read the output strategy file.

I have not attempted it yet. Can anybody please tell me what the format or structure of the output is exactly so I know how to program a file that reads it? Its impossible for me to figure out. Its not rendered in a readable way with any of my applications. Its 50 mb of text.

silentdiverchris commented 1 year ago

It's json, paste it into / open it with a json capable editor or web site.

You may need to choose a spot that generates a smaller output depending on the capabilities of whatever you paste it into or open it with, a river spot for example, to get a more manageable output to begin with.

bupticybee commented 1 year ago

Closing. Reopen if necessary.