From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7098 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: x86[_64] memset and rep stos Date: Wed, 25 Feb 2015 01:12:04 -0500 Message-ID: <20150225061204.GA25485@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 1424844749 10666 80.91.229.3 (25 Feb 2015 06:12:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Feb 2015 06:12:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7111-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 25 07:12:28 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 1YQVCt-0000My-4D for gllmg-musl@m.gmane.org; Wed, 25 Feb 2015 07:12:27 +0100 Original-Received: (qmail 11665 invoked by uid 550); 25 Feb 2015 06:12:22 -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 11619 invoked from network); 25 Feb 2015 06:12:17 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7098 Archived-At: Doing some timings on the new proposed memset code, I found it was pathologically slow on my Atom D510 (32-bit) when reaching sizes around 2k - 16k. Like 4x slower than the old code. Apparently the issue is that the work being done to align the destination mod 4 misaligns it mod higher powers of two, and "rep stos" performs pathologically bad when it's not cache-line-aligned, or something like that. On my faster 64-bit system alignment mod 16 also seems to make a difference, but less - it's 1.5x slower misaligned mod 16. I also found that on the 32-bit Atom, there seems to be a huge jump in speed at size 1024 -- sizes just below 1024 are roughly 2x slower. Since it otherwise doesn't make a measurable difference, it seems preferable _not_ to try to reduce the length of the rep stos to avoid writing the same bytes multiple times but simply use the max allowable length. Combined with the first issue, it seems we should "round up to a multiple of 16" rather than "add 16 then round down to a multiple of 16". Not only does this avoid reducing the length of the rep stos; it also preserves any higher-than-16 alignment that might be preexisting, in case even higher alignments are faster. Rich