On Sun, 7 Oct 2001, V Vinay wrote:
> I do not understand all the
> issues thought I have sampled the discussion over the last six months.
You may need to go back further, then.
> The interpreter is way too slow and we all admit to that.
No, we don't, actually. The benchmarks show us running around twice the op
rate of perl 5 and python. Whether this is sufficient depends on what
those ops do. My thinking is the rate is insufficient, but we won't know
for sure until we have something more closely equivalent.
> Contrary to Dan's
> thinking, this is the right time to set this right, with the new cycle just
> beginning.
I think you're misinterpreting my current thinking rather badly.
> >That's not fast enough; once PMCs get introduced, that advantage
> >is going to fall away. What are we doing wrong? :( Python uses a
> >switch, however, maybe that's it.
>
> Interpreter dispactching is just not written the way parrot currently is.
Details would be nice.
> Most use threaded code approaches
Which require significant amounts of preprocessing on code loaded from
disk, amongst other things. It's a technique that has its own costs
associated with it.
> and gcc specifically allows the so called
> "labels as values" to allow threading. (It is not ansi C complaint:
Which is why the base interpreter won't use it. If we're going to break
ANSI compliance (and we will) we're going to do it in a big way. We're
certainly not going to tie ourselves to gcc in doing it, given gcc's
rather sub-optimal optimizer.
> At the minimum, we should looking at some variant of threading. Otherwise
> there is simply no way we can have a fast interpreter. Some of the ideas of
> Gregor Purdy based on the parrot->C experience will, I think, lead to
> rediscovery of threading (maybe an efficient variant!).
You're about a year behind. I'm well aware of threading techniques, along
with quite a few other tricks.
I think you're passing judgement far, *far* too early. (And you're
underestimating both the design and the tricks I have handy) I know the
places we're trading off speed for simplicity and cleanliness, and I know
when and where we're going to stop doing that.
Dan
