Has anyone seen anywhere a technical rebuttal to the positions this article
takes?
http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
Thanks
Panos C. Lekkas
From: M Jared Finder
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <2to5umF21t32rU2@uni-berlin.de>
xstream wrote:
> Has anyone seen anywhere a technical rebuttal to the positions this
> article takes?
>
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
Since only the Naughty Dog example is fleshed out, that's what I'd focus
on. And it sounds to me like they made one *critical flaw*:
> The Jax & Daxter post-mortem in Game Design Magazine mentions there
> were delays related to their compiler being developed in-house, and
> all their Lisp expertise being concentrated in one man's head.
Of course it would be bad to develop a compiler in-house as well as to
have all the knowledge in an important development tool in one person.
Neither of those have any relevance to Lisp, though; they could occur
with any programming language.
-- MJF
"xstream" <·······@attglobal.net> wrote:
> Has anyone seen anywhere a technical rebuttal to the positions this
> article takes?
>
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
http://groups.google.de/groups?selm=opsd3zuvyspqzri1%40mjolner.upc.no
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Mikael Brockman
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87acuh9klp.fsf@igloo.phubuh.org>
"xstream" <·······@attglobal.net> writes:
> Has anyone seen anywhere a technical rebuttal to the positions this article
> takes?
>
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
>
> Thanks
>
> Panos C. Lekkas
Here's a preliminary rebuttal -- I'm short of time:
| Problems with Lisp:
|
| * Low performance, especially on modern processors
False
| * No module/library mechanism
False
| * No easy interface to C-based code
False
| * Lack of types makes it difficult to understand or safely modify
| large programs
False: Common Lisp has a rich type system
| * Macros makes code harder to understand
False: the only purpose of macros is to make code *easier* to
understand. Attempting to do without macros what is properly done with
them makes code harder to understand.
| Lisp has low performance by default. Low Performance is designed into
| the language at several levels:
|
| * Everything's heap based . This introduces an extra level of
| indirection which is deadly on modern processors. A modern
| processor might take 400 cycles to fetch data from main memory vs,
| one cycle to fetch data in a register.
False: choosing to allocate objects on the stack is done by the optimizer
| * Lists are the default data structure. That adds one extra level
| of indirection (each time you iterate) compared to vectors. It
| also tends to use memory less efficiently than an
| array. (CDR-coding can help with this, but not all Lisps implement
| CDR-coding.)
False: what? This one is just ridiculous. What's a "default data
structure"?
| * Every variable can hold any type of data, with the type being
| determined at run time. This makes it difficult to hold binary
| data efficiently.
False: variables with type annotations cannot hold any type of data, and
their type is statically determined.
| * Even small versions of Lisp (like Scheme) have
| performance-sapping features like continuations. (Which make it
| difficult to call functions efficiently.)
False: "even" implies that large versions of lisp (like Common Lisp) has
continuations too, which it doesn't. And I don't see why the presence
of CALL/CC makes it difficult to call functions efficiently -- surely
CPS transformation is a well-known technique by now?
I'll throw in a response to one of his ML critiques, too:
| F# / CAML / ML / Nemerle - these are all ML-derived languages. ML is
| something like Lisp with a more readable syntax and strong typing.
|
| * Types are automatically inferred by the compiler, but how's the
| poor reader going to figure things out?
By the optional type annotations provided by the programmer in the
pursuit of maintainability.
It's a silly article which hardly deserves response at all.
From: Christopher Browne
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <2tov87F22hetlU2@uni-berlin.de>
Centuries ago, Nostradamus foresaw when Mikael Brockman <······@phubuh.org> would write:
> It's a silly article which hardly deserves response at all.
The claims are pretty bizarre.
In order for all those details to be claimed, it would seem the author
would need to know Lisp intimately enough to know that many of the
claims are preposterously wrong.
--
select 'cbbrowne' || ·@' || 'ntlug.org';
http://www.ntlug.org/~cbbrowne/sap.html
"The test of a principle is whether it applies even to people you
don't like." -- Henry Spencer
Well, when I first saw the article (it's been posted here before) I
though about doing something along those lines, but once I read
through all of it, I realized that it is either a bad joke or the
author is completely clueless (there is not _one_ point he makes that
is true or even credible). Fortunately, he does admit as much. For
starters, he hasn't actually written any games in Lisp. Actually, he
hasn't even written anything in Lisp in the past 17 years, besides
porting Norvig's JScheme to the CLR (what was that Greenblatt said
about writing a Lisp in a week?). As far as his technical points, let
me pick at types (garbage like "lists are the default data structure"
have already been covered elsewhere).
"Lack of types makes it difficult to understand or safely modify large
programs."
I find the most common refrain from profuse type declaration advocates
is that programmers are brain-damaged monkeys who can't possibly
reason about their program data types unless they are made to write
them out every other line. And god forbid type errors are caught at
runtime! It would, like, cause the earth to blow up or something (of
course this is exactly what Java does with casting).
But when he says of ML that "Types are automatically inferred by the
compiler, but how's the poor reader going to figure things out?" is
when you really know that he's trolling. Where do you think those
types are inferred from, and when do you think they're checked?
There's not a lot of room for confusing a+b in ML for brain-damaged
things like string concatenation (hell, even adding two floats is a
different operator!).
One more thing I want to point out is that even John Thingstad (Frank
Buss posted a link to his rebuttal) seemed to agree that "it's hard to
tell cheap operations from expensive ones" in Lisp. I can't remember
what Knuth said about optimization, so I'll use my own aphorism:
Run the fine profiler!
Vladimir
"Vladimir Sedach" <(string-downcase (concatenate 'string last-name (subseq
first-name 0 1)))@cpsc.ucalgary.ca> wrote in message
···················@shawnews.cg.shawcable.net...
> Well, when I first saw the article (it's been posted here before) I
> though about doing something along those lines, but once I read
> through all of it, I realized that it is either a bad joke or the
> author is completely clueless (there is not _one_ point he makes that
> is true or even credible).
I agree with you completely. I believe you hit it right between the eyes.
This is the same initial thought that crossed my mind as well, when I read
the article. You must admit though that this is the same kind of generic
rubbish that leaves "ideas" on impressionable people, especially on
beginners (people who confuse software engineering with programming) or on
run-of-the-mill IT managers who dictate the choice of language and
development tools/environments based on ... trade journal surveys and trendy
rankings. It might actually not be a bad idea to put together a small series
of parallel alternative-approach articles intended for various forums
whereby we could lay out and offer the freshness of Lisp as THE development
tool of choice for areas where for instance game developers (or simulation
scenario toold developers, etc. with numerous possible applications all the
way from gaming to military operations and logistics planning) can benefit
by the experience most of us have accumulated over the years, or to put it
mildly by what has come to be known as obvious to almost everyone frequently
posting on this group.
Panos C. Lekkas
xstream wrote:
> "Vladimir Sedach" <(string-downcase (concatenate 'string last-name (subseq
> first-name 0 1)))@cpsc.ucalgary.ca> wrote in message
> ···················@shawnews.cg.shawcable.net...
>
>>Well, when I first saw the article (it's been posted here before) I
>>though about doing something along those lines, but once I read
>>through all of it, I realized that it is either a bad joke or the
>>author is completely clueless (there is not _one_ point he makes that
>>is true or even credible).
>
>
>
> I agree with you completely. I believe you hit it right between the eyes.
> This is the same initial thought that crossed my mind as well, when I read
> the article. You must admit though that this is the same kind of generic
> rubbish that leaves "ideas" on impressionable people, especially on
> beginners (people who confuse software engineering with programming) or on
> run-of-the-mill IT managers who dictate the choice of language and
> development tools/environments based on ... trade journal surveys and trendy
> rankings. It might actually not be a bad idea to put together a small series
> of parallel alternative-approach ...
Save your breath. Those rotm IT managers do not decide what language
comes next, they adopt it once it gets all the headlines. The latter is
decided by the grass roots, and if you have followed c.l.l for a few
years you know a sea change has already taken place. the joint is packed
with diapered newbys* left and right. and languages this good do not
turn back. game over. if one stupid MS programmer-authored article can
stop Lisp... chya.
kenny
* a link below leads to a survey of newbys from a couple of years ago.
growth exponential has continued since then, but I have not been
flogging newbys for stories as I did early on. at this point my
curiosity grows again: has anything changed? Is paul graham still the
beacon drawing everyone into the CL harbor? or are newbys being drawn in
by the newbys of 2002? the stories are great fun anyway and I think a
potential contribution to the growth of Lisp qua testimonials.
Would the class of '04 care to contribute?
k
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On Thu, 21 Oct 2004 04:36:11 +0000, Kenny Tilton wrote:
> * a link below leads to a survey of newbys from a couple of years ago.
> growth exponential has continued since then, but I have not been
> flogging newbys for stories as I did early on. at this point my
> curiosity grows again: has anything changed? Is paul graham still the
> beacon drawing everyone into the CL harbor? or are newbys being drawn in
> by the newbys of 2002? the stories are great fun anyway and I think a
> potential contribution to the growth of Lisp qua testimonials.
>
> Would the class of '04 care to contribute?
>
> k
I'm preparing a couple of newbies myself at the moment.
All my pro-Lisp ranting (with copious anti-Java ranting thrown in for
good measure) didn't do much except convince them that I was rather odd.
Giving them Paul Graham's "Hackers And Painters" made them stand up and
listen. I've now started one of them off on "ANSI Common Lisp", and
convinced the other that he needs to learn Emacs soon (I hooked him by
showing him a neat ELisp function I had written to deal with the
Java-induced pain I have to deal with at work).
Of course I still think of myself as a CL newbie, but I'm getting the hang
of it gradually, and having lots of fun along the way!
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
From: drewc
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <FFIdd.1139$%%1.296@pd7tw3no>
Kenny Tilton wrote:
<snip>
>
> * a link below leads to a survey of newbys from a couple of years ago.
> growth exponential has continued since then, but I have not been
> flogging newbys for stories as I did early on. at this point my
> curiosity grows again: has anything changed? Is paul graham still the
> beacon drawing everyone into the CL harbor? or are newbys being drawn in
> by the newbys of 2002? the stories are great fun anyway and I think a
> potential contribution to the growth of Lisp qua testimonials.
>
> Would the class of '04 care to contribute?
I'll give a go. Paul Graham. I'd tried lisp before, but didn't 'get it'.
I was looking for a new platform for web application development...
stumbled across pg's site (which i had read before but paid no mind),
and gave lisp another look...
never looked back..
drewc : C.L.L Class of 2004.
"xstream" <·······@attglobal.net> wrote in message news:<···············@corp.supernews.com>...
> Has anyone seen anywhere a technical rebuttal to the positions this article
> takes?
>
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
>
> Thanks
>
> Panos C. Lekkas
I am new to Lisp, but even I could recognize some mis-truths in this
article.
However, he is right about one thing. C/C++ is the best language for
writing video games. Not becuase it's the best language, but because
it is the best language for the domain. Virtually everyone in the
video game world knows C/C++. It is part of the culture of video game
development, so there is alot of information/examples/support for
newbies. Lisp and Java may make make some inroads into lower end
games, but C++ will own domain in general for a long time.
The biggest reason why the culture uses C/C++ is *performance*.
Lisp/Java/Python, or anything other then assembly will have problems
in this area. Lisp may be fast, but modern 3D video games push so
many polygons that you want every cycle out of that CPU working for
you. Only by working as close to the CPU's and GPU's as possible will
this happen.
If you are going to do video games, you can learn the basics with a
language like Lisp or Java, and you can even build some things. But
if you want to work on games like Doom 3 or HL2, you need C/C++ and
you need to get down with the OpenGL C library..."everything else is
just a wrapper."
- Darren
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4acugm4wi.fsf@franz.com>
·········@hotmail.com (Darren) writes:
> "xstream" <·······@attglobal.net> wrote in message news:<···············@corp.supernews.com>...
> > Has anyone seen anywhere a technical rebuttal to the positions this article
> > takes?
> >
> > http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
> >
> > Thanks
> >
> > Panos C. Lekkas
>
> I am new to Lisp, but even I could recognize some mis-truths in this
> article.
>
> However, he is right about one thing. C/C++ is the best language for
> writing video games. Not becuase it's the best language, but because
> it is the best language for the domain. Virtually everyone in the
> video game world knows C/C++. It is part of the culture of video game
> development, so there is alot of information/examples/support for
> newbies. Lisp and Java may make make some inroads into lower end
> games, but C++ will own domain in general for a long time.
I was with you up to this point. Libraries and culture do indeed
play an important part of the real appropriateness of a language
to a domain. Lisp is behind the curveon these aspects. [And yet,
despite the odds, it is still used successfully by some people;
ever wonder why?]
> The biggest reason why the culture uses C/C++ is *performance*.
That must mean no calls to malloc/free or new.
> Lisp/Java/Python, or anything other then assembly will have problems
> in this area. Lisp may be fast, but modern 3D video games push so
> many polygons that you want every cycle out of that CPU working for
> you. Only by working as close to the CPU's and GPU's as possible will
> this happen.
Why do you believe that Lisp cannot work as close to the CPU/GPU
as possible? What is it that you think Naughtydog _did_?
> If you are going to do video games, you can learn the basics with a
> language like Lisp or Java, and you can even build some things. But
> if you want to work on games like Doom 3 or HL2, you need C/C++ and
> you need to get down with the OpenGL C library..."everything else is
> just a wrapper."
Why not an OpenGL Lisp library?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> wrote in message news:<·············@franz.com>...
> ·········@hotmail.com (Darren) writes:
>
> > "xstream" <·······@attglobal.net> wrote in message news:<···············@corp.supernews.com>...
> > > Has anyone seen anywhere a technical rebuttal to the positions this article
> > > takes?
> > >
> > > http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
> > >
> > > Thanks
> > >
> > > Panos C. Lekkas
> >
> > I am new to Lisp, but even I could recognize some mis-truths in this
> > article.
> >
> > However, he is right about one thing. C/C++ is the best language for
> > writing video games. Not becuase it's the best language, but because
> > it is the best language for the domain. Virtually everyone in the
> > video game world knows C/C++. It is part of the culture of video game
> > development, so there is alot of information/examples/support for
> > newbies. Lisp and Java may make make some inroads into lower end
> > games, but C++ will own domain in general for a long time.
>
> I was with you up to this point. Libraries and culture do indeed
> play an important part of the real appropriateness of a language
> to a domain. Lisp is behind the curveon these aspects. [And yet,
> despite the odds, it is still used successfully by some people;
> ever wonder why?]
No doubt Lisp can be, as the article pointed out (Naughty Dog). My
only point was my believe that C/C++ are currently the best to use.
>
> > The biggest reason why the culture uses C/C++ is *performance*.
>
> That must mean no calls to malloc/free or new.
Your right, as much as possible those are avoided. Most engines
allocate as much as is possible at the start of a level and free it at
the end.
>
> > Lisp/Java/Python, or anything other then assembly will have problems
> > in this area. Lisp may be fast, but modern 3D video games push so
> > many polygons that you want every cycle out of that CPU working for
> > you. Only by working as close to the CPU's and GPU's as possible will
> > this happen.
>
> Why do you believe that Lisp cannot work as close to the CPU/GPU
> as possible? What is it that you think Naughtydog _did_?
They wrote their own compiler to do that though. That's not really an
option for most people.
>
> > If you are going to do video games, you can learn the basics with a
> > language like Lisp or Java, and you can even build some things. But
> > if you want to work on games like Doom 3 or HL2, you need C/C++ and
> > you need to get down with the OpenGL C library..."everything else is
> > just a wrapper."
>
> Why not an OpenGL Lisp library?
With some extensions and a platform specific compiler that could
indeed work... but again, my only point is what is currently best.
To be honest, if money/time were not an issue, a language built from
scratch entirely to the GPU communications/capabilities and video game
needs (object/environment maintenance, rendering, frame
synchronization, collisions, networking, etc.) would be best :)
Duane Rettig wrote:
> ·········@hotmail.com (Darren) writes:
>
>
>>"xstream" <·······@attglobal.net> wrote in message news:<···············@corp.supernews.com>...
>>
>>>Has anyone seen anywhere a technical rebuttal to the positions this article
>>>takes?
>>>
>>>http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
>>>
>>>Thanks
>>>
>>>Panos C. Lekkas
>>
>>I am new to Lisp, but even I could recognize some mis-truths in this
>>article.
>>
>>However, he is right about one thing. C/C++ is the best language for
>>writing video games. Not becuase it's the best language, but because
>>it is the best language for the domain. Virtually everyone in the
>>video game world knows C/C++. It is part of the culture of video game
>>development, so there is alot of information/examples/support for
>>newbies. Lisp and Java may make make some inroads into lower end
>>games, but C++ will own domain in general for a long time.
>
>
> I was with you up to this point. Libraries and culture do indeed
> play an important part of the real appropriateness of a language
> to a domain. Lisp is behind the curveon these aspects. [And yet,
> despite the odds, it is still used successfully by some people;
> ever wonder why?]
>
>
>>The biggest reason why the culture uses C/C++ is *performance*.
>
>
> That must mean no calls to malloc/free or new.
>
>
>>Lisp/Java/Python, or anything other then assembly will have problems
>>in this area. Lisp may be fast, but modern 3D video games push so
>>many polygons that you want every cycle out of that CPU working for
>>you. Only by working as close to the CPU's and GPU's as possible will
>>this happen.
>
>
> Why do you believe that Lisp cannot work as close to the CPU/GPU
> as possible? What is it that you think Naughtydog _did_?
>
>
>>If you are going to do video games, you can learn the basics with a
>>language like Lisp or Java, and you can even build some things. But
>>if you want to work on games like Doom 3 or HL2, you need C/C++ and
>>you need to get down with the OpenGL C library..."everything else is
>>just a wrapper."
>
>
> Why not an OpenGL Lisp library?
>
And let's not forget OpenAL, because we'll want 3D sound as well.
CL-SDL might be the best project for budding Lisp gamers. The one-window
restriction is no problem, and one gets more than just OpenGL in there.
http://cl-sdl.sourceforge.net/
Gee, that should move over to common-lisp.net so it does not get missed
by those merely surfing the Projects listing. Anyway, here is SDL itself:
http://www.libsdl.org/index.php
Looks very active, cl-sdl less so.
As for "you need to get down with the OpenGL C library", well, what is
the hard part? Lots of Lisp bindings out there, including the ones in
asubtree of the Cello project. The latter is not ready for prime time in
that there is no doc and no easy way to install the whole mess, but the
potential is obvious: sweet graphics and sound, fast and portable.
I just added a nurbs example to the massive demo. that turned out to be
a real poser because the opengl doc kinda fails to point out a fatal
gotcha when one is putting a nurb in a display list, but it said enough
that one could put two and two together.
Speaking of display lists, Cello gets ridiculous performance thanks to
those, and makes a good argument for using a powerful HLL to drive the
OpenGL library.
It turns out the dataflow paradigm of Cells meshes perfectly with the
OpenGL display-list trick, the fastest way to manage complex, changing
3D scenes: Cells automatically handle state change in complex models
optimally, and display lists likewise permit optimal scene
transformations from one frame to the next. Hellasweet.
Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
gaming is handled by the GPU, and that, where the application does get
involved, 3D performance is achieved by algorithmic tricks such as smart
culling, which any language can express... I suspect C/C++ as superior
for gaming is nowadays just holdover conventional mis-wisdom.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Cesar Rabak
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <41781E5D.4090502@acm.org>
Kenny Tilton escreveu:
[snipped]
>
> Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
> gaming is handled by the GPU, and that, where the application does
> get involved, 3D performance is achieved by algorithmic tricks such
> as smart culling, which any language can express... I suspect C/C++
> as superior for gaming is nowadays just holdover conventional
> mis-wisdom.
>
I think the only way we can bring this 20% as a tradeoff is to explain
some managers that the project cycle can be reduced in 50% by using a
more expressive language.
The problem every time I say this no one hears :-( so I can get funding
only to do things using 'proved' technologies. . .
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <46553n2j8.fsf@franz.com>
Cesar Rabak <······@acm.org> writes:
> Kenny Tilton escreveu:
> [snipped]
>
> >
> > Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
> > gaming is handled by the GPU, and that, where the application does
> > get involved, 3D performance is achieved by algorithmic tricks such
> > as smart culling, which any language can express... I suspect C/C++
> > as superior for gaming is nowadays just holdover conventional
> > mis-wisdom.
> >
> I think the only way we can bring this 20% as a tradeoff is to explain
> some managers that the project cycle can be reduced in 50% by using a
> more expressive language.
Why do you assume that the 20% has to stay? Is it a fundamental
language issue that makes C/C++ 20% faster than Lisp? Is that statement
really true, or are we just spouting truisms that we've heard?
I didn't correct Kenny on his statement, but I'll treat it with a
little more precision here, because you've accepted it as face
value. Consider Kenny's statement:
"C/C++ is only 20% faster than Lisp"
First, it is clear that C is a language that provides for very fast
operation. And, to the extent that C++ is compiling C code, it
should be able to do as well as C for C problem sets. However, most
of the benchmarks I've witnessed over the years have place Common Lisp
implementations in _faster_ positions than C++ compilers, where the
solutions require more than just rewriting a problem in C-like coding
style. Where C++ compilers are faster, it is usually because they are
compiling nothing that can't be compiled on a simple C compiler. But
start to use classes and virtual functions, and get a bad malloc/free
implemetation, and your performance is shot.
Second, Lisp is a very general term, and we tend to associate it
with Common Lisp, rather than the many dialects of Lisp (plus
domain-specific ones, especially those specifically formulated for
games, for example). Now, because of what Common Lisp is, and
how it is specified, there are some tradeoffs that we tend to make
which contributes to dynamism at the expense of speed. The challenge
is to reduce the cost of the dynamism, and for the same amount of
dynamism in C++ most CL implementations beat C++ dynamism handily
(think virtual functions, etc).
So a more realistic statement might be
"C is only 20% faster than Common Lisp"
But wait! Where did this 20% figure come from, anyway? If you
look over old comp.lang.lisp archives, you'll see a "pfannkuch"
benchmark which was thoroughly analyzed by Ken Anderson; I helped
him in his task in some capacity. See one reference to this and to
the 20% mark here:
http://groups.google.com/groups?selm=4bro5y3b9.fsf%40franz.com&output=gplain
and if we see that the number comes from a 10 or 11 instruction
benchmark, which, if the Lisp were able to reason about its
array not being gc-able it could actually knock the loop down to
9 instructions, which would be _faster_ than the C implementation!
Now, consider that the Common Lisp spec doesn't say much about
garbage-collection, and it certainly doesn't require one (though
it makes some provisions if it is there). So we can further
limit the statement down to
"C is 20% faster than traditional implementations of Common Lisp".
Now, consider a system like Naughtydog's. Andy Gavin created a
domain-specific language that was a Lisp, but which was not a
Common Lisp. I don't know of the internal architecture of this
target language, but it would not need to necessarily have a
garbage-collector (or if it did, it could have been a specific
one, like a reference-counting system or some other kind which
is also domain-specific). Or, he might have just been careful
not to cons(but regardless of what ND actually did, the concept is
still there for the experimenting). Furthermore, such a
domain-specific language is not necessarily limited to the calling
conventions or other limitations that C pose on code - those
restrictions can be lifted as if with pure assembler coding. So,
in fact, a cleverly written target language can actually be _faster_
than C, even if there is no way to improve any further on
the 10 instruction pfannkuch benchmark loops.
So I would make the bolder statement:
"C can only be as fast as its code generator allows it to be;
Lisps are suitable for generating their own code generators,
and thus are only limited by the machine code that these
generators can generate."
> The problem every time I say this no one hears :-( so I can get
> funding only to do things using 'proved' technologies. . .
Yes, I agree. This includes the Lisp community as well.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Cesar Rabak <······@acm.org> writes:
>
>
>>Kenny Tilton escreveu:
>>[snipped]
>>
>> >
>> > Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
>> > gaming is handled by the GPU, and that, where the application does
>> > get involved, 3D performance is achieved by algorithmic tricks such
>> > as smart culling, which any language can express... I suspect C/C++
>> > as superior for gaming is nowadays just holdover conventional
>> > mis-wisdom.
>> >
>>I think the only way we can bring this 20% as a tradeoff is to explain
>>some managers that the project cycle can be reduced in 50% by using a
>>more expressive language.
>
>
> Why do you assume that the 20% has to stay? Is it a fundamental
> language issue that makes C/C++ 20% faster than Lisp? Is that statement
> really true, or are we just spouting truisms that we've heard?
>
> I didn't correct Kenny on his statement, ...
Feel free. <g> I just wanted to posit a worst-case difference and make
the argument that it would be irrelevant even if true. Except that Cesar
then trumped me with the "dopey manager" card. Which is why i keep
saying, do not even worry about dopey managers or butthead coworkers or
numbskull students... the great thing about them is that they will be
screaming for Lisp training about two seconds after it becomes The
Latest Thing, and that will not be long by the look of things. Way too
many people are looking into Lisp and looking away from static
languages. Practical Common Lisp's release in 2004 (uh-oh <g>) will
really shake things up.
Maybe I should turn Cello into a games engine. I see from one of the
Roads that one of the game forums is a hotbed of Lisp advocacy. Hmmm...
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <41xfrmvim.fsf@franz.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Duane Rettig wrote:
> > Cesar Rabak <······@acm.org> writes:
> >
>
> >>Kenny Tilton escreveu:
> >>[snipped]
> >>
> >> >
> >> > Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
> >> > gaming is handled by the GPU, and that, where the application does
> >> > get involved, 3D performance is achieved by algorithmic tricks such
> >> > as smart culling, which any language can express... I suspect C/C++
> >> > as superior for gaming is nowadays just holdover conventional
> >> > mis-wisdom.
> >> >
> >>I think the only way we can bring this 20% as a tradeoff is to explain
> >>some managers that the project cycle can be reduced in 50% by using a
> >>more expressive language.
> > Why do you assume that the 20% has to stay? Is it a fundamental
>
> > language issue that makes C/C++ 20% faster than Lisp? Is that statement
> > really true, or are we just spouting truisms that we've heard?
> > I didn't correct Kenny on his statement, ...
>
>
> Feel free. <g>
OK. You asked for it :-)
> I just wanted to posit a worst-case difference and make
> the argument that it would be irrelevant even if true.
But it's not irrelevant. Oh, it may be irrelevant to you,
but when you argue with a person who claims it is relevant,
then it becomes hard to keep from talking at cross-purposes,
and even harder to convincce the other person, if he is wrong,
that it is indeed irrelevant. Catch-22.
> Except that Cesar then trumped me with the "dopey manager" card.
A powerful and deadly card, one not feared enough by us in the
Lisp community. You played a weak hand, when you should have
led with your ace.
> Which is why i
> keep saying, do not even worry about dopey managers or butthead
> coworkers or numbskull students... the great thing about them is that
> they will be screaming for Lisp training about two seconds after it
> becomes The Latest Thing, and that will not be long by the look of
> things. Way too many people are looking into Lisp and looking away
> from static languages. Practical Common Lisp's release in 2004 (uh-oh
> <g>) will really shake things up.
I will never agree to the statement that "too many" are looking
into Lisp. I know that some people really do feel that way, (i.e.
if the unwashed masses start flocking to Lisp it will somehow
become diluted) but I don't believe it for a second. Lisp's
strengths are its own, and its weaknesses are its strengths, and
no deluge will change that; we will never have "too many" Lispers.
The fact that we still have detractors still keeps us on our toes...
> Maybe I should turn Cello into a games engine. I see from one of the
> Roads that one of the game forums is a hotbed of Lisp advocacy. Hmmm...
Hmm, indeed. And?... Do we have enough gamers in the ranks?
So, now, about this 20% business; where do _you_ come up with this
number? Yes, this is a challenge; please back up your claim with
references
The bottom line is that all languages eventually get down to the
hardware, and it comes down to the same transistors turning on
and off - they switch just as fast for one language as for another;
it is just a question of how many times, which is an indicator of
how low-level your language can go. But in this bit-Lambada [sic],
people tend to confuse the ordering of things, because Lisp is usually
though of as a high-level language, and proponents of Lisp don't
like to thing in low-level terms. In fact, C is a very low-level
language, but it is surprisingly far away from the lowest level -
the machine level (note that I didn't say the assembler level; that
tends to _almost_ match the hardware, but there are sometimes assemblers
that actually can't support their own hardware, at least transiently).
Becase Lisp is a language generating language, though, it can breeze
through the entire realm; it can (and does) generate to the very bit
level that is executed. So, being both a high-level and a low-level
language, we need to honor those features of the language that allow
such to-the-metal grinding even though our own tendency is to run
away from that metal as fast as possible and layer ourselves with
higher-level concepts.
Feel free to identify or not with any portions of that last paragraph.
It is a general statement, and is not pointed at you but at our
community as a whole.
Off my soapbox, now...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Duane Rettig" <·····@franz.com> wrote in message
··················@franz.com...
>
> I will never agree to the statement that "too many" are looking
> into Lisp. I know that some people really do feel that way, (i.e.
> if the unwashed masses start flocking to Lisp it will somehow
> become diluted) but I don't believe it for a second. Lisp's
> strengths are its own, and its weaknesses are its strengths, and
> no deluge will change that; we will never have "too many" Lispers.
> The fact that we still have detractors still keeps us on our toes...
>
I respect what Kenny Tilton said about many people currently looking into
Lisp, because I respect his technical expertise and accomplishments.
Unfortunately I have not experienced the same reaction from people. Maybe he
is right (I hope he is), although Duane's point should also be taken
seriously given the fact that he is with the major commercial Lisp vendor on
the planet and knows the industry. My points remain (i) that Lisp is an
unknown (as in "exotic") and highly misunderstood language by all common
definitions of the word and (ii) that the vast majority of programmers do
not know what it even looks like if they are presented with an example on a
printed sheet of paper. From experience I am telling you that talking about
Lisp-based tool creation to the average non-initiated non-professional
programmer (say e.g. a military planner, a DSP engineer, or a molecular
biochemist) is like touting the advantages of all-wheel driving to a savage
in the mid of nowhere who has only walked on foot or at best ridden on
donkey-back. It takes a lot of fundamentals-related blablabla before one can
even bring the audience to the level that they can understand what the heck
one is talking to them about.
> The bottom line is that all languages eventually get down to the
> hardware, and it comes down to the same transistors turning on
> and off - they switch just as fast for one language as for another;
> it is just a question of how many times, which is an indicator of
> how low-level your language can go. But in this bit-Lambada [sic],
As a hardware designer that grew from microcoded bit-slice CPUs back in the
early 80's I just loooooved this "bit-Lambada" expression of yours! Did you
come up with this term or should I be giving attribution to someone else?
Neat! I mean it. :-) Have you trademarked it or what? :-)
> people tend to confuse the ordering of things, because Lisp is usually
> though of as a high-level language, and proponents of Lisp don't
> like to thing in low-level terms. In fact, C is a very low-level
> language, but it is surprisingly far away from the lowest level -
> the machine level (note that I didn't say the assembler level; that
> tends to _almost_ match the hardware, but there are sometimes assemblers
> that actually can't support their own hardware, at least transiently).
> Becase Lisp is a language generating language, though, it can breeze
> through the entire realm; it can (and does) generate to the very bit
> level that is executed. So, being both a high-level and a low-level
> language, we need to honor those features of the language that allow
> such to-the-metal grinding even though our own tendency is to run
> away from that metal as fast as possible and layer ourselves with
> higher-level concepts.
>
This is exacty the reason why in my previous message I tried to share the
VLSI design-tool background that Lisp has enabled for me. You are 100%
correct. Lisp can be used to easily simulate bit-manipulating algorithms and
generate e.g. image bit streams that you can then load into ROM for embedded
code, or even into FPGA's deciding the on-chip connectivity of logic modules
for prototype reconfigurable hardware etc. Closer than that to the metal you
cannot get!! And it is just one simple domain example from long years of
deep personal experience.
Maybe part of the issue that you allude to is that the true Lisp experts
(unlike aspiring wannabees like me) are not per definition HW-oriented
people (no reproach intended whatsoever); I believe this is a direct and
quasi-inevitable result of the fact that they do not need to be so, or at
least that they did not need to be until now. Franz ACL is par excellence
the best example that comes to my mind of a stable, successful, high-quality
product platform that runs on common-place commodity PC's generating world
class code. Back in the 80's I was involved in a classified project that
required the design of a Unibus adapter where Lisp could be offloaded from
the main CPU in order to run on a tailor-made virtual machine that was to be
running on an "accelerator board" right next to the I/O channel where
traffic was to be parsed without time to interrupt the main processor. We
used to call it (lovingly) "poor man's LMI". Guess what? Today no one in
that realm would consider things like that. Lisp runs in acceptable SW on
the humble PC at a fraction of the then overall cost.
Consequently, the real Lisp experts needed for such application work have
not been bred by the need to correlate with the underlying hardware
bidirectionally (meaning to be able to adapt the SW to the existing HW
resources and constraints, or vice versa to adapt/redesign the possible HW
platform to improve the SW performance commensurately). They are SW hackers
in the truest sense. But, just like in mathematics, there are pure and
applied mathematicians in the world and they are rarely speaking the same
language for a living, not to mention that they rarely do work in the same
building.
With full cognizance of the limitations that my poor and easily misconstrued
metaphor can imply, maybe what we need as a family of people with common
overlapping interests in the success of Lisp from both the language
design/use and the application design/implementation realms is to try to
attract more visible people and contexts from the applied side of the world.
Non-professionally programming people who can see the tangible benefits of
what an awesome tool-building tool can do for their day to day work. Not
people who program for a living that we have de facto targeted in our
debates over the last several decades.
Panos C. Lekkas
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4oeivdxae.fsf@franz.com>
"xstream" <·······@attglobal.net> writes:
> "Duane Rettig" <·····@franz.com> wrote in message
> ··················@franz.com...
> >
> > I will never agree to the statement that "too many" are looking
> > into Lisp. I know that some people really do feel that way, (i.e.
> > if the unwashed masses start flocking to Lisp it will somehow
> > become diluted) but I don't believe it for a second. Lisp's
> > strengths are its own, and its weaknesses are its strengths, and
> > no deluge will change that; we will never have "too many" Lispers.
> > The fact that we still have detractors still keeps us on our toes...
>
> I respect what Kenny Tilton said about many people currently looking into
> Lisp, because I respect his technical expertise and accomplishments.
> Unfortunately I have not experienced the same reaction from people. Maybe he
> is right (I hope he is), although Duane's point should also be taken
> seriously given the fact that he is with the major commercial Lisp vendor on
> the planet and knows the industry. My points remain (i) that Lisp is an
> unknown (as in "exotic") and highly misunderstood language by all common
> definitions of the word and (ii) that the vast majority of programmers do
> not know what it even looks like if they are presented with an example on a
> printed sheet of paper. From experience I am telling you that talking about
> Lisp-based tool creation to the average non-initiated non-professional
> programmer (say e.g. a military planner, a DSP engineer, or a molecular
> biochemist) is like touting the advantages of all-wheel driving to a savage
> in the mid of nowhere who has only walked on foot or at best ridden on
> donkey-back. It takes a lot of fundamentals-related blablabla before one can
> even bring the audience to the level that they can understand what the heck
> one is talking to them about.
Yes. I believe that the major thing that the Lisp community lacks is
a domain-specific understanding. Which domain? Pick one. Any one.
We tend to love Lisp so much, that we forget where we came from,
which makes it impossible to relate to those who are still out
in the non-lisp world and have no clue why Lisp will help them.
We need to bridge that gap.
> > The bottom line is that all languages eventually get down to the
> > hardware, and it comes down to the same transistors turning on
> > and off - they switch just as fast for one language as for another;
> > it is just a question of how many times, which is an indicator of
> > how low-level your language can go. But in this bit-Lambada [sic],
>
> As a hardware designer that grew from microcoded bit-slice CPUs back in the
> early 80's I just loooooved this "bit-Lambada" expression of yours! Did you
> come up with this term or should I be giving attribution to someone else?
> Neat! I mean it. :-) Have you trademarked it or what? :-)
I just let my mind wander on to it - as I was thinking "how low can you
go" I was thinking of "A Bug's Life", and the voice of David Ogden-Nash
popped into my head... Once I wrote it all down, though, I had to look
up its spelling in the dictionary, since it looks so much like another
familiar and endearing term.
> > people tend to confuse the ordering of things, because Lisp is usually
> > though of as a high-level language, and proponents of Lisp don't
> > like to thing in low-level terms. In fact, C is a very low-level
> > language, but it is surprisingly far away from the lowest level -
> > the machine level (note that I didn't say the assembler level; that
> > tends to _almost_ match the hardware, but there are sometimes assemblers
> > that actually can't support their own hardware, at least transiently).
> > Becase Lisp is a language generating language, though, it can breeze
> > through the entire realm; it can (and does) generate to the very bit
> > level that is executed. So, being both a high-level and a low-level
> > language, we need to honor those features of the language that allow
> > such to-the-metal grinding even though our own tendency is to run
> > away from that metal as fast as possible and layer ourselves with
> > higher-level concepts.
> >
> This is exacty the reason why in my previous message I tried to share the
> VLSI design-tool background that Lisp has enabled for me. You are 100%
> correct. Lisp can be used to easily simulate bit-manipulating algorithms and
> generate e.g. image bit streams that you can then load into ROM for embedded
> code, or even into FPGA's deciding the on-chip connectivity of logic modules
> for prototype reconfigurable hardware etc. Closer than that to the metal you
> cannot get!! And it is just one simple domain example from long years of
> deep personal experience.
This is _precisely_ the kind of expertise we need in order to promote Lisp.
Not necessarily deep Lisp expertise, but an ability to put it together
with a domain specific expertise into an explosion of productivity.
If you look at people who have made major money with Lisp, you'll find
that in almost every case that they did not win with just Lisp doing
Lispy things, but in using Lisp to solve specific problems that other
languages couldn't help them with as easily.
> Maybe part of the issue that you allude to is that the true Lisp experts
> (unlike aspiring wannabees like me) are not per definition HW-oriented
> people (no reproach intended whatsoever);
None taken; the reproach is in the result. Note that we have a _very_
strong Lisp community on general-purpose hardware, more commercial and
free versions than any other language, and we still fight for
recognition as a language that is not considered dead or arcane by others.
Why is that? Because we don't have enough hardware-oriented (or you pick
the domain) "aspiring Lisp wannabees" like yourself. The "domain" of the
current Lisp vendor community is that of GP hardware; we tend to be good
at it, and we understand how typical modern GP computers work, so we
can do a good job on these, but are not so good at specialized hardware -
there are too many of them (shall I make another movie reference? :-)
But you HW-oriented Lisp newbies can take the lisp back to your domain
and make things happen.
> I believe this is a direct and
> quasi-inevitable result of the fact that they do not need to be so, or at
> least that they did not need to be until now. Franz ACL is par excellence
> the best example that comes to my mind of a stable, successful, high-quality
> product platform that runs on common-place commodity PC's generating world
> class code.
Thank you, but that is only a testament to our expertise in our own domain.
> Back in the 80's I was involved in a classified project that
> required the design of a Unibus adapter where Lisp could be offloaded from
> the main CPU in order to run on a tailor-made virtual machine that was to be
> running on an "accelerator board" right next to the I/O channel where
> traffic was to be parsed without time to interrupt the main processor. We
> used to call it (lovingly) "poor man's LMI". Guess what? Today no one in
> that realm would consider things like that. Lisp runs in acceptable SW on
> the humble PC at a fraction of the then overall cost.
> Consequently, the real Lisp experts needed for such application work have
> not been bred by the need to correlate with the underlying hardware
> bidirectionally (meaning to be able to adapt the SW to the existing HW
> resources and constraints, or vice versa to adapt/redesign the possible HW
> platform to improve the SW performance commensurately). They are SW hackers
> in the truest sense. But, just like in mathematics, there are pure and
> applied mathematicians in the world and they are rarely speaking the same
> language for a living, not to mention that they rarely do work in the same
> building.
As a former test engineer at several hardware companies (yes, you can read
my "Road to Lisp" ...) I tend to agree, but people are becoming much more
intimate with the hardware than they once were. And, as I read back over
what I have written here, I hope nobody (especially those who are into Lisp
and have domain-specific expertise and use their Lisp for such projects)
takes what I say as disparaging. Lisp's real problem is that it is so
versatile, that there are so many areas in which it can excel, that it is
hard to build a critical mass in any one of these areas. That's why the
ILC conferences have been so exciting; they show even the most convinced
of us how many creative uses people make for Lisp, and it has helped to
generate a lot of excitement for those who feel that they are the only
ones in their field using Lisp.
> With full cognizance of the limitations that my poor and easily misconstrued
> metaphor can imply, maybe what we need as a family of people with common
> overlapping interests in the success of Lisp from both the language
> design/use and the application design/implementation realms is to try to
> attract more visible people and contexts from the applied side of the world.
> Non-professionally programming people who can see the tangible benefits of
> what an awesome tool-building tool can do for their day to day work. Not
> people who program for a living that we have de facto targeted in our
> debates over the last several decades.
Agreed, completely. We need more and more of this.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> As a former test engineer at several hardware companies (yes, you can read
> my "Road to Lisp" ...)
You mean?:
http://alu.cliki.net/Duane%20Rettig's%20Road%20To%20Lisp
Cool. It has been a while since I checked. Spotted some other new Roads,
from relatively newby-er Lispniks:
http://alu.cliki.net/Heow's%20Road%20to%20Lisp
http://alu.cliki.net/MattKnox
http://alu.cliki.net/Paul%20Potts
Roads from dinosaurs like Duane are welcome, but it would be especially
valuable to have more responses from newer newby's. Start here:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <48y9ylqns.fsf@franz.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Roads from dinosaurs like Duane are welcome,
Hey! Come on, now. Even the oldest Lisper isn't extinct, yet.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Roads from dinosaurs like Duane are welcome,
>
> Hey! Come on, now. Even the oldest Lisper isn't extinct, yet.
Neither are dinosaurs.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
xstream wrote:
> "Duane Rettig" <·····@franz.com> wrote in message
> ··················@franz.com...
>
>>I will never agree to the statement that "too many" are looking
>>into Lisp. I know that some people really do feel that way, (i.e.
>>if the unwashed masses start flocking to Lisp it will somehow
>>become diluted) but I don't believe it for a second. Lisp's
>>strengths are its own, and its weaknesses are its strengths, and
>>no deluge will change that; we will never have "too many" Lispers.
>>The fact that we still have detractors still keeps us on our toes...
>>
>
>
> I respect what Kenny Tilton said about many people currently looking into
> Lisp, because I respect his technical expertise and accomplishments.
Well, it is more a matter of spending too much time reading c.l.l. and
noticing a sea change in the number of articles that begin, "Hi, I am
new to Lisp and I was just wondering...". One only notices a trend if
one watches anything closely over a long time. i think in my first year
on c.l.l. I was the /only/ newby. Now we have one or more a day, up from
one a week a year ago. And for the last few months the acceleration has
increased, as one would expect since programmers talk to each other.
If things were dying down I would say, ok, Paul Graham caused a spike,
not a turnaround. He led a bunch of people to come look, they looked,
they left unimpressed. That ain't happenin. And since this fits with
what everyone knows to be true, viz., that Lisp is not only better but
easily recognizable as better by anyone curious enough to look, the
conclusion is ineluctable: game over. Lisp has won.
:)
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Bulent Murtezaoglu
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <871xfr9zoj.fsf@p4.internal>
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
KT> ... One only notices a trend if one watches
KT> anything closely over a long time. i think in my first year on
KT> c.l.l. I was the /only/ newby. Now we have one or more a day,
KT> up from one a week a year ago. And for the last few months the
KT> acceleration has increased, as one would expect since
KT> programmers talk to each other. ...
You're right, I've been here since 88 or 89. I think and it was pretty
much always the same people up till the late 90s, and easy usenet access
had become available earlier than that.
KT> ... And since this fits with what everyone knows to be
KT> true, viz., that Lisp is not only better but easily
KT> recognizable as better by anyone curious enough to look, the
KT> conclusion is ineluctable: game over. Lisp has won.
At least we have progressed from 'not dead' to 'has won.'
cheers,
BM
Kenny Tilton <·······@nyc.rr.com> writes:
> Well, it is more a matter of spending too much time reading c.l.l. and
> noticing a sea change in the number of articles that begin, "Hi, I am
> new to Lisp and I was just wondering...". One only notices a trend if
> one watches anything closely over a long time. i think in my first year
> on c.l.l. I was the /only/ newby. Now we have one or more a day, up from
> one a week a year ago. And for the last few months the acceleration has
> increased, as one would expect since programmers talk to each other.
I noticed that after not reading CLL for a couple days, there are 600+
articles in the spool. That is probably double from a year ago and
perhaps 2 orders of magnitude from when I first started reading CLL
regularly.
I think it's because we keep scaring the newbies. Kinda like haunted
houses. The kids are scared but they like the feeling and want to go
again. :-)
--
Fred Gilham ······@csl.sri.com
If you want to be largely ignored by women, playing jazz guitar is
pretty good strategy... --- Bob Russell
Fred Gilham wrote:
> I noticed that after not reading CLL for a couple days, there are 600+
> articles in the spool. That is probably double from a year ago and
> perhaps 2 orders of magnitude from when I first started reading CLL
> regularly.
>
> I think it's because we keep scaring the newbies. Kinda like haunted
> houses. The kids are scared but they like the feeling and want to go
> again. :-)
Right, no more newby-hugging. The CLL Fight Club is now open for
blood-letting.
Anyone know a good cut man?
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Cesar Rabak
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <41787A9E.6010406@acm.org>
Duane Rettig escreveu:
> Kenny Tilton <·······@nyc.rr.com> writes:
[snipped]
>>Feel free. <g>
>
>
> OK. You asked for it :-)
>
>
>>I just wanted to posit a worst-case difference and make
>>the argument that it would be irrelevant even if true.
>
>
> But it's not irrelevant. Oh, it may be irrelevant to you,
> but when you argue with a person who claims it is relevant,
> then it becomes hard to keep from talking at cross-purposes,
> and even harder to convincce the other person, if he is wrong,
> that it is indeed irrelevant. Catch-22.
Yes. And please folks, do not forget we normally are the novelty and the
C (or C++) technology is the incumbent.
>
>
>>Except that Cesar then trumped me with the "dopey manager" card.
>
>
> A powerful and deadly card, one not feared enough by us in the
> Lisp community. You played a weak hand, when you should have
> led with your ace.
>
And, let me add I'm just mentioning it, I'm not hiding behind a poster ;-)
Most of projects we have to justify the investments and convince people
that cannot drill so deep in these discussions.
[snipped]
>
> I will never agree to the statement that "too many" are looking
> into Lisp. I know that some people really do feel that way, (i.e.
> if the unwashed masses start flocking to Lisp it will somehow
> become diluted) but I don't believe it for a second. Lisp's
> strengths are its own, and its weaknesses are its strengths, and
> no deluge will change that; we will never have "too many" Lispers.
> The fact that we still have detractors still keeps us on our toes...
Perhaps '"too many" just look, but we ask then they repply 'they're just
browsing'?!
Also I cannot grok "...and its weaknesses are its strengths...".
>
>
>>Maybe I should turn Cello into a games engine. I see from one of the
>>Roads that one of the game forums is a hotbed of Lisp advocacy. Hmmm...
>
>
> Hmm, indeed. And?... Do we have enough gamers in the ranks?
I can guess we probably not, and we get another Catch-22?
[snipped]
> The bottom line is that all languages eventually get down to the
> hardware, and it comes down to the same transistors turning on
> and off - they switch just as fast for one language as for another;
> it is just a question of how many times, which is an indicator of
> how low-level your language can go. But in this bit-Lambada [sic],
More or less. The idea of an HLL is that it brings some kind of
additional code to create the ilusion of an abstract machine which the
bare metal does not enforce. Take, for example, dynamic typing.
There is a reasonable expectation that this service being provided by
the language runtime will ask for some additional leg swing in the
bit-Lambada (loved this one!).
> people tend to confuse the ordering of things, because Lisp is usually
> though of as a high-level language, and proponents of Lisp don't
> like to thing in low-level terms. In fact, C is a very low-level
> language, but it is surprisingly far away from the lowest level -
> the machine level (note that I didn't say the assembler level; that
> tends to _almost_ match the hardware, but there are sometimes assemblers
> that actually can't support their own hardware, at least transiently).
True indeed.
> Becase Lisp is a language generating language, though, it can breeze
> through the entire realm; it can (and does) generate to the very bit
> level that is executed. So, being both a high-level and a low-level
> language, we need to honor those features of the language that allow
> such to-the-metal grinding even though our own tendency is to run
> away from that metal as fast as possible and layer ourselves with
> higher-level concepts.
>
> Feel free to identify or not with any portions of that last paragraph.
My only clarifying question is: can we say the above is true in general?
Or put in other words, can it be conceived as reasonable that if you use
non fancy (specific) Lisp implementations nor require Lisp gurus for
programming we arrive at the results the paragraph points to?
--
Cesar Rabak
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4k6tjdvsc.fsf@franz.com>
Cesar Rabak <······@acm.org> writes:
> Duane Rettig escreveu:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> [snipped]
>
> >>Feel free. <g>
> > OK. You asked for it :-)
>
> >
>
> >>I just wanted to posit a worst-case difference and make
> >>the argument that it would be irrelevant even if true.
> > But it's not irrelevant. Oh, it may be irrelevant to you,
>
> > but when you argue with a person who claims it is relevant,
> > then it becomes hard to keep from talking at cross-purposes,
> > and even harder to convincce the other person, if he is wrong,
> > that it is indeed irrelevant. Catch-22.
>
> Yes. And please folks, do not forget we normally are the novelty and
> the C (or C++) technology is the incumbent.
Interesting. Back in 1986, when I was working at Amdahl and had
just finished porting Franz Lisp (not Allegro CL) to the 370
architecture, I would spend my lunch hour at the local Togo's
reading this new book by Stroustrup describig some new language ...
> >>Except that Cesar then trumped me with the "dopey manager" card.
> > A powerful and deadly card, one not feared enough by us in the
>
> > Lisp community. You played a weak hand, when you should have
> > led with your ace.
>
> And, let me add I'm just mentioning it, I'm not hiding behind a poster ;-)
>
> Most of projects we have to justify the investments and convince
> people that cannot drill so deep in these discussions.
Yes, that tends to be the real problem in getting these projects
approved.
> [snipped]
>
> > I will never agree to the statement that "too many" are looking
>
> > into Lisp. I know that some people really do feel that way, (i.e.
> > if the unwashed masses start flocking to Lisp it will somehow
> > become diluted) but I don't believe it for a second. Lisp's
> > strengths are its own, and its weaknesses are its strengths, and
> > no deluge will change that; we will never have "too many" Lispers.
> > The fact that we still have detractors still keeps us on our toes...
>
> Perhaps '"too many" just look, but we ask then they repply 'they're
> just browsing'?!
>
>
> Also I cannot grok "...and its weaknesses are its strengths...".
Especially for Common Lisp: its greatest strength is its generality
and its versatility - this tends to also make it invisible.
What do you hear more about; systems that are well-designed and just _work_,
or systems which have fundamental design flaws and must be constantly
fixed? Which system tends to get more money spent on it (especially
money that had not been anticipated)?
> >>Maybe I should turn Cello into a games engine. I see from one of the
> >>Roads that one of the game forums is a hotbed of Lisp advocacy. Hmmm...
> > Hmm, indeed. And?... Do we have enough gamers in the ranks?
>
>
> I can guess we probably not, and we get another Catch-22?
Perhaps; a lack of a critical mass in a specific domain, but
people understanding what can be done and doing it can build their
ranks and reach that critical mass.
> [snipped]
>
> > The bottom line is that all languages eventually get down to the
> > hardware, and it comes down to the same transistors turning on
> > and off - they switch just as fast for one language as for another;
> > it is just a question of how many times, which is an indicator of
> > how low-level your language can go. But in this bit-Lambada [sic],
>
> More or less. The idea of an HLL is that it brings some kind of
> additional code to create the ilusion of an abstract machine which the
> bare metal does not enforce. Take, for example, dynamic typing.
Yes; any extensible language will bring that "height". The question
is whether it loses sight of its lower regions, or whether that height
can be used to in fact get back down to the low-level. At my previous
company, I was amazed to see very few labs in the hardware-design
departments; they used software almost exclusively to design, simulate,
and build their hardware. (and they put gates, logic components, and
subsystems together in software with constructs they call ... macros!
> There is a reasonable expectation that this service being provided by
> the language runtime will ask for some additional leg swing in the
> bit-Lambada (loved this one!).
Well, I have no doubts that Lisp systems won't be able to squeeze
themselves as thin as paper to get under the bar, but I also have no
doubts that Lisp systems can manufacture paper that can then be slipped
under.
> > Becase Lisp is a language generating language, though, it can breeze
> > through the entire realm; it can (and does) generate to the very bit
> > level that is executed. So, being both a high-level and a low-level
> > language, we need to honor those features of the language that allow
> > such to-the-metal grinding even though our own tendency is to run
> > away from that metal as fast as possible and layer ourselves with
> > higher-level concepts.
> > Feel free to identify or not with any portions of that last
> > paragraph.
>
>
> My only clarifying question is: can we say the above is true in
> general? Or put in other words, can it be conceived as reasonable that
> if you use non fancy (specific) Lisp implementations nor require Lisp
> gurus for programming we arrive at the results the paragraph points to?
You speak of gurus, and yet if you've done any Lisp programming at
all, you've done some of it. Have you ever created a macro? What was
it for? If it was just to hide things, or to allow less typing, then
that's not it. But if it was to congeal a concept into something that
can be thought of in a way closer to the problem your program was trying
to solve, then you took a tiny step toward domain-specific extension.
Moving the modelling back down toward the hardware takes a little more
patience, planning, and art, but it is just an extension of what you've
done.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Duane Rettig wrote:
>>
>>>Cesar Rabak <······@acm.org> writes:
>>>
>>
>>>>Kenny Tilton escreveu:
>>>>[snipped]
>>>>
>>>>
>>>>>Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
>>>>> gaming is handled by the GPU, and that, where the application does
>>>>>get involved, 3D performance is achieved by algorithmic tricks such
>>>>>as smart culling, which any language can express... I suspect C/C++
>>>>>as superior for gaming is nowadays just holdover conventional
>>>>>mis-wisdom.
>>>>>
>>>>
>>>>I think the only way we can bring this 20% as a tradeoff is to explain
>>>>some managers that the project cycle can be reduced in 50% by using a
>>>>more expressive language.
>>>
>>>Why do you assume that the 20% has to stay? Is it a fundamental
>>
>>>language issue that makes C/C++ 20% faster than Lisp? Is that statement
>>>really true, or are we just spouting truisms that we've heard?
>>>I didn't correct Kenny on his statement, ...
>>
>>
>>Feel free. <g>
>
>
> OK. You asked for it :-)
>
>
>>I just wanted to posit a worst-case difference and make
>>the argument that it would be irrelevant even if true.
>
>
> But it's not irrelevant. Oh, it may be irrelevant to you,
> but when you argue with a person who claims it is relevant,
> then it becomes hard to keep from talking at cross-purposes,
> and even harder to convincce the other person, if he is wrong,
> that it is indeed irrelevant. Catch-22.
Tee-hee. Usenet Debating Theory 101? Nonsense, one does not try to get
through to anyone in a usenet discussion, one simply presents better
information in case some lurker is looking at Lisp for game development.
btw, the flaw in your otherwise impeccably reasoned recommendation to
confront the error head-on is thinking that the other person is
intellectually honest and will respond to reason. No one is, no one does.
But it is great having you /also/ cover the base by documenting that
Lisp is /not/ slower than C. It's all good.
>
>
>>Except that Cesar then trumped me with the "dopey manager" card.
>
>
> A powerful and deadly card, one not feared enough by us in the
> Lisp community. You played a weak hand, when you should have
> led with your ace.
>
>
>>Which is why i
>>keep saying, do not even worry about dopey managers or butthead
>>coworkers or numbskull students... the great thing about them is that
>>they will be screaming for Lisp training about two seconds after it
>>becomes The Latest Thing, and that will not be long by the look of
>>things. Way too many people are looking into Lisp and looking away
>>from static languages. Practical Common Lisp's release in 2004 (uh-oh
>><g>) will really shake things up.
>
>
> I will never agree to the statement that "too many" are looking
> into Lisp.
<g> You missed the implicit ending: "...for Lisp not to become the
latest thing."
> So, now, about this 20% business; where do _you_ come up with this
> number? Yes, this is a challenge; please back up your claim with
> references
Just the greatest living expert on Lisp compiler technology:
"As for why Lisp's runtime environment tends to be about 20% slower
than C's: it's the GC." -- Duane Rettig, 2004-02-11, c.l.l.
You asked for it. :)
kt
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4sm87dzi5.fsf@franz.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Duane Rettig wrote:
>
> > So, now, about this 20% business; where do _you_ come up with this
> > number? Yes, this is a challenge; please back up your claim with
> > references
>
> Just the greatest living expert on Lisp compiler technology:
>
> "As for why Lisp's runtime environment tends to be about 20% slower
> than C's: it's the GC." -- Duane Rettig, 2004-02-11, c.l.l.
>
> You asked for it. :)
Errp. Well, I was hoping for other references; now I have to blame
myself for that number :-(
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Duane Rettig wrote:
>>
>>
>>>So, now, about this 20% business; where do _you_ come up with this
>>>number? Yes, this is a challenge; please back up your claim with
>>>references
>>
>>Just the greatest living expert on Lisp compiler technology:
>>
>>"As for why Lisp's runtime environment tends to be about 20% slower
>>than C's: it's the GC." -- Duane Rettig, 2004-02-11, c.l.l.
>>
>>You asked for it. :)
>
>
> Errp. Well, I was hoping for other references; ...
Well, earlier in the same article you also stipulated that "conventional
wisdom" also had the 20% number, without slamming the CW. And I do
recall a Lisp (and other languages) vs C benchmark often cited here on
c.l.l., but for the life of me could not google it. That showed various
deltas on different tests, with +20% looking like a rough net result.
I did run into the Grabriel benchmarks, of course. But I did not see a
column for gcc.
> Errp. Well, I was hoping for other references; now I have to blame
> myself for that number :-(
Your penance is to code the Gabriel benchmarks in C and provide a new
number. Nah, benchmarks have dubious real-world relevance. So maybe your
penance is to join the Cello team and help build the ultimate game engine.
:)
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> Well, earlier in the same article you also stipulated that
> "conventional wisdom" also had the 20% number, without slamming the
> CW. And I do recall a Lisp (and other languages) vs C benchmark often
> cited here on c.l.l., but for the life of me could not google it. That
> showed various deltas on different tests, with +20% looking like a
> rough net result.
Just as an additional data point: I have this numerical code I wrote,
and while I optimized here and there some things, I got it to run at
quite a satisfactory speed (on cmucl) without investing too much
effort. One of the things I "saved" for later optimization was GC
usage. It turns out that while the code conses /a lot/, less than 2%
of the time is spent doing garbage collection.
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4oeiu3050.fsf@franz.com>
Mario S. Mommer <········@yahoo.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
> > Well, earlier in the same article you also stipulated that
> > "conventional wisdom" also had the 20% number, without slamming the
> > CW. And I do recall a Lisp (and other languages) vs C benchmark often
> > cited here on c.l.l., but for the life of me could not google it. That
> > showed various deltas on different tests, with +20% looking like a
> > rough net result.
>
> Just as an additional data point: I have this numerical code I wrote,
> and while I optimized here and there some things, I got it to run at
> quite a satisfactory speed (on cmucl) without investing too much
> effort. One of the things I "saved" for later optimization was GC
> usage. It turns out that while the code conses /a lot/, less than 2%
> of the time is spent doing garbage collection.
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).
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Edi Weitz
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <uis92xuks.fsf@agharta.de>
On 22 Oct 2004 14:37:15 -0700, Duane Rettig <·····@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 ·········@agharta.de" 5) "edi")
From: Frode Vatvedt Fjeld
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <2hbreu74x9.fsf@vserver.cs.uit.no>
Edi Weitz <········@agharta.de> writes:
> [..] 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... :)
I think what you really mean is that you'll still love your copying,
non-conservative garbage collector even if it can't deal with the
situation you described. Because that's what's restricting the
compiler's output, not the Common Lisp language as such. If you can
have conservative garbage collectors for C, then certainly you can do
the same with Lisp.
--
Frode Vatvedt Fjeld
From: Edi Weitz
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <uacuefguc.fsf@agharta.de>
On Sat, 23 Oct 2004 00:40:18 +0200, Frode Vatvedt Fjeld <······@cs.uit.no> wrote:
> I think what you really mean is that you'll still love your copying,
> non-conservative garbage collector even if it can't deal with the
> situation you described. Because that's what's restricting the
> compiler's output, not the Common Lisp language as such. If you can
> have conservative garbage collectors for C, then certainly you can
> do the same with Lisp.
OK, but can you do it with ANSI-compliant CL? AFAIK the only way to
access an array element is AREF (or SVREF or CHAR) which needs an
integer index. At the moment I can only imagine
a) an implementation which has some "non-standard" expansion of
LOOP-ACROSS,
b) an implementation which provides a DO-SEQUENCE facility that does
some extra stuff, or
c) a very smart compiler which'll figure out from your looping
constructs that you actually don't need the integer X because it's
only used in places like (AREF ARR X).
Am I missing something?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Christophe Rhodes
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <sqwtxhvoa9.fsf@cam.ac.uk>
Edi Weitz <········@agharta.de> writes:
> c) a very smart compiler which'll figure out from your looping
> constructs that you actually don't need the integer X because it's
> only used in places like (AREF ARR X).
>
> Am I missing something?
Just that (c) isn't actually that hard. It's hard in the sense that
it's been on my TODO list for years, but it hasn't been done more
because it would take a lot of time than because of any conceptual
difficulties. (Similar priorities probably occurred in gcc -- which
has way more manpower -- development: only very recently have they
merged a compiler branch which uses a representation of variables
conducive to that kind of analysis: look up "Static Single Assignment"
in your nearest compiler textbook for plenty of discussion).
Christophe
From: Edi Weitz
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <u3c05omvk.fsf@agharta.de>
On Sat, 23 Oct 2004 08:23:33 GMT, Christophe Rhodes <·····@cam.ac.uk> wrote:
> Just that (c) isn't actually that hard. It's hard in the sense that
> it's been on my TODO list for years, but it hasn't been done more
> because it would take a lot of time than because of any conceptual
> difficulties.
A lot of time during compilation or a lot of development time for the
implementor?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Christophe Rhodes
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <sqsm85v8d3.fsf@cam.ac.uk>
Edi Weitz <········@agharta.de> writes:
> On Sat, 23 Oct 2004 08:23:33 GMT, Christophe Rhodes <·····@cam.ac.uk> wrote:
>
>> Just that (c) isn't actually that hard. It's hard in the sense that
>> it's been on my TODO list for years, but it hasn't been done more
>> because it would take a lot of time than because of any conceptual
>> difficulties.
>
> A lot of time during compilation or a lot of development time for the
> implementor?
The latter. The former as well, slightly, but not excessively, and
users can be encouraged to use a higher optimization setting for
COMPILATION-SPEED if they need, well, compilation speed :)
Christophe
Edi Weitz wrote:
> On Sat, 23 Oct 2004 00:40:18 +0200, Frode Vatvedt Fjeld <······@cs.uit.no> wrote:
>
>
>>I think what you really mean is that you'll still love your copying,
>>non-conservative garbage collector even if it can't deal with the
>>situation you described. Because that's what's restricting the
>>compiler's output, not the Common Lisp language as such. If you can
>>have conservative garbage collectors for C, then certainly you can
>>do the same with Lisp.
>
>
> OK, but can you do it with ANSI-compliant CL? AFAIK the only way to
> access an array element is AREF (or SVREF or CHAR) which needs an
> integer index. At the moment I can only imagine
>
> a) an implementation which has some "non-standard" expansion of
> LOOP-ACROSS,
>
> b) an implementation which provides a DO-SEQUENCE facility that does
> some extra stuff, or
>
> c) a very smart compiler which'll figure out from your looping
> constructs that you actually don't need the integer X because it's
> only used in places like (AREF ARR X).
>
> Am I missing something?
the compiler doesn't have to be all that smart. it is a standard
optimization (e.g. most C compilers would, with the right optimization
level, produce the same code for your example if you had written it with
subscripting). the only thing that is a problem with CL is the
interaction with the garbage collector, but a possible optimization
would be to transform the code to use offsets from the array start
rather than the original code resulting from the (aref a i) form
hs
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4y8hwmvbs.fsf@franz.com>
Edi Weitz <········@agharta.de> writes:
> On 22 Oct 2004 14:37:15 -0700, Duane Rettig <·····@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).
"Enough declarations" is the key phrase. How many declarations
might it take to tell the compiler that a form is to be executed
without intervention from the gc? [Answer: perhaps 1]
> Does this happen in practice somewhere? Does it happen or can it
> happen if I wrap the loop with something like WITHOUT-GC?
It doesn't happen that I know of (certainly not in Allegro CL).
The answer to "can it happen?" is "yes". When the pfannkuch
benchmark was originally being discussed (it was mid-90s, but I
have no references), I posited the idea that Allegro CL's
excl:atomically macro could serve this purpose. When you wrap a form
with (excl:atomically ...), then if it compiles, the compiler has in
fact guaranteed to you (under normal operating circumstances) that
there will be no interrupts, scheduler breaks, or gcs within that
form. It is similar to a without-interrupts form, but adds gc inhibition
to the mix, and it does not require the binding of a special variable to
accomplish the job. There would be work involved on our part to
recognize specific compilation strategies that culd be rewritten under
these circumstances. The specific kinds of rewriting would really
depend on customers' feedback, since we would need to know that such
an optimization would truly be useful. But in those 8 to 10 years,
we've received no such feedback; our customers have indeed never
needed to reduce a pfannkuch loop from 10 instructions to 9
instructions, or even in any similar situation where it would help.
What we do find is that most of our customers adhere to the "profile
and selectively optimize" rule of thumb, which is by far the optimizing
technique that makes the most business sense, and we are able to help
them to get to acceptable performance levels; it also gives the most
return on investment by not wasting time and money on things that don't
make or break the app. I'm certain that if the acceptability bar is
lowered (think Lambada, again) and this kind of loop were to come up,
we would of course consider it. So far, though, it hasn't come up.
> 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?
I don't know. It seems your question is hypothetical, though, and
since the answer to your other question is "yes, it could be done",
I don't think it is yet a problem for either you or me.
> 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... :)
Right; the bottom line is priorities, and so far this one's number
hasn't come up to the top.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Frode Vatvedt Fjeld
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <2hfz445ofn.fsf@vserver.cs.uit.no>
Duane Rettig <·····@franz.com> writes:
> [..] But in those 8 to 10 years, we've received no such feedback;
> our customers have indeed never needed to reduce a pfannkuch loop
> from 10 instructions to 9 instructions, or even in any similar
> situation where it would help. [..]
Related to this I suspect is the current high-performace CPU
architectures. It's my impression that they spend a lot of silicon to
remove the same preformance overheads that we accout to this register
pressure etc. What I'm trying to say is that it's perhaps not anymore
very obvious that there is a real performance benefit in using such
raw pointers?
--
Frode Vatvedt Fjeld
Duane Rettig wrote:
[Mario Mommer:]
> > Just as an additional data point: I have this numerical code I wrote,
> > and while I optimized here and there some things, I got it to run at
> > quite a satisfactory speed (on cmucl) without investing too much
> > effort. One of the things I "saved" for later optimization was GC
> > usage. It turns out that while the code conses /a lot/, less than 2%
> > of the time is spent doing garbage collection.
[Duane:]
> 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).
I suspect that both effects might sometimes be swamped by
an even more indirect effect of GC, namely what it does to
locality of reference. Which may vary enormously depending
on the GC...
--
Gareth McCaughan
.sig under construc
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4u0skmujc.fsf@franz.com>
Gareth McCaughan <················@pobox.com> writes:
> Duane Rettig wrote:
>
> [Mario Mommer:]
> > > Just as an additional data point: I have this numerical code I wrote,
> > > and while I optimized here and there some things, I got it to run at
> > > quite a satisfactory speed (on cmucl) without investing too much
> > > effort. One of the things I "saved" for later optimization was GC
> > > usage. It turns out that while the code conses /a lot/, less than 2%
> > > of the time is spent doing garbage collection.
>
> [Duane:]
> > 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).
>
> I suspect that both effects might sometimes be swamped by
> an even more indirect effect of GC, namely what it does to
> locality of reference. Which may vary enormously depending
> on the GC...
The effect that locality of reference has on the performance
depends on whether the gc is actually run or not - if the gc
is run, then of course it moves data and has some negative effect
on paging and cached data. but if the gc is not run within the
loop, then it has no effect, and the entire 20% is due to the extra
instruction or two within that tight loop. Register pressure will
only affect that loop if the registers spill to the stack, and
there may be some slight cycle-count advantage of addressing via
one register over addressing via two registers (i.e. a base and an
index register), but it will not affect paging or caching, because
the same memory is being touched using either technique.
One final point: the x86 (and AMD64) have an advantage over RISC
architectures, in that addressing modes include one where three
components are used - a base register, an index register, and a
displacement (a small integer), whereas the RISC architectures
tend to give base/disp addressing modes, or sometimes base/index
addressing modes, but not a mode with all three; this becomes
important because the pointers that the gc wants to see need to be
tagged, and that thus requires an offset from the tagged array
to any one data item. So in general, RISC architectures require
two instructions in some situations where x86/AMD64 require only
one.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Svein Ove Aas
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <clg14d$mb5$4@services.kq.no>
Duane Rettig wrote:
> One final point: the x86 (and AMD64) have an advantage over RISC
> architectures, in that addressing modes include one where three
> components are used - a base register, an index register, and a
> displacement (a small integer), whereas the RISC architectures
> tend to give base/disp addressing modes, or sometimes base/index
> addressing modes, but not a mode with all three; this becomes
> important because the pointers that the gc wants to see need to be
> tagged, and that thus requires an offset from the tagged array
> to any one data item. So in general, RISC architectures require
> two instructions in some situations where x86/AMD64 require only
> one.
>
Is that right?
I seem to remember that the mode bits in question are base, index and scale,
the latter of which does come in handy but can hardly be called
displacement.
Am I overlooking something here, or can it somehow be used in the manner you
describe?
From: Kalle Olavi Niemitalo
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87wtxg6syw.fsf@Astalo.kon.iki.fi>
Svein Ove Aas <·········@aas.no> writes:
> I seem to remember that the mode bits in question are base, index and scale,
> the latter of which does come in handy but can hardly be called
> displacement.
i386 supports a [base + (index * scale) + displacement]
addressing mode, e.g. [EAX + EBX*8 - 3].
From: Joe Marshall
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4qkiwxfj.fsf@ccs.neu.edu>
Mario S. Mommer <········@yahoo.com> writes:
> One of the things I "saved" for later optimization was GC
> usage. It turns out that while the code conses /a lot/, less than 2%
> of the time is spent doing garbage collection.
If the generational GC is properly tuned and is using an algorithm
that runs in time proportional to the amount of live storage (as most
do), then `consing garbage' has a fairly negligible cost.
Allocating storage is very cheap. Retaining storage, however, is
expensive.
On Thu, 21 Oct 2004 23:38:16 +0000, Kenny Tilton wrote:
>
> Maybe I should turn Cello into a games engine. I see from one of the
> Roads that one of the game forums is a hotbed of Lisp advocacy. Hmmm...
That'd be very cool - I'd love a job hacking games almost as much as I'd
love a job hacking Lisp. A job hacking games in Lisp would be my idea
of heaven.
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
From: Dirk Gerrits
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87brevgoon.fsf@dirkgerrits.com>
William Bland <·······@abstractnonsense.com> writes:
> On Thu, 21 Oct 2004 23:38:16 +0000, Kenny Tilton wrote:
>>
>> Maybe I should turn Cello into a games engine. I see from one of the
>> Roads that one of the game forums is a hotbed of Lisp advocacy. Hmmm...
>
> That'd be very cool - I'd love a job hacking games ...
In theory, I would too, but then I remember that involves doing C++
60-80 hours per week.
> ... almost as much as I'd love a job hacking Lisp. A job hacking games in
> Lisp would be my idea of heaven.
Now *that* would rock. :)
Kind regards,
Dirk Gerrits
From: Cesar Rabak
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <41787647.3020600@acm.org>
Duane Rettig escreveu:
> Cesar Rabak <······@acm.org> writes:
>
>
>>Kenny Tilton escreveu:
>>[snipped]
>>
>> >
>> > Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
>> > gaming is handled by the GPU, and that, where the application does
>> > get involved, 3D performance is achieved by algorithmic tricks such
>> > as smart culling, which any language can express... I suspect C/C++
>> > as superior for gaming is nowadays just holdover conventional
>> > mis-wisdom.
>> >
>>I think the only way we can bring this 20% as a tradeoff is to explain
>>some managers that the project cycle can be reduced in 50% by using a
>>more expressive language.
>
>
> Why do you assume that the 20% has to stay? Is it a fundamental
> language issue that makes C/C++ 20% faster than Lisp? Is that statement
> really true, or are we just spouting truisms that we've heard?
I cannot assume of course that came to stay, but I also cannot find
support for the trend is on the other way around. . .
IIRC from the thread where the issue of 'benchmarking' C versus Lisp, in
some cases it was possible to beat the C compiled version, but when took
against the best C version, still we got a slower Lisp program.
>
> I didn't correct Kenny on his statement, but I'll treat it with a
> little more precision here, because you've accepted it as face
> value. Consider Kenny's statement:
>
> "C/C++ is only 20% faster than Lisp"
OK. I think this was said in a more lay way as "in the average", or it
can be expected that w/o having to think too much in the way of writing
your code...
>
> First, it is clear that C is a language that provides for very fast
> operation. And, to the extent that C++ is compiling C code, it
> should be able to do as well as C for C problem sets. However, most
Yes. Also it is a 'perceived truth' as much as we can hate this vicious
generalization. And do not forget we get from times to times people
asking why (for example) CLISP does not compile to 'native' binary.
> of the benchmarks I've witnessed over the years have place Common Lisp
> implementations in _faster_ positions than C++ compilers, where the
> solutions require more than just rewriting a problem in C-like coding
> style. Where C++ compilers are faster, it is usually because they are
> compiling nothing that can't be compiled on a simple C compiler. But
> start to use classes and virtual functions, and get a bad malloc/free
> implemetation, and your performance is shot.
You have an intersting point here, and I'm afraid this is somewhat we
let go though until we are at it: C and C++ are different languages.
>
> Second, Lisp is a very general term, and we tend to associate it
> with Common Lisp, rather than the many dialects of Lisp (plus
> domain-specific ones, especially those specifically formulated for
> games, for example). Now, because of what Common Lisp is, and
Fair as well. The question is that also these assertions are also in
general. If we go to the extremes, the winning Intel compiler can be
considered a 'domain' (if at least for the chip :-) specific.
> how it is specified, there are some tradeoffs that we tend to make
> which contributes to dynamism at the expense of speed. The challenge
> is to reduce the cost of the dynamism, and for the same amount of
> dynamism in C++ most CL implementations beat C++ dynamism handily
> (think virtual functions, etc).
>
Yes.
> So a more realistic statement might be
>
> "C is only 20% faster than Common Lisp"
>
> But wait! Where did this 20% figure come from, anyway? If you
> look over old comp.lang.lisp archives, you'll see a "pfannkuch"
> benchmark which was thoroughly analyzed by Ken Anderson; I helped
> him in his task in some capacity. See one reference to this and to
> the 20% mark here:
>
> http://groups.google.com/groups?selm=4bro5y3b9.fsf%40franz.com&output=gplain
>
I could remember of another thread (IIRC it helped you to find a spot to
optimize/fix something w/Allegro isn't it?) on some 'challenge' on a
code in C.
> and if we see that the number comes from a 10 or 11 instruction
> benchmark, which, if the Lisp were able to reason about its
> array not being gc-able it could actually knock the loop down to
> 9 instructions, which would be _faster_ than the C implementation!
>
> Now, consider that the Common Lisp spec doesn't say much about
> garbage-collection, and it certainly doesn't require one (though
> it makes some provisions if it is there). So we can further
> limit the statement down to
>
> "C is 20% faster than traditional implementations of Common Lisp".
YES. Now it only remain to find the converse. In order to make a point
to change to Lisp, we need the phrase above have the two programming
languages reversed, otherwise, why change?
>
> Now, consider a system like Naughtydog's. Andy Gavin created a
> domain-specific language that was a Lisp, but which was not a
> Common Lisp. I don't know of the internal architecture of this
> target language, but it would not need to necessarily have a
> garbage-collector (or if it did, it could have been a specific
> one, like a reference-counting system or some other kind which
> is also domain-specific). Or, he might have just been careful
> not to cons(but regardless of what ND actually did, the concept is
> still there for the experimenting). Furthermore, such a
> domain-specific language is not necessarily limited to the calling
> conventions or other limitations that C pose on code - those
> restrictions can be lifted as if with pure assembler coding. So,
> in fact, a cleverly written target language can actually be _faster_
> than C, even if there is no way to improve any further on
> the 10 instruction pfannkuch benchmark loops.
>
> So I would make the bolder statement:
>
> "C can only be as fast as its code generator allows it to be;
> Lisps are suitable for generating their own code generators,
> and thus are only limited by the machine code that these
> generators can generate."
>
Bold and arousing!
>
>>The problem every time I say this no one hears :-( so I can get
>>funding only to do things using 'proved' technologies. . .
>
>
> Yes, I agree. This includes the Lisp community as well.
>
Thanks for hearing and helping me to find more points to fight this
specific kind of prejudice.
From: André Thieme
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <clh32v$82a$1@ulric.tng.de>
Duane Rettig schrieb:
> Now, consider that the Common Lisp spec doesn't say much about
> garbage-collection, and it certainly doesn't require one (though
> it makes some provisions if it is there). So we can further
> limit the statement down to
>
> "C is 20% faster than traditional implementations of Common Lisp".
>
> Now, consider a system like Naughtydog's. Andy Gavin created a
> domain-specific language that was a Lisp, but which was not a
> Common Lisp.
And what do you think about the idea to program a game mostly in Common
Lisp and optimize some parts by using C?
The advantage I see is that this technique is faster available. You can
directly start to program your game and don't need to think about
creating a new Lisp, test it, etc...
Andr�
--
From: Duane Rettig
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4is8zyclw.fsf@franz.com>
Andr� Thieme <······························@justmail.de> writes:
> Duane Rettig schrieb:
>
> > Now, consider that the Common Lisp spec doesn't say much about
> > garbage-collection, and it certainly doesn't require one (though
> > it makes some provisions if it is there). So we can further
> > limit the statement down to
> > "C is 20% faster than traditional implementations of Common Lisp".
>
> > Now, consider a system like Naughtydog's. Andy Gavin created a
>
> > domain-specific language that was a Lisp, but which was not a
> > Common Lisp.
>
> And what do you think about the idea to program a game mostly in
> Common Lisp and optimize some parts by using C?
Well, that is certainly one approach, but if you're wanting to squeeze
out every last cycle, why not go directly to assembler for that, and
get _every_ last cycle?
> The advantage I see is that this technique is faster available. You
> can directly start to program your game and don't need to think about
> creating a new Lisp, test it, etc...
Some lisps have direct support for assembler code generation, and others
have similar support that is indirect. You'd have to contact your
vendor for info.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Kenny Tilton <·······@nyc.rr.com> writes:
> Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
> gaming is handled by the GPU, and that, where the application does get
> involved, 3D performance is achieved by algorithmic tricks such as smart
> culling, which any language can express... I suspect C/C++ as superior
> for gaming is nowadays just holdover conventional mis-wisdom.
I think smart pointers are going to seriously erode what advantage C++
still has over Lisp. For those who don't know, C++ smart pointers are
various hacks to solve the deallocation/ownership problems you get
when you have no gc. Usually, this means some sort of reference
counting. Yes, ref counting. It's nice to be able to almost act like
you have a gc, but even a mediocre gc would perform better. And if
you have cyclic structures, you get *really* bad performance, or
memory leaks. I bet if I rewrote this C++ code I'm working on in
Lisp, it'd see a performance improvement.
From: Joe Marshall
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <zn2avhw3.fsf@ccs.neu.edu>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Given that C/C++ is only 20% faster than Lisp, and that so much in 3D
>> gaming is handled by the GPU, and that, where the application does get
>> involved, 3D performance is achieved by algorithmic tricks such as smart
>> culling, which any language can express... I suspect C/C++ as superior
>> for gaming is nowadays just holdover conventional mis-wisdom.
>
> I think smart pointers are going to seriously erode what advantage C++
> still has over Lisp. For those who don't know, C++ smart pointers are
> various hacks to solve the deallocation/ownership problems you get
> when you have no gc. Usually, this means some sort of reference
> counting. Yes, ref counting. It's nice to be able to almost act like
> you have a gc, but even a mediocre gc would perform better. And if
> you have cyclic structures, you get *really* bad performance, or
> memory leaks. I bet if I rewrote this C++ code I'm working on in
> Lisp, it'd see a performance improvement.
It gets worse.
C++ objects are `poor man's closures' (attributed to Norman Adams).
But C++ compilers are nowhere *near* as smart as Lisp compilers when
it comes to closures. A decent Lisp compiler can take code like this:
(map 'list
(lambda (x) (if (foo x) (bar x) (quux x)))
(compute-some-list))
and do the obvious inlining.
Now suppose you did the same thing in C++ using a `visitor' pattern.
You'll find that C++ doesn't optimize a thing and that every call to
the `visitor' goes through the out-of-line indirect call via the
virtual function table.
Kenny Tilton <·······@nyc.rr.com> wrote
> display lists likewise permit optimal scene transformations from one frame to the next. Hellasweet.
Could you tell me how you're using display lists this way? I'm very new to OpenGL.
Thanks.
Manuel
Manuel Simoni wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote
>
>
>>display lists likewise permit optimal scene transformations from one frame to the next. Hellasweet.
>
>
> Could you tell me how you're using display lists this way? I'm very new to OpenGL.
> Thanks.
I am learning OpenGL myself, so take everything I say with a grain of
salt. The whole quote was:
"It turns out the dataflow paradigm of Cells meshes perfectly with the
OpenGL display-list trick, the fastest way to manage complex, changing
3D scenes: Cells automatically handle state change in complex models
optimally, and display lists likewise permit optimal scene
transformations from one frame to the next. Hellasweet."
I mention that because I am not sure if you are talking about the whole
quote or just the display list trick. I will assume the latter.
Background: A display list is effectively a compilation of a sequence of
Opengl calls into a named (by a numeric ID, in fact) object, if you
will. That lets me re-execute those instructions by simply giving opengl
the ID. My application code to make each OpenGL call (including deciding
which calls to make and what values to pass) does not have to run, and
instead of more or less info being sent down the pipeline I just send
one number, the display list ID.
Set-up: Now Suppose there are two things A and B in a room R. OpenGL
lets me create a display list for A, and then a display list for B, and
then build a display list for R by drawing the floor and walls and then
rendering A and B within the room by simply calling their display lists,
after transforming the model matrix to position each.
OK, call the list for R and now we have R drawn with A and B in place.
Now suppose A wants to be a different color in the next frame.
The trick: I just have to rebuild the display list for A. The next time
I redraw the room by calling the display list for R, that list
eventually invokes (by ID!) the display list for A, which now includes a
new instruction for the color along with all the other instructions for
rendering A.
Note that if I want to /move/ A but not change its color, then I do not
have to rebuild its display list, I have to rebuild R's, because the
transformations to position A are executed by the rendering of R just
before calling the display list for A, and so go into R's display list.
ie, just as a scene is a tree of things, and things are a tree of parts,
and parts are trees of other parts, the rendering of a scene can be a
tree of nested calls by ID to display lists, so by using display lists
for everything one can revise a scene by revising the absolute minimum
of display lists.
The cool thing is how this maps onto cells. Somewhat simplified:
(defmodel opengl-node ()
((display-list :reader display-list
:initform (c-formula (:lazy :until-asked)
(ogl-dsp-list-prep self)
(every 'display-list (kids self))
(let ((display-list-name (or .cache (gl-gen-lists 1))))
(gl-new-list display-list-name gl_compile)
(ix-paint self) ;; <== bingo
(gl-end-list)
(setf (redisplayp *window-rendering*) t)
display-list-name))))
Whatever variables are sampled during the call to ix-paint affect the
rendering of this scene graph node. (I should not be sampling irrelevant
variables just for the fun of it.) The Cells engine keeps track of which
other variables are sampled. So no matter what state change occurs,
triggered by a mouse movement or click or other OS event including time
passing, all and only those display lists necessary to manifest the new
state of the world will get rebuilt, and a redraw for the window will
get kicked off.
Anyone who has managed update events in typical GUI environments is now
jumping and down screaming. :)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·····················@twister.nyc.rr.com>...
> Manuel Simoni wrote:
>
> > Kenny Tilton <·······@nyc.rr.com> wrote
> >
> >
> >>display lists likewise permit optimal scene transformations from one frame to the next. Hellasweet.
> >
> >
> > Could you tell me how you're using display lists this way? I'm very new to OpenGL.
> > Thanks.
>
> I am learning OpenGL myself, so take everything I say with a grain of
> salt. The whole quote was:
>
> "It turns out the dataflow paradigm of Cells meshes perfectly with the
> OpenGL display-list trick, the fastest way to manage complex, changing
> 3D scenes: Cells automatically handle state change in complex models
> optimally, and display lists likewise permit optimal scene
> transformations from one frame to the next. Hellasweet."
>
> I mention that because I am not sure if you are talking about the whole
> quote or just the display list trick. I will assume the latter.
Yeah, I'm working on a dataflow/forward-inference package myself, so I
already know that dataflow is the hype when it comes to user
interfaces and graphics.
> Background: A display list is effectively a compilation of a sequence of
> Opengl calls into a named (by a numeric ID, in fact) object, if you
> will. That lets me re-execute those instructions by simply giving opengl
> the ID. My application code to make each OpenGL call (including deciding
> which calls to make and what values to pass) does not have to run, and
> instead of more or less info being sent down the pipeline I just send
> one number, the display list ID.
>
> Set-up: Now Suppose there are two things A and B in a room R. OpenGL
> lets me create a display list for A, and then a display list for B, and
> then build a display list for R by drawing the floor and walls and then
> rendering A and B within the room by simply calling their display lists,
> after transforming the model matrix to position each.
>
> OK, call the list for R and now we have R drawn with A and B in place.
> Now suppose A wants to be a different color in the next frame.
>
> The trick: I just have to rebuild the display list for A. The next time
> I redraw the room by calling the display list for R, that list
> eventually invokes (by ID!) the display list for A, which now includes a
> new instruction for the color along with all the other instructions for
> rendering A.
Ah, great.
> Note that if I want to /move/ A but not change its color, then I do not
> have to rebuild its display list, I have to rebuild R's, because the
> transformations to position A are executed by the rendering of R just
> before calling the display list for A, and so go into R's display list.
>
> ie, just as a scene is a tree of things, and things are a tree of parts,
> and parts are trees of other parts, the rendering of a scene can be a
> tree of nested calls by ID to display lists, so by using display lists
> for everything one can revise a scene by revising the absolute minimum
> of display lists.
>
> The cool thing is how this maps onto cells. Somewhat simplified:
>
> (defmodel opengl-node ()
> ((display-list :reader display-list
> :initform (c-formula (:lazy :until-asked)
> (ogl-dsp-list-prep self)
> (every 'display-list (kids self))
> (let ((display-list-name (or .cache (gl-gen-lists 1))))
> (gl-new-list display-list-name gl_compile)
> (ix-paint self) ;; <== bingo
> (gl-end-list)
> (setf (redisplayp *window-rendering*) t)
> display-list-name))))
>
> Whatever variables are sampled during the call to ix-paint affect the
> rendering of this scene graph node. (I should not be sampling irrelevant
> variables just for the fun of it.) The Cells engine keeps track of which
> other variables are sampled. So no matter what state change occurs,
> triggered by a mouse movement or click or other OS event including time
> passing, all and only those display lists necessary to manifest the new
> state of the world will get rebuilt, and a redraw for the window will
> get kicked off.
So, am I understanding it correctly that all variables that are
accessed by ix-paint are tracked by Cells, so that when one of them
changes, the whole formula is recalculated, and thusly the display
list is updated?
> Anyone who has managed update events in typical GUI environments is now
> jumping and down screaming. :)
That's right. :)
>
> kenny
Thanks,
Manuel
On 2004-10-24 04:45:02 -0400, ·······@gmail.com (Manuel Simoni) said:
> Kenny Tilton <·······@nyc.rr.com> wrote in message
> news:<·····················@twister.nyc.rr.com>...
>> Manuel Simoni wrote:
>>
>>> Kenny Tilton <·······@nyc.rr.com> wrote
>>>
>>>
>>>> display lists likewise permit optimal scene transformations from one
>>>> frame to the next. Hellasweet.
>>>
>>>
>>> Could you tell me how you're using display lists this way? I'm very new
>>> to OpenGL.
>>> Thanks.
>>
>> I am learning OpenGL myself, so take everything I say with a grain of
>> salt. The whole quote was:
>>
>> "It turns out the dataflow paradigm of Cells meshes perfectly with the
>> OpenGL display-list trick, the fastest way to manage complex, changing
>> 3D scenes: Cells automatically handle state change in complex models
>> optimally, and display lists likewise permit optimal scene
>> transformations from one frame to the next. Hellasweet."
>>
>> I mention that because I am not sure if you are talking about the whole
>> quote or just the display list trick. I will assume the latter.
>
> Yeah, I'm working on a dataflow/forward-inference package myself
Everyone is. :) Everyone, that is, who is not writing their own Lisp.
> , so I
> already know that dataflow is the hype when it comes to user
> interfaces and graphics.
>
>> Background: A display list is effectively a compilation of a sequence
>> of Opengl calls into a named (by a numeric ID, in fact) object, if you
>> will. That lets me re-execute those instructions by simply giving
>> opengl the ID. My application code to make each OpenGL call (including
>> deciding which calls to make and what values to pass) does not have to
>> run, and instead of more or less info being sent down the pipeline I
>> just send one number, the display list ID.
>>
>> Set-up: Now Suppose there are two things A and B in a room R. OpenGL
>> lets me create a display list for A, and then a display list for B, and
>> then build a display list for R by drawing the floor and walls and then
>> rendering A and B within the room by simply calling their display
>> lists, after transforming the model matrix to position each.
>>
>> OK, call the list for R and now we have R drawn with A and B in place.
>> Now suppose A wants to be a different color in the next frame.
>>
>> The trick: I just have to rebuild the display list for A. The next time
>> I redraw the room by calling the display list for R, that list
>> eventually invokes (by ID!) the display list for A, which now includes
>> a new instruction for the color along with all the other instructions
>> for rendering A.
>
> Ah, great.
>> Note that if I want to /move/ A but not change its color, then I do not
>> have to rebuild its display list, I have to rebuild R's, because the
>> transformations to position A are executed by the rendering of R just
>> before calling the display list for A, and so go into R's display list.
>>
>> ie, just as a scene is a tree of things, and things are a tree of
>> parts, and parts are trees of other parts, the rendering of a scene can
>> be a tree of nested calls by ID to display lists, so by using display
>> lists for everything one can revise a scene by revising the absolute
>> minimum of display lists.
>>
>> The cool thing is how this maps onto cells. Somewhat simplified:
>>
>> (defmodel opengl-node ()
>> ((display-list :reader display-list
>> :initform (c-formula (:lazy :until-asked)
>> (ogl-dsp-list-prep self)
>> (every 'display-list (kids self))
>> (let ((display-list-name (or .cache (gl-gen-lists 1))))
>> (gl-new-list display-list-name gl_compile)
>> (ix-paint self) ;; <== bingo
>> (gl-end-list)
>> (setf (redisplayp *window-rendering*) t)
>> display-list-name))))
>>
>> Whatever variables are sampled during the call to ix-paint affect the
>> rendering of this scene graph node. (I should not be sampling
>> irrelevant variables just for the fun of it.) The Cells engine keeps
>> track of which other variables are sampled. So no matter what state
>> change occurs, triggered by a mouse movement or click or other OS event
>> including time passing, all and only those display lists necessary to
>> manifest the new state of the world will get rebuilt, and a redraw for
>> the window will get kicked off.
>
> So, am I understanding it correctly that all variables that are
> accessed by ix-paint are tracked by Cells, so that when one of them
> changes, the whole formula is recalculated, and thusly the display
> list is updated?
Yes, in effect. Cells mediate only CLOS slots, and only those specified
via a new slot initarg to be cellular. But I always model applications
with CLOS, and it turns out almost all slots are usefully made cellular.
There is a lazy-propagation option, but that is there just so I do not
have to argue with people who for some reason will not accept that
eager propagation works fine. The dsp-list uses a different lazy option
to fend off too-early evaluation, but that is only because of a timing
problem: during window creation the Cells engine might kick off a
display-list rule before the OpenGL context has been established. Not
good.
>
>> Anyone who has managed update events in typical GUI environments is now
>> jumping and down screaming. :)
>
> That's right. :)
It is even better with OpenGL. Under Mac and Window OSes, each cellular
slot that affected the screen appearance had an "output" callback which
invalidated the necessary region of the screen, and on update events I
had to do all the usual worrying about which things to redraw given the
update region passed in by the OS. No improvement there.
No mas. The funny thing is that I just changed over to
all-display-lists-all-the-time a short time ago and there are still
moments when I go looking for how Cello handles update events. Maybe
this exchange will get me over the hump.
I guess the odd thing is that I have this huge side effect inside a
rule, whereas those are usually functional in that they just decide a
new value for a slot. But in this case I want to re-use the /same/ list
ID, so I am actually abusing the mechanism to know when to rebuild the
display list /behind/ the ID, which is not really affected by the
change to other variables.
Pardon any confusion, I am thinking this out as I write. I am in effect
redefining the function that goes with the ID. How Lispy is that!
Right. A display list is like a Lisp function. when I redefine it, I do
not have to do anything about other display lists which invoked it when
building themselves. The embedded call to the redefined list will see
the new definition of the list whenever it gets kicked off.
I guess this leveraging of the parallel between OG lists and dynamic
Lisp functions means what I am doing in the rule is not really abusing
the Cell mechanism, it just manifests that the change is once-removed
to the /contents/ of the display list.
kt
Darren wrote:
> However, he is right about one thing. C/C++ is the best language for
> writing video games. Not becuase it's the best language, but because
> it is the best language for the domain. Virtually everyone in the
> video game world knows C/C++. It is part of the culture of video game
> development, [...]
Tautology. Not impressed.
> The biggest reason why the culture uses C/C++ is *performance*.
Premature optimization seems to be the core value of this culture.
Len Charest <···········@jpl.nasa.gov> wrote in message news:<············@nntp1.jpl.nasa.gov>...
> Darren wrote:
>
> > However, he is right about one thing. C/C++ is the best language for
> > writing video games. Not becuase it's the best language, but because
> > it is the best language for the domain. Virtually everyone in the
> > video game world knows C/C++. It is part of the culture of video game
> > development, [...]
>
> Tautology. Not impressed.
Hmm...to refute your claim of tautology:
.. >Not becuase it's the best language, but because it is the best
language
> for the domain.
The current industry standard API for video game development is
OpenGL, a C API, as in the language C. You see?
.. >Virtually everyone in the video game world knows C/C++. It is
part of the
> culture of video game development,
Refer to my previous comment if you don't understand why.
...> C/C++ is the best language for writing video games. Not becuase
it's the > best language, but because it is the best language for the
domain.
The domain is video games... the domain is dominated by OpenGL...
OpenGL is written in C... video card vendors build to the standard...
implementations of the standard are optimized to the hardware... video
games rely on the hardware... draw your own conclusions. If you still
disagree, at least give a reasonable reason why.
Tautology is an interesting and dangerous word. It can make you look
intelligent or ignorant. I bet I know which you were going for. As
you said, I am not impressed.
>
> > The biggest reason why the culture uses C/C++ is *performance*.
>
> Premature optimization seems to be the core value of this culture.
For video games, optimization isn't a value, it's a requirement. It's
a consumer driven market, and they expect alot. If using the language
which has the most native interface to the problem is "premature" then
guilty. There are still some programmers that don't rely on throwing
more hardware at a problem. Their best optimization tool still exists
between their ears, and they use it. I call it wise, but whatever.
Until there is a pure implementation of OGL in some other language
that can communicate with the hardware just as efficiently, C/C++ will
dominate and they will be the best languages to learn/use if you want
to get into the industry.
From: Neo-LISPer
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87is93efmq.fsf@yahoo.com>
If I were a video game developer, I'd probably be asking different
questions:
- Can I use UT engine from Lisp?
- What Lisp implementations would let me develop for Win32, Win64 and
Xbox?
On Thu, 21 Oct 2004 17:54:53 -0700, Neo-LISPer wrote:
> If I were a video game developer, I'd probably be asking different
> questions:
>
> - Can I use UT engine from Lisp?
>
> - What Lisp implementations would let me develop for Win32, Win64 and
> Xbox?
Xbox happily runs Linux. Several Lisps run on Linux. Some Lisps run both
on Linux and on Windows (don't know about the 32/64 stuff, sorry).
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
Neo-LISPer wrote:
> If I were a video game developer, I'd probably be asking different
> questions:
>
> - Can I use UT engine from Lisp?
>
> - What Lisp implementations would let me develop for Win32, Win64 and
> Xbox?
Depends on what sort of game developer you were. I'd be developing a
new game for the fun of it, so I really wouldn't give a crap about
either of those points. No-one whose opinion of my (hypothetical) game I
would care about actually runs windows (or has an x-box), they're all
either on Linux or MacOSX by now. If my code happened to work on
windows, I probably wouldn't actively break it, but I wouldn't bother
making any particular effort getting it to work well either.
I believe lisp is probably one of the best languages for writing
enjoyable games and enjoying oneself while writing them (though I have
yet to prove that to myself fully by actually doing so, admittedly.)
From: M Jared Finder
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <2trk5dF2318u5U1@uni-berlin.de>
Darren wrote:
> Len Charest <···········@jpl.nasa.gov> wrote in message news:<············@nntp1.jpl.nasa.gov>...
>>Darren wrote:
>>
> .. >Not becuase it's the best language, but because it is the best
> language
>
>>for the domain.
>
>
> The current industry standard API for video game development is
> OpenGL, a C API, as in the language C. You see?
>
> .. >Virtually everyone in the video game world knows C/C++. It is
> part of the
>
>>culture of video game development,
>
>
> Refer to my previous comment if you don't understand why.
>
> ...> C/C++ is the best language for writing video games. Not becuase
> it's the > best language, but because it is the best language for the
> domain.
>
> The domain is video games... the domain is dominated by OpenGL...
> OpenGL is written in C... video card vendors build to the standard...
> implementations of the standard are optimized to the hardware... video
> games rely on the hardware... draw your own conclusions. If you still
> disagree, at least give a reasonable reason why.
>
> Tautology is an interesting and dangerous word. It can make you look
> intelligent or ignorant. I bet I know which you were going for. As
> you said, I am not impressed.
OpenGL does *not* dominate games. If it wasn't for Id, OpenGL would be
all but dead in game development, as most game engines use Direct3D.
The reasoning is that Direct3D has a richer utility library (it does) so
development is faster and easier. But a Direct3D call is noticablely
slower than an OpenGL call because Direct3D is exposed through COM
instead of just raw C functions.
Given this, why does speed of development and ease of use apply to the
graphics API but not to the programming environment?
-- MJF
M Jared Finder <·····@hpalace.com> wrote in message news:<···············@uni-berlin.de>...
> Darren wrote:
> > Len Charest <···········@jpl.nasa.gov> wrote in message news:<············@nntp1.jpl.nasa.gov>...
> >>Darren wrote:
> >>
> > .. >Not becuase it's the best language, but because it is the best
> > language
> >
> >>for the domain.
> >
> >
> > The current industry standard API for video game development is
> > OpenGL, a C API, as in the language C. You see?
> >
> > .. >Virtually everyone in the video game world knows C/C++. It is
> > part of the
> >
> >>culture of video game development,
> >
> >
> > Refer to my previous comment if you don't understand why.
> >
> > ...> C/C++ is the best language for writing video games. Not becuase
> > it's the > best language, but because it is the best language for the
> > domain.
> >
> > The domain is video games... the domain is dominated by OpenGL...
> > OpenGL is written in C... video card vendors build to the standard...
> > implementations of the standard are optimized to the hardware... video
> > games rely on the hardware... draw your own conclusions. If you still
> > disagree, at least give a reasonable reason why.
> >
> > Tautology is an interesting and dangerous word. It can make you look
> > intelligent or ignorant. I bet I know which you were going for. As
> > you said, I am not impressed.
>
> OpenGL does *not* dominate games. If it wasn't for Id, OpenGL would be
> all but dead in game development, as most game engines use Direct3D.
> The reasoning is that Direct3D has a richer utility library (it does) so
> development is faster and easier. But a Direct3D call is noticablely
> slower than an OpenGL call because Direct3D is exposed through COM
> instead of just raw C functions.
Well, partially right. There were/are alot more support for OGL then
just Carmack. http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html
Your point about D3D is right though, but I didn't want to bring M$
into the debate. Let be honest, D3D was M$ trying the old OS lock-in
trick. "Why use the worlds standard when you can use ours?"
>
> Given this, why does speed of development and ease of use apply to the
> graphics API but not to the programming environment?
Speed of development/ease of use is a very relevant point. It is
simply faster/easier in C/C++ becuase 80% of the work is already done,
out there and avaiable for you to use. From scratch it probably would
be faster in Lisp, but why would you start from scratch?
>
> -- MJF
Ingvar <······@hexapodia.net> writes:
> Most *Windows* games may be using OpenGL, but I am in the (possibly
> incorrect) belief that OpenGL is fairly common for games intended to
> run on consoles (and, thus, these days, most games), since teh only
> console with D3D support is the X-Box.
Your belief is indeed incorrect. There is one third-party OpenGL
implementation(*) for the PS2, but not a lot of games use it. I think
most graphics programming on the PS2 is done in assembler. The
Gamecube has a graphics API called GX that somewhat resembles OpenGL.
* - http://www.dataplus.co.jp/OpenGL4ps2.html
Note that the "Game Developer's [sic] Using OpenGL� API" document on
that site is highly misleading. It lists all the games they know which
use OpenGL, most of which have never been ported to the PS2.
Vladimir
·········@hotmail.com (Darren) wrote:
>> Premature optimization seems to be the core value of this culture.
>
> For video games, optimization isn't a value, it's a requirement.
you need to optimize the hot-spots, only. It doesn't matter if saving a
game takes 10 ms or 100 ms, but it matters if you have to invest more
programmer time in a stable C++ persistence layer.
> Until there is a pure implementation of OGL in some other language
> that can communicate with the hardware just as efficiently, C/C++ will
> dominate and they will be the best languages to learn/use if you want
> to get into the industry.
I think the overhead to communicate to OpenGL needs only a small percentage
of the time the OpenGL library needs to display what a Lisp program
transfers to the library, and there is no reason why a Lisp compiler should
not implement calls to OpenGL as fast as a native C program.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Darren wrote:
> Len Charest <···········@jpl.nasa.gov> wrote in message news:<············@nntp1.jpl.nasa.gov>...
>
>>Darren wrote:
>>
>>
>>>However, he is right about one thing. C/C++ is the best language for
>>>writing video games. Not becuase it's the best language, but because
>>>it is the best language for the domain. Virtually everyone in the
>>>video game world knows C/C++. It is part of the culture of video game
>>>development, [...]
>>
>>Tautology. Not impressed.
>
>
> Hmm...to refute your claim of tautology:
>
> .. >Not becuase it's the best language, but because it is the best
> language
>
>>for the domain.
>
>
> The current industry standard API for video game development is
> OpenGL, a C API, as in the language C. You see?
>
You seem to be unaware that Lisp can directly call into C libraries,
such as OpenGL. And since you make such a big deal out of the OpenGL API
being "C", one wonders what you would think if you were not. Unaware,
that is.
I am talking about Lisp FFIs, btw. (foreign function interfaces)
But I cannot believe you are unaware of this. Maybe your point is that
calling a C API is easier when coding in C than when coding in Lisp,
since in the end the right types must be offered to the Opengl functions?
If so, no, Lisp macrology makes programming OpenGL much easier from Lisp
than from C. I would offer deets, but I am just doing a bunch of
guesswork here.
Exactly /why/ do you think the OpenGL API being C-ish makes C better for
programming OpenGL. (I saw the bits about being able to copy C example
code, but you seem to be talking about something else when you focus so
much on the API).
Just so you know, I am happily programming OpenGL from Lisp all the time
over here (including learning from C examples) and that is part of why I
cannot understand what you are saying.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Darren wrote:
> Hmm...to refute your claim of tautology:
>
> .. >Not becuase it's the best language, but because it is the best
> language for the domain.
So to paraphrase: C/C++ is the best language for writing video games
because it is the best language for the domain [i.e., video games].
I say again: tautology.
> The current industry standard API for video game development is
> OpenGL, a C API, as in the language C. You see?
As others have pointed out, OpenGL is a language-agnostic API.
Len Charest <···········@jpl.nasa.gov> wrote in message news:<············@nntp1.jpl.nasa.gov>...
> Darren wrote:
>
> > Hmm...to refute your claim of tautology:
> >
> > .. >Not becuase it's the best language, but because it is the best
> > language for the domain.
>
> So to paraphrase: C/C++ is the best language for writing video games
> because it is the best language for the domain [i.e., video games].
>
> I say again: tautology.
If you speak english, and I speak french, sure we can get a
translator, but is it not logical to think our communications would be
more efficient if we are both speaking english?
>
> > The current industry standard API for video game development is
> > OpenGL, a C API, as in the language C. You see?
>
> As others have pointed out, OpenGL is a language-agnostic API.
As long as there is no overhead in making the calls. I have used OGL
wrappers in other languages and the call overhead has always been a
major barrier for performance.
I have been assuming Lisp incurrs overhead during calls to C. If I am
wrong, then I appologize.
TBH, even C/C++ are sometimes not enough. Maybe it's time to get
assembly into the discussion. Though the games are not developed
entirely in it (obviously), it is often used in the most demanding
parts of the engine.
All that aside, the fact that so much game code, API's, examples,
forums, tutorials, engines, tools, etc. are out there for writing
games in C/C++, seems like a good enough reason to consider it the
best language to use to me. Most people don't like re-inventing the
wheel, nor would they have time. The competitiveness of the market
means you have to arrive at the right time with the right game and the
right technology.
I should add a disclaimer (as someone else wisely did):
I am not a full-time game developer. Though, I have done
modding/mapping for several games in the past and am fairly well known
in some moding circles. However, I haven't touched the stuff in about
a year. The only professional experience I could put on a resume
would be the content I developed for Activision on the game Star Trek
Elite Force II. Myself and two other mappers from the moding
community were contacted to be special contributers to the game. Most
likely to try and leverage our online names, but hey, I wasn't gonna
say no :) My alter-ego in the video game world is 'Vorax' and I am
mostly associated with Elite Force 1/2, and for Jedi Knight II as part
of a high profile mod team called Wired Lamp Studios.
I am *not* an expert but I do know a thing or two about the industry,
the community and what is out there. I also know several people
working in the industry at Ubi Soft (on Splinter Cell) and Raven (on
Quake IV), and if it were practical for me I would go join them... in
another life maybe. <sigh>
Darren, I assume you're familiar with the game industry, but not
familiar with compiler technology.
You're basically right that C/C++ is dominant in the industry.
To say it is because of performance is half right and half wrong.
Technically, Lisp can be almost as efficient as C/C++; if you
compile Lisp, it can generate a code to call OpenGL API exactly the
same way as C/C++ program that calls OpenGL API. You can even
write an inner loop with Lisp that runs very fast, by carefully
avoiding allocation. (BTW, Lisp used to be a dominant language
for 3D applications.) So, if you say Lisp can't be used because
of performance, you'll get tons of responses that deny it.
However, you're also right in the sense that if you see somebody
tries to write 3D engine in Lisp, you'll likely see it suffer
performance compared to C/C++ ones. That's just because there are
far less programmers that can write efficient Lisp code than the ones
that can write efficient C code, and your chance to find the good
Lisp programmer is much lower than the good C programmer. Only
if you're lucky enough (e.g. working at Naughty Dog) you can see
Lisp can be fast.
And because of the population of C/C++ programmers, there are more
resources for them, more people to work on compilers to get them
better, etc; So in fact, your "tautology" is not a tautology, but
it is just describing this positive feedback.
If you're looking at just a couple of years ahead, the safe choice
is to follow the mob; use the most popular language. C/C++ is
the best choice to write the game _at this moment_. But beware,
this industry moves fast. Remember several years ago many game
programmers refused to use C++, because the compiler wasn't mature
enough and it was difficult to predict performance (that's what
they said). And before that, even C was regarded as bad thing (of
course, you should use assembly!) If you want to think of game
platforms a few generations ahead, you don't need to tie yourself to
the current industrial best practice.
(Disclaimer: I've worked at video game companies; worked on both
consumer titles and research projects.)
·····@acm.org (Shiro Kawai) wrote in message news:<····························@posting.google.com>...
> Darren, I assume you're familiar with the game industry, but not
> familiar with compiler technology.
>
> You're basically right that C/C++ is dominant in the industry.
> To say it is because of performance is half right and half wrong.
>
> Technically, Lisp can be almost as efficient as C/C++; if you
> compile Lisp, it can generate a code to call OpenGL API exactly the
> same way as C/C++ program that calls OpenGL API. You can even
> write an inner loop with Lisp that runs very fast, by carefully
> avoiding allocation. (BTW, Lisp used to be a dominant language
> for 3D applications.) So, if you say Lisp can't be used because
> of performance, you'll get tons of responses that deny it.
Actually, I am familiar with compiler technology. What I am really
lacking in is Lisp knowledge. Dynamic types (though I have learned
from this thread that this can be avoided) and garbage collection,
were the the two red flags that led me to believe there would be an
overhead hit on the calls from Lisp.
> If you're looking at just a couple of years ahead, the safe choice
> is to follow the mob; use the most popular language. C/C++ is
> the best choice to write the game _at this moment_. But beware,
> this industry moves fast. Remember several years ago many game
> programmers refused to use C++, because the compiler wasn't mature
> enough and it was difficult to predict performance (that's what
> they said). And before that, even C was regarded as bad thing (of
> course, you should use assembly!) If you want to think of game
> platforms a few generations ahead, you don't need to tie yourself to
> the current industrial best practice.
>
> (Disclaimer: I've worked at video game companies; worked on both
> consumer titles and research projects.)
This is a very good point. I remember the C vs. C++ wars. My point
was that C/C++ is best to use now, but your right, it doesn't have to
be that way in the future.
From: Coby Beck
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <9DUed.45810$z96.30906@clgrps12>
"Darren" <·········@hotmail.com> wrote in message
································@posting.google.com...
>
> Actually, I am familiar with compiler technology. What I am really
> lacking in is Lisp knowledge.
Thank you for acknowledging what has been very obvious to most of us here.
Given this fact, why don't you spend your time asking questions instead of
writing factually incorrect and slanted opinion papers?
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Coby Beck" <·····@mercury.bc.ca> wrote in message news:<·····················@clgrps12>...
> "Darren" <·········@hotmail.com> wrote in message
> ································@posting.google.com...
> >
> > Actually, I am familiar with compiler technology. What I am really
> > lacking in is Lisp knowledge.
>
> Thank you for acknowledging what has been very obvious to most of us here.
> Given this fact, why don't you spend your time asking questions instead of
> writing factually incorrect and slanted opinion papers?
Err...I didn't write the papers and my first post on this whole topic
started off by saying "I am new to Lisp" and I have asked several
questions about Lisp's capabilities.
I think you got me confused with the other guy.
From: Coby Beck
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <4DCfd.8493$df2.8478@edtnps89>
"Darren" <·········@hotmail.com> wrote in message
································@posting.google.com...
> "Coby Beck" <·····@mercury.bc.ca> wrote in message
> news:<·····················@clgrps12>...
>> "Darren" <·········@hotmail.com> wrote in message
>> ································@posting.google.com...
>> >
>> > Actually, I am familiar with compiler technology. What I am really
>> > lacking in is Lisp knowledge.
>>
>> Thank you for acknowledging what has been very obvious to most of us
>> here.
>> Given this fact, why don't you spend your time asking questions instead
>> of
>> writing factually incorrect and slanted opinion papers?
>
> Err...I didn't write the papers and my first post on this whole topic
> started off by saying "I am new to Lisp" and I have asked several
> questions about Lisp's capabilities.
>
> I think you got me confused with the other guy.
Oops...! Terribly sorry, I did just that.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
> If you're looking at just a couple of years ahead, the safe choice
> is to follow the mob; use the most popular language. C/C++ is
> the best choice to write the game _at this moment_. But beware,
> this industry moves fast. Remember several years ago many game
> programmers refused to use C++, because the compiler wasn't mature
> enough and it was difficult to predict performance (that's what
> they said). And before that, even C was regarded as bad thing (of
> course, you should use assembly!)
> If you want to think of game
> platforms a few generations ahead, you don't need to tie yourself to
> the current industrial best practice.
C/C++ is the best language to use _if_ you want to be like the other
game companies. IIRC, the failure rate in the games industry is
pretty bad, and in particular, new game companies tend to flameout
with some regularity. So while a large company would probably be
well-served by coding in C/C++ (they just want to generate returns
like all of the other companies), a new game company, particularly one
that wanted to do something new (perhaps even "next-generation"?)
would be well-served to look carefully at what language delivered the
best code/cost ratio. I believe lisp wins in that comparison.
Is it true that lisp implementation X is too slow for task Y? I don't
know, and no one else does either, here or elsewhere. The variance
between coders, both in productivity and in the characteristics of
produced code, completely swamps most of the differences between C and
lisp. This means that the question is ill defined. What is certainly
true is that lisp is far more expressive and terse, and will therefore
allow the effeciency-insensitive parts of the code to be done much
faster. Therefore, you can get by with a smaller team for constant
product, and hence lower initial capital outlay.
If it were not true that lisp can call out to other languages, the
amount of infrastructure needed for a serious game would make lisp
prohibitively expensive. But in fact, lisp can call out to C libs
about as well as any language. So the infrastructure is already there
for you, just like it is for the C guys.
It is true that there are many C code examples out there, but I don't
think that is much of problem. Just about any C code can be
translated to lisp pretty easily, particularly if it is ideas you are
looking for-they know no language. Further, I am somewhat skeptical
that the cutting edge game of 200x will depend critically on code
snippets gathered from the internet.
All of the above assumes that low-level optimization is the
differentiating factor for games. I'm not sure that that is true.
There are many entities making faster, more detailed games-perhaps a
better way to go is better enemy AI, or a more dynamic environment.
For either of those, there is not much benefit to be had from sticking
with the crowd, as the crowd is not so strong in that dimension. The
advantages of lisp are then even greater if that is true.
···········@gmail.com (matt knox) wrote in message news:<····························@posting.google.com>...
> C/C++ is the best language to use _if_ you want to be like the other
> game companies. IIRC, the failure rate in the games industry is
> pretty bad, and in particular, new game companies tend to flameout
> with some regularity. So while a large company would probably be
> well-served by coding in C/C++ (they just want to generate returns
> like all of the other companies), a new game company, particularly one
> that wanted to do something new (perhaps even "next-generation"?)
> would be well-served to look carefully at what language delivered the
> best code/cost ratio.
Right. And I guess the guys at Naughty Dog did prove that.
From my experience of being in the console game production, and
writing performance-sensitive Lisp code, I'd like to add a couple of
points here.
I think the demand of performance won't diminish in near future.
Hardware is getting so much faster, but demand on putting things in
the gameplay is so much bigger. Some say fine games don't need
fancy graphics, and I agree in some cases (I still play nethack, too).
But better graphics provide new way of expressiveness. You may be
able to encode important messages in subtle facial expressions,
instead of explicit dialog, for example. This kind of things tend to
require more and more resources, since if you come closer to the
reality, the amount of work required to make it even closer increases
steeply. (And I really like to play holographic 3D games some day!)
What does that mean? Unless you compete with niche market (say, like
Tetris-type stuff), you have to make your Lisp code as fast as tuned
C/C++ code, because big players can put resources that covers the
productiveness handicap of using C/C++. Technically it is doable,
but it is not trivial. You have to avoid inefficient function calls,
allocations inside tight loops, etc. You need to have control over
how data is layed out in the physical memory. You need to control
GC. So, you have to have very intimate knowledge about the Lisp
compiler and runtime you're using, or ideally, you have to write your
own. It is doable, and has done by one company, but certainly it
needs more determination than just say "Let's use Lisp".
Now, here's another point. The proportion of the cost of developing
game engine within the total production cost is getting smaller.
In big productions, you may have 20 programmers and 100 artists.
And some of those programmers aren't writing game engine, but
writing tools to support production pipeline---
moving data between the engine and the artists' tools back and
forth, or writing custom software for artists to make contents.
And I think that is the part that Lisp can take advantage.
If your code runs outside of the game engine, you have lots of
choices.
Even in the game runtime, some content-centric part can be handled
by Lisp; one part is the event scripting, where people already start
using scripting languages (and that's where Naughty Dog started,
right?) The other part is a glue language, such as to communicate
with development tools and lay out the data on the memory. It is
quite useful during development stage, where the data structure
and content is constanly changing and the artists need to see their
stuff in the game every time they change something. I once built
a small Scheme runtime in the engine, and wrote a distributed object
system on top of it, which communicates with Maya (that had also
a built-in Scheme runtime). That kind of stuff is so easy using
Lispy languages. The authoring tool companies provide some stuff,
but you may be able to beat them with so nice tools that artists
will become twice productive.
BTW, has anybody tried to use Lisp for shader development? You can't
have Lisp runtime on GPU at this moment, but writing a toolchain in
Lisp that emits shader language may be interesting.
I have seriously been looking at Common Lisp for Games development over
the past few years.
As has already been stated, most of the heavy graphical lifting is
offloaded to
Graphical APIs (OpenGL, DirectX) and the graphic cards upon which they
run.
My theory is that wise implementation of the program using lisp gives
the huge advantage
of flexibility in design and debugability while still maintaining close
to optimal performance
by leveraging the capabilities of the graphics APIs.
It is almost trivial for someone with C++ and Lisp knowledge to
translate all those examples from books
and the web. Having done so, you can then clean up a lot of the mess by
refactoring. Each time i have done
this my code size seems to shrink at least 50%.
List macros make a great way to simplify game scripting as well. A
domain specific language can be easily
specified to make the scripting job much simpler. You also gain the
advantages of:
- not having to define and maintain your own language (often with poor
debugging support)
- the full power of lisp at your disposal
- no integration issues between script code and core code
- scripts are dynamically loadable (base lisp functionality)
- scripts can be compiled to machine code (basic lisp compilation
capabilities)
I almost can't understand why more people aren't doing this. Once a
base foundation is created between your
lisp version and the underlying APIs, the writing of code proceeds at a
rapid pace and is very flexible.
Additionally, its very easy to create the tools needed in the build
pipeline for debugging as well as
massaging graphics and sound into the correct formats for the run-time.
I have been working on the design and implementation of an MMP (massive
multiplayer) game during the past year,
and using Common Lisp continues to make the most sense. Much of the
base level server side communications
framework is complete already.
Another advantage is that on both the client and server side, dynamic
updates to running programs
are trivial with Common Lisp, while in the current incarnation of most
of these types of games there are
huge down-cycles for server upgrades and patch uploads for clienta that
frequently occur.
I believe that using Common Lisp would be a huge advantage to a small,
intelligent team of game developers.
·······@gmail.com" <······@gmail.com> wrote in message news:<························@f14g2000cwb.googlegroups.com>...
> I have been working on the design and implementation of an MMP (massive
> multiplayer) game during the past year,
> and using Common Lisp continues to make the most sense. Much of the
> base level server side communications
> framework is complete already.
Coolness. I think Lisp shines especially on the server side.
Once you launch your title, would you share the experience?
> I almost can't understand why more people aren't doing this. Once a
> base foundation is created between your
> lisp version and the underlying APIs, the writing of code proceeds at a
> rapid pace and is very flexible.
Yeah, let's beat the averages!
From: Dirk Gerrits
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87hdoizucm.fsf@dirkgerrits.com>
·······@gmail.com" <······@gmail.com> writes:
> I have been working on the design and implementation of an MMP
> (massive multiplayer) game during the past year, and using Common Lisp
> continues to make the most sense. Much of the base level server side
> communications framework is complete already. Another advantage is
> that on both the client and server side, dynamic updates to running
> programs are trivial with Common Lisp, while in the current
> incarnation of most of these types of games there are huge down-cycles
> for server upgrades and patch uploads for clienta that frequently
> occur.
Cool, so you're actually doing pure Common Lisp game development?
> I believe that using Common Lisp would be a huge advantage to a small,
> intelligent team of game developers.
I second that:
http://groups.google.com/groups?dq=&hl=en&lr=&group=comp.lang.lisp&c2coff=1&safe=off&selm=87fz43zttz.fsf_-_%40dirkgerrits.com
Kind regards,
Dirk Gerrits
Dirk Gerrits wrote:
> ·······@gmail.com" <······@gmail.com> writes:
>
> > I have been working on the design and implementation of an MMP
>
> Cool, so you're actually doing pure Common Lisp game development?
>
Yes, but its an unfunded, independent post 5 effort so it probably
doesn't carry any weight in the "games can't be developed in lisp"
counter-argument until its actually produced.
I've been pondering this idea too...seems like there might be a great
way to utilize macros to come up with a very descriptive HLL for the
GPU shader languages...investigating this is on my (large) stack of
things i'd like to get done this year
Ingvar wrote:
> ·····@acm.org (Shiro Kawai) writes:
>
> [ SNIP, lisp in game development ]
> > BTW, has anybody tried to use Lisp for shader development? You
can't
> > have Lisp runtime on GPU at this moment, but writing a toolchain in
> > Lisp that emits shader language may be interesting.
>
> I have been looking at it, in a very, very vague way. At the moment,
> I'm mostly limited by (a) spare time and (b) relevant documentation.
> In short, there may, possibly, be something, some day. Don't hold
your
> breath. It will, hopefully, be sufficiently portable (but may,
> possibly, be limited to OpenGL).
>
> //Ingvar
> --
> ((lambda (x y l) (format nil "~{~a~}" (loop for a in x for b in y
with c = t
> if a collect (funcall (if c #'char-upcase #'char-downcase) (elt (elt
l a) b))
> else collect #\space if c do (setq c ())))) '(76 1 0 0 nil 0 nil 0 3
0 5 nil 0
> 0 12 0 0 0) '(2 2 16 8 nil 1 nil 2 4 16 2 nil 9 1 1 13 10 11) (sort
(loop for
> foo being the external-symbols in :cl collect (string-upcase foo))
#'string<))
From: Dirk Gerrits
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87is8ymsgg.fsf@dirkgerrits.com>
·······@gmail.com" <······@gmail.com> writes:
> I've been pondering this idea too...seems like there might be a great
> way to utilize macros to come up with a very descriptive HLL for the
> GPU shader languages...investigating this is on my (large) stack of
> things i'd like to get done this year
The C++ people did it: http://libsh.sourceforge.net/ So embedding a
high-level shading language in the main programming language isn't the
issue. The interesting question is how much more high-level and better
integrated the Lisp counterpart would be.
Kind regards,
Dirk Gerrits
In article <····························@posting.google.com>,
···········@gmail.com (matt knox) wrote:
>
> Is it true that lisp implementation X is too slow for task Y? I don't
> know, and no one else does either, here or elsewhere. The variance
> between coders, both in productivity and in the characteristics of
> produced code, completely swamps most of the differences between C and
> lisp.
I have been meaning to mention something that supports this. One of the
C or C++ (I forget) physics engines I looked at was an open source fork
from a commercial engine. Seems at some point the commercial fork became
much faster. Turns out a much better algorithm had been found for
collision detection. (The commercial fork was kind enough to share the
new algorithm.)
Now couple this with the Gamedev article about performance now being
determined so predominantly by the graphics card and OS that things like
whether one is using Direct3D or OpenGL becomes irrelevant, and I think
we can all safelt go back to our Lisp games programming.
:)
kt
Shiro Kawai wrote:
>
> If you're looking at just a couple of years ahead, the safe choice
> is to follow the mob; use the most popular language. C/C++ is
> the best choice to write the game _at this moment_. But beware,
> this industry moves fast. Remember several years ago many game
> programmers refused to use C++, because the compiler wasn't mature
There are still plenty of programmers in the game industry who think C++
is a bad idea, and need pursuading to use something as simple as
namespaces; and I can still remember losing a job for suggesting the use
of "C" over assembly for non-performance-critical parts of the game
frontends in the interview. This was some years ago, but based on
exrtrapolation of trends I wouldn't expect LISP to appear on the radar
for a decade, yet.
Garbage collection - or the perception of it - it one of the biggest
stumbling blocks (the garbage collector has to be suitable for a soft -
real - time system, and be enabled/disabled at will).
> enough and it was difficult to predict performance (that's what
> they said). And before that, even C was regarded as bad thing (of
> course, you should use assembly!) If you want to think of game
> platforms a few generations ahead, you don't need to tie yourself to
> the current industrial best practice.
>
> (Disclaimer: I've worked at video game companies; worked on both
> consumer titles and research projects.)
As a professional game developer, I'd look for these things in a LISP
implementation.
* Garbage collector capable of running in a soft - real time system,
leading to no dropped frames that can be disabled/enabled at will, and
with some means of pinning objects down for a given time so that DMA can
take place.
* Inline assembler, with support for most x86/SSE/MIPS/PPC instruction
sets, or subset thereof of which architectures the compiler can handle.
* Compile to native code, and executable image, the usual compiler
optimisations taken for granted - constant folding, return - value,
intelligent inlining, etc..
* Cheap-as-possible FFI and float/integer/matrix operations, prefereably
boling down to inline intrinsics ( I understand this is trivial with
macros ).
* Binding to Open GL 2.0 and the ability to run vertex programs, and or
native libraries/hardware on consoles.
* Acres of docs, so that even idiots can use it, and plenty of examples
that can be hacked over..Sony have many, many useful examples of C/C++
code on their PS2 professional developers website which enable you to
get up and running fast.
* Binding to Renderware, because most of the industry is going to be
using it for next-gen (at least, initally)..
Does such an animal even exist? I suspect the answer is Allegro/Franz..
> This was some years ago, but based on
> exrtrapolation of trends I wouldn't expect LISP to appear on the radar
> for a decade, yet.
>
...
>
> As a professional game developer, I'd look for these things in a LISP
> implementation.
>
[lots of close-to-the-machine/graphics rendering features snipped]
Perhaps I know less than I think I do about games development, but is
it really true that the majority of game development effort happens on
code that actually executes natively on the host or graphics
processor?
My impression was that the majority of development effort has to
support the "art" aspects: level design, designing of creature
graphics, etc. Where the priority is on quickly creating flexible,
adaptive, powerful, robust, yet relatively easy-to-use tools to create
binary data to be executed by the specialized game engine.
That is the kind of domain in which Lisp excels and where
close-to-the-machine execution is least needed.
For instance, in cases where a level or art designer asks for a
particular special-purpose tool, the Lisp programmer can quickly add a
new tool to the artist's palette, perhaps even inside the tool as it
executes on the artist's workstation, because he has a flexible
language in which to express tool-like actions on the underlying
artistic medium. He hasn't necessarily squeezed the last machine cycle
out of the tool, but the artist quickly gets to experiment and say
"yes, that's what I want" or "no, actually, I wanted something
slightly different." Furthermore, the Lisp programmer can easily
include meta-functionality: in a Lisp-based design, it is probably
trivial to include a Lisp extension language, to allow artists to
express their own repetitive macro operations.
From: Matthew Danish
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87zn2ev6h9.fsf@mapcar.org>
·········@hotmail.com (Darren) writes:
> The current industry standard API for video game development is
> OpenGL, a C API, as in the language C. You see?
Once again, I will point out that this is horribly misguided and is
leading into your other assumptions.
OpenGL is an industry standard API; BUT IT IS NOT A C LIBRARY.
This is OpenGL (2.0):
http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
Most operating systems come with an implementation of it which offers
a C interface. However, there is nothing about OpenGL which makes it
part of C; it just uses C for a few examples, and then mentions that
other languages would have differences in declaration syntax.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
Matthew Danish <··········@cmu.edu> wrote in message news:<··············@mapcar.org>...
> ·········@hotmail.com (Darren) writes:
> > The current industry standard API for video game development is
> > OpenGL, a C API, as in the language C. You see?
>
> Once again, I will point out that this is horribly misguided and is
> leading into your other assumptions.
>
> OpenGL is an industry standard API; BUT IT IS NOT A C LIBRARY.
>
> This is OpenGL (2.0):
> http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
>
> Most operating systems come with an implementation of it which offers
> a C interface. However, there is nothing about OpenGL which makes it
> part of C; it just uses C for a few examples, and then mentions that
> other languages would have differences in declaration syntax.
Yes, the specification is not C specific. But unless you are writing
an implementation of OpenGL from scratch, you are going to want to use
the implementation supported by the users OS. How many pure
implementations of OGL exist on OS's that a game player would use,
that are not accessed using C?
From: Rahul Jain
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87mzybd0bt.fsf@nyct.net>
·········@hotmail.com (Darren) writes:
> Yes, the specification is not C specific. But unless you are writing
> an implementation of OpenGL from scratch, you are going to want to use
> the implementation supported by the users OS. How many pure
> implementations of OGL exist on OS's that a game player would use,
> that are not accessed using C?
How can the implementation conform to the specification if it can only
be used from C? You'd also have to use a custom C compiler to achieve
that, in most cases.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
·········@hotmail.com (Darren) wrote:
> However, he is right about one thing. C/C++ is the best language for
> writing video games. Not becuase it's the best language, but because
> it is the best language for the domain. Virtually everyone in the
> video game world knows C/C++. It is part of the culture of video game
> development, so there is alot of information/examples/support for
> newbies.
for what do you need support or examples? If you need to know how to
setup Direct3D or something like this, you can translate the examples to
Lisp. If you need to know how to do the math or game design or something
like this, you can do it with Lisp, too. Your argument sounds to me like:
Eat shit! Millions of flies can't be wrong :-)
> The biggest reason why the culture uses C/C++ is *performance*.
> Lisp/Java/Python, or anything other then assembly will have problems
> in this area. Lisp may be fast, but modern 3D video games push so
> many polygons that you want every cycle out of that CPU working for
> you. Only by working as close to the CPU's and GPU's as possible will
> this happen.
You can optimize Lisp programs with "declare" etc. to compile to really
fast code, if you have a good compiler. And if this doesn't help, you can
do the things which needs to be fast in assembler or C. In most programs,
games included, are only a few hot-spots which needs to be fast. For
example it doesn't matter if the layout routine for displaying a GUI for
an inventory in an adventure game takes 10 ms or 10 us.
Would be nice to program a pixel shader for a GPU in Lisp, too.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Matthew Danish
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87d5zbx0a5.fsf@mapcar.org>
·········@hotmail.com (Darren) writes:
> The biggest reason why the culture uses C/C++ is *performance*.
Game designers really need to quit focusing on performance and start
focusing on playability and fun. What use is the fanciest graphics if
the gameplay is boring? You'll only appeal to hard-core gamers who
have the crazy souped-up systems. The average computer is more than
fast enough to run a game which is fun to play, even though it doesn't
have the best graphics.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
In article <··············@mapcar.org>, Matthew Danish wrote:
> ·········@hotmail.com (Darren) writes:
>> The biggest reason why the culture uses C/C++ is *performance*.
>
> Game designers really need to quit focusing on performance and start
> focusing on playability and fun. What use is the fanciest graphics if
> the gameplay is boring? You'll only appeal to hard-core gamers who
> have the crazy souped-up systems. The average computer is more than
> fast enough to run a game which is fun to play, even though it doesn't
> have the best graphics.
>
I agree. I still play (almost exclusively(?)) nethack for the past 15 years.
From: Christopher C. Stacy
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <uekjrs8lq.fsf@news.dtpq.com>
Marco Parrone <·····@autistici.org> writes:
> Matthew Danish on 21 Oct 2004 16:51:30 -0400 writes:
>
> > ·········@hotmail.com (Darren) writes:
> >> The biggest reason why the culture uses C/C++ is *performance*.
> >
> > Game designers really need to quit focusing on performance and start
> > focusing on playability and fun. What use is the fanciest graphics if
> > the gameplay is boring? You'll only appeal to hard-core gamers who
> > have the crazy souped-up systems. The average computer is more than
> > fast enough to run a game which is fun to play, even though it doesn't
> > have the best graphics.
>
> But a small footprint is still desiderable.
What is "small"? How desirable is it? Why?
From: Marco Parrone
Subject: Usage of resources (was: Why Lisp supposedly "sucks for game development")
Date:
Message-ID: <87fz47umtg.fsf_-_@autistici.org>
Christopher C. Stacy on Fri, 22 Oct 2004 04:02:57 GMT writes:
>> >> The biggest reason why the culture uses C/C++ is *performance*.
>> >
>> > Game designers really need to quit focusing on performance and start
>> > focusing on playability and fun. What use is the fanciest graphics if
>> > the gameplay is boring? You'll only appeal to hard-core gamers who
>> > have the crazy souped-up systems. The average computer is more than
>> > fast enough to run a game which is fun to play, even though it doesn't
>> > have the best graphics.
>>
>> But a small footprint is still desiderable.
>
> What is "small"?
Smallness is relative, to the program, to the machine.
For example, if you can have a program running in 100 KB of memory, a
version running in 5 MB of memory is big, and this may be a problem if
the program may run multiple times on a congested machine.
However this may not be the case for PC videogames, where you can shut
down all other applications, where you have plenty of memory and you
already use it for lots of data (for example for sprites).
> How desirable is it?
It depends on the pain the bigger dimensions will give.
It may range from "I can not run the program" (a lot desiderable) to
"I can not put it on a floppy" (a little desiderable).
> Why?
Because using less resources is good.
If you can get a good for 5 credits, and you can get the equivalent
good for 10 credits, what is the more desiderable good? The cheaper
one.
If a program requires less resources it can be used by a greater range
of peoples, it can be adapt to a greater range of situations (silly
example: putting it on a floppy).
I can give up some resources for some other advantage, for example I
run Emacs and not ed, because with Emacs I can make more things in
less time in a more comfortable way.
But playing a videogame, as a player I would prefer to have the
resources used in some way that would affect the gaming experience
(for example, better graphics, better sound) and not in a more
comfortable developing process.
As a game developer, I would like to be productive, and I want to
write a good game, a game peoples would enjoy.
So, I choose Lisp for what Lisp can serve me better,
and I choose C for what C can serve me better.
For what's related the low-level stuff, it requires more work to get a
good working thing in Lisp than in C, as in C there are many examples,
documentation, libraries. For high-level stuff, Lisp allows for
greater abstraction and faster development.
So, I write the low-level stuff in C, and the high-level stuff in
Lisp, and I don't need to feel as a sinner for this :)
--
Marco Parrone <·····@autistici.org> [0x45070AD6]
From: Christopher C. Stacy
Subject: Re: Usage of resources (was: Why Lisp supposedly "sucks for game development")
Date:
Message-ID: <u6552sy4a.fsf@news.dtpq.com>
Marco Parrone <·····@autistici.org> writes:
> Christopher C. Stacy on Fri, 22 Oct 2004 04:02:57 GMT writes:
>
> >> >> The biggest reason why the culture uses C/C++ is *performance*.
> >> >
> >> > Game designers really need to quit focusing on performance and start
> >> > focusing on playability and fun. What use is the fanciest graphics if
> >> > the gameplay is boring? You'll only appeal to hard-core gamers who
> >> > have the crazy souped-up systems. The average computer is more than
> >> > fast enough to run a game which is fun to play, even though it doesn't
> >> > have the best graphics.
> >>
> >> But a small footprint is still desiderable.
> >
> > What is "small"?
>
> Smallness is relative, to the program, to the machine.
I was hoping to hear some absolute numbers related to games,
especially the game machines like the X-box or whatever.
I have never played any of these video games, or even actually
seen the boxes -- I don't know anything about them at all.
Certainly on the PC, there's no problem whatsoever with the
size of Lisp applications. Most system tray icon applications
(such as the Weather, Process Explorer, iTouch keyboard)
are larger than the Lisp applications I've delivered lately.
Christopher C. Stacy on Fri, 22 Oct 2004 13:04:05 GMT writes:
>> >> >> The biggest reason why the culture uses C/C++ is *performance*.
>> >> >
>> >> > Game designers really need to quit focusing on performance and start
>> >> > focusing on playability and fun. What use is the fanciest graphics if
>> >> > the gameplay is boring? You'll only appeal to hard-core gamers who
>> >> > have the crazy souped-up systems. The average computer is more than
>> >> > fast enough to run a game which is fun to play, even though it doesn't
>> >> > have the best graphics.
>> >>
>> >> But a small footprint is still desiderable.
>> >
>> > What is "small"?
>>
>> Smallness is relative, to the program, to the machine.
>
> I was hoping to hear some absolute numbers related to games,
> especially the game machines like the X-box or whatever.
> I have never played any of these video games, or even actually
> seen the boxes -- I don't know anything about them at all.
>
> Certainly on the PC, there's no problem whatsoever with the
> size of Lisp applications. Most system tray icon applications
> (such as the Weather, Process Explorer, iTouch keyboard)
> are larger than the Lisp applications I've delivered lately.
Ah OK, I was thinking you were going to claim that small footprint is
not desiderable.
Specs for PS2:
<http://www.us.playstation.com/consoles.aspx?id=2/info/415007657.html>
However PS2 is comparable to a PC, there is also a version of
GNU/Linux including an X server available for it.
This is not true for PS.
Specs for PS one:
<http://www.us.playstation.com/consoles.aspx?id=1/info/415007665.html>
Please note that the RAM is specified in Mbit, not MB.
Please note also that 2MB of RAM for that console are not like 2MB of
RAM for a PC, as they are all available to you (WOW! :D), you have a
processor for compressing textures, and you have different coprocessor
that provides system functions, another one for 3D geometry, etc...
Some unofficial documentation for the PS:
<http://psx.rules.org/psxrul2.shtml>
You can find more searching for things like "caetla playstation",
"psyq playstation", "not yaroze".
--
Marco Parrone <·····@autistici.org> [0x45070AD6]
Marco Parrone <·····@autistici.org> wrote:
> Some unofficial documentation for the PS:
>
> <http://psx.rules.org/psxrul2.shtml>
if you have a PS2, there are some official documentation:
http://playstation2-linux.com/
but you need a kit, which costs 149 EUR, and which includes a 40 GB
harddisk, ethernet adapter, monitor cable, USB keyboard and two developer
CDs.
I think one advantage of a PS2 compared to a PC is the unique hardware:
If it runs on one PS2, then you know it runs on every PS2. This makes
programming fast games a little bit easier, because you can go to the
limits and don't have to fear, that it won't run on some slow device. And
of course, you can program it in Lisp! But selling games for it is much
more expensive than for example selling shareware for the PC, because you
can't burn your own CDs, but you must work with Sony to publish your
game.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Szymon
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87brewdqeo.fsf@eva.rplacd.net>
·········@hotmail.com (Darren) writes:
> [.....]
> The biggest reason why the culture uses C/C++ is *performance*.
> Lisp/Java/Python, or anything other then assembly will have problems in
> this area.
Objective-C. It's fast. It's C dialect. It's NOT C++. :>
Fortan ;)
> Lisp may be fast, but modern 3D video games push so many polygons that
> you want every cycle out of that CPU working for you.
Forth :))
> Only by working as close to the CPU's and GPU's as possible will
> this happen.
I think PS4 should be Lisp Machine.
Regards, Szymon.
From: Szymon
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <877jpkdqa2.fsf@eva.rplacd.net>
Szymon <············@o2.pl> writes:
> Fortan ;)
Fortran, not 'Fortan'.
"Darren" <·········@hotmail.com> wrote in message
································@posting.google.com...
> I am new to Lisp, but even I could recognize some mis-truths in this
> article.
>
> However, he is right about one thing. C/C++ is the best language for
> writing video games. Not becuase it's the best language, but because
> it is the best language for the domain. Virtually everyone in the
> video game world knows C/C++. It is part of the culture of video game
> development, so there is alot of information/examples/support for
> newbies.
This is true, but it is not a valid argument about Lisp. The Lisp
community may be smaller than C++'s, it is still very responsive, and
discussions are generally of excellent quality. Anybody willing to
do game development in Lisp would find good answers about Lisp here,
and about game principles and algorithms on the usual game sites.
> The biggest reason why the culture uses C/C++ is *performance*.
This is not correct. Performance is not a property of a language, but
of an implementation. Nothing in the C++ and Common Lisp specs say
that Lisp should be slower than C++. Modern Lisp compilers generate
code of which execution speed is comparable to that of the output of
C or C++ compilers.
> Lisp/Java/Python, or anything other then assembly will have problems
> in this area. Lisp may be fast, but modern 3D video games push so
> many polygons that you want every cycle out of that CPU working for
> you.
Many Lisp programmers also want every CPU cycle working for them,
and they can get exactly that...
> If you are going to do video games, you can learn the basics with a
> language like Lisp or Java, and you can even build some things. But
> if you want to work on games like Doom 3 or HL2, you need C/C++ and
> you need to get down with the OpenGL C library..."everything else is
> just a wrapper."
You can the OpenGL C library from Lisp as well as from C++...
--
Matthieu Villeneuve
"Matthieu Villeneuve" <·····················@freeDOTfr> wrote in message news:<·······················@news.free.fr>...
> > However, he is right about one thing. C/C++ is the best language for
> > writing video games. Not becuase it's the best language, but because
> > it is the best language for the domain. Virtually everyone in the
> > video game world knows C/C++. It is part of the culture of video game
> > development, so there is alot of information/examples/support for
> > newbies.
>
> This is true, but it is not a valid argument about Lisp. The Lisp
> community may be smaller than C++'s, it is still very responsive, and
> discussions are generally of excellent quality. Anybody willing to
> do game development in Lisp would find good answers about Lisp here,
> and about game principles and algorithms on the usual game sites.
Ya, but can you download thousands of API's and examples to assist
you? Can you get complete sources from professional published games?
There are probably more web sites just about mapping/modding for the
Quake 3 engine then there are about Lisp. (Guess, but it wouldn't
surprise me)
>
> > The biggest reason why the culture uses C/C++ is *performance*.
>
> This is not correct. Performance is not a property of a language, but
> of an implementation. Nothing in the C++ and Common Lisp specs say
> that Lisp should be slower than C++. Modern Lisp compilers generate
> code of which execution speed is comparable to that of the output of
> C or C++ compilers.
For normal applications yes, but comparable isn't good enough when you
are developing cutting edge games. Even on the best of hardware,
games such as Doom 3 can have performance problems. C's strength is
in talking to hardware, modern video games are a hardware problem.
>
> > Lisp/Java/Python, or anything other then assembly will have problems
> > in this area. Lisp may be fast, but modern 3D video games push so
> > many polygons that you want every cycle out of that CPU working for
> > you.
>
> Many Lisp programmers also want every CPU cycle working for them,
> and they can get exactly that...
Again...can Lisp do it by talking to the hardware directly? If not
then it, like Java, Python, etc. is "Doom"ed (har har) to be
"fragged".
>
> > If you are going to do video games, you can learn the basics with a
> > language like Lisp or Java, and you can even build some things. But
> > if you want to work on games like Doom 3 or HL2, you need C/C++ and
> > you need to get down with the OpenGL C library..."everything else is
> > just a wrapper."
>
> You can the OpenGL C library from Lisp as well as from C++...
Through some kind of abstraction a layer? If so, then it will not be
as fast. (I am new to Lisp, if I am wrong, tell me. I am assuming
that Like Java or Python it needs to bridge to native calls for
accessing external services/api's).
From: Matthew Danish
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <874qknwn7p.fsf@mapcar.org>
·········@hotmail.com (Darren) writes:
> Through some kind of abstraction a layer? If so, then it will not be
> as fast. (I am new to Lisp, if I am wrong, tell me. I am assuming
> that Like Java or Python it needs to bridge to native calls for
> accessing external services/api's).
What makes you think C is "native"? C has to go through a layer too;
that translates to system calls to the underlying driver. From my
experience with CL-SDL, most Lisp compilers can call C functions using
the C calling conventions with little or no overhead (depending on the
datatypes used and the underlying representation of them).
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
·········@hotmail.com (Darren) writes:
> Ya, but can you download thousands of API's and examples to assist
> you? Can you get complete sources from professional published games?
Can you tell me which came first, the chicken or the egg? There's also
no reason that you can't use the interface references for C libraries
in your Lisp program (guess what - OpenGL looks the same no matter
what languages you use). Same goes for reading commercially-published
games, not that this is a good way to learn to make your own, or to
build games, or to borrow parts from. There is a lot of difference
between a commercial game engine and something suitable for learning
to make games and making them with a small team (look at how many new
games came out using the GPLed Quake II engine vs. how many games have
been created with Torque, which the Garage Games guys put a lot of
effort in to make it usable by others, and which I believe was first
released a year after the Quake II source).
> There are probably more web sites just about mapping/modding for the
> Quake 3 engine then there are about Lisp. (Guess, but it wouldn't
> surprise me)
Here you are confusing quantity and quality. Sites on mapping for
Quake 3 aren't sites about making the Quake 3 engine, and those sites
about scripting Quake 3 are mostly garbage (well, to be perfectly
honest I stopped playing around with modding games before Quake 3 came
out, but most of the Quake II and engine-based games' modding sites
sucked).
> For normal applications yes, but comparable isn't good enough when you
> are developing cutting edge games. Even on the best of hardware,
> games such as Doom 3 can have performance problems. C's strength is
> in talking to hardware, modern video games are a hardware problem.
C is so great at talking to the hardware that testing for integer
overflow is faster and easier in assembly. Just because adding two
ints in C is one machine language instruction doesn't mean that it's
control structures always produce good code (remember all that loop
unrolling crap for the 486? remember how useless this became on the
pentium?). And if by talking to hardware, you mean pushing things into
memory-mapped devices, that's also something Lisp is pretty good at. I
do agree that modern PC games are mostly a hardware problem, that is,
the PC hardware has a lot of problems. Every new game I've seen has a
load of bugs relating to various video and/or soundcard drivers, many
of them performance related (choppy audio and redraws). Having the OS
there is just another layer of bugs, too, but despite this I don't
actually see anyone in the videogame business clamoring to go back to
assembly language to solve their "hardware problems" (hell, even in
GPU programming it only took one product cycle to settle on a
high-level language).
> Again...can Lisp do it by talking to the hardware directly? If not
> then it, like Java, Python, etc. is "Doom"ed (har har) to be
> "fragged".
You mean like Python is being used in Blade of Darkness, ST: Bridge
Commander, TOEE, Earth and Beyond, and the Freedom Force games?
Granted, the only Java-using games I know aside from Pong on the
cell-phones is Vampire: The Masquerade - Redemption (but there was a
port of Quake II that was quite snappy recently).
> > You can the OpenGL C library from Lisp as well as from C++...
>
> Through some kind of abstraction a layer? If so, then it will not be
> as fast. (I am new to Lisp, if I am wrong, tell me. I am assuming
> that Like Java or Python it needs to bridge to native calls for
> accessing external services/api's).
Since interacting with OpenGL is mostly pushing display lists around
and passing floats, there is no overhead in Lisps that use the C
calling convention (and there aren't many that don't) because unlike
Java and Python, Lisp compilers don't go through a VM, and unlike
Python they don't have to box ints.
Vladimir
From: Cesar Rabak
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <41781D03.4020809@acm.org>
Matthieu Villeneuve escreveu:
> "Darren" <·········@hotmail.com> wrote in message
> ································@posting.google.com...
>
[snipped]
>
>>The biggest reason why the culture uses C/C++ is *performance*.
>
>
> This is not correct. Performance is not a property of a language, but
> of an implementation. Nothing in the C++ and Common Lisp specs say
> that Lisp should be slower than C++. Modern Lisp compilers generate
> code of which execution speed is comparable to that of the output of
> C or C++ compilers.
>
More or less. As we observed in an earlier thread we only arrived at the
same order of magnitude and for getting closer you have to start to
close in types, etc.
In the game industry I have been told that 2% to 3% [increase in
performance] is worth the effort.
OTOH, I believe the logic engine of these games could get better if
programmed in Lisp.
--
Cesar Rabak
"xstream" <·······@attglobal.net> writes:
> Has anyone seen anywhere a technical rebuttal to the positions this article
> takes?
>
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
If Lisp really sucks for X development, why are people so scared to
death by it that they feel the need to write those "Why Lisp suck for
X development" articles and warn others against using it?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
"Paolo Amoroso" <·······@mclink.it> wrote in message
···················@plato.moon.paoloamoroso.it...
> "xstream" <·······@attglobal.net> writes:
>
> > Has anyone seen anywhere a technical rebuttal to the positions this
article
> > takes?
> >
> > http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
>
> If Lisp really sucks for X development, why are people so scared to
> death by it that they feel the need to write those "Why Lisp suck for
> X development" articles and warn others against using it?
>
>
> Paolo
> --
> Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
> Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
> - ASDF/ASDF-INSTALL: system building/installation
> - CL-PPCRE: regular expressions
> - UFFI: Foreign Function Interface
People are insecure (especially when their knowledge is half-baked) as you
know. No wonder about it.
My point was though focused on the idea that there must be a set of ways to
attract attention by potential users who can embrace the language as a tool
for their trade, be it game development or not.
Let me share some background with everyone in this thread. I appreciate the
enthusiastic comments. Apparently defending Lisp's merits is a subject many
of us care deeply about.
I am not a SW engineer. I happen to be SOC (system on a chip) architect and
designer with particular emphasis on RF microelectronics and
(military/intelligence-grade) secure communications. Technical books I have
authored and coauthored can be checked out at Amazon.com if someone is
interested in details. My personal case however might be an interesting
example for others to consider as to how we could go about attracting people
to Lisp.
Not everyone we should be targeting is a full time programmer. I originally
came to Lisp because when I was working at IBM back in the early 80's when
Cyril Alberga etc. from Yorktown Heights had put together what came to be
known as Lisp/VM (in spite of the rest of the world pushing at that time
towards some sort of Lisp core commonality) I was impressed by the
functional paradigm approach and by the concept of (believe it or not)
macros. It did not take much for me to become a believer. Subsequently of
course we ported Lucid's Lisp on the ROMP CPU (that inconjunction with the
Rosetta memory managemen chip and the virtual resounces manager VRM)
eventually became RT/PC with AIX and IBM's beginning of the Unix and RISC
era (in commercial offerings at least). But the tool-building mentality
using Lisp as my Swiss Army knife became engraved in my mind. Soon I'd be
testing my own bit-true DSP simulators or matrix diagonalization tools for
linear algebra, etc. written in Lisp. A new world was opened up in front of
me. "Revelation" is the word I can come up with. I am sure people from this
group would dance circles around me in improving performance of what I
coded, but I was interested in results for my work and guess what, Lisp was
getting them for me, easily and fast.
I am a high-speed communications hardware designer but I am elated to say
that Lisp is an awesome tool purely and simply. It satisfies your need
(almost whatever it is) and it does so by feeding the intellect. I have
looked at all types of tools and environments especially for HW architecture
specification and modeling and besides some truly original (but completely
unreadable to lay people) work in APL by Ken Iverson himself (who described
the whole IBM S/370 architecture in a few pages of APL) I have seen nothing
else come close to Lisp as a manipulatable tool-generator tool. By far, the
best kept secret in hardware design. Why is it so? Is it because of our
financial obligations in what Paul Graham calls "our day jobs" that we don't
have the time? Or are we too snobbish to mix with the programming masses and
convince them that .... the wheel has already been invented long ago?
I am not considering myself a SW engineer although I can easily code data
structures and algorithms in a handful of languages. It is a delightful
experience though to be able to hands-on compete with fresh college
graduates who swear by C++ or Java, by coding a quick solution to a problem
in 1/50-th of their code size and CPU cycles. People are in awe when they
realize what a tool this is and how it allows you to do what Paul Graham
succinctly describes as "painter-like sketching, smearing, smudging" while
writing code in a top-down approach.
IMHO it is almost criminal that so few people know about Lisp's
capabilities. I have met it originally by sheer coincidence, I embraced it,
came to love it, and have been using it even in my spare time to program all
types of projects (and I repeat I am not a hacker). I have even IMPOSED it
(whenever I could) as manager in all companies and government groups I have
worked with ever since, including my 4 startups (one of which has been sold
a few years ago in a successful IPO). My people and I have dreamed of and
implemented tools, profilers, and multiple simulators at different levels of
abstraction from scenario scripting to switching behavior analysis, from
protocol handshake simulation to chip timing closure for the silicon foundry
and even for low-power consumption management in autonomous flying vehicles.
Our tools cannot make it to the open market for many reasons; some although
functional are not well documented, because we never had the time to do it,
some are proprietary knowhow and we cannot disclose them without losing our
edge, some are simply highly classified work, etc. But (from my vantage
point) I do pity HW or communications engineers who today struggle with
kludgy SystemC trying to do what they think is "state-of-the-art" top-down
behavioral modeling in a (Pascal-like for crying out loud) HDL environment.
Maybe one day they will find out about Lisp. Or maybe the Lisp community can
create a "SystemLisp" initiative along similar lines that will attract the
attention of the EDA communities and of the startups, system OEMs, and
design-house industry blowing C and its freaking pointer mess out of the HW
design water.
I cannot imagine doing any type of creative work without Lisp as the basic
tool. I have been "forcing" my younger hires to read Paul Graham, Wilensky,
Norvig, of course Abelson and Sussman, Steele's AIM memos, Keene's work on
CLOS, Gabriel's write-ups, etc. Or "opinonated" pages with lots of substance
like Pascal Costanza's, etc. That is the only way for people to start seeing
the point. There are trees and then there is a forest. Lisp is not an
ordinary language. If it is introduced and taught as just another syntax, no
wonder we are going to be getting the kind of crappy feedback we just read
in that article from people who know little and nevertheless dare draw
sweeping conclusions. There is an unbelievable amount of expertise and
intellectual wealth among this community. I have been using in real-life the
prowess of this language for 25 years now and I am continually humbled to
see so many others who have mastered infinitely more than me on tons of
aspects of Lisp. Continuously learning is a gratification for intellectually
curious people. I agree that there is no way back once this powerful
language is seen by anyone with anything above average intelligence. But it
will take opinionated dedicated missionary-like work from the high school
level, where kids start getting exposed to programming, in order to create a
context within which they can possibly realize and embrace the beauty and
sheer power of Lisp before they go to college or get out into life. I
confess that I have no clear overriding idea as to how we can go about
disseminating this contagious intellectual tool called Lisp by showing how
"it can get the job done faster, better, and less expensively based on
multiple metrics" (along the lines of one of the other responders who talked
about payback time, etc.). I have been preaching and demonstrating its
virtues to my surroundings and even to my own kids trying to make them
believers and then "apostles" too, but I am just one swimmer in the mid of
the ocean. I know there are others too, but there is a lot of water between
us and we cannot see each other. For all practical purposes we are each one
of us alone in the ocean.
Maybe I am a dreamer, or maybe inadvertently I am committing a "faux pas" by
repeating in public what we all know but have chosen to not talk about
anymore, but I do think we have not been good at promulgating our message by
properly targeting the intended audiences. We have been blindly shooting at
all azimuth angles imaginable, hoping we will bring down a partridge or two.
This is hope, and to quote an unrelated book title that I saw on a bookshelf
the other day "hope is not a plan".
Thanks again for everyone's time, patience with me, kindness, and insight.
Panos C. Lekkas
"xstream" <·······@attglobal.net> wrote:
> I have been preaching
> and demonstrating its virtues to my surroundings and even to my own
> kids trying to make them believers and then "apostles" too, but I am
> just one swimmer in the mid of the ocean. I know there are others too,
> but there is a lot of water between us and we cannot see each other.
> For all practical purposes we are each one of us alone in the ocean.
Amen ;-)
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
"xstream" <·······@attglobal.net> writes:
> tool. I have been "forcing" my younger hires to read Paul Graham, Wilensky,
> Norvig, of course Abelson and Sussman, Steele's AIM memos, Keene's work on
> CLOS, Gabriel's write-ups, etc. Or "opinonated" pages with lots of substance
> like Pascal Costanza's, etc. That is the only way for people to start seeing
You may check the "Evaluating Lisp" page at the ALU CLiki site:
http://alu.cliki.net
Of course, feel free to share some of your own experiences, if they
are not related to confidential projects.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
"xstream" <·······@attglobal.net> wrote in message news:<···············@corp.supernews.com>...
> (almost whatever it is) and it does so by feeding the intellect. I have
> looked at all types of tools and environments especially for HW architecture
> specification and modeling and besides some truly original (but completely
> unreadable to lay people) work in APL by Ken Iverson himself (who described
> the whole IBM S/370 architecture in a few pages of APL) I have seen nothing
> else come close to Lisp as a manipulatable tool-generator tool. By far, the
Can you tell us something about the merits of APL vs. Lisp?
Thanks
I think I know some things about Lisp by the mere fact of having heavily
used it over the years, but I don't know APL anywhere so well. My answer
therefore will be rather circumspect.
What has struck me is that if we in the larger Lisp community (assuming that
my unworthiness can be included in the same wide realm as some of the really
big brains of this thread-discussion, and I mean this very respectfully)
take pride in comparing Lisp-coded cases as being deliverable in much fewer
lines of code against say Java, or C, or C++ programs that solve the same
problem in significantly more lines of code, the APL community seemed to be
fighting the similar performance argument mainly among themselves, debating
whose code (accepting the application would only be just ... one line long
of APL "hieroglyphics") could be written with the smallest number of
characters/symbols on the line before the carriage return. That says rather
a lot about APL.
That said, my limited APL exposure has shown it to me as being a mostly
unreadable language. I cannot comment about its overall merits as a
programming language but I can tell you it did scare me and many other
non-programmers away from it.
As a non-SW engineer I have not been willing to learn how to write APL
(however I could read annotated APL descriptions of hardware architecture
and took the language-inventor/author's word for its semantics) although I
have been able to understand and pick up Lisp readily (of course in order to
become fluent in it, it has taken me years and getting there it has
generated for me lots of gray hair). I know that APL and its successor APL2
have been extremely well used for corporate data-center applications based
on database queries back in the early 80's and I know some people who would
then swear by it, but so what? I also knew some people who would just spit
out IBM S/370-assembly as if it were Fortran. I believed this level of
skills in APL to be of note only as a marginal intellectual accomplishment
(like being able to boast you read Sanskrit or Khmer without realizing that
it probably does not really matter if someone else doesn't) of dubious
value, than as an endorsing expression of APL's "wide" programming
capabilities. Otherwise there would be tons of tools/applications/interfaces
and/or literature on it since that time.
Of course, it may have happened and perhaps passed me by, in which case I
may have completely missed it....... :-)
Panos C. Lekkas
"thelifter" <·········@gmx.net> wrote in message
·································@posting.google.com...
> "xstream" <·······@attglobal.net> wrote in message
news:<···············@corp.supernews.com>...
> > (almost whatever it is) and it does so by feeding the intellect. I have
> > looked at all types of tools and environments especially for HW
architecture
> > specification and modeling and besides some truly original (but
completely
> > unreadable to lay people) work in APL by Ken Iverson himself (who
described
> > the whole IBM S/370 architecture in a few pages of APL) I have seen
nothing
> > else come close to Lisp as a manipulatable tool-generator tool. By far,
the
>
> Can you tell us something about the merits of APL vs. Lisp?
>
> Thanks
xstream wrote:
> I think I know some things about Lisp by the mere fact of having heavily
> used it over the years, but I don't know APL anywhere so well. My answer
> therefore will be rather circumspect.
>
> What has struck me is that if we in the larger Lisp community (assuming that
> my unworthiness can be included in the same wide realm as some of the really
> big brains of this thread-discussion, and I mean this very respectfully)
> take pride in comparing Lisp-coded cases as being deliverable in much fewer
> lines of code against say Java, or C, or C++ programs that solve the same
> problem in significantly more lines of code, the APL community seemed to be
> fighting the similar performance argument mainly among themselves, debating
> whose code (accepting the application would only be just ... one line long
> of APL "hieroglyphics") could be written with the smallest number of
> characters/symbols on the line before the carriage return. That says rather
> a lot about APL.
Well, there is shorter and there is shorter. the exciting thing is that
Lisp is actually rather verbose, character-count-wise. That is because
it does not use ·@$^&·@;=:& to convey things. If I am reading Lisp for
the first tine I might have to look up destructuring-bind, but at least
I have something to look up, not a bunch of punctuation.
I say "exciting" because, damn, if the language is so verbose, how the
hell /does/ the code end up so short?
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Svein Ove Aas
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <clg0u5$mb5$3@services.kq.no>
Kenny Tilton wrote:
> Well, there is shorter and there is shorter. the exciting thing is that
> Lisp is actually rather verbose, character-count-wise. That is because
> it does not use ·@$^&·@;=:& to convey things. If I am reading Lisp for
> the first tine I might have to look up destructuring-bind, but at least
> I have something to look up, not a bunch of punctuation.
>
That's true, thankfully, but does longer descriptors really mean more
keypresses?
You don't get tab-completion in C, after all. I think measuring the number
of keypresses per the number of characters written might give interesting
results.
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
···························@twister.nyc.rr.com...
>
> Well, there is shorter and there is shorter. the exciting thing is that
> Lisp is actually rather verbose, character-count-wise. That is because
> it does not use ·@$^&·@;=:& to convey things. If I am reading Lisp for
> the first tine I might have to look up destructuring-bind, but at least
> I have something to look up, not a bunch of punctuation.
>
> I say "exciting" because, damn, if the language is so verbose, how the
> hell /does/ the code end up so short?
>
> :)
>
> kenny
>
I think the answer to your implicit question (which most of us understand)
is precisely "data abstraction". APL may be operationally powerful for those
few who know its syntax and semantics, but APL is not known for the
combination of abstraction and readability, something Lisp can excel in if
one applies some sensible discipline in the coding process (assuming, that
is, that one builds both the application down to the language and the
language up to the application). You can afford then to be "verbose" because
you have abstracted yourself away from the intricate details, which can be
looked up only if and when needed. If I need to learn how to drive a car and
in order to this correctly I must understand enough of how it works, why on
earth would I need to study the proprietary compression-curve dependency on
the geometric positioning of intake valves at different locations on the the
cylinder's piston?
That is the inherent beauty of Lisp; being "verbose", yet concise and short
in produced code length.
Panos C. Lekkas
From: Christopher C. Stacy
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <usm84ras3.fsf@news.dtpq.com>
"xstream" <·······@attglobal.net> writes:
> That said, my limited APL exposure has shown it to me as being a mostly
> unreadable language. I cannot comment about its overall merits as a
> programming language but I can tell you it did scare me and many other
> non-programmers away from it.
I would suggest that your exposure to APL has been extremely limited,
since APL code it is not generally unreadable to APL programmers.
(At least, good APL code is quite readable.)
From: Edi Weitz
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <uu0skecml.fsf@agharta.de>
On Sun, 24 Oct 2004 04:42:39 GMT, ······@news.dtpq.com (Christopher C. Stacy) wrote:
> I would suggest that your exposure to APL has been extremely
> limited, since APL code it is not generally unreadable to APL
> programmers. (At least, good APL code is quite readable.)
I'm pretty sure Perl programmers will say the same about Perl.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Svein Ove Aas
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <clg0ob$mb5$2@services.kq.no>
Edi Weitz wrote:
> On Sun, 24 Oct 2004 04:42:39 GMT, ······@news.dtpq.com (Christopher C.
> Stacy) wrote:
>
>> I would suggest that your exposure to APL has been extremely
>> limited, since APL code it is not generally unreadable to APL
>> programmers. (At least, good APL code is quite readable.)
>
> I'm pretty sure Perl programmers will say the same about Perl.
>
I find good Perl code to be about as readable as good C code, and I know
both languages quite well.
Is it possible that prolonged exposure to Lisp causes a value-distortion
wherein the more primitive languages seem harder to read simply because
they're less dense and need way more fluff to do the same thing?
It would appear likely. Oh well, where was I...
From: Christopher C. Stacy
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <uacucozn4.fsf@news.dtpq.com>
Edi Weitz <········@agharta.de> writes:
> On Sun, 24 Oct 2004 04:42:39 GMT, ······@news.dtpq.com (Christopher C. Stacy) wrote:
>
> > I would suggest that your exposure to APL has been extremely
> > limited, since APL code it is not generally unreadable to APL
> > programmers. (At least, good APL code is quite readable.)
>
> I'm pretty sure Perl programmers will say the same about Perl.
Yeah, but they're wrong.
(Seriously!)
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> "xstream" <·······@attglobal.net> writes:
> > That said, my limited APL exposure has shown it to me as being a mostly
> > unreadable language. I cannot comment about its overall merits as a
> > programming language but I can tell you it did scare me and many other
> > non-programmers away from it.
>
> I would suggest that your exposure to APL has been extremely limited,
> since APL code it is not generally unreadable to APL programmers.
> (At least, good APL code is quite readable.)
>
We do not really disagree although I have seen good APL programmers struggle
reading other people's code. I have eben seen APL programmers argue as to
what some piece of code "is doing". My statement was nevertheless focused to
code readability by non-APL experts.
If you read carefully my comments you must have seen that I am not
disparaging APL. On the contrary I have found it fascinating how it has been
creatively and imaginatively used to describe in detail the hardware
architecture of S/370 mainframes. However, I believe that Lisp offers a more
significant advantage when it comes down to readability by those who DO NOT
know the Lisp language well, as apposed to those who try to understand APL
code without being experts in APL. In Lisp (despite my not being a language
hacker) I can write (and name) macros that (i) shorten my ultimate code
product and while doing so (ii) elucidate both flow control and operational
processes, thereby making my code legible, modular, maintainable, and better
documented. I am sure others more specialized in the language would do it
even better than me. How many people can claim something similar for APL
though? I believe few and they are the exception among APL programmers not
the rule. My humble opinion. :-)
Panos C. Lekkas
"xstream" <·······@attglobal.net> writes:
> Let me share some background with everyone in this thread. I appreciate the
> enthusiastic comments. Apparently defending Lisp's merits is a subject many
> of us care deeply about.
>
> I am not a SW engineer. I happen to be SOC (system on a chip) architect and
> designer with particular emphasis on RF microelectronics and
> (military/intelligence-grade) secure communications. Technical books I have
> authored and coauthored can be checked out at Amazon.com if someone is
> interested in details. My personal case however might be an interesting
> example for others to consider as to how we could go about attracting people
> to Lisp.
Nice:
http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Lekkas%2C%252520Panos%252520C./103-6784548-2532637
> Panos C. Lekkas
Very nice speach. I'm glad google will remember it.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Thank you.
Panos
"David Steuber" <·····@david-steuber.com> wrote in message
···················@david-steuber.com...
> "xstream" <·······@attglobal.net> writes:
>
> > Let me share some background with everyone in this thread. I appreciate
the
> > enthusiastic comments. Apparently defending Lisp's merits is a subject
many
> > of us care deeply about.
> >
> > I am not a SW engineer. I happen to be SOC (system on a chip) architect
and
> > designer with particular emphasis on RF microelectronics and
> > (military/intelligence-grade) secure communications. Technical books I
have
> > authored and coauthored can be checked out at Amazon.com if someone is
> > interested in details. My personal case however might be an interesting
> > example for others to consider as to how we could go about attracting
people
> > to Lisp.
>
> Nice:
>
>
http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=Lekkas%2C%252520Panos%252520C./103-6784548-2532637
>
> > Panos C. Lekkas
>
> Very nice speach. I'm glad google will remember it.
>
> --
> An ideal world is left as an excercise to the reader.
> --- Paul Graham, On Lisp 8.1
"xstream" <·······@attglobal.net> wrote in message news:<···············@corp.supernews.com>...
> Has anyone seen anywhere a technical rebuttal to the positions this article
> takes?
>
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
>
Hi everybody! I've written a response to some of the criticisms raised
in this thread, as well as some criticisms raised by an earlier thread
(last month) that I missed until now.
http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
I hope it will help people understand my point of view.
From: Wade Humeniuk
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <3Hged.48572$qU.8092@clgrps13>
Jack Palevich wrote:
>
> Hi everybody! I've written a response to some of the criticisms raised
> in this thread, as well as some criticisms raised by an earlier thread
> (last month) that I missed until now.
>
> http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
>
> I hope it will help people understand my point of view.
So you are saying that by putzing around with some Lisps for a little
while that you have exhausted the possible solutions in Lisp. While the
C/C++ developers have spent much time (probably 100's of thousands of man years)
honing their engines. Do you think this is fair?
A lot could be done for gaming with Lisp on a $20,000,000 budget. How much was spent
to develop Visual Studio 2005's C++ compiler?
C/C++ works for game development because the time, thought and effort
that have been put into it. If Lisp were used it would also take
time and effort. I am surprised that anyone would think that is a surprise.
Wade
From: Neo-LISPer
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <878y9xixnx.fsf@yahoo.com>
············@yahoo.com (Jack Palevich) writes:
> http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
How does your theory explain Naughty Dog's success and their comments
like "Lisp was just the best solution for the job"?
Neo-LISPer <··········@yahoo.com> wrote in message news:<··············@yahoo.com>...
> ············@yahoo.com (Jack Palevich) writes:
>
> > http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
>
> How does your theory explain Naughty Dog's success and their comments
> like "Lisp was just the best solution for the job"?
I believe Naughty Dog is a very talented game company, and would be
able to produce excellent games in any language.
The head programmer of Naughty Dog likes Lisp, and he's probably the
reason they've invested heavily in Lisp, and why you see glowing
quotes.
In article <····························@posting.google.com>,
············@yahoo.com (Jack Palevich) wrote:
> Neo-LISPer <··········@yahoo.com> wrote in message news:<··············@yahoo.com>...
> > ············@yahoo.com (Jack Palevich) writes:
> >
> > > http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
> >
> > How does your theory explain Naughty Dog's success and their comments
> > like "Lisp was just the best solution for the job"?
>
> I believe Naughty Dog is a very talented game company, and would be
> able to produce excellent games in any language.
Think again. "Any language" does not make sense.
Atleast it shows that you *can* create a very competetive
graphics&animation engine in some kind of Lisp. The
reviews I have read about the graphics and animation in Jak II
were mostly very positive (from people not knowing that Jak II
is based on some 900klocs of Lisp code - plus some other stuff).
I don't think I have read once that their graphics is slow
or sluggish. Instead most comments were very positive about the
performance, the complexity of the graphics, etc.
> The head programmer of Naughty Dog likes Lisp, and he's probably the
> reason they've invested heavily in Lisp, and why you see glowing
> quotes.
Whether he likes Lisp or not, the technical execution of their games
seems to be quite good. Competetive with other C/C++ based games
I would say.
I have to admit that I'm not a game programmer - but I have enjoyed
Crash Bandicoot on the Playstation. :-)
Neo-LISPer <··········@yahoo.com> wrote in message news:<··············@yahoo.com>...
> ············@yahoo.com (Jack Palevich) writes:
>
> > http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
>
> How does your theory explain Naughty Dog's success and their comments
> like "Lisp was just the best solution for the job"?
The key developer was a Lisp guru's from MIT what else would he choose
;)
BTW: Naughty Dog is now doing most of the core engine in Assembly,
not Lisp...probably for the same performance reasons outlined in this
thread.
Neo-LISPer <··········@yahoo.com> wrote:
> ············@yahoo.com (Jack Palevich) writes:
>
>> http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
>
> How does your theory explain Naughty Dog's success and their comments
> like "Lisp was just the best solution for the job"?
Naughty Dog's platform was also used to build "Ratchet and Clank". Fantastic
game.
Neil
Jack Palevich wrote:
> "xstream" <·······@attglobal.net> wrote in message news:<···············@corp.supernews.com>...
>
>>Has anyone seen anywhere a technical rebuttal to the positions this article
>>takes?
>>
>>http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
>>
>
>
> Hi everybody! I've written a response to some of the criticisms raised
> in this thread, as well as some criticisms raised by an earlier thread
> (last month) that I missed until now.
>
> http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
>
> I hope it will help people understand my point of view.
Definitely, and thanks for dropping by. You really have me in a panic,
because I was hoping to do OpenGL from Lisp, but I can see that is out
the window. Maybe I can pick your brain a little? It is a rare
opportunity to have acces to someone with your deep games background.
It is a shame some people accused you of being a troll. Posting not one
but two pages that say something sucks should not be taken as a negative
or provocative, not nowadays. I mean, when fans are yelling "Yankees
suck!" or "Boston sucks!", certainly they mean no offense.
In your first article you mentioned:
> # They also say it's hard to find good Lisp programmers.
Wow, did we luck out at CliniSys! We placed one ad and got resumes from
names so big I recognized them, including one actual author of a Lisp
compiler. My partner has been a technical recruiter for thirty years and
says it was by far the strongest stack of resumes he'd ever seen.
> # ex-ND programmers have mentioned that Lisp macros can make code
written by other developers harder to understand.
Tell me about it! But then, /all/ code is hard for me to read. I always
have to go see what a function actually does, because I never trust the
name. And as for understanding a class hierarchy, good luck! And I am
talking about my own code.
But the problem with macros is that they hide so many details in the
name of making the code easier to follow. I'll tell you a little
secret--every time I find a macro some other developer has written, I
just macroexpand it and replace the macro code with the expansion. That
just leaves the functions and class definitions to understand. Whew!
> # Low performance, especially on modern processors
uh-oh. This I did not know about. All the Lisps I use compile to native
machine instructions. I was totally unaware the CPU could still figure
out that they had come from Lisp and run them slower. That sucks!
> # No module/library mechanism
Yeah, why did they have to call it "packages"?
> # No easy interface to C-based code
Agreed. It must have taken me three frickin days to master that FFI crap.
> # Lack of types makes it difficult to understand or safely modify large programs
Check. I see some parameter called font height and I cannot tell if it
is a number or a string or a structure or a character or a pointer --
well, no, Lisp does not have pointers, but I also do not know if the
font height is in pixels or twips or DPI, but if I could see it was an
int -- ok, no, that would not do me any good. Never mind.
In your follow-up:
> Criticism 2: You say one reason Lisp sucks for games is that performance sucks.
> But it doesn't have to suck: look at this example, by decorating my Lisp
> code with tons of declarations, and thereby restricting my use of the
> language to a subset that's the equivalent of C, then I can get
> performance that's on par with C.
Thank you so much for this. I thought I could get away with declarations
in just the small amount of compute-intensive stuff. I did not realize
the entire application would require declarations just to get 2% of the
code humming.
And I have been really dreading learning how to do declarations in Lisp.
I could see easily a day of study going straight down the drain. I would
much rather be using a language built around types, so i would be
concentrating on them 24-7 and would be able to code up the necessary
types for each variable and parameter in my sleep.
> Criticism 5: You hate Lisp, therefore you suck.
>
> * I may suck, but it's not because I hate Lisp. I like Lisp quite a bit.
> I just don't see it as useful for writing modern video games.
Well, I guess one good suck deserves another, but c'mon, you are a
Microsoft manager and C++ programmer considering using Lisp! These guys
should be cheering you. If Microsoft turns its back on a language, it
must be for good reason. Look at C# and Java. Microsoft was fully behind
the Java bandwagon, and did not start C# until a court order stopped
them from trying to fix it with great proprietary code that would have
made much Java better, albeit no longer portable to other OSes. Lawyers!
> * With the exception of Naughty Dog, nobody uses Lisp in modern game
> engines, and few developers use Lisp even as a scripting language.
Right, and when you consider how otherwise ubiquitous is the language,
the low penetration of the games market really stands out.
> Perhaps everyone else is stupid, or perhaps Lisp has issues.
Good one! Programmers are not stupid. They all tried Lisp and voted with
their feet. They use what works best. Just watch what all those Java
programmers do when they find out about C#. if only Microsoft had some
way to get the word out to developers.
> Before you flame me too much, consider if your love of Lisp is
> blinding you to its faults.
I think it has. It must have! I am a really good programmer, just like
you, but I have been using the program intensely for like eight years
and only since reading your Web pages I have been noticing fault after
fault. Now if only I could figure what I was in love with!
>
> Criticism 6: If you don't like Lisp, why did you write about it?
>
> * I'm trying to explain the drawbacks of Lisp to people who might be
> considering using Lisp for their game engines. I wish an
> article like mine had been available a few months ago, when
> I was starting to research the possibility of using Lisp
> for a game engine. All I found were cheerleading papers
> about how wonderful and high performance Lisp was, and how it
> was the perfect language for any large project.
Bulent laughed at me when I said Lisp had won, but there you go. The
hype on Lisp is so deep we need hip-waders. Shame on us, wasting three
months of a Microsoft manager. I mean, it is so bad that even tho he had
a Lisp-based undergraduate education at MIT (wow!) and used Lisp
professionally for two years it took him /three months/ to unravel all
the brainwashing.
Hell, I only had to read the CLIM spec for twenty minutes before
realizing... ohhhh, never mind.
> * I also found a ton of misinformed speculation on the
> suitability of Lisp for games.
> It bothered me to see so much misinformation.
Let me be the first of many games programmers to thank you for the extra
trouble you took, and I commend your courage in standing up to the
kneejerk attacks of these chauvinist jerks.
If they give you any more abuse, just put up a Sucks III page, and keep
it up until they understand the power a Microsoft C++ programmer has to
direct the minds of developers. That'll teach them!
You know, a year ago Lisp had to worry about rumors of our death. You
have proved that, like polio, Lisp is back. I hope this time folks do
not rest until it is truly stamped out.
> * It's true that the sensible thing to do would be to
> just ignore Lisp entirely. But for whatever reason, I
> find I can't leave it alone. Back in the early
> 80's it was pretty darn amazing, and I guess I'll
> always have a soft spot in my heart for it.
>
It shows.
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
It's all fine to reply to the original criticism, but not forgetting
the space domain it talks about. Game programming isn't at all like
any standard application programming or gui programming you know
about.
o low frame per second can not be tolerated, and sometimes a constant
frame per second is required. (for physics simulation)
This precludes making use of any interactive intepretive
read-eval-loop at the beginning of the development, as any non
optimized code you may add in the inner loop may completly kill the
results. Or start to massively CONS. (see next)
o Jitter can not be tolerated
The human eye and ear dislikes jitter. And it breaks the immersive
quality games look for. Garbage collection must thus be somehow cut or
reduce to the minimum. Stalling like that also completly kills the
interpretation of user's inputs. This causes heavy game play problems.
o Cohabit with the C world
A substantial part of a work will have been coded in C (third-party
libraries notably, audio engines etc)
The runtime must cohabit with this in a polite way, and must not
assume it has all the cpu and memory. Notably through support of
threads: no global lock around the runtime, enable C code to call lisp
and lisp call the C code even in multiple threads. Leave enough memory
for C allocations.
o Support for totally unboxed floating point in the FFI
To avoid putting pressure on the GC, it is required to use unboxed
floating-point in the inner loop.
There will be lots of coordinates to handle
o Adequate and maintenable FFI layer
Coding and maintaining by hand a FFI layer, because the ffi requires
declaration of all the used C types and functions is an overhead
(notably when the APIs are changing, as libraries evolve) that is not
all that acceptable in a small team.
o One usually doesn't have the budget to maintain a compiler for all
the specific targets (ps2, gamecube, xbox)
Tool making is a very important part of game-making, but it is a far
more constrained topic than what compiler making is.
o C/C++ Game developers are cheap
---
> o Jitter can not be tolerated
>
> The human eye and ear dislikes jitter. And it breaks the immersive
> quality games look for. Garbage collection must thus be somehow cut or
> reduce to the minimum. Stalling like that also completly kills the
> interpretation of user's inputs. This causes heavy game play problems.
People use Java to write games all the time. It has a GC. I agree that
GC would have to be fast if it is done at all. GC'ing peices of code
is usually better for intesive apps, that the user can aford to wait a
few milliseconds for someting to happen. Games on intensive apps where
users can't wait.
I've been thinking a lot about programming games in Lisp, as that is
how I got started with the whole prgramming thing. I wanted to write
games. Eventually, I realized that I was spending most of my time
concetrating on the AI part of the games I was trying to write, and
now I'm here.
However, I think that the jitter problem can be avoided if for the
video streaming\sound parts of the game, the programmer uses
keyworded types such as :integer, etc. Video and sound parts of games
have been written so many times, I don't see a problem with them being
strongly typed at least for a game. For the rest of the game (AI,
physics, etc) you could use dynamic typing, and only GC at certain
times (when the game is being saved). Is there anyway to do this with
a GC? I have a feeling that the folks at Naughty Dog did something
similar to this.
--
Certum quod factum.
Philip Haddad
·············@gmail.com (Philip Haddad) wrote in message news:<····························@posting.google.com>...
> > o Jitter can not be tolerated
> >
> > The human eye and ear dislikes jitter. And it breaks the immersive
> > quality games look for. Garbage collection must thus be somehow cut or
> > reduce to the minimum. Stalling like that also completly kills the
> > interpretation of user's inputs. This causes heavy game play problems.
>
> People use Java to write games all the time. It has a GC. I agree that
> GC would have to be fast if it is done at all. GC'ing peices of code
> is usually better for intesive apps, that the user can aford to wait a
> few milliseconds for someting to happen. Games on intensive apps where
> users can't wait.
People use Java to write games and they could use Lisp as well. But
you couldn't write something like Doom 3 or HL2 in either...yet. In a
few years the hardware will be moved up enough that they can be done
and playable though (like the Q2/Q3 conversions being done in Java).
I think this entire discussion is flawed TBH.
It really depends on the type of game you want to write. For high
perforamnce cutting edge 3D games, I still believe that C/C++ is the
best to use, but for games with less demanding interfaces,
Lisp/Python/Java might as well be used.
From: Wade Humeniuk
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <eAted.40806$z96.8607@clgrps12>
Philip Haddad wrote:
> physics, etc) you could use dynamic typing, and only GC at certain
> times (when the game is being saved). Is there anyway to do this with
> a GC? I have a feeling that the folks at Naughty Dog did something
> similar to this.
>
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
From my reading of it, they developed GOAL and a compiler that compiles the game
that actually runs on the Playstation. There is probably no gc in the running
image. They probably has the game running under a Allegro CL image
on their development machine to develop and shake out bugs.
It's stated they valued expressiveness, a virtue of Lisp.
Wade
From: Matthew Danish
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87r7nputge.fsf@mapcar.org>
····@free.fr (n++k) writes:
> This precludes making use of any interactive intepretive
> read-eval-loop at the beginning of the development, as any non
> optimized code you may add in the inner loop may completly kill the
> results. Or start to massively CONS. (see next)
No it doesn't, actually, since most interactive read-eval-print-loops
are just as fully optimized and compiled as code in files. I can
verify this from personal experience, having modified my CL-SDL
programs in mid-run and having them continue to run without problems.
(Using threads, too).
> o Jitter can not be tolerated
>
> The human eye and ear dislikes jitter. And it breaks the immersive
> quality games look for. Garbage collection must thus be somehow cut or
> reduce to the minimum. Stalling like that also completly kills the
> interpretation of user's inputs. This causes heavy game play problems.
Not too difficult, so long as you don't play fast and loose with
memory in the inner loop.
> o Cohabit with the C world
>
> A substantial part of a work will have been coded in C (third-party
> libraries notably, audio engines etc)
>
> The runtime must cohabit with this in a polite way, and must not
> assume it has all the cpu and memory. Notably through support of
> threads: no global lock around the runtime, enable C code to call lisp
> and lisp call the C code even in multiple threads. Leave enough memory
> for C allocations.
This, unfortunately, I only got working one way: Lisp -> C. It was
enough for my purposes. Kenny, who works in Allegro mostly, has FFI
going both ways.
> o Support for totally unboxed floating point in the FFI
>
> To avoid putting pressure on the GC, it is required to use unboxed
> floating-point in the inner loop.
CMUCL can do this. It can use unboxed values wherever it can prove
that they won't escape. Just exploit closures, and arrays which can
also be unboxed.
> o Adequate and maintenable FFI layer
>
> Coding and maintaining by hand a FFI layer, because the ffi requires
> declaration of all the used C types and functions is an overhead
> (notably when the APIs are changing, as libraries evolve) that is not
> all that acceptable in a small team.
Not sure why this has to be maintained by hand? Plenty of automated
tools nowadays. I happened to do CL-SDL by hand, but that is after I
received the automatically generated code for OpenGL FFI declarations
that Timo was working on; SDL was much smaller by comparison.
> o One usually doesn't have the budget to maintain a compiler for all
> the specific targets (ps2, gamecube, xbox)
Yes, my target was already established: Linux. I don't know about
consoles.
> o C/C++ Game developers are cheap
Don't you get what you pay for? =)
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
[I don't have a horse in this race.]
Although some of your arguments make sense, the following
three do not -- at least to me, and as currently written.
In article <····························@posting.google.com>,
····@free.fr (n++k) wrote:
> o low frame per second can not be tolerated, and sometimes a constant
> frame per second is required. (for physics simulation)
>
> This precludes making use of any interactive intepretive
> read-eval-loop at the beginning of the development, as any non
> optimized code you may add in the inner loop may completly kill the
> results. Or start to massively CONS. (see next)
My experience is that the beginning of development is
precisely the time when speed can be sacrificed to the
goal of understanding the problem at hand and erecting
a suitable foundation for the rest of the project. But
even if you don't agree, then just use a Common Lisp that
compiles *everything*, such as Macintosh Common Lisp
(which lacks an interpreter altogether) or add
declarations and compile everything like you would if you
were writing in C.
> o Support for totally unboxed floating point in the FFI
>
> To avoid putting pressure on the GC, it is required to use unboxed
> floating-point in the inner loop.
I though Richard Fateman and others (Duane?) have shown
that anything numerics C can do, Common Lisp can do just
as fast. Is this another case of penalizing Lisp for
making optional the declarations C demands, even in the
initial stages and outside the hotspots?
> o C/C++ Game developers are cheap
Do you get what you pay for? That is, this is only a
criticism *if* both Common Lisp and C programmers can
do the job -- then it's all about economics. And then
the question really reduces to a cost/benefit analysis:
which language's programmers offer better bang for the
buck?
····@free.fr (n++k) writes:
> o C/C++ Game developers are cheap
They will drink Bud Light over Sierra Nevada Bigfoot Ale? Not only
would that make them cheap, it means they have bad taste.
That was my favorite bullet point.
I've seen jitter from C code too. It ain't pretty.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Wow Kenny, good one! Pretending to be swayed by my arguments, but
actully cleverly rebutted each one. It really makes me want to
consider your point of view!
Oh wait, no it doesn't. It makes me think you must be a smug Lisp
weenie who doesn't know anything about the problem domain I'm
operating in.
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·····················@twister.nyc.rr.com>...
> Jack Palevich wrote:
>
> > "xstream" <·······@attglobal.net> wrote in message news:<···············@corp.supernews.com>...
> >
> >>Has anyone seen anywhere a technical rebuttal to the positions this article
> >>takes?
> >>
> >>http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
> >>
> >
> >
> > Hi everybody! I've written a response to some of the criticisms raised
> > in this thread, as well as some criticisms raised by an earlier thread
> > (last month) that I missed until now.
> >
> > http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
> >
> > I hope it will help people understand my point of view.
>
> Definitely, and thanks for dropping by. You really have me in a panic,
> because I was hoping to do OpenGL from Lisp, but I can see that is out
> the window. Maybe I can pick your brain a little? It is a rare
> opportunity to have acces to someone with your deep games background.
>
> It is a shame some people accused you of being a troll. Posting not one
> but two pages that say something sucks should not be taken as a negative
> or provocative, not nowadays. I mean, when fans are yelling "Yankees
> suck!" or "Boston sucks!", certainly they mean no offense.
>
> In your first article you mentioned:
>
> > # They also say it's hard to find good Lisp programmers.
>
> Wow, did we luck out at CliniSys! We placed one ad and got resumes from
> names so big I recognized them, including one actual author of a Lisp
> compiler. My partner has been a technical recruiter for thirty years and
> says it was by far the strongest stack of resumes he'd ever seen.
>
> > # ex-ND programmers have mentioned that Lisp macros can make code
> written by other developers harder to understand.
>
> Tell me about it! But then, /all/ code is hard for me to read. I always
> have to go see what a function actually does, because I never trust the
> name. And as for understanding a class hierarchy, good luck! And I am
> talking about my own code.
>
> But the problem with macros is that they hide so many details in the
> name of making the code easier to follow. I'll tell you a little
> secret--every time I find a macro some other developer has written, I
> just macroexpand it and replace the macro code with the expansion. That
> just leaves the functions and class definitions to understand. Whew!
>
> > # Low performance, especially on modern processors
>
> uh-oh. This I did not know about. All the Lisps I use compile to native
> machine instructions. I was totally unaware the CPU could still figure
> out that they had come from Lisp and run them slower. That sucks!
>
> > # No module/library mechanism
>
> Yeah, why did they have to call it "packages"?
>
> > # No easy interface to C-based code
>
> Agreed. It must have taken me three frickin days to master that FFI crap.
>
>
> > # Lack of types makes it difficult to understand or safely modify large programs
>
> Check. I see some parameter called font height and I cannot tell if it
> is a number or a string or a structure or a character or a pointer --
> well, no, Lisp does not have pointers, but I also do not know if the
> font height is in pixels or twips or DPI, but if I could see it was an
> int -- ok, no, that would not do me any good. Never mind.
>
> In your follow-up:
>
> > Criticism 2: You say one reason Lisp sucks for games is that performance sucks.
> > But it doesn't have to suck: look at this example, by decorating my Lisp
> > code with tons of declarations, and thereby restricting my use of the
> > language to a subset that's the equivalent of C, then I can get
> > performance that's on par with C.
>
> Thank you so much for this. I thought I could get away with declarations
> in just the small amount of compute-intensive stuff. I did not realize
> the entire application would require declarations just to get 2% of the
> code humming.
>
> And I have been really dreading learning how to do declarations in Lisp.
> I could see easily a day of study going straight down the drain. I would
> much rather be using a language built around types, so i would be
> concentrating on them 24-7 and would be able to code up the necessary
> types for each variable and parameter in my sleep.
>
> > Criticism 5: You hate Lisp, therefore you suck.
> >
> > * I may suck, but it's not because I hate Lisp. I like Lisp quite a bit.
> > I just don't see it as useful for writing modern video games.
>
> Well, I guess one good suck deserves another, but c'mon, you are a
> Microsoft manager and C++ programmer considering using Lisp! These guys
> should be cheering you. If Microsoft turns its back on a language, it
> must be for good reason. Look at C# and Java. Microsoft was fully behind
> the Java bandwagon, and did not start C# until a court order stopped
> them from trying to fix it with great proprietary code that would have
> made much Java better, albeit no longer portable to other OSes. Lawyers!
>
> > * With the exception of Naughty Dog, nobody uses Lisp in modern game
> > engines, and few developers use Lisp even as a scripting language.
>
> Right, and when you consider how otherwise ubiquitous is the language,
> the low penetration of the games market really stands out.
>
> > Perhaps everyone else is stupid, or perhaps Lisp has issues.
>
> Good one! Programmers are not stupid. They all tried Lisp and voted with
> their feet. They use what works best. Just watch what all those Java
> programmers do when they find out about C#. if only Microsoft had some
> way to get the word out to developers.
>
>
> > Before you flame me too much, consider if your love of Lisp is
> > blinding you to its faults.
>
> I think it has. It must have! I am a really good programmer, just like
> you, but I have been using the program intensely for like eight years
> and only since reading your Web pages I have been noticing fault after
> fault. Now if only I could figure what I was in love with!
>
> >
> > Criticism 6: If you don't like Lisp, why did you write about it?
> >
> > * I'm trying to explain the drawbacks of Lisp to people who might be
> > considering using Lisp for their game engines. I wish an
> > article like mine had been available a few months ago, when
> > I was starting to research the possibility of using Lisp
> > for a game engine. All I found were cheerleading papers
> > about how wonderful and high performance Lisp was, and how it
> > was the perfect language for any large project.
>
> Bulent laughed at me when I said Lisp had won, but there you go. The
> hype on Lisp is so deep we need hip-waders. Shame on us, wasting three
> months of a Microsoft manager. I mean, it is so bad that even tho he had
> a Lisp-based undergraduate education at MIT (wow!) and used Lisp
> professionally for two years it took him /three months/ to unravel all
> the brainwashing.
>
> Hell, I only had to read the CLIM spec for twenty minutes before
> realizing... ohhhh, never mind.
>
> > * I also found a ton of misinformed speculation on the
> > suitability of Lisp for games.
> > It bothered me to see so much misinformation.
>
> Let me be the first of many games programmers to thank you for the extra
> trouble you took, and I commend your courage in standing up to the
> kneejerk attacks of these chauvinist jerks.
>
> If they give you any more abuse, just put up a Sucks III page, and keep
> it up until they understand the power a Microsoft C++ programmer has to
> direct the minds of developers. That'll teach them!
>
> You know, a year ago Lisp had to worry about rumors of our death. You
> have proved that, like polio, Lisp is back. I hope this time folks do
> not rest until it is truly stamped out.
>
> > * It's true that the sensible thing to do would be to
> > just ignore Lisp entirely. But for whatever reason, I
> > find I can't leave it alone. Back in the early
> > 80's it was pretty darn amazing, and I guess I'll
> > always have a soft spot in my heart for it.
> >
>
> It shows.
>
> :)
>
> kenny
Jack Palevich wrote:
> Wow Kenny, good one! Pretending to be swayed by my arguments, but
> actully cleverly rebutted each one. It really makes me want to
> consider your point of view!
>
Yes, and the fact linux geeks have a habit of calling Microsoft
Micro$oft makes their criticisms of windows security invalid. No,
wait, it doesn't. Actually, I thought some of Kenny's arguments
a bit weak (sorry Kenny), but you have not managed to invalidate
them - an ad hominem claiming Kenny doesn't understand the problem
domain is just silly as Kenny has already demonstrated some degree
of understanding of the problem domain.
I remember some of the assembler old-guard ranting publically against C
back in the day (Amiga gaming scene), too, and I just thought "hey,
people can write games in forth* for all I care, what matters is if the
game is fun."
(with-paranoia
"It is consistent with microsoftian zero-sum thinking to try to cripple
the competition: maybe microsoft has actually discovered lisp totally
rocks for games and therefore wishes to slow down adoption by
competitors.")
* And actually, ISTR, they did. People interested in Forth 3D
programming nowadays could check out BigForth/MINOS by Bernd Paysan
http://www.jwdt.com/~paysan/bigforth.html#MINOS
David Golden <············@oceanfree.net> wrote in message news:<6Qwed.39908
Hmmm..this is why I avoided mentioning Direct 3D and stuck with
OpenGL.
This entire thread seems to be turning into a religious debate. From
now on, I am Agnostic.
Someone build a Doom 4 in Lisp so we can end this thread! :D
David Golden wrote:
> Jack Palevich wrote:
>
>
>>Wow Kenny, good one! Pretending to be swayed by my arguments, but
>>actully cleverly rebutted each one. It really makes me want to
>>consider your point of view!
>>
>
>
> Yes, and the fact linux geeks have a habit of calling Microsoft
> Micro$oft makes their criticisms of windows security invalid. No,
> wait, it doesn't. Actually, I thought some of Kenny's arguments
> a bit weak (sorry Kenny)
I don't like being too precise when counter-trolling. But you have
committed Jack's sin of not saying what you thought was weak! <g>
Doesn't matter. I think the stuff I posted today from GameDev kinda slam
dunks the matter.
, but you have not managed to invalidate
> them - an ad hominem claiming Kenny doesn't understand the problem
> domain is just silly as Kenny has already demonstrated some degree
> of understanding of the problem domain.
The scary thing is that I was right about the graphics cards (and using
them wisely) are so huge a factor in the performance question that
differences between OpenGL and D3D/D3X disappear in the noise, as would
differences between Lisp and C++.
I musta got lucky on that one, not knowing anything about the domain. :)
> (with-paranoia
> "It is consistent with microsoftian zero-sum thinking to try to cripple
> the competition: maybe microsoft has actually discovered lisp totally
> rocks for games and therefore wishes to slow down adoption by
> competitors.")
The crazy thing is that it cannot work. Just having Microsoft take an
official position against Lisp helps Lisp as much as did Graham's
writing. There is no such thing as bad publicity.
I think Pavelich is really a Lispnik trying to promote Lisp -- who else
would serve up such fat pitches of misstatements and then leave factual
refutations unanswered?
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Jack Palevich wrote:
> Wow Kenny, good one! Pretending to be swayed by my arguments, but
> actully cleverly rebutted each one. It really makes me want to
> consider your point of view!
Oh, gosh, if I had only responded in good faith you would have stopped
spouting nonsense such as "Lisp cannot call C"? [Duane, you were right!
I should have reasoned with him!]
>
> Oh wait, no it doesn't. It makes me think you must be a smug Lisp
> weenie who doesn't know anything about the problem domain I'm
> operating in.
Good for you, don't get sucked into actually responding to the points
made. I think it was brilliant how your Sucks II simply did not address
any of the telling things said here in response to Sucks I. You have
been watching Dubbya debate, haven't you?
Anyway, I /am/ pretty stupid, but one of my monkeys was curious and went
over to Gamedev.net (a known hotbed of SLWs) to learn about the alleged
slowness of Direct3D vs OpenGL. If Gamedev is right, that is wrong. I am
surprised you did not pounce on that. Oh, wait, I see why: "Performance
is no longer an issue! <snip> performance is in the hands of the guys
who make graphics cards and drivers". He is talking about the race
between D3D and OG, but the point is still that performance is not in
the hands of either the application or even d3d/og, let alone C++ or Lisp.
Here is the full excerpt, from the d3d/og comparison:
http://www.gamedev.net/reference/articles/article1775.asp
"Performance and Quality Factors
I've carefully avoided mentioning performance for most of this article.
Why? There is a huge debate on the problem. There are many people who
claim that OGL is faster than D3D, and of course, the reverse as well.
I've been studying performance results: I've considered my own, my
friends', and the results of major companies. I have come to the
following conclusion: Performance is no longer an issue! The speed for
both APIs has come out exactly even for well written programs. The
performance can only be gauged per machine, and that by testing. There
is no way to predict which will run faster...<snip>.
I feel that I should still address what exactly it is that affects the
performance. If a game is well written, by people who know how to
properly use the API, then performance is in the hands of the guys who
make graphics cards and drivers. No one else has anything to do with it
anymore. What determines performance is how well the API, driver,
operating system, and hardware interact. On one of my computers, for
example, OpenGL runs somewhat faster. I do know, however, that this is
due to an incompatibility between DirectX and WindowsXP and my GeForce
MX100/200 card/driver.
The above applies a great deal to quality as well. The APIs don't really
have an edge over each other at all. The most important factor in
quality, however, is your artwork. A good artist will make even a bad
game look fantastic, but the converse applies as well. If you want
high-quality, get a high-quality artist. "
A high quality artist, and as someone else noted, an HQ story. But wait,
what do I know? Let's check in again, this time with those SLWs over at
Gamespot, on how they rate games:
http://www.gamespot.com/misc/reviewguidelines-2.html
"Graphics
This includes technical use of graphics, as well as the aesthetic
quality of a game's appearance and presentation. Games that look
impressive in still images do not automatically earn high graphics
scores, because the graphical performance of a game weighs heavily into
our consideration of its visuals.
Sound
This includes the quality and use of sound effects, voice acting, and
music in the game. Any of these may potentially have a significant
impact on the overall sound score. For instance, a game with an
excellent soundtrack and sound effects may still lose points for sound
if the voice acting is of low quality.
Gameplay
This includes everything, from the game's interface to its control to
how well balanced it is. Basically, this represents how well a game
plays and how enjoyable it is to play. Games very rarely earn a 10 in
this category, due to how elusive games with perfect or near-perfect
gameplay actually are.
Value
For the most part, a game's value score is an indicator of the game's
longevity. It represents how long you'll be able to both play and enjoy
the game, and it also signifies how much replay value you'll get out of
it. Breadth of gameplay options and overall volume of content both weigh
heavily into this score. The retail price of a game can also figure into
the value score, as can the presence or lack of similar, competitive
products in the market. Finally, the overall quality of the game has
some impact on its value, so, for instance, a bad game that's extremely
long is still probably not worth playing.
Reviewer's Tilt (Tilt)
This score basically lets a reviewer sway the final score--either higher
or lower--based on the reviewer's overall experience with a game. Here's
an example: A game might have really good graphics and sound but only
mediocre gameplay. As a result, it gets a low tilt score to keep the
overall from being boosted too high, since the game ultimately isn't
fun. Likewise, a game might have mediocre graphics and sound, but it
might include a really good story and a lot of original ideas. As a
result, it might get a high tilt to boost the overall score a bit, which
suggests to you that you should look beyond the game's production values."
You were right! Performance (which is now only a factor of the OS and
graphics card and machine power) is an important /part/ of the graphics
score, which is a /part/ of the overall score. That was your point, right?
[I have a letter into Gamespot asking them exactly how the sub-scores
are weighted. They do that, but I could not find the specific weights.]
By the way, I love that "head them off at the pass" move in which you
pretended you were looking in earnest at using Lisp for games
development. You work for Microsoft and already are a C++ whiz. But
earlier in that gamedev d3d/og comparison we see this:
"DirectX also provides something called the Direct3DX function library,
introduced with DirectX 7.0. This is a static library that provides gobs
of useful functions that help make your life easier. There is one catch,
though: many of the things that have been added are C++ specific.
D3DXMATRIX is derived from D3DMATRIX, for example, and many of the
operators are overloaded as well. Of course, if you're using C++ anyway,
this really isn't a problem."
So unless you also have your letter of resignation from Microsoft open
in another window, there is no way you would be considering anything
other than C++. But, hey, what chance is there that a bunch of SLWs
would know any of the above? None!
Don't worry, your secret is safe with me. Just don't blow it by actually
responding to anything of substance -- not that I have to tell you that!
kenny
Kenny Tilton wrote:
>
> [...]
>
> I feel that I should still address what exactly it is that affects the
> performance. If a game is well written, by people who know how to
> properly use the API, then performance is in the hands of the guys who
> make graphics cards and drivers. No one else has anything to do with
> it anymore. What determines performance is how well the API, driver,
> operating system, and hardware interact. On one of my computers, for
> example, OpenGL runs somewhat faster. I do know, however, that this is
> due to an incompatibility between DirectX and WindowsXP and my GeForce
> MX100/200 card/driver.
Maybe I missed some other discussion of it, but I think you also need to
consider
non-graphical display performance issues. For example, many games require
collision detection and/or physical simulation. If you have a game with
a bowling
ball knocking down pins, you need to simulate the physics and collisions
of those
pins getting knocked down. That's very computationally expensive and
not part of any
standard api like OpenGl. The same goes for skeletal dynamics and
inverse kinematics
to have characters move and react in their environments. Also, some
game engines
do internal ray-tracing so that game agents can be aware of their
environment by
"seeing" what's around them. Again, all this requires lots of
computational power.
There's no reason, of course, why Lisp can't do all this efficiently if
care is taken
to avoid obvious pitfalls like floating point boxing.
Bob Coyne wrote:
> Kenny Tilton wrote:
>
>>
>> [...]
>>
>> I feel that I should still address what exactly it is that affects the
>> performance. If a game is well written, by people who know how to
>> properly use the API, then performance is in the hands of the guys who
>> make graphics cards and drivers. No one else has anything to do with
>> it anymore. What determines performance is how well the API, driver,
>> operating system, and hardware interact. On one of my computers, for
>> example, OpenGL runs somewhat faster. I do know, however, that this is
>> due to an incompatibility between DirectX and WindowsXP and my GeForce
>> MX100/200 card/driver.
>
>
> Maybe I missed some other discussion of it, but I think you also need to
> consider
> non-graphical display performance issues. For example, many games require
> collision detection and/or physical simulation.
<sigh> which "C" physics engine do you want in Cello? I was looking at
Open Dynamics Engine, but I am open to suggestions. (please do not tell
me I was supposed to write one from scratch!*)
* OK, that is probably what I am going to do. :)
> to have characters move and react in their environments. Also, some
> game engines
> do internal ray-tracing so that game agents can be aware of their
> environment by
> "seeing" what's around them.
Good point.
Again, all this requires lots of
> computational power.
>
> There's no reason, of course, why Lisp can't do all this efficiently if
> care is taken
> to avoid obvious pitfalls like floating point boxing.
Check. And if the Unbearable Heaviness of Lisp Type Declarations is too
much to bear, code that bit in "C". The silly way to get that bit
written in C is to write the entire application in C.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<OuDed.93588
> > Maybe I missed some other discussion of it, but I think you also need to
> > consider
> > non-graphical display performance issues. For example, many games require
> > collision detection and/or physical simulation.
>
> <sigh> which "C" physics engine do you want in Cello? I was looking at
> Open Dynamics Engine, but I am open to suggestions. (please do not tell
> me I was supposed to write one from scratch!*)
>
> * OK, that is probably what I am going to do. :)
Kenny, I see you are not really concerned with weather Lisp is
*currently* the best to use or not. I think you just want to make
sure Lisp is not removed from anyones list of tools to use. Many of
the performance concerns raised really only apply to bleeding edge
games. My experience was in these kind of games but, in reality they
probably account for 5% of the games that come out in a year. So even
if Lisp isn't quite as fast as C for SOME things under SOME
circumstances, it really doesn't matter. 95% of the games could be
written in Lisp.
The other arguments placed out there have all been about what is
available to developers is mostly C/C++ code. This is not Lisp's
fault, it's just an artifact of video game history.
Until there are robust game engines or at least physics engines
available in Lisp, it won't be the first choice for many. Tons of
those exist for C/C++. They are to big a part of the problem to be
discounted for most developers. It would be like trying to develop a
GUI app and having to develop the GUI API to go with it.
If you and others are willing and committed to developing a robust
game engine in Lisp, then you would put Lisp alot futher down the road
in the game domain.
You want Lisp to be used and that is admirable.
Good luck in your efforts. Hopefully by the time you get it finished,
I will some understanding of Lisp so I can try it out :)
Hi Kenny Tilton,
> So unless you also have your letter of resignation from Microsoft open
> in another window, there is no way you would be considering anything
> other than C++. But, hey, what chance is there that a bunch of SLWs
> would know any of the above? None!
>
> Don't worry, your secret is safe with me. Just don't blow it by actually
> responding to anything of substance -- not that I have to tell you that!
If you substitute "Linux" for "Lisp" in the articles it's easier to see
that Jack Palevich is making arguments about popularity, not technological
superiority. His definition of "Games" simply favours Microsoft because of
its current market share.
I work at Microsoft on the Xbox system software team. Currently I'm
working on graphics for current and future versions of Xbox. I'm a full
time C++ developer. I don't currently write games myself, but my code's
in every Xbox game, and I spend a lot of time talking with developers
about their game architectures. I know an awful lot about what video
game hardware and software is going to look like in the next three to
five years.
As for Linux, in addition to getting a Unix-based undergraduate
education at MIT, and having a full time job for a year and a half
programming upon Unix at HP Labs during the AI boom, I have recently
spent a few months as a hobbyist trying to figure out how Linux could
be used to implement modern video games. It may seem from these essays
that I hate Linux, but in fact I've spent quite a bit of my free time
trying to see if Linux has a place on the modern game world. (And it's
why I'm willing to spend even more time defending my opinions.)
...
I wrote the "Why Linux Sucks for Games" article as a post-mortem on my
hobby investigation to see if Linux would make sense as an operating
system for writing next-gen video games.
...
So when I say Linux sucks for games, I'm arguing from at least as much
Linux knowledge as the average internet discussion group denizen, and
way more game knowledge.
...
Criticism 5: You hate Linux, therefore you suck.
* I may suck, but it's not because I hate Linux. I like Linux quite a
bit. I just don't see it as useful for writing modern video games.
* With the exception of Id Software, nobody uses Linux for modern game
development, and few developers even use Linux as a game machine.
Perhaps everyone else is stupid, or perhaps Linux has issues. Before
you flame me too much, consider if your love of Linux is blinding you
to its faults.
Regards,
Adam
············@yahoo.com (Jack Palevich) wrote in message news:<····························@posting.google.com>...
> http://www.spies.com/~palevich/CLRScheme/WhyLispStillSucksForGames.htm
>
> I hope it will help people understand my point of view.
Thanks for building up the store of Lisp literature. I wish the Lisp
world were more conducive to interesting criticisms. However, there
are possible ways to improve yours.
> By "Lisp" I mean any Lisp-derived language such as ...
Don't forget Naughty Dog's proprietary gaming Lisp. Otherwise:
- People will think there's an inherent problem with Lisp.
- People won't realize that someone quickly whipped up a successful,
competitive gaming Lisp, without the resources of a Microsoft.
- I realize you're only talking about Lisps you could legally run, but
you've opened up your definition of Lisp to be extremely inclusive, so
it implies that Lisp itself is an issue, on some fundamental logical
level.
> By "Games" I mean commercial video game titles that typically take two
> years to write, have teams of ten to fifty developers, and cost $2 to
> $5 million to make, and are sold on CD DVD for $20 to $50, for both a
> PC or a game console.
Your performance arguments do not cover profitable ones like Sid Meier
games. More precisely, you're talking about the business model which
hitches onto hardware improvements to drive upgrades.
I would like to see the failure rate of companies which could not pump
out a fast prototype and then optimize later. Lisp implies a different
engineering possibility.
> The Gamasutra post-mortem on Jax and Daxter lists many drawbacks of
> using Lisp
- Read "Postmortem: The Tools Development of Turbine's Asheron's Call
2" for inherent problems of building your own tools, even though it
has enormous advantages. Are Naughty Dog's issues worse?
- All Gamasutra post-mortems list drawbacks. How many said, "Boy, with
C++, there were no drawbacks!"
> ex Naughty Dog developers don't seem to be trying to use Lisp in
> their post-Naughty Dog projects.
If you like Lisp, can you go into a new company which uses J2EE and
say, "Today, we'll all switch to Lisp!"? There's a reason why
corporations are occasionally called private tyrannies. It is a fact
of corporations you're expected do what some authority says.
> Naughty Dog is a very talented group of developers. I believe they
> could write excellent video games in any language.
And that's why they chose Lisp. Or so I'd think by making a small
inference using your logic.
> Game scripts are usually simple enough that they don't need the full
> power of Lisp. Any old language will do for scripting.
Out of curiosity, might there be advantages in doing without the wall
between engine language and a separate scripting language?
MfG,
Tayssir
From: Dirk Gerrits
Subject: Let's prove them wrong [Was: Why Lisp supposedly "sucks for game development"]
Date:
Message-ID: <87fz43zttz.fsf_-_@dirkgerrits.com>
···········@yahoo.com (Tayssir John Gabbour) writes:
> Out of curiosity, might there be advantages in doing without the wall
> between engine language and a separate scripting language?
I believe so, although I have no concrete evidence, hence this post
(read on).
(Disclaimer: I have lurked in the C++ game development scene for most of
my youth (though never professionally) and I have done a fair bit of C++
template meta-programming, so I have *some* idea what I'm talking about,
although I do not claim to be any kind of expert.)
Most of this thread has been concerned with speculations on how suitable
Lisp would be for game development. A few posts have dealt with Lisp
actually having been used for game development at Naughty Dog. But how
about actually investigating Lisp's suitability for game development for
ourselves?
The use of Lisp in the creation of high-quality, modern computer games
is very much unexplored territory. That's why I don't know how well
Lisp's style of creating task-specific sub-languages applies to modern
games. My guess, though, is that it would work very well indeed. After
all, even the C++ people are starting to do this. [1]
Creating the appropriate sub-languages will take a lot of creativity and
experimentation, but Lisp is very well suited for the latter. For the
former, we have a good number of comp.lang.lisp'ers interested in
computer game development. This is nowhere near the strength in numbers
and money that the C++'ers have, but my guess is that Lisp's higher
abstractions make that unnecessary. Also, we won't have to start
completely from scratch. One could just wrap a few C libraries and let
the code evolve to more Lispy ground from there.
I don't know if I've sparked enough interest to get any of you to
actually do this, but I am going ahead with it regardless. In fact, I
have already started. Ever since I read about using microthreads for
game AI I have been interested in light-weight concurrency, and I'm now
trying to bring those ideas to Common Lisp. [2] My guess is that this
can be used for a lot more than "mere" game AI, both inside and outside
of game development.
Another interest of mine (that will have to wait for a bit) is the
development of a good language for doing geometry. Geometric algebra
(sometimes called Clifford algebra) has sparked my interest in the past,
as have collision detection and rigid body dynamics. This too would be
very useful both inside and outside of game development. It may
interest the visualization group at my university for instance.
(Perhaps there is even prior art?)
Developing these two sub-languages, and any other ones that'll prove
useful when writing an actual game, will take me a lot of time. Perhaps
so much that the industry finally decides to move away from C++. So if
any of you think this is a cause worthy spending some of your free time
on, please do. I hope I don't just speak for myself when I say that I'm
very interested to see what we can come up with.
Kind regards,
Dirk Gerrits
[1] Sh (http://developers.slashdot.org/developers/04/09/20/1747210.shtml),
to name just one example.
[2] Shameless Erlisp plug: http://www.dirkgerrits.com/erlisp/
"Game development tools on the PS2 suck (compared to Windows, Xbox, or
_even Unix_)." (emphasis mine)
Will you please stop the trolling? Taking pot shots at ML was bad
enough, but now you have to drag Unix into this! I suppose now you're
going to delight us with stories about how you used System 3 with vi
or ed at HP 20 years ago or something. This is especially
unprofessional considering you're a Microsoft developer.
Considering all the negative responses you received (and from the
looks of it, that's the only kind of response you did receive), it
would have been smart to leave the issue alone and maybe "lose" the
document once everyone forgot about it in a couple of weeks. I don't
mean to attack you personally, but you're doing nothing but damaging
your reputation by posting error-ridden speculation like those two
articles. I suppose you don't care, but chances are pretty good that
because of this you'll never be able to work professionally with Lisp
again (but I suppose you have pretty good job security considering the
indecent amount of cash Microsoft is willing to burn on the
Xbox). Most people just get a pseudonym account on Slashdot for these
purposes. I suggest you do too.
Vladimir
PS - Personally I happen to find the editor and interface of Visual
Studio abhorrent.
From: Bulent Murtezaoglu
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87acuc9772.fsf@p4.internal>
>>>>> "VS" == Vladimir Sedach <(string-downcase (concatenate 'string last-name (subseq first-name 0 1)))@cpsc.ucalgary.ca> writes:
VS> "Game development tools on the PS2 suck (compared to Windows,
VS> Xbox, or _even Unix_)." (emphasis mine)
VS> Will you please stop the trolling? Taking pot shots at ML was
VS> bad enough, but now you have to drag Unix into this!
Well, I know the next time I want something I wrote heavily
scrutinized, I'll say I work at MS and that I think lisp sucks.
VS> ... it would have been smart to leave the issue alone
VS> and maybe "lose" the document once everyone forgot about it in
VS> a couple of weeks.
This would have been wise. I agree. It also would have been wise for
_us_ to leave things alone.
VS> ... I suppose
VS> you don't care, but chances are pretty good that because of
VS> this you'll never be able to work professionally with Lisp
VS> again ...
I don't know about this. I didn't see anything that bad. Usenet is not
a great medium to gauge how people might behave in a professional setting.
I am slightly annoyed that people are repeatedly bringing up the fact
that he works at MS. I get the feeling that he's getting personally
picked on because of it. Would we have reacted the same way had he said
'I work at Sony doing playstation things?'
[...]
VS> PS - Personally I happen to find the editor and interface of
VS> Visual Studio abhorrent.
I don't know about the latest versions but v. 6.0 was a nightmare for
me when I had to use it. I wonder what kind of past with computers
one needs to have to find that abomination usable. (There goes _my_
chances of ever working professionally with Visual-<mumble>, and thank
heaven for that.)
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"VS" == Vladimir Sedach <(string-downcase (concatenate 'string last-name (subseq first-name 0 1)))@cpsc.ucalgary.ca> writes:
>
>
> VS> "Game development tools on the PS2 suck (compared to Windows,
> VS> Xbox, or _even Unix_)." (emphasis mine)
>
> VS> Will you please stop the trolling? Taking pot shots at ML was
> VS> bad enough, but now you have to drag Unix into this!
>
> Well, I know the next time I want something I wrote heavily
> scrutinized, I'll say I work at MS and that I think lisp sucks.
Save your breath. Stop at "I work at MS".
>
> VS> ... it would have been smart to leave the issue alone
> VS> and maybe "lose" the document once everyone forgot about it in
> VS> a couple of weeks.
>
> This would have been wise. I agree. It also would have been wise for
> _us_ to leave things alone.
Really? I was thinking about publicizing those pages on Slashdot. :)
At LUGM '99 Richard Gabriel, when a BOF was wringing its hands over the
unpopularity of Lisp, suggested Lisp pick a fight. The point being not
that we would persuade anyone directly, but that the publicity was all
Lisp needed. Once people take a look, they like what they see.
It is simple. There is no such thing as bad publicity.
>
> VS> ... I suppose
> VS> you don't care, but chances are pretty good that because of
> VS> this you'll never be able to work professionally with Lisp
> VS> again ...
>
> I don't know about this. I didn't see anything that bad. Usenet is not
> a great medium to gauge how people might behave in a professional setting.
>
> I am slightly annoyed that people are repeatedly bringing up the fact
> that he works at MS. I get the feeling that he's getting personally
> picked on because of it.
Hey, I am a demon, what do you expect? But seriously, if I want to
attack him personally it will be for intellectual dishonesty, which
really gives me a pain where I sit. The Microsoft/D3X/C++ association
creates a great honking conflict of interest, so it is fair game harping
on that. Not as a personal attack, but as a conflict which, when
juxtaposed with the extraordinary factual incompetence...stinks.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Neo-LISPer
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <873c04im7n.fsf@yahoo.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> Really? I was thinking about publicizing those pages on Slashdot. :)
"A Microsoft employee tries to stop people from using Lisp for game
development, denies any direct knowledge of Lisp being used in Halo"
From: Svein Ove Aas
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <clg0bu$mb5$1@services.kq.no>
Neo-LISPer wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>> Really? I was thinking about publicizing those pages on Slashdot. :)
>
> "A Microsoft employee tries to stop people from using Lisp for game
> development, denies any direct knowledge of Lisp being used in Halo"
Sounds about right.
Hey, any particular reason *not* to publish it on Slashdot? Anyone going to
do so?
From: Neo-LISPer
Subject: Re: Why Lisp supposedly "sucks for game development"
Date:
Message-ID: <87u0skgznn.fsf@yahoo.com>
Svein Ove Aas <·········@aas.no> writes:
> Neo-LISPer wrote:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >
> >> Really? I was thinking about publicizing those pages on Slashdot. :)
> >
> > "A Microsoft employee tries to stop people from using Lisp for game
> > development, denies any direct knowledge of Lisp being used in Halo"
>
> Sounds about right.
>
> Hey, any particular reason *not* to publish it on Slashdot? Anyone going to
> do so?
Feel free. Add "Linux", "cross-platform" and "PS2" (vs Xbox) for drama :)
············@yahoo.com (Jack Palevich) writes:
...
> I hope it will help people understand my point of view.
Not the interesting part. What I would like to know is why people
like you seem so _enthusiastic_ about showing to the whole world how
stupid they are. Can you say a bit about your point of view on this?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> ············@yahoo.com (Jack Palevich) writes:
>
>>I hope it will help people understand my point of view.
>
> Not the interesting part. What I would like to know is why people
> like you seem so _enthusiastic_ about showing to the whole world how
> stupid they are. Can you say a bit about your point of view on this?
Can one get a CS degree from MIT and still be stupid?
I think he's just got a bad case of cognitive dissonance and/or a flaw
in his unification algorithm. Consider Jack's statements:
"You can use arrays and structs instead of lists, but then you're
essentially writing C code with a peculiar syntax."
"If you have to write code [with type annotations] to get decent
performance, you are effectively writing in C, just with a peculiar syntax."
Possibilities:
- Jack is an exceptional C/C++ programmer who regularly demonstrates
Greenspun's tenth, and doesn't mind the extra typing that his favourite
turing-complete languages force upon him.
- He didn't really understand the power of Lisp when he was at MIT, so
he didn't miss anything when he switched to Java/C{,++,#}
- He reasons along pragmatic lines: Microsoft is the most successful
software company, and they didn't get there by using Lisp, therefore
Microsoft's favourite languages are at least as good as Lisp?
*My* first experience with Lisp was Supersoft's LISP on a TRS-80 Model
I, along with Ken Tracton's truly terrible Programmer's Guide to LISP
(TAB BOOKS Inc., 1980), which claims that LAMBDA is "somewhat like
DEFINE", and shows no examples of higher order functions.
Somebody on c.l.l thought Greenblatt's code scared children? How about
this, from page 171:
(DEFINE
(FACTORIAL X)
(PROG (F)
(SETQ F 1)
AGAIN
(COND
((ZEROP X)
(RETURN F)))
(SETQ F(TIMES F X))
(SETQ X (SUB1 X))
(GO AGAIN)))
The above is an exact reproduction, excepting that the original is set
in a proportional sans serif font.
Nearly two decades in the wilderness followed. That I can understand,
but Jack's bragging about rubbing shoulders with big wheels in the Lisp
community and attending MIT seem terribly difficult to reconcile with
his odd notions.
SICP was, to me, a revelation. Maybe one has to have first spent time in
static language purgatory in order to appreciate higher order languages?
--
Cameron MacKinnon
Toronto, Canada
For anyone who's been following along and wondering what, exactly, was
claimed in the post-mortem, here's the subset of it that talks about Lisp:
=====8<=====
What Went Right
...
5. GOAL rules!
Practically all of the run-time code (approximately half a million lines
of source code) was written in GOAL (Game Object Assembly Lisp), Naughty
Dog's own internally developed language, which was based on the Lisp
programming language. Before you dismiss us as crazy, consider the many
advantages of having a custom compiler.
Lisp has a very consistent, small set of syntactic rules involving the
construction and evaluation of lists. Lists that represent code are
executed by evaluating the items that are in the list; if the head of
the list is a function (or some other action), you could think of the
other items in the list as being the parameters to that function. This
simplicity of the Lisp syntax makes it trivial to create powerful macros
that would be difficult or impossible to implement using C++.
Writing macros, however, is not enough justification for writing a
compiler; there were features we felt we couldn't achieve without a
custom compiler. GOAL code, for example, can be executed at a listener
prompt while the game is running. Not only can numbers be viewed and
tweaked, code itself can be compiled and downloaded without interrupting
or restarting the game. This allowed the rapid tuning and debugging,
since the effects of modifying functions and data structures could be
viewed instantaneously.
We wanted creatures to use non preemptive cooperative multi-tasking, a
fancy way of saying that we wanted a creature to be able to execute code
for a while, then "suspend" and allow other code to execute. The
advantage of implementing the multi-tasking scheme using our own
language was that suspend instructions could be inserted within a
creature's code, and state could be automatically preserved around the
suspend. Consider the following small snippet of GOAL code:
(dotimes (ii (num-frames idle))
(set! frame-num ii)
(suspend)
)
This code has been simplified to make a point, so pretend that it uses a
counter called ii to loop over the number of frames in an animation
called idle. Each time through the loop the animation frame is set to
the value of ii, and the code is suspended. Note that the value of ii
(as well as any other local variables) is automatically preserved across
the suspend. In practice, the preceding code would have been
encapsulated into a macro such as:
(play-anim idle
;; Put code executed for each time..
;; through the loop here.
)
There are other major compiler advantages: a unified set of assembly
op-codes consistent across all five processors of the Playstation 2,
register coloring when writing assembly code, and the ability to
intermix assembly instructions seamlessly with higher-level code. Outer
loops could be written as "slower" higher-level code, while inner loops
could be optimized assembly.
What Went Wrong
1. GOAL sucks! While it's true that GOAL gave us many advantages, GOAL
caused us a lot of grief. A single programmer (who could easily be one
of the top ten Lisp programmers in the world) wrote GOAL. While he
called his Lisp techniques and programming practices "revolutionary,"
others referred to them as "code encryption," since only he could
understand them. Because of this, all of the support, bug fixes, feature
enhancements, and optimizations had to come from one person, creating
quite a bottleneck. Also, it took over a year to develop the compiler,
during which time the other programmers had to make do with missing
features, odd quirks, and numerous bugs.
Eventually GOAL became much more robust, but even now C++ has some
advantages over GOAL, such as destructors, better constructors, and the
ease of declaring inline methods.
A major difficulty was that we worked in such isolation from the rest of
the world. We gave up third-party development tools such as profilers
and debuggers, and we gave up existing libraries, including code
previously developed internally. Compared to the thousands of
programmers with many years of C++ experience, there are relatively few
programmers with Lisp experience, and no programmers (outside of Naughty
Dog) with GOAL experience, making hiring more difficult.
GOAL's ability both to execute code at the listener and to replace
existing code in the game at run time introduced the problem of memory
usage, and more specifically, garbage collection. As new code was
compiled, older code (and other memory used by the compiler) was
orphaned, eventually causing the PC to run low on free memory. A slow
garbage collection process would automatically occur when available
memory became sufficiently low, and the compiler would be unresponsive
until the process had completed, sometimes taking as long as 15 minutes.
...
Since all of our tools (including the GOAL compiler) ran across our
network, we ran into severe network bandwidth issues. Making better use
of local hard drives would have been a smarter approach. In addition, we
found extreme network slowdown issues related to reading file time/date
stamps, and some tools took several minutes just to determine that
nothing needed to be rebuilt. When we compiled some of our tools under
Linux, we noticed dramatic improvements in network performance, and we
are planning on using Linux more extensively in our next project.
=====8<=====
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> 1. GOAL sucks! While it's true that GOAL gave us many advantages, GOAL
> caused us a lot of grief. A single programmer (who could easily be one
> of the top ten Lisp programmers in the world) wrote GOAL. While he
> called his Lisp techniques and programming practices "revolutionary,"
> others referred to them as "code encryption," since only he could
> understand them. Because of this, all of the support, bug fixes,
> feature enhancements, and optimizations had to come from one person,
> creating quite a bottleneck. Also, it took over a year to develop the
> compiler, during which time the other programmers had to make do with
> missing features, odd quirks, and numerous bugs.
That's not GOAL sucks, that's MANAGEMENT SUCKS! They could easily
hire more lisp experts to help this poor soul.
I've seen a small company that literally depended on only one
programmer, to develop a whole LOGO system, that was constantly
interrupted to do other task like user support, or whaterver. He
hardly spent 30% of his time developping their product, and no
surprise they folded in a few years despite generous financial
resources. Adding only one 100% programmer they could have made it.
> Compared to the thousands of
> programmers with many years of C++ experience, there are relatively
> few programmers with Lisp experience, and no programmers (outside of
> Naughty Dog) with GOAL experience, making hiring more difficult.
Another management botching: that was rather a hiring opportunity, to
filter out the inteligent people who can adapt and think for
themselves instead of C++ coding monkeys.
> GOAL's ability both to execute code at the listener and to replace
> existing code in the game at run time introduced the problem of memory
> usage, and more specifically, garbage collection. As new code was
> compiled, older code (and other memory used by the compiler) was
> orphaned, eventually causing the PC to run low on free memory. A slow
> garbage collection process would automatically occur when available
> memory became sufficiently low, and the compiler would be unresponsive
> until the process had completed, sometimes taking as long as 15
> minutes.
I don't see how you can count that a a wrong point. It comes along
with the advantage of being able to debug and tune interactively. It
would never happen in "production".
> Since all of our tools (including the GOAL compiler) ran across our
> network, we ran into severe network bandwidth issues. Making better
> use of local hard drives would have been a smarter approach. In
> addition, we found extreme network slowdown issues related to reading
> file time/date stamps, and some tools took several minutes just to
> determine that nothing needed to be rebuilt. When we compiled some of
> our tools under Linux, we noticed dramatic improvements in network
> performance, and we are planning on using Linux more extensively in
> our next project.
Here too, this has nothing to do with GOALisp. If you put your
sources on the NFS server, you can't complain that you C++ compiler
suddenly is slow no more for GOAL. If they suffered all along the
project time, against that only proves they had a bad management
unable to fire the guy responsible for such suffering and hiring
somebody able to set them a functional development environment.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.