From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7050 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] x86_64/memset: use "small block" code for blocks up to 30 bytes long Date: Sun, 15 Feb 2015 17:55:59 -0500 Message-ID: <20150215225559.GV23507@brightrain.aerifal.cx> References: <1423845589-5920-1-git-send-email-vda.linux@googlemail.com> <20150214193533.GK23507@brightrain.aerifal.cx> <20150215040655.GM23507@brightrain.aerifal.cx> <20150215150313.GO23507@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 1424040981 13603 80.91.229.3 (15 Feb 2015 22:56:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 22:56:21 +0000 (UTC) Cc: musl To: Denys Vlasenko Original-X-From: musl-return-7063-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 15 23:56:20 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 1YN86u-0007AP-OF for gllmg-musl@m.gmane.org; Sun, 15 Feb 2015 23:56:20 +0100 Original-Received: (qmail 32069 invoked by uid 550); 15 Feb 2015 22:56:19 -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 32000 invoked from network); 15 Feb 2015 22:56:14 -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:7050 Archived-At: On Sun, Feb 15, 2015 at 10:44:59PM +0100, Denys Vlasenko wrote: > On Sun, Feb 15, 2015 at 4:03 PM, Rich Felker wrote: > >> Just because we don't personally see a hit from 6-cycle imul of AMD CPUs, > >> it does not mean people who do use those CPUs don't exist. Have heart... > > > > Did you test the version I attached? I think there should be at least > > 4-5 cycles between when the imul is launched and when the result is > > used, so I'm failing to see how the latency is a big deal. > > Okay, I won't insist. > Your version works good. The "rep stosq" setup time is still noticeable > even when we switch to it after 126: > > 129 byte block: 10.37 bytes/ns > 128 byte block: 10.65 bytes/ns > 127 byte block: 10.58 bytes/ns > 126 byte block: 18.44 bytes/ns > 125 byte block: 18.30 bytes/ns > 124 byte block: 18.15 bytes/ns > > but I don't think we should do anything about this. > > > Here > > lea -1(%rdx),%rcx > cmp $126,%rcx > jae 2f > > you'd have a stall, since cmp needs the result of lea. why not this? > > lea -1(%rdx),%rcx > cmp $127,%rdx > jae 2f > > then you can even move lea to "big buf" code part > (no point doing it in "small buf" code where it is not used). Because the point was to eliminate the extra conditional for n==0 (hopefully uncommon) in the fast case. By comparing the decremented value as unsigned, we have 0UL-1 > 126. > Possible bug: this check seems misplaced: > > 2: test %rdx,%rdx > jz 1b > > it should be before byte stores: > mov %sil,(%rdi) > mov %sil,-1(%rdi,%rdx) > cmp $2,%edx > jbe 1f > otherwise memset of zero length will fill two bytes, at buf[0] and buf[-1] No it's intentional; see above. > "sub $8,%rcx" can be folded into lea. No, it can't, for the above reason. > Please see attached file. I'll compare how it performs. Rich