Open AlessandroPierro opened 1 year ago
We had the expected behavior in a previous release and it was removed in the last one in favor of the current behavior. We should bring back the previous version which I would have left as default and offered the most performant version as optional. The reason being that the cost in performance is relatively low and the user experience is much better if the user can track the evolution of the search.
Also, are we sure we are providing the best solution if target cost was not found? In a debug session one user was getting an all -1 vector when target_cost was not found. Maybe we need a test for this.
But @AlessandroPierro, how are you envisioning the strategy implementation? We can probably not support a fully generic strategy easily, because it requires changing the CostIntegrator (microcode) and ReadGate (C) processes. Thus, we would only allow the user to switch between streaming every better cost or only the best. Right?
We had the expected behavior in a previous release and it was removed in the last one in favor of the current behavior. We should bring back the previous version which I would have left as default and offered the most performant version as optional. The reason being that the cost in performance is relatively low and the user experience is much better if the user can track the evolution of the search.
I agree for CPU backend, but on Loihi we observed 100x speedup. We can redesign this now using StateProbes. I would leave the most performant version for the ReadGate/SolutionReadout and delegate the finer tracking to a probe_cost flag as we discussed. What do you think? @GaboFGuerra
Objective of issue: propose implementation of different reading strategies for ReadGate/SolutionReadout
lava-optimization version:
I'm submitting a ...
Current behavior:
Expected behavior: