Re: Interpreters and computationally intensive programs

kendall@centerline.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
> citation.)


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.


Later,
Andrew Mullhaupt
--

Return to the comp.compilers page.
Search the comp.compilers archives again.