Closed odow closed 1 year ago
Patch coverage has no change and project coverage change: -0.06
:warning:
Comparison is base (
bbf2835
) 80.24% compared to head (b9096d5
) 80.19%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Users can still over-ride this manually.
They can and, for now, they won't notice any performance degradation.
However, this won't be the case once we've got the concurrent LP solver, parallel MIP search and parallel IPM solver.
They can and, for now, they won't notice any performance degradation. However, this won't be the case once we've got the concurrent LP solver, parallel MIP search and parallel IPM solver.
So just to summarize my understanding (let me know if I have some part wrong):
0
0
, HiGHS will internally set threads to half the number of cores0
, HiGHS sometimes stalls on Windows only1
should have minimal impactThe stall on Windows when the default is 0
but not 1
seems like the bug is in HiGHS, not in how we're compiling things on Yggdrasil. But it's pretty hard to track down because we can't compile Yggdrasil binaries directly on windows machines, and I don't have a Windows machine to test things on.
So just to summarize my understanding (let me know if I have some part wrong):
- The default is
0
Yes
- When the value is
0
, HiGHS will internally set threads to half the number of cores
Half the maximum number of threads for the machine
- When the value is
0
, HiGHS sometimes stalls on Windows only
Yes
- If the user manually sets a positive value, no stall happens
Not sure: I can try some experiments on my W10 laptop
- Currently HiGHS doesn't really use threading, so setting to
1
should have minimal impact
Yes
- It will have an impact once HiGHS starts to really use multithreading.
Yes
The stall on Windows when the default is
0
but not1
seems like the bug is in HiGHS, not in how we're compiling things on Yggdrasil. But it's pretty hard to track down because we can't compile Yggdrasil binaries directly on windows machines, and I don't have a Windows machine to test things on.
It would seem to be something to do with how HiGHS shuts down threads on Windows. It would be good to identify why, but there's too much to do at the moment. Using 1 is certainly OK with JuMP. HiGHS will use a larger default value so that our Linux benchmark performance for the MIP solver isn't compromised.
Would doing something like:
julia> Sys.cpu_info()
8-element Vector{Base.Sys.CPUinfo}:
Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz:
speed user nice sys idle irq
2300 MHz 3248726 s 0 s 1526146 s 22719837 s 0 s
Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz:
speed user nice sys idle irq
2300 MHz 226257 s 0 s 241621 s 27026610 s 0 s
Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz:
speed user nice sys idle irq
2300 MHz 2975710 s 0 s 1113774 s 23405012 s 0 s
Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz:
speed user nice sys idle irq
2300 MHz 219407 s 0 s 224294 s 27050788 s 0 s
Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz:
speed user nice sys idle irq
2300 MHz 2609224 s 0 s 887438 s 23997833 s 0 s
Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz:
speed user nice sys idle irq
2300 MHz 220094 s 0 s 209349 s 27065045 s 0 s
Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz:
speed user nice sys idle irq
2300 MHz 2662113 s 0 s 782994 s 24049388 s 0 s
Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz:
speed user nice sys idle irq
2300 MHz 227937 s 0 s 199417 s 27067132 s 0 s
julia> div(length(Sys.cpu_info()), 2)
4
be a better default?
So long as 4
doesn't mess up Windows, it's the value that I was thinking of for the in-HiGHS default.
So long as 4 doesn't mess up Windows, it's the value that I was thinking of for the in-HiGHS default.
Let's put this out there and see if any complaints roll in 😆. That's probably the only way we'll know.
Closes #160
Users can still over-ride this manually.