-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello
I am new to coding and am teaching myself my first few languages.
I was talking with a few people the other day about game engines and game
creation, when one of them said that a popular language for the creation of
games was Lisp.
He also said that Lisp was very expensive to, the environments I mean, not
the free ones but ones like Allegro and so on.
he also said that allot Nintendo games for the gamecube and earlier
consoles, were created using Lisp.
Games such as mario brothers and Zelda.
Is this true of Lisp?? is Lisp used in the creation of some games??
See I always thought that game creation was the domain of C/C++ with the
adding of some scriptable languages for game scripts and so on.
Can anyone elaborate for me??
Thanks..
Anon
- --
*************
The Imagination may be compared to Adam's dream-
he awoke and found it truth.
John Keats.
*************
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
iQA/AwUBQT9eLi/z2sM4qf2WEQLKPACfaenhfF+Kk1o2Af+53XeJL6hO5loAoNgD
s6DsCsX3LGw8AzFNatt9h0/p
=lRPm
-----END PGP SIGNATURE-----
On Wed, Sep 08, 2004 at 08:32:00PM +0100, Anon wrote:
> he also said that allot Nintendo games for the gamecube and earlier
> consoles, were created using Lisp.
> Games such as mario brothers and Zelda.
In this case, he may have been speaking of Mirai, which currently runs
under Allegro Common Lisp. Mirai is a popular tool to model 3D designs
and animations.
See http://www.izware.com/mirai/
--
;;;; Matthew Danish -- user: mrd domain: cmu.edu
;;;; OpenPGP public key: C24B6010 on keyring.debian.org
Anon wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello
>
> I am new to coding and am teaching myself my first few languages.
> I was talking with a few people the other day about game engines and game
> creation, when one of them said that a popular language for the creation of
> games was Lisp.
>
> He also said that Lisp was very expensive to, the environments I mean, not
> the free ones but ones like Allegro and so on.
>
> he also said that allot Nintendo games for the gamecube and earlier
> consoles, were created using Lisp.
> Games such as mario brothers and Zelda.
>
> Is this true of Lisp?? is Lisp used in the creation of some games??
>
> See I always thought that game creation was the domain of C/C++ with the
> adding of some scriptable languages for game scripts and so on.
>
> Can anyone elaborate for me??
As a recent example, Jak and Daxter games from Naughty Dog were written
mostly in GOAL ("Game Oriented Lisp"), a Lisp compiler that Naughty Dog
wrote specifically for game development.
The GOAL compiler was written in Common Lisp (using Franz's Allegro
Common Lisp).
Franz has a page about it here:
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
It's somewhat common for people to implement at least some part of the
game logic in one version of Lisp or another. Lisp was invented by
people trying to solve hard problems (including AI) and is still good
for that purpose.
To paraphrase something that has been said several different ways by
several different people, you generally want a high-level language for
solving hard, complicated problems, and a low-level language for
tweaking performance. Lisp happens to be able to do both jobs.
Anon on Wed, 8 Sep 2004 20:32:00 +0100 writes:
> I am new to coding and am teaching myself my first few languages.
> I was talking with a few people the other day about game engines and game
> creation, when one of them said that a popular language for the creation of
> games was Lisp.
>
> He also said that Lisp was very expensive to, the environments I mean, not
> the free ones but ones like Allegro and so on.
>
> he also said that allot Nintendo games for the gamecube and earlier
> consoles, were created using Lisp.
> Games such as mario brothers and Zelda.
>
> Is this true of Lisp?? is Lisp used in the creation of some games??
The successful company Naughty Dog used it for `Crash Bandicoot' and
`Jak & Dexter'.
They use Common Lisp for the tools, and use a proprietary Lisp named
GOAL for the game. GOAL is written in Common Lisp.
Some links:
http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml
http://www.naughtydog.com/jak1/20Questions.htm
Search `naughty dog lisp' using google for more.
Among other things I aim to write a client/server game infrastructure
in my spare time, with a thin client and a fat server, and I'm using
`C in a lispy way' for the client side, while planning to use a
dynamic (in the sense that I've a REPL and that I can rewrite the
system at run-time) Scheme or a dynamic Common Lisp for the server
side. One of the cool things would be to be able to improve and fix
the game (server) while the users are playing. The first steps I'm
doing are with the `Lingerie' game library at `gna.org'. However it
will take undefined time before having something meaningful.
> See I always thought that game creation was the domain of C/C++ with the
> adding of some scriptable languages for game scripts and so on.
Most games are implemented using C/C++. C/C++ are very popular languages.
--
Marco Parrone <·····@autistici.org> [0x45070AD6]
"Anon" <·····@My.email.address.scum.com> wrote in message news:<············@newsg1.svr.pol.co.uk>...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello
>
> I am new to coding and am teaching myself my first few languages.
> I was talking with a few people the other day about game engines and game
> creation, when one of them said that a popular language for the creation of
> games was Lisp.
>
> He also said that Lisp was very expensive to, the environments I mean, not
> the free ones but ones like Allegro and so on.
>
> he also said that allot Nintendo games for the gamecube and earlier
> consoles, were created using Lisp.
> Games such as mario brothers and Zelda.
>
> Is this true of Lisp?? is Lisp used in the creation of some games??
>
> See I always thought that game creation was the domain of C/C++ with the
> adding of some scriptable languages for game scripts and so on.
C and C++ are extremely inconvenient when the job requires you to
create another language and then develop in that. By contrast, Lisp is
very good for this, nearly ideal.
Consider that one popular compiler suite, GCC, which includes C and
C++ front-ends, internally uses a language called RTL for passing a
representation of the compiled program between the front and back-end.
The printed representation of RTL is basically Lisp S-expressions.
If you wanted to write tools that operate on RTL, Lisp would be your
ideal choice, because you would instantly have a parser and nice
collection of library routines for free, so you could immediately
buckle down and focus on your algorithms.
So we could say that Lisp is involved in all development done with
GCC, from compiling the Linux kernel onward.
The way Lisp is used in these games is similar to how it's used in
GCC; some language is defined in Lisp syntax and parts of the software
are written in that language. The difference is that a Lisp
implementation is used to handle that language, rather than a tool
written in C or C++, which would take a lot more effort to develop.
On 9 Sep 2004 16:16:10 -0700, Kaz Kylheku <···@ashi.footprints.net> wrote:
>
> If you wanted to write tools that operate on RTL, Lisp would be your
> ideal choice, because you would instantly have a parser and nice
> collection of library routines for free, so you could immediately
> buckle down and focus on your algorithms.
>
> So we could say that Lisp is involved in all development done with
> GCC, from compiling the Linux kernel onward.
>
> The way Lisp is used in these games is similar to how it's used in
> GCC; some language is defined in Lisp syntax and parts of the software
> are written in that language. The difference is that a Lisp
> implementation is used to handle that language, rather than a tool
> written in C or C++, which would take a lot more effort to develop.
GNU provides Guile these days. A scheme dialect which is mostly
intended to provide a high level interface on top of a C/C++ library.
(Kinda like Emacs and GCC.)
In some ways it seems ideal to program games.
You get the libraries and low level control of C/C++ and the high
level abstractions possible in Lisp.
The biggest hurdle is the GPL which means that if you use guile
then the program must be public domain.
(I think. Please correct me if I'm wrong.)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> GNU provides Guile these days. A scheme dialect which is mostly
> intended to provide a high level interface on top of a C/C++ library.
> (Kinda like Emacs and GCC.)
> In some ways it seems ideal to program games.
> You get the libraries and low level control of C/C++ and the high
> level abstractions possible in Lisp.
> The biggest hurdle is the GPL which means that if you use guile
> then the program must be public domain.
> (I think. Please correct me if I'm wrong.)
I tried once to program gimp with guile. It was painful. I'd rather
develop a gimp in common-lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon <····@mouse-potato.com> writes:
> "John Thingstad" <··············@chello.no> writes:
> > GNU provides Guile these days. A scheme dialect which is mostly
> > intended to provide a high level interface on top of a C/C++ library.
> > (Kinda like Emacs and GCC.)
> > In some ways it seems ideal to program games.
> > You get the libraries and low level control of C/C++ and the high
> > level abstractions possible in Lisp.
> > The biggest hurdle is the GPL which means that if you use guile
> > then the program must be public domain.
> > (I think. Please correct me if I'm wrong.)
>
> I tried once to program gimp with guile. It was painful. I'd rather
> develop a gimp in common-lisp.
It was probably SIOD and not guile... not that guile is very pleasant,
either.
Cheers,
mwh
--
The Programmer's Quick Guide To Python (Time Machine version):
You try to shoot yourself in the foot, only to realize that
there's no need, since Guido thoughtfully shot you in the foot
years ago. -- Nick Mathewson, comp.lang.python
Michael Hudson <···@python.net> wrote:
+---------------
| Pascal Bourguignon <····@mouse-potato.com> writes:
| > "John Thingstad" <··············@chello.no> writes:
| > > GNU provides Guile these days. A scheme dialect which is mostly
| > > intended to provide a high level interface on top of a C/C++ library.
| >
| > I tried once to program gimp with guile. It was painful. I'd rather
| > develop a gimp in common-lisp.
|
| It was probably SIOD and not guile...
+---------------
Yup. SIOD is a rather idiosyncratic R3RS Scheme -- *very* different
from R4RS/R5RS Scheme.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"John Thingstad" <··············@chello.no> writes:
> The biggest hurdle is the GPL which means that if you use guile
> then the program must be public domain.
> (I think. Please correct me if I'm wrong.)
Since Guile is GPL, any program using Guile must also be GPL. GPL is
not public domain.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> "John Thingstad" <··············@chello.no> writes:
>
> > The biggest hurdle is the GPL which means that if you use guile
> > then the program must be public domain.
> > (I think. Please correct me if I'm wrong.)
>
> Since Guile is GPL, any program using Guile must also be GPL. GPL is
> not public domain.
Guile is actually licensed under the LGPL. That means that only
changes to the actual Guile implementation must be (L)GPL. Merely
linking to the Guile runtime, or using Scheme code that is executed
by Guile, does not require that a program be (L)GPL. If I understand
the license correctly. IANAL.
--
"We sat and watched as this whole <-- (Died Pretty -- "Springenfall")
blue sky turned to black..."
... Re-defeat Bush in '04.
--
pub 1024D/BA496D2B 2004-05-14 Joseph A Knapka
Key fingerprint = 3BA2 FE72 3CBA D4C2 21E4 C9B4 3230 94D7 BA49 6D2B
If you really want to get my attention, send mail to
jknapka .at. kneuro .dot. net.
On Fri, 10 Sep 2004 04:50:26 GMT, Joe Knapka <·······@kneuro.net> wrote:
> Guile is actually licensed under the LGPL. That means that only
> changes to the actual Guile implementation must be (L)GPL. Merely
> linking to the Guile runtime, or using Scheme code that is executed
> by Guile, does not require that a program be (L)GPL. If I understand
> the license correctly. IANAL.
>
I was hoping this was true. Perhaps the licence has changed since
I last time looked up Guile.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> On Fri, 10 Sep 2004 04:50:26 GMT, Joe Knapka <·······@kneuro.net> wrote:
>
>
> > Guile is actually licensed under the LGPL. That means that only
> > changes to the actual Guile implementation must be (L)GPL. Merely
> > linking to the Guile runtime, or using Scheme code that is executed
> > by Guile, does not require that a program be (L)GPL. If I understand
> > the license correctly. IANAL.
> >
>
> I was hoping this was true. Perhaps the licence has changed since
> I last time looked up Guile.
Ok. Joe's interpretation of LGPL is correct so far as I know. So you
can use Guile in your program and license your program however you
wish, but any changes that you do to Guile are under LGPL.
Considering Guile as a seperate entity, you just treat it as a piece
of GPL'd software on its own. But you can use it without incurring
the GPL license obligation of making your client code also be GPL.
I think the LGPL license is something people can live with. Things
obviously get fuzzier with Common Lisp when you start talking about
linking library code. Franz's LLGPL makes that clearer I think. It
is also probably useful to think of the license as being on the source
files rather than the object code. However I'm sure that in itself is
enough to give lawyers lots to talk about.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Joe Knapka <·······@kneuro.net> writes:
> Guile is actually licensed under the LGPL.
No, it is GPL plus permission to link with propietary programs. See:
<http://www.gnu.org/software/guile/docs/guile-ref/Guile-License.html>
I think this even allows you to link with a modified version of
GUILE and then distribute binaries while hoarding the source code
of the modifications. But if you do distribute the source, the
recipients get at least the GPL rights to your modifications.
Kalle Olavi Niemitalo on Sat, 11 Sep 2004 18:13:59 +0300 writes:
> Joe Knapka <·······@kneuro.net> writes:
>
>> Guile is actually licensed under the LGPL.
>
> No, it is GPL plus permission to link with propietary programs. See:
> <http://www.gnu.org/software/guile/docs/guile-ref/Guile-License.html>
From http://www.gnu.org/software/guile/ :
(...snip...)
Changes since the 1.6.x series:
- Guile is now licensed with the GNU Lesser General Public License.
(...snip...)
--
Trenitalia censoring online!
-. .-----. .-----. ---------- .--.
#| o======|#####| o======|#####| |# #| .--. |##|
---. .------------. .------------. |----+####+-----+##+--+##|
o)o ) ( (o)o(o)o(o)o ) ( (o)o(o)o(o)o ) |###aAAb###aAAb###aAAb###|
= http://www.autistici.org/ai/trenitalia =-|--(doob)-(doob)-(doob)--#
o )) ( o )) ( o )) ( o )) ( o )) `uu' `uu' `uu'
"Anon" wrote in message news:<············@newsg1.svr.pol.co.uk>...
> is Lisp used in the creation of some games??
Yes. Here are some Lisp source files for the game Abuse:
http://web.mit.edu/~linux/lockers/games/lib/abuse/lisp/
It looks as if large parts of the game logic are written in Lisp, with
a small core probably written in C.
This page has some info about games written in Lisp, and some Lisp
bashing:
http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
Manuel
·······@gmail.com (Manuel Simoni) writes:
> "Anon" wrote in message news:<············@newsg1.svr.pol.co.uk>...
>
> > is Lisp used in the creation of some games??
>
> Yes. Here are some Lisp source files for the game Abuse:
> http://web.mit.edu/~linux/lockers/games/lib/abuse/lisp/
>
> It looks as if large parts of the game logic are written in Lisp, with
> a small core probably written in C.
>
> This page has some info about games written in Lisp, and some Lisp
> bashing:
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
Since he mentions that: "Lists are the default data structure." you
can imagine the level of his bashing... (and wonder what he learnt
with Pr. Abelson, whose name he can't even spell right!)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon <····@mouse-potato.com> writes:
> ·······@gmail.com (Manuel Simoni) writes:
>
> > This page has some info about games written in Lisp, and some Lisp
> > bashing:
> > http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
>
> Since he mentions that: "Lists are the default data structure." you
> can imagine the level of his bashing... (and wonder what he learnt
> with Pr. Abelson, whose name he can't even spell right!)
He also spelled paradigms wrong ;-)
There are other nits I would pick with the article also. Essentially,
most of what he says about Lisp is both wrong and right. By default,
Lisp is slow. But once you start throwing in declarations, code can
speed up tremendously.
Macros making code harder to understand? Well, why isn't that also
true of any 3rd party library code (in any language)?
Knowledge of Lisp compiler in one man's head? Don't they have proper
documentation procedures? Library code can also suffer from this
problem.
Lisp programmers hard to find? Aren't _good_ programmers hard to find
in general? That 100:1 productivity spread between the best and worst
programmers is independent of the language used. I should think a
good programmer can pick up Lisp over time and it is a mistake for
companies to want people who can "hit the ground running".
Programmers don't jump out of helicopters landing in hot zones. They
still have to learn the architecture of the system they are going to
maintain and that takes as much time as learning a language. Probably
more if you are talking about simple competence vs expertise.
IDEs, Librarys, & linkage with C? I thought those issues have been
beaten into the ground like a dead horse. The union of Common Lisp
implementations seems to have those issues sorted. Yes, it would be
very nice to have those issues sorted in a single, free
implementation. How many commiters does SBCL have? OpenMCL? As I
understand things, all these people are paid to do something else.
I suspect one "problem" is that Common Lisp (and Lisp as a family) was
ahead of its time. In the general case, good performance does require
good hardware that wasn't widely available in the 80's. That is not
an issue now. I have also seen plenty of C/C++ programs chug. It's
not always the language that is to blame for slow code. I'm sure hand
coded assembler can be very suboptimal also.
I will confess that I still think in Cish terms even when I program in
Lisp (which is not as much as I would like). I think far more in
terms of side-effects than returning results. Turning things inside
out and going from the bottom up are still odd to me (although I think
I am beginning to get it). I think this is because I "mastered" C
first. C has constrained my thinking. C is also so close to the
machine that it is really just a high level assembler language.
Java isn't even that high level. I would say that it is fairly much
an assembler language for Java byte code. Yes, it has garbage
collection and some degree of introspection (not so much as Lisp I
think). I suspect that the reason Java code is so verbose is because
it is so much like C trying to be a VHLL. Well it was a nice try.
The popularity of scripting languages (VHLLs) like Perl, Python, Ruby,
etc I think is a signal that raw performance is far less of an issue
these days. Doesn't Lisp have similar conciseness to Python? I know
that when it comes to run time performance, Lisp generally wins.
CMUCL's numerical code is able to compete with C numerical code.
Unlike the approach of using Python to prototype and then rewriting
the slow parts in C, you can prototype in Lisp and then optimize (with
declare and other "tricks") the bottlenecks. Which approach is more
RAD?
My only regret is that I didn't buckle down with Lisp back in 1998. I
got stuck in the "it's too hard" mentality.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Lisp programmers hard to find? Aren't _good_ programmers hard to find
It would be really interesting if those who state this provided a bit
more details on their efforts--if any--to look for Lisp programmers.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
On 10 Sep 2004 01:02:07 -0700, Manuel Simoni <·······@gmail.com> wrote:
> "Anon" wrote in message news:<············@newsg1.svr.pol.co.uk>...
>
>> is Lisp used in the creation of some games??
> This page has some info about games written in Lisp, and some Lisp
> bashing:
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
>
Some of the things in this article are wrong.
>> Problems with Lisp:
>> No module/library mechanism
First the two are hardly equivalent.
For a module interface use defpackage.
No support for libraries in the standard but most implementations
support the creations of DLL's.
>> Lack of types makes it difficult to understand or safely modify large
>> programs
Types adds to the clutter of creating a program, distracting him from
the purpose.
Having to specify types means that the data structure has to be known
up front before the
problem is fully understood. This leads to premature optimisations and
thus to less clear
and less efficient code.
So in my experience it has the opposite effect.
>> Macros makes code harder to understand
Macro's are a mechanism for providing high level abstractions related
to the
problem at hand. Used correctly the make the code easier to understand.
(It can not make a bad programmer produce good code.)
>> Lisp has low performance by default. Low Performance is designed into
>> the language at several levels
Depends what you mean by default. If you need an array use an array!
>> 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.
(make-array size :type 'byte) ... duh
>> The typical Lisp object system is too general to be able to run quickly.
Generality has little to do with it. More to the point is that the
class structure is
created and modified at runtime. And yes it is slower...
>> It's hard to tell cheap operations from expensive ones.
This is true and probably the best argument in the article.
>> Garbage Collection Pauses
Not on any lisp I have used. The typically use a generational garbage
collector which
eliminates most of the problem. However Java pauses on me..
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> >> It's hard to tell cheap operations from expensive ones.
>
> This is true and probably the best argument in the article.
Not even: what is the most expensive op�ration:
#include "graflib.h"
#include "mechlib.h"
void f(graf_object_t* obj){
graf_add_object(obj); /* this one, or the following? */
mech_apply(obj,force_new(10.0,20.0,0.0),GRAV_CENTER);
}
In general, Common-Lisp functions are well enough specified that their
complexity can be well assessed.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On 10 Sep 2004 12:05:59 +0000, Pascal Bourguignon <····@mouse-potato.com>
wrote:
>
> "John Thingstad" <··············@chello.no> writes:
>> >> It's hard to tell cheap operations from expensive ones.
>>
>> This is true and probably the best argument in the article.
>
> Not even: what is the most expensive op�ration:
>
> #include "graflib.h"
> #include "mechlib.h"
>
> void f(graf_object_t* obj){
> graf_add_object(obj); /* this one, or the following? */
> mech_apply(obj,force_new(10.0,20.0,0.0),GRAV_CENTER);
> }
>
> In general, Common-Lisp functions are well enough specified that their
> complexity can be well assessed.
>
The fact that is is true for other languages to don't really
change the fact. A entry about efficiency in the ANSI spec
wouldn't hurt.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Duane Rettig
Subject: Re: lisp used in game creation?
Date:
Message-ID: <4zn3yuozi.fsf@franz.com>
"John Thingstad" <··············@chello.no> writes:
> On 10 Sep 2004 12:05:59 +0000, Pascal Bourguignon
> <····@mouse-potato.com> wrote:
>
>
> >
> > "John Thingstad" <··············@chello.no> writes:
> >> >> It's hard to tell cheap operations from expensive ones.
> >>
> >> This is true and probably the best argument in the article.
> >
> > Not even: what is the most expensive op�ration:
> >
> > #include "graflib.h"
> > #include "mechlib.h"
> >
> > void f(graf_object_t* obj){
> > graf_add_object(obj); /* this one, or the following? */
> > mech_apply(obj,force_new(10.0,20.0,0.0),GRAV_CENTER);
> > }
> >
> > In general, Common-Lisp functions are well enough specified that their
> > complexity can be well assessed.
> >
>
> The fact that is is true for other languages to don't really
> change the fact.
Absolutely true.
> A entry about efficiency in the ANSI spec
> wouldn't hurt.
An entry about efficiency would be almost definitionally incorrect,
because there are very few things in CL whose speed can be said to
be language-mandated. CL implementations have been doing amazing
things to speed up various operations that might have otherwise
been considered inherently slow.
The _only_ way to know for sure how efficient two operations are
relative to each other is to use a statistical profiler to tell
you how fast each are for particular runs.
--
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:
> > > In general, Common-Lisp functions are well enough specified that their
> > > complexity can be well assessed.
> > >
> >
> > The fact that is is true for other languages to don't really
> > change the fact.
>
> Absolutely true.
>
> > A entry about efficiency in the ANSI spec
> > wouldn't hurt.
>
> An entry about efficiency would be almost definitionally incorrect,
> because there are very few things in CL whose speed can be said to
> be language-mandated. CL implementations have been doing amazing
> things to speed up various operations that might have otherwise
> been considered inherently slow.
>
> The _only_ way to know for sure how efficient two operations are
> relative to each other is to use a statistical profiler to tell
> you how fast each are for particular runs.
And in addition, even if all implementations have the same O() for the
same CL functions, there are enormous differences in the constants,
and there could be quite a lot of differences in the Omega().
(And it would be quite ridiculous to specify the Theta()).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
"John Thingstad" <··············@chello.no> writes:
> On 10 Sep 2004 12:05:59 +0000, Pascal Bourguignon
> <····@mouse-potato.com> wrote:
>
> >
> > "John Thingstad" <··············@chello.no> writes:
> >> >> It's hard to tell cheap operations from expensive ones.
> >>
> >> This is true and probably the best argument in the article.
> >
> > Not even: what is the most expensive op�ration:
> >
> > #include "graflib.h"
> > #include "mechlib.h"
> >
> > void f(graf_object_t* obj){
> > graf_add_object(obj); /* this one, or the following? */
> > mech_apply(obj,force_new(10.0,20.0,0.0),GRAV_CENTER);
> > }
> >
> > In general, Common-Lisp functions are well enough specified that their
> > complexity can be well assessed.
> >
>
> The fact that is is true for other languages to don't really
> change the fact. A entry about efficiency in the ANSI spec
> wouldn't hurt.
No, it does not change the fact, but it change the point! It does not
matter that it's hard to tell cheap operations from expensive ones
because in any language it's hard (that's why thesis are written about
complexity of algorithms), so you cannot take that against lisp (or
any other language)!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
On 10 Sep 2004 12:43:32 +0000, Pascal Bourguignon <····@mouse-potato.com>
wrote:
> No, it does not change the fact, but it change the point! It does not
> matter that it's hard to tell cheap operations from expensive ones
> because in any language it's hard (that's why thesis are written about
> complexity of algorithms), so you cannot take that against lisp (or
> any other language)!
>
That is true. But it shows a way in which lisp could provide an example?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> wrote:
>>> Garbage Collection Pauses
>
> Not on any lisp I have used. The typically use a generational
> garbage
> collector which
> eliminates most of the problem. However Java pauses on me..
you can use "java -Xincgc", which turns on incremental garbage collection
and is a good ideas for games.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Fri, 10 Sep 2004 14:05:17 +0000 (UTC), Frank Buss <··@frank-buss.de>
wrote:
> "John Thingstad" <··············@chello.no> wrote:
>
>>>> Garbage Collection Pauses
>>
>> Not on any lisp I have used. The typically use a generational
>> garbage
>> collector which
>> eliminates most of the problem. However Java pauses on me..
>
> you can use "java -Xincgc", which turns on incremental garbage collection
> and is a good ideas for games.
>
Then why isn't it on by default?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
> Then why isn't it on by default?
>
Presumably because most people don't use Java for writing games.
Incremental garbage collection probably gives you lower latency at the
expense of overall performance (on the assumption that several small GCs
will take longer than one large GC).
Alex
John Thingstad wrote:
> On Fri, 10 Sep 2004 14:05:17 +0000 (UTC), Frank Buss <··@frank-buss.de>
> wrote:
>
>> "John Thingstad" <··············@chello.no> wrote:
>>
>>>>> Garbage Collection Pauses
>>>
>>>
>>> Not on any lisp I have used. The typically use a generational
>>> garbage
>>> collector which
>>> eliminates most of the problem. However Java pauses on me..
>>
>>
>> you can use "java -Xincgc", which turns on incremental garbage collection
>> and is a good ideas for games.
>>
>
> Then why isn't it on by default?
>
Alex Drummond <············@notanaddress.invalid> writes:
> >
> > Then why isn't it on by default?
> >
>
> Presumably because most people don't use Java for writing
> games. Incremental garbage collection probably gives you lower latency
> at the expense of overall performance (on the assumption that several
> small GCs will take longer than one large GC).
I thought that ephemeral/incremental GC simply recycled short lived
memory blocks so that the trade off didn't really exist.
Even so, once you can use DECLARE in your code, large chunks of GC can
be eliminated. Of course, Java forces you to do the equivalent of
DECLARE up front. Waaaay up front.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
In article <··············@david-steuber.com>,
David Steuber <·····@david-steuber.com> wrote:
> Alex Drummond <············@notanaddress.invalid> writes:
>
> > >
> > > Then why isn't it on by default?
> > >
> >
> > Presumably because most people don't use Java for writing
> > games. Incremental garbage collection probably gives you lower latency
> > at the expense of overall performance (on the assumption that several
> > small GCs will take longer than one large GC).
>
> I thought that ephemeral/incremental GC simply recycled short lived
> memory blocks so that the trade off didn't really exist.
Ephemeral GC typically goes after short lived objects. It also
means that this GC only works in RAM - using a table of changed
memory pages (like in Genera).
Incremental means that the GC runs from time to time doing a bit
of work.
So these are different things.
> Even so, once you can use DECLARE in your code, large chunks of GC can
> be eliminated.
What will you declare? There is the case of dynamic extent data
that can be declared. Then you can say (optimize (space 3)) - but
if the compiler actually does something is up to the implementation.
But then?
> Of course, Java forces you to do the equivalent of
> DECLARE up front. Waaaay up front.
Rainer Joswig <······@lisp.de> writes:
> In article <··············@david-steuber.com>,
> David Steuber <·····@david-steuber.com> wrote:
>
> > Alex Drummond <············@notanaddress.invalid> writes:
> >
> > > >
> > > > Then why isn't it on by default?
> > > >
> > >
> > > Presumably because most people don't use Java for writing
> > > games. Incremental garbage collection probably gives you lower latency
> > > at the expense of overall performance (on the assumption that several
> > > small GCs will take longer than one large GC).
> >
> > I thought that ephemeral/incremental GC simply recycled short lived
> > memory blocks so that the trade off didn't really exist.
>
> Ephemeral GC typically goes after short lived objects. It also
> means that this GC only works in RAM - using a table of changed
> memory pages (like in Genera).
>
> Incremental means that the GC runs from time to time doing a bit
> of work.
>
> So these are different things.
OK. Thanks for the clarification.
I wonder if there are any numbers on Java's GC performance vs Lisp.
Obviously the implementations are what matter. I wonder if such a
comparison can be done.
> > Even so, once you can use DECLARE in your code, large chunks of GC can
> > be eliminated.
>
> What will you declare? There is the case of dynamic extent data
> that can be declared. Then you can say (optimize (space 3)) - but
> if the compiler actually does something is up to the implementation.
> But then?
I know its an implementation issue, but I was quite impressed to see a
48x speed improvement in code under SBCL by simply fully declaring the
types stored in variables and optimizing for speed. I only declared
type and optimize, not dynamic-extent. I don't think SBCL supports
that yet, but I believe OpenMCL does.
How much a compiler can infer without the declerations is also a
mystery to me.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
> How much a compiler can infer without the declerations is also a
> mystery to me.
And a field worthy of (and having received) much research.
For something to give you some food for thought, you may want to play
with Rice U's Scheme interpreter, DrScheme. It's got a mode in which
it can display lots of its compiler's type inferences.
joelh
From: Rahul Jain
Subject: Re: lisp used in game creation?
Date:
Message-ID: <87isadjxyv.fsf@nyct.net>
Joel Ray Holveck <·····@juniper.net> writes:
>> How much a compiler can infer without the declerations is also a
>> mystery to me.
>
> And a field worthy of (and having received) much research.
>
> For something to give you some food for thought, you may want to play
> with Rice U's Scheme interpreter, DrScheme. It's got a mode in which
> it can display lots of its compiler's type inferences.
Do you mean MrSpidey?
Does MrSpidey no longer crash on analyzing an internal DrScheme function?
In any case, just look up the COMP 311 notes by Dr. Cartwright. He
explains exactly what type inference is and how to do it (at least for
H-M type systems...)
Lisps are slightly more complex, but really, the whole thing is rather
obvious... look at the types put in and based on the operator, figure
out the types sent out. For example, + with an (integer 1 15) and a
(rational -5 17) gives a (rational -4 32). For numeric operators,
basically, you do type contagion and then figure out the least possible
result and the greatest possible result by applying the operator to
lower or upper bounds of the input types, with the choice depending on
the operator.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Duane Rettig
Subject: Re: lisp used in game creation?
Date:
Message-ID: <4u0txgzpa.fsf@franz.com>
Rahul Jain <·····@nyct.net> writes:
> Joel Ray Holveck <·····@juniper.net> writes:
>
> >> How much a compiler can infer without the declerations is also a
> >> mystery to me.
> >
> > And a field worthy of (and having received) much research.
> >
> > For something to give you some food for thought, you may want to play
> > with Rice U's Scheme interpreter, DrScheme. It's got a mode in which
> > it can display lots of its compiler's type inferences.
>
> Do you mean MrSpidey?
>
> Does MrSpidey no longer crash on analyzing an internal DrScheme function?
>
> In any case, just look up the COMP 311 notes by Dr. Cartwright. He
> explains exactly what type inference is and how to do it (at least for
> H-M type systems...)
>
> Lisps are slightly more complex, but really, the whole thing is rather
> obvious... look at the types put in and based on the operator, figure
> out the types sent out. For example, + with an (integer 1 15) and a
> (rational -5 17) gives a (rational -4 32). For numeric operators,
> basically, you do type contagion and then figure out the least possible
> result and the greatest possible result by applying the operator to
> lower or upper bounds of the input types, with the choice depending on
> the operator.
In Allegro CL, it's (declare (:explain :calls :types ...))...
--
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
David Steuber wrote:
> Alex Drummond <············@notanaddress.invalid> writes:
>
>
>> >
>> > Then why isn't it on by default?
>> >
>>
>>Presumably because most people don't use Java for writing
>>games. Incremental garbage collection probably gives you lower latency
>>at the expense of overall performance (on the assumption that several
>>small GCs will take longer than one large GC).
>
>
> I thought that ephemeral/incremental GC simply recycled short lived
> memory blocks so that the trade off didn't really exist.
I think it's probably going to cost more to do incremental collection as
opposed to non-incremental collection, because you're going to have to
do extra work to provide the incrementalness. I'm not sure 'incremental'
has to be all that well defined, but it basically means that you do less
GC more often so that you don't have to do as much GC all at once (so
that pauses are shorter).
The advantage of collectors that do it all at once is that they don't
have to worry about things like the mutator changing the heap in the
middle of the collection. By contrast, if a collector is 'incremental'
then presumably that means it might need to stop collecting before it
has visited everything to determine whether it can be disposed, and
since it has to stop before it's done, it essentially will have to
recheck some or all of its work the next time it gets called. So it does
more work. Probably.
For example, sometimes an incremental collector uses a
reference-counting scheme to distribute part of the collection over many
small operations, but this means imposing extra cost on every
assignment. Or sometimes the incremental collector runs in a parallel
thread, basically collecting in the background while the mutator does
its thing. But this means the program must synchronize on memory access,
which imposes extra cost.
Maybe there are incremental collectors that don't impose extra cost, but
I think that depends in part on the memory use of the overall program.
For example, maybe you have a parallel collector whose collection
strategy, when used with your program, gives efficiencies that outweigh
the cost of synchronization. In that case incremental collection doesn't
cost extra because the benefit outweighs the cost. But I don't know
about an incremental strategy that can in general be done without extra
cost (that doesn't mean there isn't one; I'm no GC expert).
On Fri, 10 Sep 2004 16:19:15 +0200, John Thingstad
<··············@chello.no> wrote:
> On Fri, 10 Sep 2004 14:05:17 +0000 (UTC), Frank Buss <··@frank-buss.de>
> wrote:
>
>> "John Thingstad" <··············@chello.no> wrote:
>>
>>>>> Garbage Collection Pauses
>>>
>>> Not on any lisp I have used. The typically use a generational
>>> garbage
>>> collector which
>>> eliminates most of the problem. However Java pauses on me..
>>
>> you can use "java -Xincgc", which turns on incremental garbage
>> collection
>> and is a good ideas for games.
>>
Perhaps this is he time to clarify some issues.
First a incremental garbage collector allocates memory in segments.
When one segment is full it only garbage collects that segment.
A generational garbage collector is bases on the assumption that
most items allocated on the heap are short lived. Therefore it makes
allocation very cheap. (bumping up a pointer)
When the segment is full it copies the elements that are still
alive to a larger heap. (stop and copy algorithm)
Given that most items are 'dead' this is fairly cheap.
The larger heap is GC'ed much more rarely.
It typically uses a "mark and sweep" algorithm.
This algorithm is also often compacting.
You can add more generations. You can also segment the second heap
and do incremental garbage collection on it.
It seems that the most efficient implementations have only two generations.
This gives the best balance between the overhead of the garbage collection
algorithm has and avoiding long winded garbage collections that halt the
programs execution for prolonged periods.
By the way the program that halted was borlands C++ cross development
environment C++ BuilderX, not a game. It seems it had been keeping
events from windows I closed an hour ago allocating more and
more memory. After an hour or two it spends all it's time
trashing data back and to disk. Serious abuse of virtual memory!
Then it stops for 2 minutes while cleaning up..
This is just bad design. (Partly Borlands, partly Java I assume.)
Anyhow generational garbage collection, well implemented, does not add a
significant
overhead and particularly in the case of windows programs can
greatly improve the perceived performance.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> Anyhow generational garbage collection, well implemented, does not add a
> significant
> overhead and particularly in the case of windows programs can
> greatly improve the perceived performance.
>
In the context of this thread, I think a noticeable pause is much shorter
than in virtually any other application. When you need to keep up a
framerate of 60 fps on pain of death, is even the most incremental of
garbage collectors going to make a noticeable pause in the gameplay, or
make the framerate uneven? I think a GC pause of 100 ms or less would be a
maximum.
Perhaps if the game was smart enough to know how much time it had before the
next frame, and try to work around the GC pause by staying a few frames
ahead, and perhaps regulating the framerate... It seems entirely possible.
I bet many 3d engines already do this.
Chris Capel
> Perhaps if the game was smart enough to know how much time it had before
> the next frame, and try to work around the GC pause by staying a few
> frames ahead, and perhaps regulating the framerate... It seems entirely
> possible. I bet many 3d engines already do this.
If you know how close you are to a garbage collection, when it's about to be
triggered by the environment, you could wait until a frame has just been
displayed, then trigger the GC, then keep going. Then the impact is
minimized.
Chris Capel
On Sat, 11 Sep 2004 11:51:34 -0500, Chris Capel <······@iba.nktech.net>
wrote:
> In the context of this thread, I think a noticeable pause is much shorter
> than in virtually any other application. When you need to keep up a
> framerate of 60 fps on pain of death, is even the most incremental of
> garbage collectors going to make a noticeable pause in the gameplay, or
> make the framerate uneven? I think a GC pause of 100 ms or less would be
> a
> maximum.
From my experience a < 100 ms delay is achieved in lisp.
(only tested Allegro and Corman)
If it is a problem a forced garbage collection can be made
before a critical routine. The means is implementation dependent.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> wrote:
> From my experience a < 100 ms delay is achieved in lisp.
> (only tested Allegro and Corman)
how did you measure this?
I've found an interesting article about the IBM Java GC:
http://www-106.ibm.com/developerworks/ibm/library/i-garbage1/
http://www-106.ibm.com/developerworks/ibm/library/i-garbage2/
Maybe with parallel and concurrent mark the stop-time is reduced.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
John Thingstad wrote:
> Perhaps this is he time to clarify some issues.
That would have been an excellent plan. Unfortunately,
what you have actually done is to spread confusion.
(When you post about something you don't know much
about, it is polite to say so rather than to try to
sound like an expert.)
> First a incremental garbage collector allocates memory in segments.
An incremental garbage collector doesn't allocate
memory at all. The allocator that works with an
incremental garbage collector need not allocate
memory in segments.
> When one segment is full it only garbage collects that segment.
I think you're thinking of generational GC here.
Generational GC is not the same thing as incremental
GC. If you *are* thinking of generational GC, though,
this is a pretty misleading description, because it
suggests that it might be any segment that fills up
first. In fact, in a generational GC, all allocation
takes place in the "youngest" segment (i.e., generation)
and that's always the one that fills up first. And
if somehow another generation managed to fill up
sooner, it would no longer be true that "it only
garbage collects that segment" -- all younger ones
would also need GCing.
(Note: for efficiency reasons some allocation
may go straight into the "oldest" generation
instead. When that one fills up, the *whole*
heap is GCed.)
> A generational garbage collector is bases on the assumption that
> most items allocated on the heap are short lived.
This is true.
> Therefore it makes
> allocation very cheap. (bumping up a pointer)
This is nothing to do with generational GC. Many GCed
systems do make allocation (usually) as cheap as bumping
a pointer, but whether you do that or not has nothing
to do with whether you're generational or not.
> When the segment is full it copies the elements that are still
> alive to a larger heap. (stop and copy algorithm)
Generational GC need not actually copy objects to
older generations. There are implementations that
simply diddle a counter, for instance.
> Given that most items are 'dead' this is fairly cheap.
> The larger heap is GC'ed much more rarely.
In a generational GC there may be -- and, I think,
usually are -- several generations. It will be true,
normally, that each generation is GCed much less
often than the next. But, given that there may
be several generations, it's not clear what "It"
refers to in the following statement:
> It typically uses a "mark and sweep" algorithm.
> This algorithm is also often compacting.
> You can add more generations. You can also segment the second heap
> and do incremental garbage collection on it.
> It seems that the most efficient implementations have only two generations.
I would be interested in a reference for this statement.
My knowledge is rather out of date; I thought it was still
(1) an open question and (2) believed to depend on the
workload.
> Anyhow generational garbage collection, well implemented, does not add
> a significant
> overhead and particularly in the case of windows programs can
> greatly improve the perceived performance.
Why Windows programs, especially?
--
Gareth McCaughan
.sig under construc
From: Bulent Murtezaoglu
Subject: GC references (was Re: lisp used in game creation?)
Date:
Message-ID: <874qm486db.fsf_-_@p4.internal>
When we're done discussing who knows what and who confuses people (and how
many cylinders cll has with what kind of performance in the past upmteen
days), we might want to exchange some links. I'll start. The -- possibly
dated -- reference/strating point I know and like is:
Uniprocessor Garbage Collection Techniques by Paul R. Wilson
The citeseer entry is:
http://citeseer.ist.psu.edu/wilson92uniprocessor.html
The download links in citeseer are obsolete but it is downloadable
(with others) from:
http://www.cs.utexas.edu/users/oops/papers.html
ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps [direct link]
cheers,
BM
Bulent Murtezaoglu <··@acm.org> wrote:
> When we're done discussing who knows what and who confuses people (and how
> many cylinders cll has with what kind of performance in the past upmteen
> days), we might want to exchange some links....
The best general reference these days would be Richard Jones's book;
see http://www.cs.kent.ac.uk/people/staff/rej/
His bibliography, with over 1400 references, is at
http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbib.html
Since someone appears to have referred to research by Lars Hansen
and myself, here's a page that contains links to four of our papers,
including Lars's PhD thesis: http://www.ccs.neu.edu/home/will/GC/
I see that it is time for me to update that page...
Will
Bulent Murtezaoglu <··@acm.org> wrote:
> When we're done discussing who knows what and who confuses people (and how
> many cylinders cll has with what kind of performance in the past upmteen
> days), we might want to exchange some links....
The best general reference these days would be Richard Jones's book;
see http://www.cs.kent.ac.uk/people/staff/rej/
His bibliography, with over 1400 references, is at
http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbib.html
Since someone appears to have referred to research by Lars Hansen
and myself, here's a page that contains links to four of our papers,
including Lars's PhD thesis: http://www.ccs.neu.edu/home/will/GC/
I see that it is time for me to update that page...
Will
From: Joe Marshall
Subject: Re: lisp used in game creation?
Date:
Message-ID: <pt4r8dge.fsf@comcast.net>
Gareth McCaughan <················@pobox.com> writes:
> An incremental garbage collector doesn't allocate memory at all.
It could. (couldn't resist)
I was writing an incremental GC and found that in one edge case it
would be very convenient to allocate some memory. There was an
interaction between the GC and the interrupt system that was unlikely
to occur, but could not be ruled out. The ability to take recursive
interrupts meant that it was *possible*, however unlikely, to need an
arbitrary amount of memory. Rather than pre-allocate a huge amount of
memory just in case, it was easier to just allocate out of newspace on
the rare occasion. So long as you collect faster than you allocate,
consing during GC isn't prohibited.
--
~jrm
Joe Marshall <·············@comcast.net> writes:
> Gareth McCaughan <················@pobox.com> writes:
>
> > An incremental garbage collector doesn't allocate memory at all.
>
> It could. (couldn't resist)
Er, yeah, OK. :-)
> I was writing an incremental GC and found that in one edge case it
> would be very convenient to allocate some memory. There was an
> interaction between the GC and the interrupt system that was unlikely
> to occur, but could not be ruled out. The ability to take recursive
> interrupts meant that it was *possible*, however unlikely, to need an
> arbitrary amount of memory. Rather than pre-allocate a huge amount of
> memory just in case, it was easier to just allocate out of newspace on
> the rare occasion. So long as you collect faster than you allocate,
> consing during GC isn't prohibited.
Entertaining.
--
Gareth McCaughan
.sig under construc
John Thingstad wrote:
> It seems that the most efficient implementations have only two generations.
and I asked for more information about this.
As a point of reference, neither Allegro CL nor LispWorks
defaults to "only two generations", unless I have misunderstood
their documentation.
--
Gareth McCaughan
.sig under construc
On Sun, 12 Sep 2004 04:03:01 GMT, Gareth McCaughan
<················@pobox.com> wrote:
> John Thingstad wrote:
>
>> It seems that the most efficient implementations have only two
>> generations.
>
> and I asked for more information about this.
>
> As a point of reference, neither Allegro CL nor LispWorks
> defaults to "only two generations", unless I have misunderstood
> their documentation.
>
When I worked for Opera Software 4 years ago I shared a room with a guy.
He was taking his Ph.D in computer science.
His was about to defend his thesis on garbage collection.
As a consequence I learn quite a bit about garbage collection.
The stuff about two generations being the optimal and the
choice of algorithms are from his thesis.
He basically tested a number of options and explored how
to get the best performance.
(Incidentally he had a summer job at Harlequin (1998) where
he maintained their garbage collector.)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> wrote:
>
> When I worked for Opera Software 4 years ago I shared a room with a guy.
> He was taking his Ph.D in computer science.
> His was about to defend his thesis on garbage collection.
Sounds like Lars Hansen. I was his thesis advisor.
He certainly understands the difference between generational and
incremental garbage collection.
> As a consequence I learn quite a bit about garbage collection.
> The stuff about two generations being the optimal and the
> choice of algorithms are from his thesis.
Well, he found that Larceny's youngest-first generational collector
performed better with two generations than with three on most of his
gc-intensive benchmarks. That finding shouldn't be generalized to
all benchmarks, because gc-intensive benchmarks are (by definition)
a little unusual. Furthermore that finding may not even generalize
to other generational collectors.
> He basically tested a number of options and explored how
> to get the best performance.
Oh, he did much more than that. Among other things, he showed that
hybrid younger-first/older-first generational collection is viable.
By the way, most of the popular implementations of Java now use
generational garbage collection by default, so I don't understand
why you think generational garbage collection is an argument for
Lisp over Java.
Will
On 12 Sep 2004 21:32:21 -0700, William D Clinger <··········@verizon.net>
wrote:
> Sounds like Lars Hansen. I was his thesis adviser.
Right you are.
>
> He certainly understands the difference between generational and
> incremental garbage collection.
So do I.. Maybe I wasn't clear enough.
> By the way, most of the popular implementations of Java now use
> generational garbage collection by default, so I don't understand
> why you think generational garbage collection is an argument for
> Lisp over Java.
I believe I said Java pauses on me some times.
Don't seem to recall mentioning the algorithm.
However memory leaks in Swing seem to be the main cause to this slowdown.
See "Does Java have Memory Leaks?"
http://industry.java.sun.com/javaone/99/pdfs/e618.pdf
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad replied to this
> This page has some info about games written in Lisp, and some Lisp
> bashing:
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
thus:
>>> Lack of types makes it difficult to understand or safely modify large
>>> programs
>
> Types adds to the clutter of creating a program, distracting him from
> the purpose.
<Further explanation of why types are over-rated snipped>
I've just created a little Common Lisp file
(declaim (ftype (function (integer) symbol) bar))
(defun bar(n)(* n n))
(bar "string")
and compiled the file with CMUCL 18d
In: DEFUN BAR
(DEFUN BAR (N) (* N N))
Warning: The result type from previous declaration:
SYMBOL
conflicts with the result type:
UNSIGNED-BYTE
Byte Compiling Top-Level Form:
File: /home/alan/Learning/lisp/safety.lisp
In: BAR "string"
(BAR "string")
Warning: This is not a (VALUES &OPTIONAL INTEGER &REST T):
"string"
Compilation unit finished.
2 warnings
Leaving aside the issue of whether types really help, Lisp
has types, available for the use of those who believe in
them. Different persons mean different things by
"types". Nevertheless, I think my Lisp code and compiler
output exhibit the kind of typing that the article
says Lisp lacks, with the maintainers of a large program
being able to read what types to expect and be warned of
conflicts by the compiler.
I went to Palevich's web site to see where he was coming
from and found:
* Why Lisp Sucks for Games - An Anti-Scheme rant.
Alan Crowe
Edinburgh
Scotland
·······@gmail.com (Manuel Simoni) writes:
> This page has some info about games written in Lisp, and some Lisp
> bashing:
> http://www.spies.com/~palevich/CLRScheme/WhyLispSucksForGames.htm
A quick look tells anyone with even a cursory amount of knowledge that
this guy knows nearly nothing about Lisp. You can safely ignore this
guy due to the fact he is completely ignorant of what he is
blowviating about. Why is that fools like this seem to take such an
odd pleasure in shouting to the world how stupid they are?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Anon wrote:
> is Lisp used in the creation of some games??
Lisp is extensively used in Age of Empires II (published by Microsoft).
Check out the computer AI tutorial:
http://dgdn.net/dgdn.php?id=102&cat=article_pages&cat_ID=1&heading_ID=1
Modpacks (game extensions used for creating your own campaigns and
scenarios) are written in Lisp, example of a modpack:
http://aok.heavengames.com/blacksmith/php/getfile.php3?type=Mods&id=559
Also it seems that Lisp is used in Halo (the bestseller game for
Microsoft Xbox):
http://www.gameai.com/cgdc02notes.html - search for "Question #6".