Squawks of the Parrot

VEE workshop, day 1

Breakfast at these things is always somewhat disheartening -- everyone in the conversations seems significantly more clever than I am. Granted, it may just be that everyone who's not, including me, just doesn't talk, but still... Anyway, interesting chats on some of the internals of the hotspot JVM, along with a bunch of other Java talk. (Everyone who got here early seems to be a Java guy)

One thing that's just occurred to me is that we're going about optimization all wrong. There are a lot of people putting a lot of work into optimizing code. That's cool, and I do that too. I think we've gotten about to the point where we can't go any further. Optimizers in general try to order and fiddle with code to make it run as fast as possible. Woohoo! But... At some point you just can't run code any faster, and the only way to go faster is to not run code. That's something that isn't well managed right now.

Sure, optimizers do what they can to find dead code, or find code that only needs to be run once rather than multiple times, but by the time most optimizers get code it's far too late to do this with any real effectiveness. What really needs to happen to make this work is to introduce more HLL constructs and annotations that allow for it. Lazy execution and memoization are two biggies, but there are others. This desperate lack of information (and it's not type information, really) makes things more difficult, which is a shame. It's a lot faster to not do something than it is to actually do something.

Interesting -- looks like there's a big blind spot in the JVM community about embedding and extending the VM with native code. Seems like a big problem, but I dunno, since it's something that Perl/Python/Ruby have been doing for ages, and doing well. Go figure. Blind spots are what this thing's mostly about, though.

One of the talks was basically "We're thinking about solving the problem that Inline solves" only without knowing about Inline. So my being here hasn't been completely one-sided -- the perl/python/ruby folks have definitely solved some of the problems the Java folks haven't thought of, or have only started to think about.

Paolo's talk on mono's interesting. One thing he just said was the reason for mono was so they could write one binding to GNOME, rather than one per language. The implication there is that it's easier to write a compiler for any language to mono than it is to write the GNOME bindings. I'm not sure if that's what he meant, or if it is if it's what he implied. Wonder what that says about the difficulty of binding to GNOME. (Or what it implies about the difficulty of writing language compilers) Not that having a common back end's a bad thing, I just find the implications amusing.

Now this is interesting. On the Need for Data Management Primitives in a VEE makes the point that SQL engines are really just bytecode engines. Specialized ones, but still... And this gives me another Evil Idea. I do like those. I really need to talk to the Postgres folks. (I think this comes after becoming independently wealthy so I have actual free time, but...)

As this goes on, one thing keeps coming to mind: Dammit, I want access to the MMU on the system! Even in a limited way! Because I do. Being able to put some memory blocks in place with catching code would make Parrot's life ever so much easier.

Oh, yeah, and IBM puts on a good spread. Which is a nice thing. :)