Re^2: TIMTOWTDI vs. ithreads

How is this avoided with interpreter threads? They can, after all, share data... I reckon that since it's a special case it might be handled specially, whilst other data is not?

Furthermore, today starting a thread is an enourmous performance penalty, because all non shared data is copied. Unlike forking, where we have copy-on-write (for the curious- it's very efficient, because the kernel simply marks all memory pages as readonly, causing write operations to raise an exception from the MMU, to which the kernel responds to making a new copy of the page which the writing process can work on), there is no optimisation of the process. The main advantage I'm looking for in threads is to gain performance due to concurrency on SMP platforms, for small tasks. Starting a thread needs to be cheap for this to be effective. I think a tradeoff of some continuous speed penalty for an efficient startup time, should at least be a choice.

I'll go looking for some reading material, but I'm sick and too tired to concentrate for any reasonable length of time, so I doubt I can introduce any worthwhile discussion to this thread.

-nuffin
zz zZ Z Z #!perl

Comment on Re^2: TIMTOWTDI vs. ithreads

Replies are listed 'Best First'.
Re^3: TIMTOWTDI vs. ithreads by ambrus (Abbot) on Sep 14, 2004 at 17:59 UTC
When you use ithreads properly, you create the threads soon, when there are only very few data in the heap, and you use as few shared data as possible. When ithreads is used this way, it should be reasonably fast. This means that the ithreads model is not ideal for some tasks you could normally do with threads. Ithreads are, however, very good for tasks where the threads do almost independent work, such as fork emulation or servers handling multiple connections. It is not suited for other tasks, such as tasks with heavy paralel computation imo. Thus, I aggree with your original post in that ithreads might not always be what you want. I do not know about any high level language supporting a thread model similar to for example pthreads, probably because that would make the interpreter unstable when you do not uses locks properly (5005Threads were like that iirc). If you need such threads, you migt want to look at other languages than Perl. Ruby has continuation-based threads, that means of course that it uses only one cpu at a time.	[reply]

Replies are listed 'Best First'.

Re^3: TIMTOWTDI vs. ithreads
by ambrus (Abbot) on Sep 14, 2004 at 17:59 UTC

When you use ithreads properly, you create the threads soon, when there are only very few data in the heap, and you use as few shared data as possible. When ithreads is used this way, it should be reasonably fast.

This means that the ithreads model is not ideal for some tasks you could normally do with threads. Ithreads are, however, very good for tasks where the threads do almost independent work, such as fork emulation or servers handling multiple connections. It is not suited for other tasks, such as tasks with heavy paralel computation imo.

Thus, I aggree with your original post in that ithreads might not always be what you want.

I do not know about any high level language supporting a thread model similar to for example pthreads, probably because that would make the interpreter unstable when you do not uses locks properly (5005Threads were like that iirc). If you need such threads, you migt want to look at other languages than Perl. Ruby has continuation-based threads, that means of course that it uses only one cpu at a time.

[reply]