Mark H Weaver <[email protected]> skribis: > Andy Wingo <[email protected]> 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’.
