You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By moving the cache to a separate HashMap or something, neurons would not need to be stored in a RwLock, greatly reducing the amount of data being cloned while transferring between topology and mutable. Additionally, flush_state could be merged into predict without fear of performance issues because the map can simply be replaced by a new one in memory, which is way faster than the current iterative approach.
The text was updated successfully, but these errors were encountered:
The main difficulty I see with this approach is accidentally wasting CPU cycles due to situations where a neuron is in the process of being solved but other threads also try to solve it because there is no RwLock telling it that the work is already being done. Perhaps this could be solved by first creating a temporary locking entry that forces the other ones to wait until it has finished before having free read access to the value.
By moving the cache to a separate HashMap or something, neurons would not need to be stored in a RwLock, greatly reducing the amount of data being cloned while transferring between topology and mutable. Additionally,
flush_state
could be merged intopredict
without fear of performance issues because the map can simply be replaced by a new one in memory, which is way faster than the current iterative approach.The text was updated successfully, but these errors were encountered: