On Wed, 5 Nov 2003, Thies C. Arntzen wrote:
> hi,
Hi ho, and glad to have you on-board. :)
> we've started a project (will have a web-page soon) that aims to port the
> php-language (www.php.net) to run on top of parrot. we've written some
> initial code and i'm kinda stuck while writing the codegen (i target imc)
> my problem is that php is typeless.
As is perl, python, and ruby, FWIW. Luckily that's what Parrot's
ultimately designed to run :)
> i am writing code to to some basic
> type-recognition in my ast to be able to leverage the much speedier I S and
> N types in parrot, but for obvious reasons i have to make the php basic
> type an PMC. problem now is that using pmc for everything will make execution
> much much slower that it could be.
Well... while that's true, in its own way, it's also misleading, though
that's partially our fault. PMCs are Parrot's base type, and what most
languages operating on it should use. I, N, and S registers are in for
local optimizations--PMCs are the main data element.
> my compiler currently translates:
[Snippage]
There are a number of spots in there that can be improved--we can work
that out with you later if you like.
> (i know it can be made better - working on it) - but the basic dilemma is
> obvious: $i starts as an INT and becomes a FLOAT at runtime. so my compiler
> made it a PMC. (i know that i'll at one point have to write my own PMC for
> the PHP base-type, but for now PerlUndef works for me).
It's possible one of the provided types will work out OK as well--if PHP's
base variable type has the same semantics as perl's scalar, it seems to
make sense to use that, just to skip out on having to rewrite the same
code.
> because pmc as so much slower that native types i loose most of parrots
> brilliant speed due to the fact that i don't know the types at
> compile-time.
Nah, you still get our brilliant speed. You're just blinded by the fact
that we're even faster with the primitive types. :)
> would't it make sense to introduce one additional new type into parrot that
> can "morph" between the normal types (I, S, N, P)?
That would be a PMC. :)
> if you think this is unneeded could you explain how you are planning to
> make untyped languages run really fast on parrot and what direction i have
> to take to use that technique?
Use PMCs.
> (PMC will always carry the vtable jump
> overhead, so they will be slower than what perl or php use currently in the
> inner execution loop)
That, as they say, turns out not to be the case. PMCs are faster than
the SVs that perl currently uses, and I'd bet they're quite a bit faster
than what PHP uses.
It's counter-intuitive, but the vtable approach has less overhead than the
current integrated "check flags and figure out what to do" scheme that
perl uses. (I can't speak for PHP, as I don't know the source, but I'd
expect that things are the same there)
A function call does, definitely, blow the processor's prefetch pipeline.
You make a call and since the destination's likely unknown to the
processor's prefetch decoding system the pipeline needs to be flushed and
refilled from the beginning. That blows between 3 and 11 cycles depending
on the processor. Which, interestingly, is the same amount of time you
blow for a mispredicted branch. That means that the vtable dispatch time
and an if jump take about the same time, assuming the destination for both
is in L1 cache.
At that point, then, you need to factor in the other costs to see what's
ultimately more expensive. The vtable dispatch has an indirect pointer
fetch, function arg setup, function preamble and function postamble.
Luckily function preamble and postamble are generally very
low-overhead, and are often nonexistant. (Unless stack space is allocated,
but then it's a block entry cost rather than a functione entry cost, and a
constant cost for both vtable and flag check schemes, as we can assume
that the variables would be created in the body of the flag-check-handling
code as well)
The flag check requires the flag word be fetched out of the struct, the
flag bit extracted out, and tested. This is, for a single test, slightly
faster than the vtable dispatch overhead--it's more than the cost of
fetching the vtable function pointer, but less than the cost to fetch the
pointer and set up the args for dispatch by a cycle or three, depending on
your processor.
The win, then, comes in when you have to do multiple checks at the start
of a function. Perl, for example, does a *lot* of checking at the start of
each op function (much, but not all, of it hidden behind a few macros) and
spends much more time in each op function than Parrot does, because parrot
can roll almost all of those flag checks into the single vtable dispatch.
The trick is to make the vtable attached to a PMC as specific to the
variable type as you can, so those flag checks don't have to be done.
All this essentially ignores multimethod dispatch, which has sufficient
overhead in the general case to overwhelm the issues here, but that's a
separate problem. :)
> i'd also like to add that eg PHP has different semantics when you do binary
> operations on strings that perl has so this VAL type would have to be
> as flexible as a PMC. (PHP would have to use a different implementation
> than Perl6 or Python)
Ah, OK. That just means a few changed vtable methods for PHP scalars. No
biggie, and simple to do with the current system. (Though there may be
some fun issues when it comes time to do some interoperation with perl and
python code. OTOH, I'm facing that now for other reasons, so I expect
we'll have things nicely worked out, or you can help me work 'em out :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
