Re: Why Lisp supposedly "sucks for game development"

From: Edi Weitz (spamtrap_at_agharta.de)
Date: 10/23/04 

Date: Sat, 23 Oct 2004 00:21:39 +0200

On 22 Oct 2004 14:37:15 -0700, Duane Rettig <duane@franz.com> wrote:

> Actually, though, the "gc issue" is not only the time spent in the
> gc itself, but also the effective time that is spent in user code
> compensating for the gc. For example; a running pointer into an
> array can't normally be kept in a register when a gc might move that
> array, unless there is also some way to "forward" that running
> pointer. Instead, a lisp might need to always keep a pointer to the
> array itself, and use fixnum indeces (which don't get changed during
> a gc) and then always perform object/offset style accesses, rather
> than accessing whatever is directly under the pointer. Keeping two
> registers instead of one represents what is called "register
> pressure", and contributes to inefficiency in the generated code.
> It's hard to measure that, except in very small examples (like
> pfannkuch).

That's very interesting. I've always had this question about array
access in my mind but I'm not an implementor. My thoughts were about
as follows: In C you can write a tight loop that, say, walks through
an array of characters and basically looks like this

   char *s = initialize_it();

   while (some_condition(s)) {
     do_something_with(s);
     s++;
   }

which will most likely result in very efficient assembler code. On the
other hand the macro expansions I've seen of something like

   (loop for c across s do (foo c))

always resulted in an application of AREF within the body of the loop
(which is obvious as there is no notion of a "pointer" that can walk
across a sequence in CL, at least not an implementation-independent
one).

So I asked myself if, with proper declarations, the mythical SSC will
ever be able to produce C-like code in this case, i.e. if the running
pointer into the array can be kept in a register (given enough
declarations and enough knowledge about the array in question).

Does this happen in practice somewhere? Does it happen or can it
happen if I wrap the loop with something like WITHOUT-GC?

Suppose I have a very large array of octets and in a time-critical
part of my app I need a tight loop that does nothing but walk through
this array until it finds a certain octet. I'm willing to suspend GC
for this task. Will one of the existing CL compilers be able to
produce code that's as good as hand-written assembler code in this
case?

No, I don't have a real app that needs this. Yes, this is a
theoretical question. Yes, I'll still love CL even if the answer is
no. But I'm curious nevertheless... :)

Cheers,
Edi. 

-- 
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

Relevant Pages

  • Re: char **argv & char *argv[]
    ... "pointer to pointer to char". ... >> pointer)) pointing to the first element of an array. ... so we have to start adding more context. ... type "pointer to char", rather than "array MISSING_SIZE of char". ...
    (comp.lang.c)
  • Re: AMPC 1.4.3 released (C to Java Class Files compiler suite)
    ... array indexing in the JVM wouldn't be able to take advantage of the ... into the array each time thru the loop. ... using pointer arithmetic. ...
    (comp.compilers)
  • Re: newbie question
    ... > The second assigns a pointer to an array 1000 of char to an int pointer. ... >> note the printf right after the assignment of input to the first array. ... By the outer loop. ...
    (comp.lang.c)
  • Re: why cannot assign to function call
    ... hypothetical C-like languages, ... sizeof business would still indicate that a pointer was being passed. ... talk about variables of an array type. ... the earlier version of the standard didn't have numbered ...
    (comp.lang.python)
  • Re: Code comments solicited
    ... A decrementing loop is reasonably well understood, ... pointer to an array of pointers to functions, ... pointer to a function that returns an array of int's, ... counter unless you have a specific reason to do otherwise, ...
    (comp.lang.cpp)