Okay, I need to prefix this with a public apology. My initial reply was
cranky and unprofessional
At 01:48 AM 10/8/2001 +0530, V Vinay wrote:
>Dear Dan,
>
>You are doing a wonderful job and my intension is not to pass judgements on
>any one's technical abilities on this list. We have a bunch of very
>talented people here that would be difficult to match in any other group.
>
>:> 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.
>
>Of course, we should finally be faster than perl/python to make the
>effort worthwhile. But why is this a reasonable measure?
Because "Faster than perl 5" is one of the design goals, and if we meet
that, I'm happy. "Faster than Compaq FORTRAN" isn't one of the goals.
(Which is good, as I don't think it's doable) Faster than Python or Ruby
would just be a nice bonus.
>The output of parrot->C compiler on test.pbc compiled with -O0 switch gives
>a (ops/s) performance of 110-120M. (libparrot was compiled with an O3.)
>
>./test_prog compiled with a -O3 give about 17-19M on my machine (PIII, 650).
Yup, that's about what I expect, but I think this was the bit I answered
earlier.
>:> 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.
>
>Preprocessing of code??
Yes. The compiled code stored on disk is position independent and directly
executable. If we thread things it means we have to process that code after
(or while) we load it from disk. For this to be worthwhile it means the
time it takes to process the code must be outweighed by the time it saves.
This is definitely an issue with modules and library code, where we'd end
up processing pages of code we might not otherwise use in the run, thus
paying the time to load in things we won't use.
>:> 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.
>
>Good. We will search for solutions that will not break ANSI then.
Nah. We'll break ANSI rules big time, rather than in little ways. :) Jump
straight to TIL or low-level machine code and skip the whole opcode loop
entirely.
>:> 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.
>
>Cool it! I come from an academic world where nothing is holy and all ideas
>are subject scrutiny. But there is no scope for personal attacks, or being
>judgemental. So please don't read between the lines.
>
>My only points were, this is a good time to make things faster;
>switches will not help substantially in this cause; theading is a
>possibility.
My point was that we'd *already* looked at the things you were talking
about. The current _implementation_ was chosen on purpose and with thought,
and the design the implementation is being written to was also thought
about long and hard. (And the design doesn't preclude the implementation
you proposed--rather it specifically takes it into account as a potential
future optimization)
Basically you jumped in feet first with insufficient research as to what's
gone before (and why, though the whys might be lacking in the archive) and
caught me on a cranky day. For which I apologize again--it was
un-called-for and unprofessional on my part.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
