From ... From: Erik Naggum Subject: Re: How fast can lisp go? Date: 2000/07/12 Message-ID: <3172431287769739@naggum.net>#1/1 X-Deja-AN: 645676004 References: <396B397E.C63DF2AD@spam.com> <396B7E25.F67E096F@spam.com> <8kh5af$2op$1@counter.bik-gmbh.de> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 963442496 27728 195.0.192.66 (12 Jul 2000 22:54:56 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 12 Jul 2000 22:54:56 GMT Newsgroups: comp.lang.lisp * Martin Cracauer | Well, if it's real-time, you may get into conflict with the Garbage | Collector. This is a persistent myth. Real time does not mean zero latency. With stream data, non-zero latency translates to buffering. You don't want to saturate the processor, anyway, so you have time to catch up after a GC. | There are no "real" problems with Common Lisp reaching what I'd call | "raw machine speed". Minor problems are that the declarations in | Lisp are ugly and hard to write, so that you loose some of Lisp's | advantage. So use Common Lisp to its advantage and write macros to help with the type declarations, then. | Using objects from classes in the classical sense in Lisp (CLOS) is | a lot slower than C++ or Objective-C, but for raw speed you don't | want that anyway. Another persistent myth. Properly declared, CLOS is not at a disadvantage compared to C++, which does a lot of unnecessary copying due to its lack of garbage collection. It takes more time than C++ aficionados are willing to admit. If CMUCL still uses PCL, it should be noted that a native CLOS is much, much more efficient than PCL. #:Erik -- If this is not what you expected, please alter your expectations.