At 1:49 PM -0500 12/22/03, Josh Wilmes wrote:Still, at the moment, so far as I can tell, most perl, python, and ruby programs that are run are run single-threaded, and as such that mode ought to have the fastest run.I think it might be good to get started on regretting that as soon as possible ;-)
I wonder whether that is a good reason. Parrot originally came out of a desire to make a Perl 6 engine. In which threads, co-routines, events or whatever, are an integral part of the system. What Perl, Python and Ruby programs do now, should carry less weight than what all of these systems, and who knows what other languages that want to build on top of Parrot, want to be able to do in the future.
People will not migrate from Perl 5 to Perl 6 because it will be able to run the same application faster. If that iis the goal, you get bigger hardware and your done with much less fear of migration problems. People _will_ want to move from Perl 5 to Perl 6 because of:
- good threads support
- good signalling support
- good event handling support
All of these more or less need a system that can quickly switch context.
Threaded programs are less common (though certainly not unknown) and as such they should be as efficient as possible but, when a tradeoff's to be made, the single-thread case should win unless it jeapordizes stability or truly screws performance in the multithreaded case.
I think we need a change of mindset. Instead of seeing threaded programs as the special case, we would need to see that the single threaded program is the special case. See how many people use POE for event handling, and through what hoops (Perl) Tk needs to jump through to get proper event handling.
And yes, there are many, many single threaded Perl programs in the world. Which will continue to run _fine_ on Perl 5.X.
Liz
