There were three interesting talks that I attended at the DLS this year:
Of Scripts and Programs: Tall Tales, Urban Legends, and Future Prospects
(Unfortunately, I missed the first 10 minutes of the talk where Jan was talking about his experiences with the Pluto language).
Some aspects of their evaluation include:
- Size of code (in megabytes)
- Prototype chain lengths â€“ Almost like inheritance chains in Object-oriented languages
- eval(...) â€“ which can used sanely to grab data from JSON or used dangerously to evaluate any string as code.
His solution? Yet another programming language (but, of course :-)). His language is called Thorn. I don't have the time to look at it yet, but it reminds me a lot of Strongtalk language with optional typing.
Jan's slides should be available from the DLS website soon.
Optimization of Dynamic Languages Using Hierarchical Layering of Virtual Machines
Here's a crazy idea: what if you wanted to run Lua on the Lua VM on the ActionScript VM?! Now, why would anyone do this? To test out their optimization technique for layering VMs, of course.
It's a rather circuitous way to evaluate this but it seems to be the easiest route. After all, you don't want to write a VM just to be able to try this out. You just want to use an existing one. And the Alchemy project provides an easy way to translate the original C-based Lua VM to ActionScript.
Of course, the caveat of such an evaluation is that the implementation will be so slow in the first place (the presenter was honest and mentioned this early) that it is relatively easy to get speedups no matter how trivial or naive your technique is.
Hosting an Object Heap on Manycore Hardware: An Exploration
This is a continuation of Dave Ungar's work which he presented at the Squeak BOF at OOPSLA 2008.
In a nutshell, he implemented a simple benchmark (baton passing) between different Squeak Smalltalk VMs running on the 56 (it has 64 cores but some of them are reserved) cores of the Tilera multicore processor.
His goal with this experiment was to investigate what kinds of problems we would run if we are going to use manycore (not just multicore) processors. With manycore processors, you have non-uniform memory access and it becomes infeasible to maintain true cache coherence between those cores. In other words, you do need to be aware of the location of your data (much like what the distributed computing folks have been doing).
This is in contrast to what Intel's multicore chips are doing. Even in Larrabee with 10+ cores, all the cores still maintain cache coherence.
I liked the talk because it presented a different view from all the other research papers that I have been reading where they try to solve the problem (or push the solution as far as it can go) for multicore systems and just implicitly assume that it will scale to manycore. People are trying to hold on to the shared memory model for as long as they can and trying very hard to not use a message passing system.Tweet
comments powered by Disqus