On Fri, May 20, 2011 at 7:33 PM, Richard Sandiford
wrote:
> Michael Hope writes:
>> How about also 'Ensure vectorised code doesn't regress over
>> non-vectorised code'? The goal would be for 90 % of benchmarks to not
>> regress and 99 % to regress no more than 2 %. At the moment good 'ol
>> Cor
On Sun, May 22, 2011 at 9:05 PM, Ira Rosen wrote:
>
>
>> At the moment good 'ol
>> CoreMark is worse with -O3 -omfpu=neon...
>
> It maybe worth to try -fvect-cost-model.
Worse again I'm afraid. -O3 -mfpu=neon scores 99 % of -O3. -O3
-mfpu=neon -fvect-cost-model scores 96 %.
-- Michael
__
> At the moment good 'ol
> CoreMark is worse with -O3 -omfpu=neon...
It maybe worth to try -fvect-cost-model.
Ira
>
> -- Michael
>
> ___
> linaro-toolchain mailing list
> linaro-toolchain@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/l
Well, I suppose if we're setting figures like that, then it's really
"Limit regressions in vectorised code over non-vectorised code". :-)
But maybe it'd be better to keep figures out of it. 99% is awkward because
I don't think we even have 100 benchmarks yet. And what about benchmarks
like DEN
Michael Hope writes:
> On Fri, May 20, 2011 at 2:07 AM, Richard Sandiford
> wrote:
>> I've added some ideas to the NEON blueprint. There are now really 6
>> separate tasks, broken down into subitems, so it looks like we really
>> could have 6 separate blueprints, as you mentioned on the wiki pag
On Fri, May 20, 2011 at 2:07 AM, Richard Sandiford
wrote:
> I've added some ideas to the NEON blueprint. There are now really 6
> separate tasks, broken down into subitems, so it looks like we really
> could have 6 separate blueprints, as you mentioned on the wiki page.
> I wasn't sure how to cre
On Thu, May 19, 2011 at 9:43 PM, Ulrich Weigand
wrote:
> Michael Hope wrote:
>
>> Hi there. The next two weeks is where we take the technical topics
>> from the TSC and the discussions had during the summit and turn them
>> into the concrete engineering blueprints for this cycle. I've created
>
Peter Maydell wrote on 05/19/2011 12:16:58 PM:
> On 19 May 2011 10:43, Ulrich Weigand wrote:
> > Also, some of the feedback from UDS sessions included features that
> > could arguably be considered part of our blueprints, but go beyond
> > what was originally their scope. For example, one user a
Hello Richard,
> Another one that would be interesting is the missed SMS opportunity
> exposed by Jim Huang's NEON intrinsic example from a while back.
> If we have a loop such as:
>
>for (int i = 0; i < n; i++)
> {
>unsigned short foo = a[i];
>...
>a[i] = ...;
>
I've added some ideas to the NEON blueprint. There are now really 6
separate tasks, broken down into subitems, so it looks like we really
could have 6 separate blueprints, as you mentioned on the wiki page.
I wasn't sure how to create those blueprints correctly though.
Please let me know if they d
On 19 May 2011 10:43, Ulrich Weigand wrote:
> Also, some of the feedback from UDS sessions included features that
> could arguably be considered part of our blueprints, but go beyond
> what was originally their scope. For example, one user asked for
> GDB tracepoints to be also supported with nat
Michael Hope wrote:
> Hi there. The next two weeks is where we take the technical topics
> from the TSC and the discussions had during the summit and turn them
> into the concrete engineering blueprints for this cycle. I've created
> a page at:
> https://wiki.linaro.org/MichaelHope/Sandbox/111
Hi there. The next two weeks is where we take the technical topics
from the TSC and the discussions had during the summit and turn them
into the concrete engineering blueprints for this cycle. I've created
a page at:
https://wiki.linaro.org/MichaelHope/Sandbox/Blueprints
listing all of the
13 matches
Mail list logo
