Re: Is there an Euphoria compiler?
> I'd be interested in the details. It seems to me
>>that the engine that produces the code for the interpreter to send to
>>the CPU could be easily modified to send the code to a file instead.
>>Wouldn't that be a compiler?
>
>Not exactly.
Even if it was possible, would it be any faster? No
Would it require more memory? Yes for large programs.
Again, compiled languages are faster because they have demand more
information. That's why you have to specify a data type instead of a scaled
value like this.
Lets go back to your perspective, sending the code we execute to a file
instead..
One of the ways a program can make a computer seem to think, is by having it
made decisions and then choose which code to execute based upon that
decision. That is the whole idea of a computer.
Since we do not want to execute the same code again and again, we would like
some interaction.
Which means some decisions have to be made in run-time (when you run your
program)
Euphoria's elegance, provided because its language definition is based upon
the flexibilities of an interpreter, exist because it makes all decisions at
run time. (actually, those decisions he can make at forehand are done by a
quick preproccesor that prepares the execution stack).
You could see it like this:
The interpeter reads your program and makes a stack.
At this point, we have all the code the most memory efficient compiler would
produce only in a different order.
We have a stack full of machine addreses of the machine code to be executed
and their arguments, are on the stack also. All variables are replaces by
machine addreses.
So, at this point the overhead is *one* "jmp" per statement. ( foo = bar +
5 --> 2 statements: addition and a store )
About 0,0001 % of the execution time.
No reason to create such a brilliant compiler. 1) It takes a lot of time 2)
More chances on bugs
On the other hand, a much simpeler compiler, a real compiler approuch would
produce a program with _no_ run-time checking of anything. Make a mistake..
BOOM. and it still wouldn't be much faster for sequences anyway.
The problem is not the compiler/interpreter as you have now seen the small
overhead actually caused by that difference. The problem is that interpreter
has to check and do a lot of things at run-time. Both could be optimized
with more specific information. A fixed-length sequence subscripts way
faster. Thats is also why types would speed up a program. They know the
*fixed* position of eveyr element.
And fixed is off course the oposite of flexibile.
Like some one else said.. if you want small don't use Euphoria.. if you
wanne be big .. eh.. :)
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
Maybe Robert could explain the stack-interpreter method Euphoria uses a bit
better than I just did, so people have a better understanding of the
internals of Euphoria and its behaviour.
|
Not Categorized, Please Help
|
|
