Re: Indepth Analyses Of Euphoria Translator
> MTS wrote:
>
> > For one, code size is still way too big...
>
> Well, the code is obviously always going to be
> larger than interpreted code,
> and considerably larger than 'equivalent' C code.
> That's primarily because
> of the overhead of the garbage collection, which has
> to be made explicit.
> You can't just add two objects:
>
> a = b + c
>
> You have to dereference the prior values, hold and
> release temporary
> expressions, and so on. Instead of nice, space
> efficient bytecodes, you're
> at the mercy of whatever compiler you happen to be
> using.
Yeah, but still, there must be a way to simplify
garbage collection...
The speed penalty is way too big...
You have a routine wich is called 5 million times,
then there can be hundreds of millions of Refs and
DeRefs that have to be performed...
> Additionally, there's usually a tradeoff of speed
> versus size. For example,
> instead of calling small, common routines (and
> incurring the associated
> overhead), the compiled version inlines a lot of
> code with macros, making
> the source code even larger.
Well, not realy...
Calling a macro or calling a function requires the
same space, ie one labeled call...
The produced executable is bigger, though, but that's
not that bad realy...
> > For two, execution speeds are still not
> > as fast as they should be...
>
> Relative to what? The interpreter? I'm not suprised
> that the interpreter
> remains faster in many cases. For one thing, you
> have better control over
> the optimization of the bytecodes, and deciding what
> needs to be inlined.
That's not the case, as any inlining or bytecode
optimisations can be directly performed on the C
source aswell, wich I'm betting the translator is
allready doing...
> Garbage collection can be made implicit within the
> instructions, instead of
> having to spell them out with seperate instructions.
>
> If you were talking about low-level stuff (like
> adding integers), C code
> might run faster. But when you start working with
> high-level constructs with
> complex datatypes, bytecodes start coming into their
> own.
The speed gain is just not worth the trouble writing a
translator for, especially if things like DLL
compilation and interfacing with C code isn't
utilised...
The translated code could be a max of only 10% slower
than equivalent hand-written C code, but obviously
it's not.
> > For two, the code is still unreadable,
> > mainly because it's so big...
>
> And optimized. Integer code, for example, creates
> 'empty' blocks because the
> compiler knows that it will never be reached.
>
> > If the code size was reduced, you could
> > hand-edit stuff much easier,
>
> Or you could just use dummy routines at the high
> level, and then write a
> routine that would seek out these dummy routines,
> and replace them with
> appropriate calls.
Did that, it was called MTSECW...
> > and it would pass as hand-written
> > code as well...
>
> Given that the code is worthless on it's own, I
> can't imagine why you would
> want that.
Well, it'd make a damned good resume don't ya think?
Anyone that can code a C app in the complex fashion as
the translater emits, is a coding genius...
:P
> > For three, the runtime library is still
> > in compiled form...
>
> I don't think that Robert is going to give away 'the
> keys to the kingdom',
> so to speak.
Rob said he would do it, but *when* is the key...
> -- David Cuny
Mike The Spike
>
|
Not Categorized, Please Help
|
|
