I just did a quick scan through parrot's opcode files. We have, as of now...
261 ops.
Yep, that's it, 261. Barely more than .NET or the JVM. That's counting multiple variants of the same op as one op, which isn't an unreasonable thing to do, as the only difference between the open op that takes a string and one that takes a PMC is the PMC version needs to extract out the string from the PMC before opening.
Now, if you count actual op bodies, we're at 527 ops, which isn't an unreasonable number to count either, as that's the number of functions that need maintaining. At this, at least for right now, we're still somewhat below the number of op bodies you'd need for a .NET interpreter. (While .NET has fewer opcodes, many of those opcodes are untyped, and need to check the types of the elements on top of the stack, so while it has one add op we might have 9. We're just making explicit what .NET does implicitly, but the amount of code's the same since we both need to have 9 types of addition. (Or 18, if you consider immediate constants as separate types))
If you go full-on and count actual opcodes in the generated source, we're currently at 1097. That number's mostly irrelevant as nobody ever sees those op bodies, as they're all generated from the input data files. The only people who have to deal with that are folks writing JIT versions of the ops. (This is a place where we win a bit over .NET, since our ops are simpler, so we don't have to do nearly as much analysis to get the equivalent results) Since we're as much concerned with interpreted as JITted or compiled performance, as we can't count on the JIT everywhere, nor on the JIT when running with enhanced security, the fanout's a win for us.
Not nearly so many as I'd expected, which is cool.
Update Of course there's always the question "Why do I care?" Well, a few reasons.
First, folks seem to like throwing the "You have a zillion ops and that's insane! We have a small number and that's just swell!" thing at me. I don't care all that much, but it's nice to be able to say "Well, actually, that turns out not to be the case."
Second, there's the issue of brain space. If we really did have a zillion ops, that makes the interpreter potentially more difficult to master. Not a huge issue, as anything we didn't make an op would just be a function, and there's not a huge difference between a zillion ops and a zillion functions (except that the ops, even non-JITted, would run faster) but still, it's there.
Finally there's a maintenance issue. That's a lot of op bodies to maintain, fix if some fundamental structural flaw pops up, secure when it's time to enable security, and generally thump about. But, again, not much of a difference there between a zillion ops and a zillion functions.
Posted by Dan at July 28, 2003 01:53 PM | TrackBack (1)