Subject: Re: The Weakness of Lisp
From: rpw3@rpw3.org (Rob Warnock)
Date: Fri, 25 Aug 2006 03:27:03 -0500
Newsgroups: comp.lang.lisp
Message-ID: <tcSdnb9nQ_HKKXPZnZ2dnUVZ_o6dnZ2d@speakeasy.net>
bradb <brad.beveridge@gmail.com> wrote:
+---------------
| Fabien LE LEZ wrote:
| > [****] How well does Lisp handle those very low-level and/or
| > performance-critical cases, like decoding MPEG-4 video and sending it
| > to the graphics card's RAM?
| 
| Accessing RAM can be done in an implementation specific way, but I
| won't comment more because I've not done it myself.
+---------------

I use the SYSTEM:SAP-REF-{8,16,32} functions is CMUCL quite a lot
in low-level hardware debugging user-mode code for peeking/poking
at hardware being developed/debugged. The compiler does quite a
good job of optimizing uses of them. The bottleneck for throughput
of code that copies bytes/words to/from device registers/memory is
almost always the CPU pipeline stalls caused by accessing the hardware
device as uncached memory, not the CL code per se. E.g., scanning
64 MiB of a certain PCI-X device's RAM for ECC errors, which takes
two 32-bit uncached reads per 32 bits (one to read a word and one
to read the ECC error register) takes ~30 s realtime or ~230 ns/read,
which is about right for an Opteron going across a 2-3 HT links to get
to a PCI-X and then through the hardware device to its attached SDRAM.

CMUCL has been a big help for me in doing this kind of user-mode
hardware debugging. Back in the the mid-90's I used MzScheme
for this sort of thing, but it was way slower. [And before that
I used Tcl, which was way, *WAY* slower!!]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607