weight-efficient pyshac, possibly tf eager

[Andrew Hundt]

ENAS shows that keeping/reloading past model weights during search can make model search much more efficient, and with eager execution models could potentially be modified more often, perhaps on a per-batch basis even. Overhead of building/evaluating models would have to be kept very low, as would memory utilization and the component which selects a new set of model params.

Since I'm not sure how the threading/process model currently works here I'm not sure if I could simply declare a shared model object which would be called with the current choice of params. Do you have any thoughts on gotchas I might encounter, and could it be feasible to run pyshac with eager execution enabled?

I'm hoping it would be too troublesome since I see some tfe code (though not using pyshac), and there is already a pytorch backend.

Aside: why is the actual pyshac fit call commented?

[Somshubra Majumdar]

The fit call is expensive, while evaluation is relatively fast, so it's commented out.

You can do eager execution, but you must manage the creation and update of models yourself. Probably in a management class, whose evaluation function is passed to shac.

To do this, you have to use the Threading backend instead of the Loky or multiprocessing backend, as created processes are destroyed, but threading backend shares it's heap with the evaluation function. You can do so with shac.concurrent_evaluators().

After that, just use the PyTorch backend. Everything is the same.

So it would be

shac = TorchSHAC(...)
shac.concurrent_evaluators()