Re^11: If I am tied to a db and I join a thread, program chrashes

I tried to resist but eventually I lost my resolve and responded ;-)

What exactly is it benchmarking?

My answer would be matrix multiplication. Ok, his test matrices are too small (which makes it a worst case benchmark). But in the proceedings of the perl workshop there is a diagram where matrix multiplications/s (not simply multiplications/s) are compared to the matrix size. The diagram shows that he tested variable matrix sizes, up to 1000x1000 matrices, and also used a different benchmark metric. PS: I found the diagram on the same server where the test script is, http://data.plan9.de/mat.png

Naturally the coro-version is slower than pure perl. But the interesting thing is how much slower. Threads allow different programming styles or paradigms, for example producer/consumer relationships. How much is the penalty to do it this way instead of the simple iterative way?

...I'll attempt to produce a fair comparison...

I'm anxious to hear those results. I even might show Marc Lehmann the results at the next perl workshop, if he is there.

Comment on Re^11: If I am tied to a db and I join a thread, program chrashes

Replies are listed 'Best First'.
Re^12: If I am tied to a db and I join a thread, program chrashes by Anonymous Monk on Jul 04, 2009 at 16:20 UTC
Hi, thanks for trying to dissect my benchmark (unfrotunately you failed to understand it, and spread a lot of fud - e.g. calling time takes the same amount of time in threads as in Coro, so if at all, ithreads have an advantage here because they can run it in parallel, while Coro threads cannot). I don't fail you, because ithreads are horribly confusing to most people, because they wrongly imply that they are threads,a nd they wrongly imply that they are useful for anything on non-windows machines. The talk I gave was about threading models in general in scripting languages. Threads are defined by a shared address space, so ithreads are not threads in the first place. Many people (including you) confuse them with real threads (as implemented by Coro), doubtlessly because of the badly chosen name. What I wanted to show, and without doubt succeeded, is that in data-sharing-extensive scenarious, ithreads totally lose, because they can't share data efficiently (which is normally the only advantage of threads). I also showed that data sharing is so slow with ithreads as to be useless. real processes certainly perform better than ithreads in about any scenario. the problem with ithreads is that they emulate unix processes (thats what they were written for), in software, something a unix system does efficiently in hardware. This cpu/mmu emulation costs around 25%, whether used or not. It also means that unlike unix processes, starting a pseudo ithreads process involves a very costly copy operation, doubling the amount of memory used (under unix only small amounts of memory are neecsssary). So, the bad points about ithreads is that they slow down every perl interpreter for a windows hack, that they slowly emulate in software what on a typical OS today does in hardware, and that it doesn't implement threads at all, as it emulates processes. Processes, of course, can be had faster and with much less overhead by, well, using OS processes instead of the emulated ones. What's in favour of ithreads? The only thing is the existing API that allows yout o create and join processes easily, and implements data copying between them. That advantage is, however, no longer existing now that theAPI-comaptible "forks" module exists, which implements the ithreads API using real processes, outperforming it greatly in most cases. So in summary, ithreads are a total misnomer, as they don't even implement threads. They should not be enabled on non-windows perls for that reason, as non-windows perls have a hardware-assited process implementation, which cna be used instead. The benchmark is meant to illustrate how expensive it is to treat ithreads as if they were real threads (both in program complexity as well as in cpu time), compared to a real threads package. Without doubt, it did succeed in that.	[reply]
Re^13: If I am tied to a db and I join a thread, program chrashes by BrowserUk (Patriarch) on Jul 04, 2009 at 17:26 UTC
Threads are defined by a shared address space, so ithreads are not threads in the first place. Many people (including you) confuse them with real threads (as implemented by Coro), Utter, unmitigated & unmitigatable, ridiculously uninformed or knowingly deceitful, grade-A, four-star baloney. Threads are defined by two things: shared memory and concurrency. Coro fails to meet this fundamental definition because it doesn't do concurrency. It also cannot make use of multiple cores, and so cannot be used to speed up process intensive processing (like matrix multiplication!). Your benchmark is garbage and your words either naively & hopelessly misinformed; or deliberately misleading. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP PCW	[reply]
Re^13: If I am tied to a db and I join a thread, program chrashes by jethro (Monsignor) on Jul 05, 2009 at 13:42 UTC
"I also showed that data sharing is so slow with ithreads as to be useless. real processes certainly perform better than ithreads in about any scenario" As far as I can see you only (if at all) showed that preemptive threads (in particular ithreads) pay for the added comfort with a speed penalty. Which is not really surprising. Any form of preemptive multitasking needs at least some form of locking or synchronizing that costs speed BrowserUK showed without question (the copying of the data to non-shared to make only one use of that data can't be better than simply using the value) that your implementation of the ithreads matrix mulitplication could be faster, so the comparision was definitely unfair. This may have been an oversight by you, it may possibly not really change the end result in any significant way if done correctly (who knows), but it still makes any conclusions from your results at the moment impossible No denying you make some excellent points (IMHO). I don't like the penalty on everyone so that ithreads can be used, I don't care much about performance on windows, I wouldn't miss anything if ithreads would be replaced completely by an implementation with forks. But I also think that comparing ithreads to Coro (or simple linear execution) in a worst case szenario is not the way to go if you really want to convince a lot of people to drop ithreads. Coro is very useful for programming user interfaces or other tasks with lots of I/O. But its inabilty to use more than one core makes it it an ill fit for CPU intensive tasks in todays landscape of multicore CPUs. Preemptive and nonpreemptive multitasking simply have different use cases today and if you had compared ithreads to the API-compatible forks module it might have had a lot more relevance	[reply]

Coro fails to meet this fundamental definition because it doesn't do concurrency.