From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11171 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] aarch64: add single instruction math functions Date: Sun, 19 Mar 2017 11:05:22 -0400 Message-ID: <20170319150522.GT1693@brightrain.aerifal.cx> References: <20170319042644.GP2082@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1489935938 3896 195.159.176.226 (19 Mar 2017 15:05:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Mar 2017 15:05:38 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11186-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 19 16:05:35 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cpcOh-0000Lw-4i for gllmg-musl@m.gmane.org; Sun, 19 Mar 2017 16:05:31 +0100 Original-Received: (qmail 5679 invoked by uid 550); 19 Mar 2017 15:05:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5658 invoked from network); 19 Mar 2017 15:05:34 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11171 Archived-At: On Sun, Mar 19, 2017 at 08:55:58AM -0400, David Edelsohn wrote: > I thought that the goal of musl was "Minimal machine-specific code". My interpretation of minimal is two-fold: - minimal amount of arch-specific coding required to bring up a new arch. - when arch-specific code is present by necessity or for optimization (speed or size), keeping complexity, maintenance cost, and room for arch-specific bugs minimal. This is not intended to preclude use of single-instruction primitives (see existing code for x86, etc.) for math functions or even critical things that may be somewhat more complex like memcpy. > Does musl want to start a new arms race? What I call an arms race is perpetually adding new, often runtime-selected, vectorized memcpy variants for every new vector isa level, often with costly tradeoffs (like greatly increasing context switch time) and no empirical evidence to justify them on a system-wide scale, just benchmarks tailored to get the results the author of the asm wants. That kind of stuff is not appropriate for musl. Ideally we'll eventually be able to rely on compilers just generating the optimal code for memcpy from a trivial one-line C version. We're not there yet. But I don't even have such hope for the future with math. It's highly nontrivial for a compiler to establish that complex code with multiple levels of branches is equivalent to a single ieee operation that the isa implements. Rich