This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Add math-inline benchmark
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>, Wilco Dijkstra <wdijkstr at arm dot com>
- Cc: "'GNU C Library'" <libc-alpha at sourceware dot org>
- Date: Thu, 23 Jul 2015 14:04:41 -0400
- Subject: Re: [PATCH v2] Add math-inline benchmark
- Authentication-results: sourceware.org; auth=none
- References: <002001d0bfb8$b36fa330$1a4ee990$ at com> <20150716225056 dot GA24479 at domone> <002501d0c094$3ea04cd0$bbe0e670$ at com> <20150718113423 dot GC30356 at domone> <002a01d0c2db$7ad80c30$70882490$ at com> <20150720192216 dot GA2019 at domone> <003001d0c3d0$5fb0a390$1f11eab0$ at com> <20150721174732 dot GB22893 at domone> <003301d0c3e8$c8276b80$58764280$ at com> <20150723153941 dot GB5009 at domone>
On 07/23/2015 11:39 AM, OndÅej BÃlka wrote:
>> No that wouldn't make any difference - all that matters for that experiment was
>> encapsulating the immediate in a separate function, you'll get one call every
>> iteration either way.
>>
> Thats completely false as my implementation shows that different
> implementation is faster than yours when I use noinline with specific
> expressions. For example these could be invalid as gcc decides to turn
> all implementations into branchless code which completely changes
> performance characteristic.
When a conversation gets to a sufficient length it is beneficial for one party
in the conversation to summarize the current position without responding point
by point through a long thread.
It would be immensely beneficial to additional reviewers to start the thread
again from the v3 version of the patch, and instead of responding point by point,
respond at a high level with a summary of what has been agreed upon and what
issues are still outstanding.
With a sufficiently complex topic we are going to need to learn how to have
proper discussions that gravitate towards consensus rather than spiral apart
towards long threads. That is to say that the emails should get shorter and
shorter as fewer and fewer topics are left to clarify and discuss after
consensus is reached one-by-one on each point.
Cheers,
Carlos.