Rhealstone detailed benchmark
gedare at rtems.org
Mon May 29 20:50:43 UTC 2017
On Mon, May 29, 2017 at 12:35 PM, Andreas Kölbl
<andreas.koelbl at st.oth-regensburg.de> wrote:
> Am 28.05.2017 um 18:24 schrieb Joel Sherrill:
>> On Sun, May 28, 2017 at 6:43 AM, Andreas Kölbl <
>> andreas.koelbl at st.oth-regensburg.de> wrote:
>>> Hi guys,
>>> I've tried measuring the real time capability of a BSP using the
>>> Rhealstone benchmark. This benchmark only tells about the average time
>>> spent for e.g. task switching.
>>> Is there interest in a more fine-grained Rhealstone benchmark, which
>>> prints the Worst Case Execution Time (WCET) or the deviation of the
>>> measured values?
>>> Has there already been an attempt to modify Rhealstone in order to get
>>> the WCET from each benchmark?
>> Rhealstone was a proposal from someone at Intel in 1989 that appeared
>> in Dr Dobbs Journal.
>> There was a follow up article a year later with some code which I didn't
>> remember. I am not sure how closely the code written for RTEMS follows
>> that code.
>> AFAIK there is no "standard" source for this benchmark -- just the
>> and some odd code for a few RTOSes.
>> We would welcome a review of the code against the original articles
>> and the code they published as well as improvements in the numbers
>> gathered and their reporting. Statistical information and WCET would
>> be valuable if the code accurately reflects the intended measurement.
> I will try this for each benchmark and respond if I were successful.
> The source of the benchmarks (drdobbs) seems to be similar to the ones
> used in RTEMS.
> So maybe there is a reason, like to get a more efficient implementation
> (with caches) or more comparable results when measuring the hardware
> this way?
>From what I remember from reading the original article, the Rhealstone
is meant to measure the overhead of usual real-time operating system
>> One thing I have noticed in benchmarks over the years is that they
>> may want to measure say blocking time of a semaphore with a
>> set of N threads. But they accidentally include the code associated
>> with the first execution of each thread. So you have to be careful
>> to not include unintended overhead.
>> Sorry for the long answer but if you are interested in these benchmarks,
>> you are encouraged to help improve them.
> Sure ;)
> Andreas Kölbl
>>> Andreas Kölbl
>>> users mailing list
>>> users at rtems.org
> users mailing list
> users at rtems.org
More information about the users