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
12 matches
Mail list logo
