16 Nov 11:33
Re: Strange parallel behaviour with Ubuntu Karmic / GHC 6.10.4
Neil Brown <nccb2 <at> kent.ac.uk>
2009-11-16 10:33:25 GMT
2009-11-16 10:33:25 GMT
Michael Lesniak wrote: > Hello, > > >> getTime? I wonder if that number might be causing the problem; can you >> replicate it with lower sys times? >> > That was it! Thanks Neil! > > When I'm using some number crunching without getTime it works (with > more or less the expected speedup and usage of two cores) on my Ubuntu > 9.10, too. > > Out of curiosity, the question is still open: Why does the old example > (using getTime) work so much better on an older version of > Ubuntu/RedHat and not on the new ones? > > Your kernels were: Setup: Machine A: Quadcore, Ubuntu 9.04, Kernel 2.6.28-13 SMP Machine B: AMD Opteron 875, 8 cores, 2.6.18-164 SMP- (some redhat) Machine C: Dual-Core, Ubuntu 9.10, Kernel 2.6.31-14 SMP Looking at the implementation of getTime ThreadCPUTime in the clock package, it calls clock_gettime(CLOCK_THREAD_CPUTIME_ID,..). According to this page (http://www.h-online.com/open/news/item/Kernel-Log-What-s-new-in-2-6-29-Part-8-Faster-start-up-and-other-behind-the-scenes-changes-740591.html), the changes in 2.6.29 (changes which only your Ubuntu 9.10 machine has) included a patch (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c742b31c03f37c5c499178f09f57381aa6c70131) which altered the implementation of that function. Perhaps on some multi-processor machines the new implementation effectively serialises the code? I know there used to be issues of whether some of the timers were synchronised across processors/cores (to stop them appearing to go backwards), so maybe something with the timers and their synchronisations effectively stops your program running in parallel. If it helps, my machine is: "Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz" according to /proc/cpuinfo. Thanks, Neil.
RSS Feed