Rhealstone detailed benchmark

[Gedare Bloom]

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.
>>
>> http://www.drdobbs.com/article/print?articleId=184408081&siteSectionName=
>>
>> 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.
>>
>> http://www.drdobbs.com/article/print?articleId=184408332&siteSectionName=cpp
>>
>> AFAIK there is no "standard" source for this benchmark -- just the
>> definitions
>> 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
features.

>>
>> 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
>>
>> --joel
>>
>>
>>> --
>>> Andreas Kölbl
>>>
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users