Re: Interpreters and (math) speed

Robert Bernecky <bernecky@acm.org>
12 May 1998 22:21:49 -0400

          From comp.compilers

Related articles
Interpreters and (math) speed stefan.wils@zorro.ruca.ua.ac.be (1998-05-04)
Re: Interpreters and (math) speed marlet@irisa.fr (1998-05-07)
Re: Interpreters and (math) speed di6adag@cse.hks.se (Adam Granicz) (1998-05-07)
Re: Interpreters and (math) speed bernecky@acm.org (Robert Bernecky) (1998-05-12)
| List of all articles for this month |
From: Robert Bernecky <bernecky@acm.org>
Newsgroups: comp.compilers
Date: 12 May 1998 22:21:49 -0400
Organization: ICAN.Net Customer
References: 98-05-025
Keywords: interpreter

Stefan Wils wrote:
> I'm kind of new to this area, but I am in the process of designing a
> 'graphics language' : a language which has a very extended set of


> [Depends on the granularity of the operations. If each op is big enough,
> the interpreter overhead vanishes into the noise. That's why interpretive
> matrix math systems are popular. -John]


APL and J are good examples of the array-oriented languages alluded to
by John. The problem with them as interpreted languages is that, even
with big arrays, you usually get Amdahl's-Lawed to death by the scalar
and wee tiny array ops that creep into any computation other than
something like a linear equation solver with no other work (so it
becomes a single primitive in APL or J).


Compiling these is a good way out -- it gives lots of expressiveness,
conciseness( due to array ops and higher-order functions), and rapid
development. WHat we need is a JIT compiler for these interpreters.


For some performance stats, overview on the problem, etc., check my
thesis and tech report at: http://home.ican.net/~bernecky


Bob
--


Post a followup to this message

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