On 07/04/17 00:54, Jonathan Wakely wrote: > On 6 April 2017 at 23:26, Toebs Douglass wrote: >> Now, I may be wrong, but it seems to me when a new GCC is being >> released, it will be compiled for sure with the most recently published >> glibc, libmpfr, libgmp and libmpc. Similarly, it will be created with >> the most recently release binutils. > > No, not necessarily. > > When GCC is released it's compiled by users, and so will use whatever > glibc a user has on their machine. I may be wrong, but I think generally people using a distro will use and only use the compiler and glibc which came with the distro. It is unusual for a person using a distro to compile a new GCC or glibc. It seems to me then in practise GCC and glibc versions in the field will bear a strong correspondence, although I do understand from what you have said it is not actually *fixed*; it might for example be a distro update ships a new GCC, but keeps the original glibc. >> However, the benchmark app also benchmarks normal locking data >> structures, as provided by the OS. For Linux, all the usual suspects. >> I assume - but I do not *actually* know, now I think about it to answer >> the question - that these will depend, directly or indirectly, upon glibc. > > But I see no reason they would depend on the glibc version. I may also be wrong here too, but I think the pthreads source code is part of glibc. I am thinking the pthreads code will change over glibc releases, and it is the pthread code which contains the OS provided locking mechanisms - mutexes, rwlocks, etc. The benchmark app also benchmarks normal locking data structures. The lock-free benchmarks are interesting, but they only really make sense when you can compare them to the alternatives. For that comparison to be fair, I should use the GCC and glibc in use by the user. Perhaps I in fact need to build every GCC against every version of glibc, so to have benchmarks for every possible combination.
