|Interpreters and computationally intensive programs firstname.lastname@example.org (1992-06-24)|
|Re: Interpreters and computationally intensive programs email@example.com (1992-06-26)|
|Re: Interpreters and computationally intensive programs firstname.lastname@example.org (1992-06-27)|
|Re: Interpreters and computationally intensive programs email@example.com (1992-07-01)|
|From:||firstname.lastname@example.org (Andrew Mullhaupt)|
|Organization:||Renaissance Technologies Corp., Setauket, NY.|
|Date:||Sat, 27 Jun 1992 16:30:37 GMT|
email@example.com (Sam Kendall) writes:
[Pure interpreter performance issue raised]
>For this reason, a practical interpreter allows the mixing of interpreted
>and compiled code. An ideal interpreter (not ours, unfortunately) allows
>you to swap between interpreted and compiled code in the middle of
>execution, so that you can execute at full speed for a while, then swap
>some of your program into interpreted code, then continue executing.
Why can't this problem be solved by compiling the compiled parts, and then
dynamically loading/unloading them into the interpreter. Given a case like
yours, where you have control over the compilation, you can have the
compiler write the "wrapper" internally, and in the case of C++, you
shouldn't have much of a type checking/casting problem.
> This assumes that interpreted execution gives you some benefit, such as
> better debugging, runtime checking, or exact arithmetic (as in the following
Perhaps the interpreter is a different language, (e.g. APL, Smalltalk, S,
etc.) which has advantages of its own, and you're providing a way out of
the generally wretched performance problems which high level interpreted
languages generate, or that this is the natural mechanism for extending
the interpreted language.
Return to the
Search the comp.compilers archives again.