This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Machine maintainer veto.
- From: David Miller <davem at davemloft dot net>
- To: dalias at libc dot org
- Cc: carlos at redhat dot com, libc-alpha at sourceware dot org
- Date: Fri, 03 Jul 2015 09:58:55 -0700 (PDT)
- Subject: Re: Machine maintainer veto.
- Authentication-results: sourceware.org; auth=none
- References: <5596AE46 dot 7030507 at redhat dot com> <20150703163836 dot GQ1173 at brightrain dot aerifal dot cx> <20150703165438 dot GR1173 at brightrain dot aerifal dot cx>
From: Rich Felker <dalias@libc.org>
Date: Fri, 3 Jul 2015 12:54:38 -0400
> BTW, another specific issue I expect to come up again and again is
> performance, particularly situations where a machine maintainer
> wants a "fast" implementation of some function that's fast in the
> cases they care about but O(n²) whereas the generic implementation
> is O(n) or O(n*log(n)). I would say this is a situation where
> allowing the bad-big-O implementation should require consensus at
> the project level rather than machine maintainer veto
> discretion. The right solution in general is almost sure to be
> something like the introsort solution (self-measurement to fall back
> to generic code for cases where worst-case performance is imminent)
> which is more work for the machine-specific code contributor or
> machine maintainer but better for the project.
I don't think the project as a whole gets to dictate what is the best
performance selection or set of tradeoffs for CPU X in all possible
scenerios.
Port specific performance tradeoffs exist (f.e.: people who use CPU X
do _NOT_ care about case Y of string function Z so we don't have to
optimize it well), and you cannot enfore tree wide rules in this area.
Some of the viewpoints expressed here really concern me as a cpu port
maintainer, and makes me want to have stronger rather than weaker
veto powers.