12 May 1998 22:21:49 -0400

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

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.