Xref: utzoo comp.arch:19124 comp.benchmarks:16
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!princeton!cs!samadams!tr
From: tr@samadams.princeton.edu (Tom Reingold)
Newsgroups: comp.arch,comp.benchmarks
Subject: Re: Optimal Computer Architectures
Message-ID: <4337@rossignol.Princeton.EDU>
Date: 9 Nov 90 15:32:55 GMT
References: <1990Nov8.212412.14317@funet.fi>
Sender: news@cs.Princeton.EDU
Followup-To: comp.arch
Organization: Noo Joizy -- The Cultural Mecca
Lines: 21

In article <1990Nov8.212412.14317@funet.fi> neal@uikku.tut.fi (Norwitz
Neal) writes:

$ 
$ I have a recursive algorithm that I would like to run as fast as possible.  I am running a part of it on a SPARCstation SLC.  But at this rate, it might finnish in a couple of years!!  I was wondering if someone could suggest a couple of architectures tha
$ t may suit this recursive algorithm better than others.  The program takes no memory (about 12K).  So all I need is speed.  There are no floating point operations, except a couple of increments.
$ 
$ Also, any information about speed ratings (in mips) from many different computers would be appreciated.

You pose a vague question, so I don't know what we (the net) can
suggest.  If it's really going to take years with the current
algorithm, it sounds worthwhile changing it to an iterative one.

Have you looked at lisp systems?  Some of them handle recursion pretty
efficiently.  I am not talking about lisp running under UNIX.  I am
talking about machines with lisp semantics in the processor.
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
	from windshield before starting ignition."