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 seeing this commit from @petervdonovan in the benchmark repository, I remembered that I implemented a simple optimization in the C++ runtime that completely avoids the overhead for reading physical time in the scheduler. The idea is to keep a cached value of the last read physical time. Let's call it last_pt. If the current logical time (let's call it lt) is smaller than last_pt, then there is no need to read the physical time again since we already know that whatever reading we will get, will be larger than lt. Only if lf > last_pt we read the current physical time and update last_pt.
Surely such an optimization could also be implemented in the C runtime. With this optimization, there is no measurable difference between benchmarks run with fast=true and without.
The text was updated successfully, but these errors were encountered:
After seeing this commit from @petervdonovan in the benchmark repository, I remembered that I implemented a simple optimization in the C++ runtime that completely avoids the overhead for reading physical time in the scheduler. The idea is to keep a cached value of the last read physical time. Let's call it
last_pt
. If the current logical time (let's call itlt
) is smaller thanlast_pt
, then there is no need to read the physical time again since we already know that whatever reading we will get, will be larger thanlt
. Only iflf > last_pt
we read the current physical time and updatelast_pt
.Surely such an optimization could also be implemented in the C runtime. With this optimization, there is no measurable difference between benchmarks run with
fast=true
and without.The text was updated successfully, but these errors were encountered: