Hi,

Thank you for your interest in glpk.


On Fri, 2026-02-06 at 12:31 +0100, [email protected] wrote:
> Hi,
> 
> I'm using glpk in my game to calculate engine thrust configurations for 
> spaceships moving through a 2D physics simulation. This involves solving 
> tiny (3 constraints, <50 variables) LPs many times (100-1000) per 
> second. 

I think glpk is not a good choice in your case.  Much better would be to use 
some simple implementation, e.g. the simplx routine from the book "Numerical
Recipes in C", Section 10.8; see
https://freecomputerbooks.com/Numerical-Recipes-in-C-Second-Edition.html

Could you show the formulation of your LP?



Best,

Andrew Makhorin



> I am using GLPK version 4.65. GLPK was compiled with MSVC, and 
> my game is running on Windows 11.
> 
> Since this is a soft realtime application, I experimented with applying 
> a time limit to glpk via tm_lim in glp_smcp. I initially set the limit 
> to 2ms, which was meant to stop the game from hanging on an LP solve 
> that takes unexpectedly long. This didn't happen in practice, and 2ms 
> would already be super noticable (I'd need microsecond resolution to 
> make this useful), so this was an experiment more than an actual feature 
> from my perspective. With this 2ms limit in place, I noticed that 
> sometimes glp_simplex would return GLP_ETMLIM for invocations that took 
> on the order of single digits microseconds. So for some reason that I do 
> not fully understand, the time limit doesn't work as intended is 
> stopping optimization way too early.
> 
> I speculated that maybe glpk was using a clock with a very coarse 
> resolution, so I increased the time limit to 1000ms, yet it would still 
> be hit, for super short invocations. For the LP shown below, glp_simplex 
> returned GLP_ETMLIM after 5us and glp_get_status returned GLP_FEAS 
> instead of GLP_OPT:
> 
> The Linear Program "get_max_achievable_accelerations" is a maximization 
> problem with 8 variables and 3 constraints:
> vars:              x0       |      x1       |      x2       | x3      
>   |      x4       |      x5       |      x6       | x7       |
> cost:             0.00      |     0.00      |     0.00      |  0.00      
> >      0.00      |     0.00      |     0.00      |  1.00      |
> bounds:       0.00 to 1.00  | 0.00 to 1.00  |  0.00 to Inf  | 0.00 to 
> Inf  |  0.00 to Inf  |  0.00 to Inf  | 0.00 to 0.00  | 0.00 to Inf  |
> constraints:
>                   -1.25      |    -1.25      |     1.00      | -1.00    
>    |     0.00      |     0.00      |     0.00      |  0.00      =   0.00
>                    0.00      |     0.00      |     0.00      |  0.00    
>    |     1.00      |    -1.00      |     0.00      |  0.00      =   0.00
>                   -37.10     |     1.46      |     0.00      |  0.00    
>    |     0.00      |     0.00      |     0.00      | -1.00      =   0.00
> 
> I got the actual timinigs from manual instrumentation using rdtsc and 
> also profiling using the Tracy profiler. Besides that, I would _notice_ 
> if my game hang for 1 second, and it definitely doesn't, so the timeout 
> shouldn't be hit.
> 
> This is not a pressing issue to me, my game works fine without the time 
> limit in place, but I wanted to report it. Only being able to specify a 
> timeout in milliseconds makes this feature already not useful to me, but 
> on top of that, it just seems to be broken. I suspect this feature is 
> usually used for timeouts on the order of minutes or hours and my 
> usecase is very niche.
> 
> Have a nice day!
> 
> Simon van Bernem
> 
> 


Reply via email to