Date: Fri, 11 Nov 2011 18:09:54 -0500 From: Eitan Adler <lists@eitanadler.com> To: Daniil Cherednik <dcherednik@masterhost.ru> Cc: hackers@freebsd.org Subject: Re: performance of fork() syscalls Message-ID: <CAF6rxgnNQ=0odmQ1MLgtENrxH9e4Ja0F9D9jQf9r8FomrrGOuw@mail.gmail.com> In-Reply-To: <4EAA8B4B.2090002@masterhost.ru> References: <4EAA8B4B.2090002@masterhost.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for the delayed reply. On Fri, Oct 28, 2011 at 7:00 AM, Daniil Cherednik <dcherednik@masterhost.ru> wrote: > Hello. > I have some questions about performance fork syscall. Great! > Result in FreeBSD (8.2, amd62): > > real 0m2.010s > user 0m0.053s > sys 0m1.946s > > Result in Linux (2.6.32-5-amd64): > > real 0m1.210s > user 0m0.008s > sys 0m1.200s > > Does this mean performance of fork() in Linux is better? No. It may be true that Linux's fork is faster than ours, but these numbers don't show that. >From my own (albeit limited) knowledge the numbers you gave above are statistically meaningless. You have one iteration of the sum of using time(1) on one machine 10000 times. This data can only provide the average of a single test case with many possible causes for the slowness. Additionally, time(1) includes time spent in system calls, running other programs, processing interrupts, etc. "sys" is a lie, as not every context switch is tracked for performance reasons. Use getrusage() instead. In order to have a meaningful comparison you would need to a) Run the results under the Student's T test to see if there is a significant different at p=95%. b) Do the benchmarks on a machine running nearly nothing else. Run your tests on Single User Mode, disable all services, remove the computer from the network, mount the disks read-only, etc. Without doing this there is too much noise, and it isn't possible to determine what is causing the slow down (if there is any difference at all, see part a) I understand that the numbers look bad, and that this is a lot of work to do to see if there is a difference, but benchmarking is a non-trivial exercise :) If I'm wrong here, please correct me. I am always open to learning new things. > And can you explain why? See above ;) -- Eitan Adler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF6rxgnNQ=0odmQ1MLgtENrxH9e4Ja0F9D9jQf9r8FomrrGOuw>