[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170319150522.GT1693@brightrain.aerifal.cx>
Date: Sun, 19 Mar 2017 11:05:22 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] aarch64: add single instruction math functions
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
