List:Commits« Previous MessageNext Message »
From:Vladislav Vaintroub Date:December 9 2009 9:44pm
Subject:RE: Review of WL#2373 "Use cycle counter for timing" (Sun Studio and
SPARC specifics)
View as plain text  
Hello,
 
A question regarding  relevancy of v8 and gcc3 on Sparc. By default gcc3.4
does think the architecture is v8 and compiling my_rdtsc without -mcpu=v9
would fail. Do you think always adding -mcpu=v9 on solaris/gcc(<4)/sparc
would be a correct solution for the problem. Or should be declarer gcc(<4)
also irrelevant. Or is there a way to fix the problem without requiring
support of the build system (that would of course be preferred solution)?

I've seen that problem  couple of days ago on Sun machines and Olav have
seen it too while trying out the -cmake branch. 


> -----Original Message-----
> From: Olav.Sandstaa@stripped [mailto:Olav.Sandstaa@stripped]
> Sent: Wednesday, December 09, 2009 10:24 PM
> To: Peter Gulutzan
> Cc: Marc Alff; Vladislav Vaintroub; Kay Röpke; Staale Deraas; Guilhem
> Bichot; commits@stripped
> Subject: Re: Review of WL#2373 "Use cycle counter for timing" (Sun
> Studio and SPARC specifics)
> 
> Hi Peter,
> 
> Peter Gulutzan wrote:
> > Hi Olav,
> >
> > Our discussion of clock_gettime versus gethrtime in June 2009 in this
> thread was:
> > "
> > OLAV >> * (Irrelevant) comment/question/observation: in
> > OLAV >> my_timer_nanonseconds() the function clock_gettime() will be
> used on
> > OLAV >> Solaris (you seem to prefer this over gethrtime() - which
> probably is
> > OLAV >> fine) but in my_timer_cycles() only gethrtime() will be used
> on
> > OLAV >> Solaris if there is no assembly code for the function (ie.
> you prefer
> > OLAV >> gethrtime() instead of clock_gettime(). (feel free to ignore
> this - it
> > OLAV >> was just an observation).
> > PETER > It's an interesting observation. I don't ignore it,
> > PETER > I pretend it's a feature. This way the user
> > PETER > on that platform has a way to choose whether the timer
> > PETER> will be clock_gettime() or gethrtime().
> > OLAV > Great - and you even have provided code to give the user data
> > OLAV > about the overhead of these two methods. So she has both the
> > OLAV > opportunity to choose and the data to make the right choice :-
> )
> >
> > So we were happy. But now I prefer gethrtime over clock_gettime
> > for the performance schema nanosecond timer.
> >
> > Here are rdtsc3.c timings in cycles for development machines which
> allow both.
> >   Machine         clock_gettime          gethrtime
> >   butch            530                    510
> >   hpux31          2080                    220 (same as cycle counter)
> >   sol9x86         1500                   1324
> >   sol10-amd64-a    456                    371
> >   sol10-sparc-a    151                    121
> >   sunfire100a      526                    483
> >
> 
> Not a big issue but I too prefer gethrtime over clock_gettime (mostly
> because that is the one I normally have used). Thanks for providing
> test
> data. Makes this a very easy change to agree to.
> 
> > This does not affect AIX which continues to prefer read_real_time().
> >
> > As you know, I have requested that we declare officially that
> > we don't support SPARC v8. With SPARC v9, gethrtime will rarely
> > appear in the cycles column.
> >
> 
> Great to get SPARC v8 officially declared as irrelevant to avoid to
> have
> to consider this in the future. Thanks for doing this.
> 
> > The change would be solely in mysys/my_rdtsc.c and would look like
> this:
> > 258a259,261
> >
> >> #elif defined(HAVE_SYS_TIMES_H) && defined(HAVE_GETHRTIME)
> >>   /* SunOS 5.10+, Solaris, HP-UX: hrtime_t gethrtime(void) */
> >>   return (ulonglong) gethrtime();
> >>
> > 265,267d267
> > < #elif defined(HAVE_SYS_TIMES_H) && defined(HAVE_GETHRTIME)
> > <   /* SunOS 5.10+, Solaris, HP-UX: hrtime_t gethrtime(void) */
> > <   return (ulonglong) gethrtime();
> > 582,583d581
> > < #elif defined(HAVE_CLOCK_GETTIME)
> > <   mti->nanoseconds.routine= MY_TIMER_ROUTINE_CLOCK_GETTIME;
> > 585a584,585
> >
> >> #elif defined(HAVE_CLOCK_GETTIME)
> >>   mti->nanoseconds.routine= MY_TIMER_ROUTINE_CLOCK_GETTIME;
> >>
> >
> > In other words the order of "if defined(HAVE_CLOCK_GETTIME)"
> > and "if defined(HAVE_GETHRTIME)" would be reversed in
> > my_timer_nanoseconds() and my_timer_init().
> >
> > Do I make sense?
> >
> 
> Yes. Change looks fine, approved.
> 
> Olav
> 
> --
> MySQL Code Commits Mailing List
> For list archives: http://lists.mysql.com/commits
> To unsubscribe:
> http://lists.mysql.com/commits?unsub=1


Thread
Review of WL#2373 "Use cycle counter for timing" (Sun Studio and SPARCspecifics)Olav Sandstaa15 May
  • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Peter Gulutzan15 May
    • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Peter Gulutzan9 Jun
      • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Olav Sandstaa9 Jun
        • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Peter Gulutzan9 Jun
          • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Peter Gulutzan9 Jun
          • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Olav Sandstaa10 Jun
            • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Peter Gulutzan12 Jun
              • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Olav Sandstaa16 Jun
                • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Peter Gulutzan17 Jun
                  • Re: Review of WL#2373 "Use cycle counter for timing"Peter Gulutzan27 Oct
                    • RE: Review of WL#2373 "Use cycle counter for timing"Vladislav Vaintroub27 Oct
                      • Re: Review of WL#2373 "Use cycle counter for timing"Peter Gulutzan27 Oct
                    • Re: Review of WL#2373 "Use cycle counter for timing"Olav Sandstaa28 Oct
                      • RE: Review of WL#2373 "Use cycle counter for timing"Vladislav Vaintroub28 Oct
                    • Re: Review of WL#2373 "Use cycle counter for timing"Kay Röpke2 Nov
            • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Peter Gulutzan8 Dec
              • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Olav Sandstaa9 Dec
                • RE: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Vladislav Vaintroub9 Dec
                  • Re: Review of WL#2373 "Use cycle counter for timing" (Sun Studio andSPARC specifics)Peter Gulutzan10 Dec