Sat

Sep 29
2007

Tim O'Reilly

Tim O'Reilly

Parrot and Multi-threading

Over on the O'Reilly Network, Kevin Farnham has an interesting blog post about the connection between Parrot and the arrival of multi-core processors (Radar posts.) Kevin makes a number of good points, especially how changing fundamentals can help a technology to "arrive." (Think of how Ruby on Rails made Ruby suddenly the language of choice after ten years as a second-stringer, or how multicore is renewing interest in languages like Erlang and Haskell.) Kevin is also absolutely right about how multi-core will affect even home computing.

Sometimes a technology is invented, and the time simply isn’t right, the need at the moment for solutions that apply that technology is nearly non-existent, though many people readily admit it’s a “wonderful” technology. I wonder if this might apply to a certain extent to Parrot prior to the age of many-core computing?

In a few years, inexpensive PCs will have 8, 16, or more processing cores. Some people doubt that the average home or office user is going to have any use for all these cores. I think that’s like saying “no one will ever need more than 640K of RAM.” Once it’s possible for the average home or office user to apply algorithms and image analysis and video processing and stock market simulators that were previously available only on high-end workstations in data centers, you cannot tell me they won’t want to do this.

 ...

I doubt that applying conventional low-level threads is going to be an efficient way to accomplish this in terms of programming time (I’ve worked at this level for a long time). But on the other side: no one is going to want to convert the mass of existing software platforms/applications that could potentially apply these computation libraries, into C++ or C. A convenient means to enable a broad spectrum of languages to call multithreaded C++, C, and Fortran libraries is going to be needed. Otherwise, again we face enormous software development inefficiency, as a separate interface has to be constructed for each library for each calling language. That’s not a solution that is going to fly, in my opinion.

It seems to me that Parrot is an excellent candidate for addressing this problem. If this is the case, the Parrot team may soon find itself lent increasing support from independent developers, and possibly from companies who recognize the need for this capability with respect to their own applications.

I don’t think this need was really there when PC performance could be improved simply through ever-increasing clock speeds. Single-threaded software that did a few simple calculations was fine then. Multicore, however, changes everything. As highly-scalable multithreaded computation / simulation libraries become available, and people realize they want them, and developers realize they need to be able to call these libraries from every language platform, Parrot’s time may arrive.

Kevin's suggestion that Parrot may solve a big problem for multi-core programming also suggests that the wait for Perl 6 may not have been in vain. (I've always hesitated to count out Larry Wall, one of the true geniuses of programming, and he's backed up by some other great programmers.)

Disclosure: a couple of people on the Parrot team, including Allison Randal and chromatic, work for O'Reilly.

tags: nitty gritty tech  | comments: 5   | Sphere It
submit:

 
Previous  |  Next

0 TrackBacks

TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/5881

Comments: 5

  rektide [10.02.07 01:41 PM]

so what about parrot makes it interesting for multi-threading? i have seen a couple of interesting things in perl6 relating to multi-core systems (the hyper operator in perl6 is certainly interesting, described in the "exegesis 3 operators": 'process this list, i dont care how or in what order'), but i'm not sure what within parrot underlie these capabilities, nor do I know what is particularly innovative or apt about parrot as regards to MT environments.

exegesis 3 - operators:
http://dev.perl.org/perl6/doc/design/exe/E03.html

larry's state of perl6 talk at oscon was phenomenal. it took the hyper-annotated jumble of the exegesis's and distilled it into "where perl5 was and how perl6 is an evolution," and it made me absolutely certain that the wait will be worth it. there was a visceral sense of just how forward-looking and iterative perl is trying to be: it was warming to see a language be so humble about its past and so dedicated towards self improvement.

i've never felt that euphoria moment for parrot. i understand most of the pieces of what is described in the documentation, and i can comfortably approve of most of it as good design (arm chair engineering) but i've never wrapped my mind around data flow between a large number of in flow interpretters and how the event queueing & its handlers would play out within that, the execution-qua-execution of parrot.

currently the defacto reading on parrot is at
http://www.parrotcode.org/docs/
and the parrot design documents can be found at
http://www.parrotcode.org/docs/pdd/

notably, PDD 24 concerns parrot's event subsystem
and PDD 25 concerns parrots concurrency model

  Thomas Lord [10.02.07 02:46 PM]

Ok, here's a suggestion for a euphoria moment:

Parrot is not going to win any awards for technical innovation or for fanciest VM or any of those things. It looks from here like it will be comfortably polished, safe, fun, and friendly to use.

The aha thing might be: The story isn't "Can Ruby, Python, Lua, Scheme, [etc.] be ported to Parrot?!?!" Who cares, really. The story yet to unfold is what happens as people make it easier and easier to build entirely new, domain-specific languages on top of Parrot. What happens as the community of Perl experts evolves into a community of language designers, where "design a new programming language" becomes a standard technique for day-to-day problem solving?

I think Parrot has a decent chance of helping that shift to come about.

-t

  chromatic [10.02.07 07:17 PM]

Tom almost reaches the heart of the matter. If Parrot works out (and I'm betting a fair amount of my time and skill that it will), people will be able to create their own little languages with really good tools -- and those little languages will have access to the full power of all other languages running on top of Parrot within the same process!

If Parrot has a good event model and a good concurrency model (and rektide's links are to the current draft documents, where both designs are very much works in progress), languages built on Parrot get those features almost for free. (They have to map the language semantics to Parrot's semantics, and they need to choose syntax, but that's all.) They get to interoperate with other languages which use the same underlying Parrot subsystems.

All of this is part of a virtual machine designed around the needs of dynamic languages, intended to allow interoperability, released under a free license, and without the shadow of patent concerns or the control of a large company which has traditionally held a variety of positions in working with F/OSS communities.

There's my euphoria moment.

  Thomas Lord [10.02.07 07:31 PM]

Um... thank you chromatic. That really reinforces the sense that I am, in fact, sensing a good vibe.

I have no idea what you guys are doing re a concurrency model but that would seem to be relevant to your "multi-core readiness". My (over-priced?) $0.02 worth: be sure to include models of lots of VM instances that communicate but that don't (at a semantic level) share memory. That's the most conservative model and the easiest one to optimize. I'm sure you already know that and guess you're already working on that -- it's a pro forma comment.

-t

  Anonymous [10.07.07 12:41 AM]

does Parrot support message-based/share nothing concurrency like Erlang !!
I could not figure that out reading the docs.

Post A Comment:

 (please be patient, comments may take awhile to post)






Type the characters you see in the picture above.