From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7015 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 1/2] x86_64/memset: avoid multiply insn if possible Date: Fri, 13 Feb 2015 02:24:36 -0500 Message-ID: <20150213072436.GD23507@brightrain.aerifal.cx> References: <1423761423-30050-1-git-send-email-vda.linux@googlemail.com> <20150212172735.GX23507@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1423812298 5139 80.91.229.3 (13 Feb 2015 07:24:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 07:24:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7028-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 13 08:24:55 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YMAcQ-0002hR-Ds for gllmg-musl@m.gmane.org; Fri, 13 Feb 2015 08:24:54 +0100 Original-Received: (qmail 26078 invoked by uid 550); 13 Feb 2015 07:24:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26037 invoked from network); 13 Feb 2015 07:24:48 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7015 Archived-At: On Thu, Feb 12, 2015 at 09:36:26PM +0100, Denys Vlasenko wrote: > On Thu, Feb 12, 2015 at 8:26 PM, Denys Vlasenko > wrote: > >> I'd actually like to extend the "short" range up to at least 32 bytes > >> using two 8-byte writes for the middle, unless the savings from using > >> 32-bit imul instead of 64-bit are sufficient to justify 4 4-byte > >> writes for the middle. On the cpu I tested on, the difference is 11 > >> cycles vs 32 cycles for non-rep path versus rep path at size 32. > > > > The short path causes mixed feelings in me. > > > > On one hand, it's elegant in a contrived way. > > > > On the other hand, multiple > > overlaying stores must be causing hell in store unit. > > I'm thinking, maybe there's a faster way to do that. In practice it performs quite well. x86's are good at this. The generic C code in memset.c does not do any overlapping writes of different sizes for the short buffer code path -- all writes there are single-byte, and multiple-write only happens for some of the inner bytes depending on the value of n. > For example, like in the attached implementation. > > This one will not perform eight stores to memory > to fill 15 byte area... only two. I could try comparing its performance, but I expect branches to cost a lot more than redundant stores to cached memory. My approach in the C code seems to be the absolute minimum possible number of branches for short memsets, and it pays off -- it's even faster than the current asm for these small sizes. Rich