But apart from the bug with the time measurement the Coro side of the benchmark seems to be a valid benchmark.
I don't wish to press the point, though I suppose I am by even mentioning it, but I'm not sure it makes much sense even as a standalone benchmark of Coro. I'll explain why, but don't feel the need to respond.
What exactly is it benchmarking?
but of course it's Perl that's doing the multiplication, and if you take Coro out of the picture, Perl alone wins hands down.
Why not just set four threads running doing multiplies in a loop, and cedeing every N?
Why bother with all the multiplying?
I really cannot see the merit of the benchmark, as either a comparative study of Coro and iThreads, nor as a standalone test of Coro itself.
One thing is for sure, if this is the basis of the POD claim: "A parallel matrix multiplication benchmark runs over 300 times faster on a single core than perl's pseudo-threads on a quad core using all four cores.", then quite frankly, he should be prosecuted by the Statistics Police :)
And the sentence: Unlike the so-called "Perl threads" (which are not actually real threads but only the windows process emulation ported to unix, and as such act as processes), is a candidate for the I-know-what-you-were-trying-to-say-but-that-isn't-it of The Year award. :)
I'll continue to endeavour to get Coro to build on my system, and if I succeed, I'll attempt to produce a fair comparison of matrix multiplication using both. Within the limitations of Coro, I believe that it would still show Coro in a good light. threads::shared memory is horribly and unnecessarily slow. I wish I could see how to address that. But the claim above is frankly ludicrous.
In reply to Re^10: If I am tied to a db and I join a thread, program chrashes
by BrowserUk
in thread If I am tied to a db and I join a thread, program chrashes
by lance0r
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |