Cp-sat solver usage is over time lower than expected

[gregy4]

Hello,
in latest stable version (9.9) is over time cpu usage lower than expected. I use python and windows 10.

For example for attached model ortools uses 32 search workers (100% cpu) for first 10 minutes but over time with no progress in a solution or a bound cpu usage goes down to 50% in 30minutes.

Is it a bug or the solver simply give up on progress with some variants of lns for example? In that case some info in progress log would be helpful.

Thanks,
Jan

protofile.zip

[lperron]

I cannot read the protofile.

Check failed: ReadFileToProto(filename, cp_model) is OK (INVALID_ARGUMENT: binary format error: '', text format error: '1:0: Invalid control characters encountered in text., 2:12: Invalid control characters encountered in text., 2:15: Interpreting non ascii codepoint 128., 2:15: Message type "operations_research.sat.CpModelProto" has no field named "pocet_archu".', json error: 'invalid JSON in operations_research.sat.CpModelProto, near 1:1 (offset 0):

[gregy4]

Strange. There's text version of proto file. It was succesfully parsed by text_format.Parse method and solved by a solver.

protofile.txt

[lperron]

#Bound 79.82s best:34737 next:[34444,34736] objective_shaving_search_max_lp (vars=211 csts=185) #Bound 80.03s best:34737 next:[34445,34736] objective_shaving_search_max_lp (vars=211 csts=185) #Model 122.06s var:212/214 constraints:169/169 #Model 2957.08s var:210/214 constraints:169/169 #Model 4108.84s var:184/214 constraints:157/169 #Model 4132.64s var:183/214 constraints:157/169 #Done 4133.17s reduced_costs #Done 4133.17s probing I could not reproduce it. Are you sure this is not thermal throttling ? Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le mer. 13 mars 2024 à 18:15, gregy4 ***@***.***> a écrit :

…

Strange. There's text version of proto file. It was succesfully parsed by text_format.Parse method and solved by a solver. protofile.txt <https://github.com/google/or-tools/files/14591231/protofile.txt> — Reply to this email directly, view it on GitHub <#4129 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3PYNMIFFB57AG4D6XLYYCCT3AVCNFSM6AAAAABEULCTTGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONZWGU3DK> . You are receiving this because you commented.Message ID: ***@***.***>

[gregy4]

I reproduced it on another computer with windows 11 but lower cpu usage was less visible.

• with 16 core cpu amd 7950x and 16 search workers there was no problem.
• with 32 search workers, frequency fixed to 3GHz and temperature below a limit cpu usage dropped over time to 80%. Restart of calculation without rest time immediately forced to use 100% cpu.

Finally I tried debian 12 and it worked without any problems with 32 search workers and dynamic frequency. So my suspicion about problems with memory access is gone and I think the problem can be in windows scheduler and hyperthreading of amd zen cpus.