Re: time stamp counter in "make check"

[Dmitrieva Liubov <liubov dot dmitrieva at gmail dot com>]

But I don't know how to implement this feature in a good way.
Maybe it should be just option for make check to use correct time
stamp counter instead of counter with misleading results.
I guess some people can be interesting just in stability testing not
performance.
But ... replacing rdtsc with rdtscp for core i7 increases "make check"
execution time in more than 2 times.

On my machine time of "make check" running in 4 threads is as following:

Before replacing:

-bash-4.2$ time nohup make check -j4
nohup: ignoring input and appending output to `nohup.out'

real    6m41.962s
user    5m18.994s
sys     2m9.086s

After replacing:

real    20m56.105s
user    13m7.373s
sys     7m9.821s

I guess some people may be disappointed if the change will be not optional.

I didn't check how CPUID barrier effects time, but likely even greater
than rdtscp/rdtscp replacing fix.

--
Liubov Dmitrieva
Intel Corporation

2012/7/12 Carlos O'Donell <carlos_odonell@mentor.com>:
> On 7/12/2012 10:58 AM, Dmitrieva Liubov wrote:
>> So, my proposal is to change from "rdtsc" instruction to "rdtscp"
>> instruction (which is a serializing variant of the RDTSC)  if rdtscp
>> is available for target architecture.
>> This definitely solves the issue with negatives values.
>
> I see no problem in replacing rdtsc with rdtscp if the target machine
> has support for rdtscp.
>
> Note:
> I never liked that ./sysdeps/i386/i686/hp-timing.h didn't use CPUID
> as a barrier, since IMO it would seem to violate some of the constraints
> of the interfaces that are built upon hp-timing.h. I would be happy
> to see this changed to use rdtscp or cpuid. Though this is a distinct
> patch from what your suggesting.
>
> Cheers,
> Carlos.
> --
> Carlos O'Donell
> Mentor Graphics / CodeSourcery
> carlos_odonell@mentor.com
> carlos@codesourcery.com
> +1 (613) 963 1026
>