Hi Guys,

I've been porting my b0 compiler between Linux, Win-x64 and ability to use glibc/libc so it's multi-platform as possible. (See the b0 thread in the compilers section for more info on the compiler/language).

However after some testing, found that the version that uses glibc is roughly 5-6x time quicker than the version that calls the kernel directly for OS services! (There are about 16 functions that are wrappers for the OS services which either directly call the OS or call the equivalent glibc function - so the number of calls to either the kernel or libc are the same).

Using 'time', shows that user times are roughly equal (1.5sec to recompile the compiler in user code), however the system times are vastly different (0.5sec for libc, 8.5sec for linux version). Total times are 2sec vs 10sec, libc and direct calling respectively.

Has anyone else experienced this? So does libc have any magik in it, that improves it's performance over what calling the kernel directly?

PS. Linux AMD64 is the target, and kernel is v2.6.11.7 (stock from kernel.org).

Hi Chewy. Which syscall's are you measuring? Perhaps you are just witnessing the buffering that the C library does to minimize syscall overhead? Another possibility is the cache state. If the cache is primed in one of your tests it would run faster.

As you mentioned, it appears that glibc does some of it's own buffering to minimise syscalls. Measuring the number of syscalls (not the duration) shows that glibc must be doing a huge amount of buffering on read/write requests of its own, rather than letting the kernel do the buffering.

PS. I only use: open, close, remove, sys_brk, read, write and lseek. (99% of the calls would be read/write).