Hi Larry, > I apologize if I'm not up to speed on multi-threaded and re-entrant coding. > What is the purpose you are trying to accomplish with your patch? Is it just > the ability to multithread?
Most definitely. > Or is there a possible benchmark improvement to > GLPK? I don't think the parts in my patch have anything to do with the performance (speed) of GLPK, nor were they intended to. And I personally don't have an interest in benchmarking GLPK. > Just wondering what is lacking to make it on par with CPELX or whatnot. I'm sure Andrew would have a better idea of this than I would. I have profiled the code a couple of times, and if I'm not mistaken a good deal of time is spent in LU-factorization stuff. It looks like it was coded from scratch for GLPK, which is cool. But I think that using a library (open source or not) optimized to do this work would pay some speed dividends. Can anyone comment on the appropriateness of that assessment? If you are super-interested in this topic, I'd recommend profiling GLPK with a bunch of different problems and see what functions are gobbling up the processing time. Joey _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
