It's a good post, and it builds on what I started to do in my post, which was to show some differences in threading through benchmarks and highlight some (ok, one) cases where you need to be aware of what your chosen model gets you. Juster seems to be looking to do an actual comparison of or the models, and goes as far as finding better matching models within the languages to compare.
Some of his complaints about my methodology are that the benchmarks are only there to serve a point (apparently to make Perl enthusiasts happy), that the benchmarks are CPU bound, and that my code doesn't make use of threads as it should. This all makes sense, if you assume I was trying to compare Perl's concurrent processing to Python's, which I was not. Apparently I wasn't clear, so I'll attempt to rectify that now.
My post was meant only to illustrate the differences in truly concurrent processing through Os threads and Python's chosen threading model, which is "green" threads. Please view my assertions and examples in that light.
Pandering to an audience - Apparently, JAPHs should be applauding me for bashing perennial foe Python in it's thread-hole. Unfortunately I didn't set out to elevate Perl in any way, nor to disparage Python, just to discuss threading models and benefits and detriments for some programming needs for each. I would think anyone with even a passing interest would see that as obvious, but apparently I was wrong. I guess you can't have Perl and Python together in a post with different results without implying that one is better than the other, no matter your original intention or assertions that it's a special case.
It's unfortunate that I chose to use Perl and Python. I could just as easily have use Perl with the Coro module, or Python threads and Python's multiple processes, capabilities. It would have been just as illustrative for my point. Alas, my mind was stuck in the original context of this, which was Perl and Python, and it seemed natural for me to just use the default threading of each. It WAS on my mind that Perl's threading isn't really true threading, but I figured that mattered little to my point.
CPU bound - Another critique is that my benchmarks are CPU bound. They are. By design. How else should I show that one technique doesn't help with CPU bound problems while the other does?
And note this was in my post:
Now, it's only fair to note, this isn't always the case. We are seeing this behavior because this is a CPU bound problem. If the workload for each thread were IO bound, we would probably see much better performance from python than we are in this case. Green threads have the ability to much more closely and easily control the separate threads, which yields good results when you don't actually NEED multiple CPU cores.
Flawed code - As stated, it was specifically designed to take advantage of multiple CPU cores, not exhibit a real world problem in all it's complexity. That said, it does map to some problems fairly well. I do share data within the threads, but only after the main processing has been completed. This is a common worker technique, where you spawn threads, hand them work to compute, and collect it afterwords. Some sorting techniques may make use of this, as well as Perl 6's auto-threading. Regardless of all that, it does illustrate some patterns don't lend themselves well to that model.
All said and done, I think Juster really missed the point of my post. I think he ran with what he got out of it though, and did a fairly thorough benchmarking of Perl vs. Python in more comparable terms. I think that should be applauded, so his post isn't without merit. I just wish he interpreted my post as what I was really trying to say. Though, from his post I figure he understands it well enough.
Edit: It just occurred to me why Juster interpreted it the way he did. As a boneheaded move, I left the subject from when I first started the article, and it says Perl vs. Python. With that coloring the reading of the article, it's only fair to assume I was actually comparing them. Mea culpa.
As a testament to just how oblivious I was to this, I also missed it when copy-pasting the subject into this new article. Duh.
