Re: [PATCH 03/34] include: copy unlocked-io.h from gnulib

[Sami Kerola <kerolasa@iki.fi>]

On 9 July 2013 10:16, Kay Sievers <kay@vrfy.org> wrote:
> On Tue, Jul 9, 2013 at 8:37 AM, Sami Kerola <kerolasa@iki.fi> wrote:
>> On 8 July 2013 21:21, Kay Sievers <kay@vrfy.org> wrote:
>>> On Sun, Jul 7, 2013 at 9:54 PM, Sami Kerola <kerolasa@iki.fi> wrote:
>>>> At the moment util-linux command are not threading, which means they can
>>>> safely use thread-unsafe IO system calls which should make printing
>>>> quicker.
>>>
>>> Do you have numbers about the assumption that this will produce better
>>> results on Linux?
>>>
>>> Uncontended mutexes/futexes on Linux probably might not really show
>>> up. Maybe in inner loops, not sure. Would be nice to know ...
>>
>> I did not do much testing, and to be honest results were slightly
>> disappointing. With simple 'time command < big_file' most of the
>> commands did not show measurable difference, but as a junior
>> programmer I thought the _unlocked would be beneficial for single
>> thread programs. As such assumptions are not preferred I will set up
>> some sort of test, which will try to accomplish what is the difference
>> of each locked vs _unlocked function call with various output sizes.
>> Assuming I get the test right it should not be a big deal to run it on
>> various systems I have access.
>
> Here is a bit of the background, which explains a bit why uncontended
> futexes (which is always the case in single-threaded programs) might
> not really make a difference on common Linux architectures. They will
> not even involve the kernel, just a simple instruction:
>   http://lwn.net/Articles/360699/

Hello Kay, Karel, and others who like statistics,

This is how I created numbers, and analysed them.

http://www.iki.fi/kerolasa/locked_vs_unlocked_io.tar.xz

Replicating results should be easy enough.  Other than the usual
developer tools I used R to visualize the numbers.  I have doubts my test
is measuring something else than what I hope it to measure, if so
comments about bias are welcome.

When I look the measurement

http://www.iki.fi/kerolasa/locked_vs_unlocked_io.png

it does, and doesn't, make sense.  As one could expect unlocked IO is
slightly quicker, when comparing mean run time.  But locked IO has much
more predictable run time, although some requests form quite long tail of
slow runs.  When looking slow runs the unlocked tail is heavier.

Conclusion.  Maybe my test is broken, or performance characteristics of
these two functions are dissimilar enough that comparison is a bit like
with apples and oranges.

--
Sami Kerola
http://www.iki.fi/kerolasa/