[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile's I/O procedures should *not* do thread synchronization
From: |
Ludovic Courtès |
Subject: |
Re: Guile's I/O procedures should *not* do thread synchronization |
Date: |
Tue, 08 Apr 2014 22:53:27 +0200 |
User-agent: |
Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) |
Mark H Weaver <address@hidden> skribis:
> Andy Wingo <address@hidden> 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
> =======================
Interesting; I didn’t expect such differences between unlocked/locked,
and among architectures.
Ludo’.