This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fixes tree-loop-distribute-patterns issues
- From: Torvald Riegel <triegel at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, "Carlos O'Donell" <carlos at redhat dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Fri, 21 Jun 2013 10:07:08 +0200
- Subject: Re: [PATCH] Fixes tree-loop-distribute-patterns issues
- References: <51C0AFB7 dot 1060009 at linux dot vnet dot ibm dot com> <20130618205608 dot 9CCE22C0AC at topped-with-meat dot com> <51C1BFE9 dot 4070805 at linux dot vnet dot ibm dot com> <51C1CEFC dot 9000100 at redhat dot com> <51C1FE4C dot 3020400 at linux dot vnet dot ibm dot com> <20130619221130 dot 7B91A2C10E at topped-with-meat dot com> <51C31177 dot 90303 at linux dot vnet dot ibm dot com> <20130620175832 dot 0E6FA2C133 at topped-with-meat dot com> <20130620213141 dot GA4833 at domone dot kolej dot mff dot cuni dot cz> <20130620205919 dot 9156B2C135 at topped-with-meat dot com> <20130621020055 dot GA4729 at domone dot kolej dot mff dot cuni dot cz>
On Fri, 2013-06-21 at 04:00 +0200, OndÅej BÃlka wrote:
> I choose a O0 as lesser evil than having reference implementation twice
> faster depending what compiler you do use.
>
> One solution is mandate to run benchmarks with fixed version of gcc and
> fixed flags.
>
> Second variant could be have assemblies and regeneration script that would
> be ran with specific gcc.
Yes you can try to find a niche where you hope you can compare stuff.
But you can as well just get all the measurements you can from people
out there -- with whatever version of gcc is available -- and take this
into account when drawing conclusions from the data. That is, you'd
setup your machine learning in such a way that it looks a data and
checks whether there is high confidence for a certain conclusion (eg,
new version of code faster or not). Confidence will be lower if, for
example, we see performance vary a lot with different versions of gcc,
but remain more or less unchanged when gcc versions don't differ; but if
performance varies independently of the gcc version, that's also useful
to know because it means we draw our conclusion from a wider set of
tests. Likewise for other properties of the test environment such as
the CPU etc.
Obviously, right now I don't have a patch to do this. But I believe we
need to keep this in mind. This approach isn't rocket science either.
We already make use of it every day.