
How about re-engineering the interpreter to make it more MP friendly? (This is probably a bigger task than a Masters thesis.) The current interpreter serializes on the global interpreter lock (GIL) and blocks everything. Is there another approach which would allow processing to continue? Guido said once that there was an attempt to change the granularity of the locking, but that it quickly became overly complex and unstable. Perhaps some of Maurice Herlihy's ideas may be adapted to the problem. Moreover, it may not be necessary that the interpreter state be consistent and deterministic all the time as long as it eventually produces the same answer as a deterministic equivalent. There may be interpreter organizations which move forward optimistically, ignoring potential locking problems and then (if necessary) recoveri, and these may have better performance than the more conservative ones. Or they may not. Some kind of performance tests and evaluations would need to be part of any such study. On Tue, 28 Oct 2003, Brett C. wrote:
Today I got the wheels turning on my masters thesis by getting an adviser. Now I just need a topic. =) The big goal is to do something involving Python for a thesis to be finished by fall of next year (about October) so as to have it done, hopefully published (getting into LL4 would be cool), and ready to be used for doctoral applications come January 2005.
So, anyone have any ideas? The best one that I can think of is optional type-checking. I am fairly open to ideas, though, in almost any area involving language design.