From ... From: Erik Naggum Subject: Re: How fast can lisp go? Date: 2000/07/12 Message-ID: <3172424339277270@naggum.net>#1/1 X-Deja-AN: 645645195 Content-Transfer-Encoding: 8bit References: <396B397E.C63DF2AD@spam.com> <396B7E25.F67E096F@spam.com> <0D_a5.154$5d3.2857@m2newsread.uni2.es> mail-copies-to: never Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 963437359 26340 195.0.192.66 (12 Jul 2000 21:29:19 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 21:29:19 GMT Newsgroups: comp.lang.lisp * "Fernando Rodríguez" | It would be interesting if someone with greater experience could explain | how to handle the GC delay in this sort of realtime applications... O:-) Well, suppose you have a stream that produces about 50 M/s, your maximal GC delay is 100 ms, and your processing ability is above 50 M/s, you can set up output buffers of about 5 M, which you would fill before starting actual output and which would drain during GC, coupled with an input buffer that would fill up during GC and be drained faster than new input is filling it. Nobody would ever notice any GC pauses. All you would see is 100 ms processing latency without any reduction in bandwidth. If you can control the input bandwidth and read and process faster than you need to output, your application would block on output and you wouldn't need to worry about GC pauses at all if you set up big enough output buffers. The key is really to have faster-than-real-time processing power. #:Erik -- If this is not what you expected, please alter your expectations.