This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't use SSE4_2 instructions on Intel Silvermont Micro Architecture.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, Dmitrieva Liubov <liubov dot dmitrieva at gmail dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 21 Jun 2013 15:28:27 +0200
- Subject: Re: [PATCH] Don't use SSE4_2 instructions on Intel Silvermont Micro Architecture.
- References: <20130618064910 dot GA19972 at domone dot kolej dot mff dot cuni dot cz> <CAHjhQ90Fc0kdZfQrUwLwpKbz2va4X9rzf1EkGD-s-RH-iF7guQ at mail dot gmail dot com> <CAHjhQ92qfjdKZthqAwxCVuCnLqDr2stdEbQpne5rKhzJPeN_cQ at mail dot gmail dot com> <51C23583 dot 1070307 at redhat dot com> <CAHjhQ93vWnCiVVU9MPoGptjQtn2J2PCDT2B7ZfXiKt+Cv_Rh_w at mail dot gmail dot com> <51C307A5 dot 7030608 at redhat dot com> <20130620151711 dot GA4891 at domone dot kolej dot mff dot cuni dot cz> <51C317AA dot 6080502 at redhat dot com> <20130621012427 dot GA4574 at domone dot kolej dot mff dot cuni dot cz> <51C3A8E4 dot 1060305 at redhat dot com>
On Thu, Jun 20, 2013 at 09:14:12PM -0400, Carlos O'Donell wrote:
> On 06/20/2013 09:24 PM, OndÅej BÃlka wrote:
> > On Thu, Jun 20, 2013 at 10:54:34AM -0400, Carlos O'Donell wrote:
> >> On 06/20/2013 11:17 AM, OndÅej BÃlka wrote:
> >>> On Thu, Jun 20, 2013 at 09:46:13AM -0400, Carlos O'Donell wrote:
> >>>> On 06/20/2013 09:10 AM, Dmitrieva Liubov wrote:
> >>>>> What benchmarks do you mean? string/test-str** unit tests?
> >>>>
> >>>> I mean the new glibc microbenchmark suite :-)
> >>>>
> >>
> >>> What you have is currently nowhere near of state where you can get
> >>> usable results by it. It has five major flaws that i wrote earlier and
> >>> any of them is enough to have paper immidiately rejected.
> >>
> >> Please help us make the microbenchmark better.
> >>
> > Already tried and will not make same mistake again. Making it better is
> > simple, run it and check if outputs make sense. For two months a
> > performance of several functions was 100 times faster than it shoud be.
> > I do not have any confidence in benchmarks where you do not do such
> > basic stuff.
>
> I'm a bit confused, if there was a defect in the benchmark did
> you file a bug or post a patch to fix it? What is the mistake
> that was made?
>
Here,
http://sourceware.org/bugzilla/show_bug.cgi?id=15424
I am not sure which original mistake was but there was problem that gcc
optimized call away.
> >> Until then it's what I'm going to use to determine if Dmitrieva's
> >> patch makes performance objectively faster.
> >>
> > You said that you want performance objectively faster. A definition of objective is:
> >
> > Condition in the realm of sensible experience independent of individual
> > thought and perceptible by all observer.
> >
> > To see if this is a case I added Andi. Andi, could you browse sources
> > and tell if you think that benchtests are adequate to measure
> > performance?
>
> I'd love to have Andi review the bench tests and give feedback,
> including filing bugs, or helping us make them better.
>
> In my LFCS2013 talk I came out and directly asked for people
> with performance measurement experience to help glibc.
>
Could you also invite them to say their opinion?
> Surely the implementation can't offend you so much that you
> aren't willing to help us make it better? :-)
>
A question is if I staring from scratch would be faster than writing
patch, waiting few weeks for review and meanwhile I need to rewrite
patch because half internals changed and more bugs were introduced.