From: "Ondřej Bílka" <neleai@seznam.cz>
To: "Shih-Yuan Lee (FourDollars)" <sylee@canonical.com>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
libc-ports@sourceware.org, Jesse Sung <jesse.sung@canonical.com>,
patches@eglibc.org, YC Cheng <yc.cheng@canonical.com>,
rex.tsai@canonical.com
Subject: Re: [Patches] [PATCH] ARM: NEON detected memcpy.
Date: Wed, 03 Apr 2013 16:20:00 -0000 [thread overview]
Message-ID: <20130403161949.GA6759@domone.kolej.mff.cuni.cz> (raw)
In-Reply-To: <CAAT15mMJSHiO5rZ6EAbss79f_t4Qiaryi-qjmw3TwGg4vrg2=A@mail.gmail.com>
On Wed, Apr 03, 2013 at 11:47:36PM +0800, Shih-Yuan Lee (FourDollars) wrote:
> Hi Joseph,
>
...
> > I was previously told by people at ARM that NEON memcpy wasn't a good idea
> > in practice because of raised power consumption, context switch costs etc.
> > from using NEON in processes that otherwise didn't use it, even if it
> > appeared superficially beneficial in benchmarks.
> >
> About raised power consumption and context switch costs, I may be able
> to add some option in configure for the users to decide if they want
> to use this feature or not.
> How do you think?
>
Configure option is bit overkill.
You need to compare neon/other implementation speed. Then determine
size where neon is faster if we include energy cost and context switch.
My first estimate is use neon when larger than 4096 bytes.
However to determine context switch cost of neon you must account network effect.
If you use neon in one function that is called sufficiently often (to
always save registers) then adding neon implementation for additional functions
does not increase cost.
next prev parent reply other threads:[~2013-04-03 16:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 7:58 Shih-Yuan Lee (FourDollars)
2013-04-03 8:15 ` Will Newton
2013-04-03 9:19 ` Ondřej Bílka
2013-04-03 15:08 ` Joseph S. Myers
2013-04-03 15:48 ` Shih-Yuan Lee (FourDollars)
2013-04-03 16:02 ` Joseph S. Myers
2013-04-04 3:56 ` Shih-Yuan Lee (FourDollars)
2013-04-03 16:20 ` Ondřej Bílka [this message]
2013-04-04 4:15 ` [Patches] " Shih-Yuan Lee (FourDollars)
2013-04-04 6:37 ` Ondřej Bílka
2013-04-08 9:12 ` Will Newton
2013-04-08 10:27 ` Ondřej Bílka
2013-04-09 8:45 ` Richard Earnshaw
2013-04-09 9:05 ` Richard Earnshaw
2013-04-09 12:04 ` Ondřej Bílka
2013-04-09 12:59 ` Carlos O'Donell
2013-04-09 15:00 ` Richard Earnshaw
2013-04-09 15:54 ` Ondřej Bílka
2013-04-09 15:59 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130403161949.GA6759@domone.kolej.mff.cuni.cz \
--to=neleai@seznam.cz \
--cc=jesse.sung@canonical.com \
--cc=joseph@codesourcery.com \
--cc=libc-ports@sourceware.org \
--cc=patches@eglibc.org \
--cc=rex.tsai@canonical.com \
--cc=sylee@canonical.com \
--cc=yc.cheng@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).