SIsimonpure·Apr 26, 2020Submission
Uarch-bench – a benchmark for low-level CPU micro-architectural features
2 points · Open discussiontravisdowns
uarch-bench
C++2018–2020
travisdowns / uarch-bench
uarch-bench
A benchmark for low-level CPU micro-architectural features
4Distinct people
7Mentions
0Explicit recommenders
779GitHub stars
What to know before exploring
What it is
A benchmark for low-level CPU micro-architectural features
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month7 dated mentions
Observed mentions: 2018-01-22 00:51:04 UTC to 2020-04-26 14:22:41 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Jan 2018 | 2018-01-01 00:00:00 UTC | 2018-02-01 00:00:00 UTC | 1 | 1 | 0 |
| Feb 2018 | 2018-02-01 00:00:00 UTC | 2018-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2018 | 2018-03-01 00:00:00 UTC | 2018-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2018 | 2018-04-01 00:00:00 UTC | 2018-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2018 | 2018-05-01 00:00:00 UTC | 2018-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2018 | 2018-06-01 00:00:00 UTC | 2018-07-01 00:00:00 UTC | 1 | 1 | 0 |
| Jul 2018 | 2018-07-01 00:00:00 UTC | 2018-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2018 | 2018-08-01 00:00:00 UTC | 2018-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2018 | 2018-09-01 00:00:00 UTC | 2018-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2018 | 2018-10-01 00:00:00 UTC | 2018-11-01 00:00:00 UTC | 1 | 0 | 1 |
| Nov 2018 | 2018-11-01 00:00:00 UTC | 2018-12-01 00:00:00 UTC | 3 | 1 | 2 |
| Dec 2018 | 2018-12-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2019 | 2019-01-01 00:00:00 UTC | 2019-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2019 | 2019-02-01 00:00:00 UTC | 2019-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2019 | 2019-03-01 00:00:00 UTC | 2019-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2019 | 2019-04-01 00:00:00 UTC | 2019-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2019 | 2019-05-01 00:00:00 UTC | 2019-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2019 | 2019-06-01 00:00:00 UTC | 2019-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2019 | 2019-07-01 00:00:00 UTC | 2019-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2019 | 2019-08-01 00:00:00 UTC | 2019-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2019 | 2019-09-01 00:00:00 UTC | 2019-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2019 | 2019-10-01 00:00:00 UTC | 2019-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2019 | 2019-11-01 00:00:00 UTC | 2019-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2019 | 2019-12-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2020 | 2020-01-01 00:00:00 UTC | 2020-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2020 | 2020-02-01 00:00:00 UTC | 2020-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2020 | 2020-03-01 00:00:00 UTC | 2020-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2020 | 2020-04-01 00:00:00 UTC | 2020-05-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
7 sourcesI have measured it several times in various places with fairly consistent results. Of course, if you are on a platform which doesn't offer VDSO for your clock, or which disables or virtualizes `rdtsc` then the results could be much longer.
One of the places I measure it is in uarch-bench [1], where running `uarch-bench --clock-overhead` produces this output:
----- Clock Stats --------
Resolution (ns) Runtime (ns)
Name min/ med/ avg/ max min/ med/ avg/ max
StdClockAdapt<system_clock> 25.0/ 27.0/ 27.0/ 29.0 27.1/ 27.4/ 27.6/ 30.6
StdClockAdapt<steady_clock> 25.0/ 26.0/ 26.9/ 94.0 27.0/ 27.0/ 27.1/ 32.6
StdClockAdapt<high_resolutio
Read the rest
n_clock> 26.0/ 27.0/ 27.0/ 28.0 27.1/ 27.5/ 27.7/ 30.0
GettimeAdapter<CLOCK_REALTIME> 25.0/ 26.0/ 25.7/ 27.0 25.1/ 25.5/ 25.6/ 48.3
GettimeAdapter<CLOCK_REALTIME_COARSE> 0.0/ 0.0/ 0.0/ 0.0 7.2/ 7.3/ 7.3/ 7.3
GettimeAdapter<CLOCK_MONOTONIC> 24.0/ 25.0/ 25.5/ 27.0 24.7/ 24.7/ 24.9/ 27.2
GettimeAdapter<CLOCK_MONOTONIC_COARSE> 0.0/ 0.0/ 0.0/ 0.0 7.0/ 7.2/ 7.2/ 7.3
GettimeAdapter<CLOCK_MONOTONIC_RAW> 355.0/358.0/357.8/361.0 357.4/358.2/358.1/360.5
GettimeAdapter<CLOCK_PROCESS_CPUTIME_ID> 432.0/437.0/436.4/440.0 434.7/436.0/436.2/440.9
GettimeAdapter<CLOCK_THREAD_CPUTIME_ID> 422.0/426.0/426.1/431.0 424.6/427.1/427.2/430.4
GettimeAdapter<CLOCK_BOOTTIME> 363.0/365.0/365.3/368.0 364.2/364.5/364.7/367.7
DumbClock 0.0/ 0.0/ 0.0/ 0.0 0.0/ 0.0/ 0.0/ 0.0
The Runtime column shows the cost. Ignoring DumbClock (which is a dummy inline implementation returning constant zero), note that the clocks basically group themselves into 3 groups: around 7 ns, 25-27 ns and 300-400 ns.
The 7 ns group are those that are implemented just by reading a shared memory location, and don't need any rdtsc call at all. The downside, of course, is that this location is only updated periodically (usually during the scheduler tick), so the resolution is limited.
The 25ish ns group are those that are implemented in the VDSO - they need to do an rdtsc call, which is maybe half the time, and then do some math to turn this into a usable time. Note that CLOCK_REALTIME falls into this group on my system.
The 300+ ns group are those that need a system call. This used to be ~100 ns until Spectre and Meltdown mitigations happened. Some of these cannot easily be implemented in VDSO (e.g., those that return process-specific data), and some could be, but simply haven't.
For what it's worth, I wasn't able to reproduce your results from the SO question. Using your own test program (only modified to print the time per call), running it with no sleep and 10000 loops gives:
$ ./clockt 0 10 10000
init run 15256
trial 0 took 659834 (65 cycles per call)
trial 1 took 659674 (65 cycles per call)
trial 2 took 659578 (65 cycles per call)
trial 3 took 659550 (65 cycles per call)
trial 4 took 659548 (65 cycles per call)
trial 5 took 659556 (65 cycles per call)
trial 6 took 659552 (65 cycles per call)
trial 7 took 659556 (65 cycles per call)
trial 8 took 659546 (65 cycles per call)
trial 9 took 659544 (65 cycles per call)
On my 2.6 GHz system, 65 cycles corresponds to 25 ns, so those results are exactly consistent with the uarch-bench results shown above. So either your system is weird, or you weren't running enough loops, or ... I'm not sure.
[1] https://github.com/travisdowns/uarch-bench
The code to reproduce my results can be found at [1] (Linux only for now, but porting is welcome). Basically `run-all.sh` generates the results and `plot-all.sh` plots them.
It would be especially interesting to see Zen2 results since that's the first AMD chip with 256-bit wide loads executed in a single op, so the first one that can do better than 16 bytes per cycle from any level of the cache.
[1] https://github.com/travisdowns/uarch-bench/tree/master/scrip...
In How much bandwidth does the L2 have to give, anyway?How much bandwidth does the L2 have to give, anyway?
143 points · Open discussionI have found that load instructions take one less cycle (4 vs 5) if using an index register, where the index register is zero, and the value was set to zero via zeroing idiom. More details on RWT [1].
You didn't include immediates in your question, but it was included in the quote you referred to so it's worth mentioning adc with immediate zero, which is "twice as fast" [2] from Sandy Bridge through Haswell.
Of course many FP instruction have value-dependent performance, particularly with denormals (although it is common even if denormals don't occur).
FWIW recent AMD chips seem to have fixed-latency integer dividers.
[1] https://www.realworldtech.com/forum/?threadid=179004
[2] https://github.com/travisdowns/uarch-bench/wiki/Intel-Perfor...
In Uops.info: Characterizing Latency, Throughput, and Port Usage on IntelMemory Disambiguation on Skylake
46 points · Open discussionA benchmark for low-level CPU micro-architectural features
1 points · Open discussion