At 14:14 -0500 12/22/03, Dan Sugalski wrote: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,
More than that. Separating the runtime from the language front-end has been key in my book.
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.
I don't see how you can decide to attribute less "weight" to what Perl, Python and Ruby programs do now.
Most programmers I know rank speed-of-prototyping and reduced line-count as their favorite things about
the aforementioned languages.
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:
Lots of companies are still developing on the same hardware they were before Y2K. I'd bet they would welcome a
Perl implementation that got them 3-4x speedup for free for new code. I will agree with you on legacy Perl apps, as most
of my clients are exactly as paranoid as you describe.
- good threads support - good signalling support - good event handling support All of these more or less need a system that can quickly switch context.
I think it is unbalanced to regard threads & context-switching as the most important aspect when dealing with languages that
do not lend themselves to optimization and static compilation.
If you really want reliable signal handling (to the point of worrying about context switch overhead, we begin to sound
like we want a real-time OS and language), then you (at least currently) don't write it in Perl/Python and _especially_
not Ruby. You write it in C/C++/Java/Objective-C, take yer pick.
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.
I don't think we are of the mindset that threading is so special and rare that we will force threading programs to suffer in pain.
I don't see optimization like that. When Dan says we optimize for a common case, it doesn't mean the uncommon case
won't be greatly improved as well. I expect any implementation of Parrot to run single & multi-threaded programs many times
faster than the Perl5 engine.
I think I agree with you in spirit, that we should have high expectations for Parrot and hopefully make the scripting
languages that we are running more realistic as all-around programming languages. I see Parrot as an effort to
close the gap between Perl/Python/Ruby and C#/Java on the exact same hardware, since significant advancements in
execution speed by the Java and C# implementations are pretty unlikely. (They are already pretty fast)
-Melvin
