Speed improvements for Perl's chameneos-redux in the Computer Language Benchmarks Game?

I ran the source code through the Devel::SmallProf profiler. The profile output is a little too verbose to post here, but you can see the results yourself using $ perl -d:SmallProf chameneos. Pl 10000 (no need to run it for 6000000 meetings unless you really want to!) See perlperf for more details on some profiling tools in Perl It turns out that using semaphores is the major bottleneck.

The lion's share of total CPU time is spent on checking whether a semaphore is locked or not. Although I haven't had enough time to look at why the source code uses semaphores, it may be that you can work around having to use semaphores altogether. That's probably your best shot at improving the code's performance.

I ran the source code through the Devel::SmallProf profiler. The profile output is a little too verbose to post here, but you can see the results yourself using $ perl -d:SmallProf chameneos. Pl 10000 (no need to run it for 6000000 meetings unless you really want to!) See perlperf for more details on some profiling tools in Perl.

It turns out that using semaphores is the major bottleneck. The lion's share of total CPU time is spent on checking whether a semaphore is locked or not. Although I haven't had enough time to look at why the source code uses semaphores, it may be that you can work around having to use semaphores altogether.

That's probably your best shot at improving the code's performance.

1 I could have told you without profiling, there really wasn't anything else that could that much time. The question is: what to do about it though. – Leon Timmermans Apr 10 '10 at 16:07.

As Zaid posted, Thread::Semaphore is rather slow. One optimization could be to use the implicit locks on shared variables instead of them. It should be faster, though I suspect it won't be faster by much.In general, Perl's threading implementation sucks for any kind of usage that requires a lot of interthread communication.

It's very suitable for tasks with little communication (as unlike CPython's threads and CRuby's threads they are actually preemptive). It may be possible to improve that situation, we need better primitives.

I hadn't realized that (C)Ruby got that so far wrong too. – Donal Fellows Apr 19 '10 at 12:20.

I have a version based on another version from Jesse Millikian, which I think was never published. I think it may run ~ 7x faster than the current entry, and uses standard modules all around. I'm not sure if it actually complies with all the rules though.

I've tried the forks module on it, but I think it slows it down a bit.

Or Coro / Coro::MP, though the latter would probably trigger the 'interesting alternative implementations' clause.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.