Hacker News new | ask | show | jobs
by Tarrosion 1523 days ago
At Zoba we use CLP, CBC, NLOpt, and OR-tools. Used to use Gurobi.

* CLP/CBC: open source makes deployment and devops easy, which is great. Linear models are nice in that you "know what you're getting." Performance is at times a pain point.

* Gurobi: super fast, but the licensing was just impossible. Partly that was due to high cost, but ultimately we could have borne the cost; the inability to do something like have autoscaling containers using Gurobi was ultimately the dealbreaker for us. As Zoba grew, we had to turn to alternatives.

* NLOpt: absolutely a blessing, but the variety of algorithms and tuning parameters is really opaque, even for a team with some OR experience/background.

* OR-tools: powerful but the documentation is remarkably terrible, and the vehicle routing problem solver doesn't natively support all the constraints we'd like, so we have to do some hacks.

Overall my feeling for all these tools is roughly gratitude: solvers are complex, and rolling our own would be absolutely impractical at our size. But also there's some pain in between "I've formulated my problem as a nice mathematical model" and "I can reliably get optimal results on time."

4 comments

Gurobi is so frustrating. I had the same experience: blistering performance on my problems, much better than OR-Tools, but just couldn't make it work at all with the licensing. It's like they've never heard of the cloud, or had any concept that anyone would use their software in any way other than big "batch" jobs on an in-house machine. I feel like someone could make a killing just buying Gurobi and making it work in a modern way.

NextMV was practically the opposite (at the time, I'm sure it has improved now, especially since they used to be far more insistent on decision diagrams): rather bad/terrible performance, but excellent in terms of licensing and deploying the code, and they had great support too. The modern deployment made sense given they were a new/modern company. One silver lining to the terrible performance, and why I used to stick up for them at the time was that you could get somewhat acceptable results fast: if you stopped after one second, CBC might be absolutely nowhere, but NextMV's solver would at least give you something. This meant you could do things that made use of extremely fast results, like trying a configuration and checking the (approximate) solution, then trying a bunch more, all very quickly.

In the end I mostly settled on OR-Tools.

Disclaimer: I work for Gurobi, but these views are my own.

---

I'm sorry to hear that you find our licensing frustrating. It is true that in the past we focused a lot on local deployments holding on to the notion of a physical machine. However, we have added a few licensing options that you might find interesting, specifically the Web License Service (https://www.gurobi.com/web-license-service/), where you can get a short-lived JSON Web Token inside of a Docker container which renews automatically. You can find our Docker Hub images here (https://hub.docker.com/orgs/gurobi/repositories).

There are also other ways like the Instant Cloud (https://www.gurobi.com/products/gurobi-instant-cloud/) which give you a very scalable SaaS approach.

Feel free to reach out to me (<lastname>@gurobi.com) to discuss more!

Do consider HiGHS. MIP performance is way ahead of Cbc now. For LP, our simplex solver is comparable with Clp, and our interior point solver is well ahead of any open-source solver.
I noticed that your comment contains no complaint about Gurobi's performance. For comparable problems, was Gurobi superior in solution convergence speed or the quality of the solution itself?

Gurobi, AFAIK, is considered the leading edge of the field, and other tools, especially open-source ones, do not perform as well.

I cannot speak specifically for your firm and use cases, but in my experience, if the use cases are structured and specific enough, rolling out a in-house optimizer is not such a bad idea.

Gurobi had excellent speed for us, but we didn't notice a difference between Gurobi and open source tools on final solution quality; all the linear solvers we've tried get to certifiable optimality on our problems, some just faster than others.
Disclaimer: I work for Gurobi but views are my own

---

Sorry to hear you found our licensing problematic! You might find interesting that we now have developed a Web License Service (https://www.gurobi.com/web-license-service/), where you can retrieve a short-lived JSON Web Token inside of your container to run Gurobi; our Docker Hub images are here: https://hub.docker.com/orgs/gurobi/repositories.

From what you are saying ("autoscaling containers"), this may be a good fit for you. What do you think?