Re: Interpreters and computationally intensive programs

andrew@rentec.com (Andrew Mullhaupt)
Sat, 27 Jun 1992 16:30:37 GMT

          From comp.compilers

Related articles
Interpreters and computationally intensive programs kendall@centerline.com (1992-06-24)
Re: Interpreters and computationally intensive programs chambers@klamath.cs.washington.edu (1992-06-26)
Re: Interpreters and computationally intensive programs andrew@rentec.com (1992-06-27)
Re: Interpreters and computationally intensive programs macrakis@osf.org (1992-07-01)
| List of all articles for this month |

Newsgroups: comp.compilers
From: andrew@rentec.com (Andrew Mullhaupt)
Organization: Renaissance Technologies Corp., Setauket, NY.
Date: Sat, 27 Jun 1992 16:30:37 GMT
References: <19920609091040SEB1525@MVS.draper.com> 92-06-120
Keywords: interpreter, performance

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
--


Post a followup to this message

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