-
Notifications
You must be signed in to change notification settings - Fork 605
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The inline caching benchmark as written before did not provide accurate information on the slowdown of polymorphic inline caches. As the morphism increased, the benchmark would perform more calls, skewing results toward the benchmarks with less polymorphism but not due to the cost of the polymorphic cache itself. It was also reusing the same "call_on" method for all morphisms, which on a newer version of benchmark/ips resulted in the lower-morphic runs being poisoned by higher-morphic runs (since benchmark/ips now pre-warms all benchmarks as a group, rather than immediately before measurement). My modification attempts to avoid this via the following strategy: * Measure all morphisms from 1 to 10. * Each morphism uses its own call_on method. * Each morphism performs the same number of call_on invocations. * The objects are rotated every five invocations, allowing the call_on call site to eventually see all types. * Rotation is performed manually, to avoid multiple assignment overhead skewing results. It is assumed that most interesting implementations will have relatively inexpensive local variable retrieval and assignment costs (or at least inexpensive when compared to invocation, polymorphic caching, and method lookup). The new benchmark should provide more accurate results, since the non-cache work done in each benchmark is mostly the same and the different morphisms can no longer poison each other's results. The ideal results for a well-tuned implementation should be gradual decline toward the higher morphisms, rather than a sudden drop-off when inline caching is abandoned in favor of a lookup mechanism. Various impls will have their own sweet spot where a polymorphic cache becomes more expensive than doing the lookup each time.
Showing
1 changed file
with
247 additions
and
23 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters