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
After two forked processes have the same control flow again, join them.
challenge: How to detect joinable processes? Return from the same method? How does this affect execution order of different branches?
Complex index structures for memory slices
If memory slice indexes could have "gaps", we could reduce the number of forks significantly. For instance, for thisContext tdbRetracingTimeIndex even asString, we would only require 2 instead of n forks.
challenge: How does an efficient object layout for such indexes look like? How can we transform, combine, and merge such slices efficiently?
Streaming of results
To improve the interactivity of slow range queries, we could use something like a (buffered) generator to display all results iteratively. Problems with this, however, include:
Iteration/update overhead can be pretty high
Especially in combination with join semantics/complex index structures, it turns out that streaming would expect a contrary scheduling scheme (more SIMD = fewer total time != fewer time to first result)
Optimize further bytecodes, in particular:
primitive 168 (primitiveCopyObject)
primitive 83/84/100 (perform/execute prims) to work like message sends
cloning might benefit from bulk access to memory
honor the actual number of numArgs for all unknown primitives to avoid superfluous vector checks/combinations/forks - at the moment, we sometimes even seem to do forks for Quick Push Const Methods)
Further experiments: How much speed could we gain ...
... by not reusing the non-simulated stack from the caller but using a fresh process?
... by setting the contextAtEachStep block to nil and avoiding to evaluate it?
... by avoiding redundant copies/coalescions/transformations of vectors?
Hand-crafted client optimizations (e.g., for TDBHistoryExplorer>>#detailsTextForFormValue:, extract non-crucial part to not happen inside simulation)
For all of this, using the benchmark runner again would be very beneficial.
The text was updated successfully, but these errors were encountered:
Share simulator caches #82
Join semantics for forks
After two forked processes have the same control flow again, join them.
Complex index structures for memory slices
If memory slice indexes could have "gaps", we could reduce the number of forks significantly. For instance, for
thisContext tdbRetracingTimeIndex even asString
, we would only require 2 instead of n forks.Streaming of results
To improve the interactivity of slow range queries, we could use something like a (buffered) generator to display all results iteratively. Problems with this, however, include:
Optimize further bytecodes, in particular:
Further experiments: How much speed could we gain ...
contextAtEachStep
block tonil
and avoiding to evaluate it?Hand-crafted client optimizations (e.g., for
TDBHistoryExplorer>>#detailsTextForFormValue:
, extract non-crucial part to not happen inside simulation)For all of this, using the benchmark runner again would be very beneficial.
The text was updated successfully, but these errors were encountered: