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
Whenever a call to update is updated off the update queue, rather than during a recursive call, we are guaranteed that every value u this call v looked up in the previous world has already been updated, and thus we have all diff information for it. Furthermore, when we updated each previous call u, we enqueued v to be updated--so at nearly no additional cost, at this time, we could add u to a set of diffed dependencies for v. Then, when we update v, rather than just looking at the world.state.diffs containing all diffs in the world, we can look specifically at the diffs for dependencies of v.
I have in mind at least 2 ways that this could improve performance. One is that for mgfcall_map, etc., we currently scan all the diffs in the world to find which looked-up keys have had their values changed; it would be faster to know exactly what the diffs are for the function with the mgfcall_map. Another is that it might be possible to have different types of WorldUpdateDiff, eg. having WorldUpdateDiff{changed_calls} where changed_calls is a tuple of all the changed calls which the generative function it is passed to depended on. This would enable static generative functions to specialize to the specific diffs of its dependencies (at least according to the previous world state).
One reason this change may not be very significant is that presumably, most updates are changing variables which are all related in some way, and thus a lot of the time, all/almost all of the variables diffed in the world are dependencies of things we update in the future.
The text was updated successfully, but these errors were encountered:
Whenever a call to update is updated off the update queue, rather than during a recursive call, we are guaranteed that every value
u
this callv
looked up in the previous world has already been updated, and thus we have all diff information for it. Furthermore, when we updated each previous callu
, we enqueuedv
to be updated--so at nearly no additional cost, at this time, we could addu
to a set of diffed dependencies forv
. Then, when we updatev
, rather than just looking at theworld.state.diffs
containing all diffs in the world, we can look specifically at the diffs for dependencies ofv
.I have in mind at least 2 ways that this could improve performance. One is that for
mgfcall_map
, etc., we currently scan all the diffs in the world to find which looked-up keys have had their values changed; it would be faster to know exactly what the diffs are for the function with the mgfcall_map. Another is that it might be possible to have different types ofWorldUpdateDiff
, eg. havingWorldUpdateDiff{changed_calls}
wherechanged_calls
is a tuple of all the changed calls which the generative function it is passed to depended on. This would enable static generative functions to specialize to the specific diffs of its dependencies (at least according to the previous world state).One reason this change may not be very significant is that presumably, most updates are changing variables which are all related in some way, and thus a lot of the time, all/almost all of the variables diffed in the world are dependencies of things we update in the future.
The text was updated successfully, but these errors were encountered: