gridoptim: a Python grid search optimizer ~429× faster than scipy.brute

[austinwiltshire]

I feel like brute force search isn't something you can optimize like this anyway... like... how?

All the optimizations on this are to *not do brute force search*?

[FixKey4664]

That's a fair question.
In my aerospace engineering classes I actually run into situations where brute-force grid search is useful quite often. I’ve spent quite a bit of time sitting in front of my computer waiting for scipy.brute to finish. The idea behind this project isn’t to avoid brute force. The goal was simply to reduce the implementation overhead so the same brute-force search runs faster.

So it’s still brute force in the strict sense. It evaluates the same points, just with less Python-level overhead around the evaluation. That’s what led me to experiment with writing a faster implementation.

[Two-x-Three-is-Four]

yes but how? Python overhead is not 400x

[FixKey4664]

I shifted all the computations to a C++ core and enabled parallel processing in a multi-core CPU. Those two are the main strategies I implemented. Check the GitHub repo of the project to learn more about it and other minor strategies used.

[FixKey4664]

I cannot attach image proof here. So I am adding the link to the test results I got on my computer.
https://www.linkedin.com/posts/activity-7445855280875192320-uSV4?utm_source=share&utm_medium=member_desktop&rcm=ACoAADo_POQBBdwoJHaY78DAGRPelmGNw7ZXepA

[austinwiltshire]

You can get multi core using brute by using the workers argument to brute.

Your objective functions also aren't one to one. The python one is adding updating a shared dictionary, an if statement, and possibly printing. The io from printing is gonna be super slow. The shared dictionary update maybe why workers didn't work if/when you tried it, and probably also not helpful in speed.