Re: Guile's I/O procedures should *not* do thread synchronization

[Mark H Weaver <mhw@netris.org>]

Andy Wingo <wingo@pobox.com> writes:

>>>> However, if we promise to do thread synchronization, we will condemn
>>>> Guile to forever having dog slow 'read-char', 'peek-char', 'write-char',
>>>> 'get-u8', 'peek-u8', and 'put-u8' operations.
>>>
>>> I think you are wrong about "dog slow".  Uncontended mutexes are fast,
>>
>> I did some benchmarks of 'putchar' vs 'putchar_unlocked' in C, without
>> contention.  I think it's fair to assume that the GCC and GLIBC folks
>> did a reasonably good job of making both of these as fast as they could.
>>
>> With gcc -O2, I tested two variants of this program: one with 'putchar'
>> and one with 'putchar_unlocked'.  On my YeeLoong (mips64el w/ N32 ABI),
>> the 'putchar_unlocked' version is faster by a factor of 26.3.
>
> On my i7-2620M, the difference is only a factor of 3.0.
>
> Now I think I understand your perspective; 26x is terrible.  But surely
> this is an architecture problem, and not a Guile problem?  The world
> will only get more multithreaded, and ignoring that does no one any
> service.

Now that I have access to the GCC Compile Farm, I repeated these
benchmarks on a variety of machines, and here are the results:

Ratio  CPU
=======================
26.3   Loongson 2F
14.0   PowerPC (Power7)
13.7   Loongson 3A
 9.33  ARMv6l
 6.47  UltraSparc IIe
 5.09  AMD Athlon II
 4.27  AMD Opteron
 3.46  Core 2 Duo P8600
=======================

     Mark