Jan Kara wrote:
time perl -e 'use threads; $T=12 ; foreach (1..$T) { $thr[$i++] = threads->create(sub { printf "I am thread %s\n", threads->tid(); foreach (1..9e6) { push(@a, sqrt(1234)/sin(1234)) } ; printf "thread %s finished.\n", threads->tid(); }); } foreach (0..$T-1) { $thr[$_]->join(); }'
what ugly perl :)
Does anyone have an idea why this could be happening? For such a simple test case I'd say that it's a difference in scheduling or some system call used implicitely by perl. What seems a bit strange though is that after all threads report they are finished, it still takes a noticeable time for parent thread to exit. From a quick strace I see a storm of madvise() calls when the thread exists so maybe this is the culprit? If yes, I'd try to oprofile the test on both kernels and compare results.
In my experience, a slow exit from a perl program, even if you watch it enter an explicit exit statement, is always due to perl's memory management system cleaning up. AIUI, the garbage collector has to garbage collect everything nicely because there's always the possibility that there's a DESTROY sub attached somewhere that needs to be executed. If you know that this isn't the case and you simply want to discard all the memory and exit then the best way I know is: use POSIX (); POSIX::_exit(0); In this case, the program made huge numbers of calls to the memory allocator by extending @a 12 x 9e6 times. So unwinding the memory could well take some time. If you want to benchmark threads instead of perl memory allocation then it probably would be better to preallocate the array. Incidentally, I noticed the other day that the vendor perl on an 11.3 box I have (with current kernel 2.6.34) states that it was compiled under 2.6.32. I haven't yet investigated why or whether it matters. Cheers, Dave -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org