In <87tyz8e3q4....@ma-patru.mathematik.uni-karlsruhe.de>, Nicolas
Neuss wrote: > Richard Heathfield <r...@see.sig.invalid> writes:
>> But performance is clearly one factor. (Not the only factor, as >> Richard Gabriel rightly points out.) And although I am no Lisp >> expert (in fact, I'm currently a "hello world" kind of guy), it >> seems from my (minimal) research on the subject that it is quite >> difficult to squeeze enough out of Lisp to get it anywhere near C >> in performance terms.
> If one uses a good Common Lisp implementation (especially one which > compiles to native code, as e.g. CMUCL/SBCL, Allegro CL, or > Lispworks), fI would expect that for most code the results for > equivalent code are > not worse than C by a factor of 2 or maybe 3.
<cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. Look, it isn't dirty or anything. Thanks for your time, but I was looking for something a little sportier. I mean, I knew it would be slower, but a factor of TWO?
<snip>
-- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
On Sep 11, 11:11 am, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
> I believe it was another famous Lisp hacker, David Moon, who said that > no language can prevent a bad programmer from writing bad code. The > most we can say is that some languages provide more ways for you > easily write bad code. C is, in some respects, such a language, but > in return it provides various advantages to the careful programmer.
> It's not for nothing that many Lisp implementations are written at > least partly in C.
The reason that part of the runtime of many language implementations, including CL, is written in C is because the environment (OS, system libraries, etc.) is written in C, and at some point we need to interface with them. The simplest way to interface with C is using C, wouldn't you think?
People have found creative ways to minimize the amount of code that needs to be written in C; for example: Pre-Scheme <http:// citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4031>, or ThinLisp <http://www.thinlisp.org/>, etc..
In article <baff19b4-2b3a-4752-9345-0059d7d4d...@h13g2000yqk.googlegroups.com>, Michael Weber <mw+goo...@foldr.org> wrote:
>The reason that part of the runtime of many language implementations, >including CL, is written in C is because the environment (OS, system >libraries, etc.) is written in C, and at some point we need to >interface with them.
That's one reason.
But numerous Lisp interpreters have been written in C, and there are several Lisps that compile to C. The latter case is an example of C's role as a portable assembler language.
-- Richard -- Please remember to mention me / in tapes you leave behind.
Richard Heathfield wrote: > In <87tyz8e3q4....@ma-patru.mathematik.uni-karlsruhe.de>, Nicolas > Neuss wrote:
>> Richard Heathfield <r...@see.sig.invalid> writes:
>>> But performance is clearly one factor. (Not the only factor, as >>> Richard Gabriel rightly points out.) And although I am no Lisp >>> expert (in fact, I'm currently a "hello world" kind of guy), it >>> seems from my (minimal) research on the subject that it is quite >>> difficult to squeeze enough out of Lisp to get it anywhere near C >>> in performance terms. >> If one uses a good Common Lisp implementation (especially one which >> compiles to native code, as e.g. CMUCL/SBCL, Allegro CL, or >> Lispworks), fI would expect that for most code the results for >> equivalent code are >> not worse than C by a factor of 2 or maybe 3.
> <cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. > Look, it isn't dirty or anything. Thanks for your time, but I was > looking for something a little sportier. I mean, I knew it would be > slower, but a factor of TWO?
Keep in mind that we're talking about a language that's extremely flexible and dynamic, similar to 'modern' scripting languages like Python, Ruby, JavaScript, and the like, with all the benefits of providing higher productivity, etc.
Considering that, a factor of only two is very impressive, IMHO.
> Richard Heathfield wrote: > > In <87tyz8e3q4....@ma-patru.mathematik.uni-karlsruhe.de>, Nicolas > > Neuss wrote:
> >> Richard Heathfield <r...@see.sig.invalid> writes: > >> not worse than C by a factor of 2 or maybe 3.
> > <cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. > > Look, it isn't dirty or anything. Thanks for your time, but I was > > looking for something a little sportier. I mean, I knew it would be > > slower, but a factor of TWO?
> Keep in mind that we're talking about a language that's extremely > flexible and dynamic, similar to 'modern' scripting languages like > Python, Ruby, JavaScript, and the like, with all the benefits of > providing higher productivity, etc.
> Considering that, a factor of only two is very impressive, IMHO.
Yes, that's pretty good. I'm working on a dynamic language now which at present is some 3 to 10 times as slow as optimised C (although there's some way to go yet...).
But that's measured for tight integer code. When you throw in some string processing, higher level datatypes, and calls into the runtime, then they can be comparable, say between 1 and 2 times as slow, for a language considerably more expressive (ie. increase in apparent runtime of 0 to 100%). In theory...
So perhaps some of that may be true for Lisp, although it did sound as though you were already pulling out all the stops to get it down to only 2x as slow as C.
And ultimately, for programs with a short runtime, it really doesn't matter if it takes 100ms or 200ms.
James Kuyper <jameskuy...@verizon.net> writes: > James Dow Allen wrote: [...] >> ... Isn't "0" the only Boolean false >> in C? ...
> If you mean a value of boolean type no. The constant 0 has int > type. C90 doesn't have any boolean type as such; in C99 you could use > (_Bool)0 or, if you #include <stdbool.h>, you could also use (bool)0.
> If you mean a value that is treated as false when it appears as a > condition in if(), while(), or for() statements, or in ?: expressions, > the answer is still "No". Any C expression with a value of 0 is > treated as false in those contexts. The value 0 can be represented in > any integer, floating point (including complex and _Imaginary), or > character type. As a special rule, a null pointer of any type compares > equal to 0, even though 0 is an integer, not a value of pointer type: > the 0 gets implicitly converted to a null pointer of the corresponding > type, for purposes of the comparison.
To be painfully precise, it's not quite "Any C expression with a value of 0" that's treated as false, it's any C expression whose value *compares equal* to 0.
0, which is syntactically an octal (yes, octal) integer constant, yields the value zero of type int. 0.0 yields the value zero of type double; it's really a different value, since it's of a different type. But the comparison (0.0 == 0) yields a true result because of the conversion rules, so in "if (0.0)" it's treated as false.
So rather than "Any C expression with a value of 0", it's any C expression whose value, when compared to 0 using "==", after any conversions imposed by the "==" operator to force both operands to be of the same type.
> As a result, there are LOTS of ways to write a constant with a value > that counts as false in C. Here's just a few of them:
> And of course, (T*)0, where T represents any arbitrary type.
'-'-'-'
[...]
> I think it would be a good idea for conditions to require an > expression of boolean type, with all comparison operators returning > values of that type, and with no conversions allowed to and from > boolean type. The equivalent of such conversions could be achieved by
> (nonbool == 0)
> and
> (boolvalue ? 1 : 0)
> Such rules would be a minor inconvenience when writing code, but would > make the code clearer and more maintainable. However, the need for > backwards compatibility means that such a change could never be made > to C.
I agree, both that it would be better and that it's too late for C.
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
> <cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. > Look, it isn't dirty or anything. Thanks for your time, but I was > looking for something a little sportier. I mean, I knew it would be > slower, but a factor of TWO?
> <snip>
Oh, trolling through the park. I think you should put C back on the shelf and program in assembler. Real men program in assembler. But maybe if you program in binary you would save all the time it takes to run through an assembler. So maybe real men program in binary. RJF
>> <cough, splutter> Er, okay, I think I'll put Lisp back on the >> shelf. Look, it isn't dirty or anything. Thanks for your time, but >> I was looking for something a little sportier. I mean, I knew it >> would be slower, but a factor of TWO?
>> <snip>
> Oh, trolling through the park. I think you should put C back on the > shelf and program in assembler. Real men program in assembler. > But maybe if you program in binary you would save all the time it > takes to run through an assembler. So maybe real men program in > binary. RJF
Been there, done that. Programmed in machine code and assembly language, and written an admittedly not very sophisticated assembler. No big deal, actually - it's easier than many people think.
But C combines power with portability, which neither machine code nor assembly language can manage.
This isn't about "real men", and it isn't about trolling. Clearly, Lisp has benefits that make it attractive to those who choose to use it. (Otherwise, they wouldn't choose it, right?) And presumably they rate it above C because either it lacks those benefits completely or lacks them in sufficient degree. Likewise, C has benefits that make it, for some people, more attractive than Lisp.
And then there are those horribly objective people who will let the task govern the language choice. What are we to do with *them*? :-)
-- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
> On Sep 12, 3:17 pm, Vassil Nikolov <vniko...@pobox.com> wrote:
> > On Sat, 12 Sep 2009 00:30:15 -0700 (PDT), James Dow Allen <jdallen2...@yahoo.com> said: > > The meaning of > > b+++c > > in the C programming language cannot be asserted by what a compiler > > does with it ...
> Yep. Sorry if my post implied otherwise. :-) > I sometimes report gcc's behavior in lieu of quoting > The Standard(tm) (which I've never read) since, if there's > a difference, it would be interesting to know!
> > ... the syntactic rule (which I thought was very > > well known) that, essentially, tokenization is greedy ...
> I'm sure it's well known to C language experts, but count me > out there! In 30 years of C programming (which never included > a C parser, obviously) I've *never* needed to remember this > fact! Perhaps my C coding is just too tame, but > I don't think it's been overly unsuccessful. For me, C > is about interesting algorithms like some of the code or puzzles > at my website, but I know for some of you it's more important > to see who can parse "a+ + ++ + +b" first. :-)
> > > (BTW, gcc accepts both "a+ + + +b" and "a+ ++ +b" > > > without complaint but generates *different* results > > > for them! Is *this* compliant?)
> > These are two different expressions, of course, but is > > +b > > an lvalue?
> I sure don't think so! This gcc behavior is mysterious to me; > I stumbled on it only because I'd already typed in the > unremembered "+++" case and added some more "+"s just for > fun. :-)
> > > ... > > > By this measure, Fateman might win the debate with > > > (dolist (x Foo) > > > (Guzzle x)) > > > compared with C's slightly less terse > > > for (x = Foo_head; x; x = x->next) > > > Guzzle(x); > > > but a C programmer might #define dolist > > > if tersity is all that matters.
> > What would that definition look like? (The body of DOLIST may > > contain an arbitrary number of forms.)
> As I imply, I don't advocate it (except for special purposes) > but simplest might be > #define dolist(x,h) for (x = h; x; x = x->next) > Now the Lisp fragment above "translates" to > dolist(x, Foo) { > Guzzle(x); > } > Very similar -- except for trivia like a prefix "(" > becoming an infix "{".
Where is x declared in the C version? dolist in Lisp introduces a new local variable.
> > <cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. > > Look, it isn't dirty or anything. Thanks for your time, but I was > > looking for something a little sportier. I mean, I knew it would be > > slower, but a factor of TWO?
> > <snip>
> Oh, trolling through the park. I think you should put C back on the > shelf and program in assembler. Real men program in assembler. > But maybe if you program in binary you would save all the time it takes > to run through an assembler. So maybe real men program in binary. > RJF
Bart wrote: > On Sep 12, 3:12 pm, Pascal Costanza <p...@p-cos.net> wrote: >> Richard Heathfield wrote: >>> In <87tyz8e3q4....@ma-patru.mathematik.uni-karlsruhe.de>, Nicolas >>> Neuss wrote: >>>> Richard Heathfield <r...@see.sig.invalid> writes:
>>>> not worse than C by a factor of 2 or maybe 3. >>> <cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. >>> Look, it isn't dirty or anything. Thanks for your time, but I was >>> looking for something a little sportier. I mean, I knew it would be >>> slower, but a factor of TWO? >> Keep in mind that we're talking about a language that's extremely >> flexible and dynamic, similar to 'modern' scripting languages like >> Python, Ruby, JavaScript, and the like, with all the benefits of >> providing higher productivity, etc.
>> Considering that, a factor of only two is very impressive, IMHO.
> Yes, that's pretty good. I'm working on a dynamic language now which > at present is some 3 to 10 times as slow as optimised C (although > there's some way to go yet...).
> But that's measured for tight integer code. When you throw in some > string processing, higher level datatypes, and calls into the runtime, > then they can be comparable, say between 1 and 2 times as slow, for a > language considerably more expressive (ie. increase in apparent > runtime of 0 to 100%). In theory...
> So perhaps some of that may be true for Lisp, although it did sound as > though you were already pulling out all the stops to get it down to > only 2x as slow as C.
That depends on the kind of application you want to build. The good thing about Lisp is, though, that you can stay within the same language both for the convenient, flexible parts as well as for the performance-critical parts. You don't have to get outside the boundaries of Lisp "just" for performance purposes.
> > Keith Thompson <ks...@mib.org> wrote: > > >Oh goody, a cross-posted language war! Those are always so interesting > > >and constructive.
> > I'm of the opinion that both LISP and C are pretty rockin', and we all > > should just go out for pints. Amen.
> Hmmm. Maybe we could morph this into a Beer vs. Ale discussion?
We can't. Ale is a kind of beer. You're thinking of ale vs. lager, or even more correctly, of top-fermented vs. bottom-fermented beers. But since I've just finished a Belgian trappist and am halfway through a Dutch white beer, I'd much prefer to opine that I really, really like both (*hic*).
Michael Weber <mw+goo...@foldr.org> wrote: > The reason that part of the runtime of many language implementations, > including CL, is written in C is because the environment (OS, system > libraries, etc.) is written in C, and at some point we need to > interface with them. The simplest way to interface with C is using C, > wouldn't you think?
No. Only people who understand computing theory, but not computing practice, would think so. I would add a nasty remark about Lispers here, but really, I can't be arsed. (And it would probably only be true about Lisp _advocates_, anyway - as opposed to normal Lisp users.)
> On Sep 12, 3:12 pm, Pascal Costanza <p...@p-cos.net> wrote:
> > Richard Heathfield wrote: > > > In <87tyz8e3q4....@ma-patru.mathematik.uni-karlsruhe.de>, Nicolas > > > Neuss wrote:
> > >> Richard Heathfield <r...@see.sig.invalid> writes: > > >> not worse than C by a factor of 2 or maybe 3.
> > > <cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. > > > Look, it isn't dirty or anything. Thanks for your time, but I was > > > looking for something a little sportier. I mean, I knew it would be > > > slower, but a factor of TWO?
> > Keep in mind that we're talking about a language that's extremely > > flexible and dynamic, similar to 'modern' scripting languages like > > Python, Ruby, JavaScript, and the like, with all the benefits of > > providing higher productivity, etc.
> > Considering that, a factor of only two is very impressive, IMHO.
> Yes, that's pretty good. I'm working on a dynamic language now which > at present is some 3 to 10 times as slow as optimised C (although > there's some way to go yet...).
> But that's measured for tight integer code. When you throw in some > string processing, higher level datatypes, and calls into the runtime, > then they can be comparable, say between 1 and 2 times as slow, for a > language considerably more expressive (ie. increase in apparent > runtime of 0 to 100%). In theory...
> So perhaps some of that may be true for Lisp, although it did sound as > though you were already pulling out all the stops to get it down to > only 2x as slow as C.
It depends what are you doing with it. Beside the extremely naive coding practices, in normal use its something like a third slower than c++ without optimizations. That was a drop in frame rate I was experiencing when coding graphic demos with c++ vs cl. The convenience for that price in speed is enormous. Instead of using scripts to modify its behavior while the demo is running I could just stop it and use the Lisp REPL, full language is available all the time, you could just recompile some function and restart the game loop, the new version is immediately there, no need for rebuilding the project or do anything like that. You could practically change the whole system at runtime. Unless the problem is very well known the price in efficiency is worth it.
Slobodan Blazeski <slobodan.blaze...@gmail.com> wrote: +--------------- | Richard Fateman <fate...@cs.berkeley.edu> wrote: | > ... Real men program in assembler. | > But maybe if you program in binary you would save all the time it takes | > to run through an assembler. So maybe real men program in binary. | | Nope, real programmers use butterflies http://xkcd.com/378/ +---------------
Naaahh... Read the tooltip text on that one:
Real programmers set the universal constants at the start such that the universe evolves to contain the disk with the data they want.
Anthropic programming!! Simply select a universe from the Many Worlds such that your coding problems all solve themselves. Yeah, that's the ticket...
-Rob
p.s. But Emacs's "good ol' C-x M-c M-butterfly" was cute, too. ;-}
----- Rob Warnock <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
r...@rpw3.org (Rob Warnock) writes: > Slobodan Blazeski <slobodan.blaze...@gmail.com> wrote: > +--------------- > | Richard Fateman <fate...@cs.berkeley.edu> wrote: > | > ... Real men program in assembler. > | > But maybe if you program in binary you would save all the time it takes > | > to run through an assembler. So maybe real men program in binary. > | > | Nope, real programmers use butterflies http://xkcd.com/378/ > +---------------
> Naaahh... Read the tooltip text on that one:
> Real programmers set the universal constants at the start such that > the universe evolves to contain the disk with the data they want.
> Anthropic programming!! Simply select a universe from the Many Worlds such > that your coding problems all solve themselves. Yeah, that's the ticket...
> p.s. But Emacs's "good ol' C-x M-c M-butterfly" was cute, too. ;-}
<WAY_OT> GNU emacs 23.1 actually has a M-x butterfly command. </WAY_OT>
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Heathfield <r...@see.sig.invalid> writes: > In <87tyz8e3q4....@ma-patru.mathematik.uni-karlsruhe.de>, Nicolas > Neuss wrote:
>> Richard Heathfield <r...@see.sig.invalid> writes:
>>> But performance is clearly one factor. (Not the only factor, as >>> Richard Gabriel rightly points out.) And although I am no Lisp >>> expert (in fact, I'm currently a "hello world" kind of guy), it >>> seems from my (minimal) research on the subject that it is quite >>> difficult to squeeze enough out of Lisp to get it anywhere near C >>> in performance terms.
>> If one uses a good Common Lisp implementation (especially one which >> compiles to native code, as e.g. CMUCL/SBCL, Allegro CL, or >> Lispworks), fI would expect that for most code the results for >> equivalent code are >> not worse than C by a factor of 2 or maybe 3.
> <cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. > Look, it isn't dirty or anything. Thanks for your time, but I was > looking for something a little sportier. I mean, I knew it would be > slower, but a factor of TWO?
Now, assume you need 10 days to write your program in C, that will run in 5 minutes. Total: 10 days, 5 minutes to get the answers.
In Lisp, indeed the program will run in 10 or perhaps 15 minutes. But you will need only 3 days to write it in Lisp. Total: 3 days 15 minutes. That's actually 3 times faster!
On 2009-09-13, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> Now, assume you need 10 days to write your program in C, that will run > in 5 minutes. Total: 10 days, 5 minutes to get the answers.
> In Lisp, indeed the program will run in 10 or perhaps 15 minutes. But > you will need only 3 days to write it in Lisp. Total: 3 days 15 > minutes. That's actually 3 times faster!
Assuming only one person ever runs the program, and it only runs once, yes.
Imagine that you're targeting something that will run in a period of months on a supercomputer. At that point, a 20% decrease in runtime could save you several times the cost of having your whole development team work for the entire lifespan of the product.
In short, special case examples can make just about anything seem like a good idea. In the bulk of cases, the right thing to do is to figure out what your requirements are, and decide what tools to use based on that. There's stuff I write in Ruby, stuff I write in shell, stuff I write in C, and even stuff I write in English instructions to someone with 15 years' less experience. It's all a question of costs and benefits...
On Sat, 12 Sep 2009 19:54:29 -0500, r...@rpw3.org (Rob Warnock) wrote: > > Nope, real programmers use butterflies http://xkcd.com/378/
> Anthropic programming!! Simply select a universe from the Many Worlds such > that your coding problems all solve themselves. Yeah, that's the ticket...
> p.s. But Emacs's "good ol' C-x M-c M-butterfly" was cute, too. ;-}
To be honest, I was mildly annoyed at the randomly selected key bindings like `M-c' and `M-butterfly'. They should have been more realistic, eg. `M-x butterfly-mode C-u C-c C-c'. The `M-butterfly' one was the one that almost spoiled the joke for me. But it was a very funny xkcd joke indeed ;-)
On 2009-09-13, Giorgos Keramidas <keram...@ceid.upatras.gr> wrote:
> To be honest, I was mildly annoyed at the randomly selected key bindings > like `M-c' and `M-butterfly'. They should have been more realistic, > eg. `M-x butterfly-mode C-u C-c C-c'. The `M-butterfly' one was the one > that almost spoiled the joke for me. But it was a very funny xkcd joke > indeed ;-)
Pascal J. Bourguignon wrote: > Richard Heathfield <r...@see.sig.invalid> writes:
>> In <87tyz8e3q4....@ma-patru.mathematik.uni-karlsruhe.de>, Nicolas >> Neuss wrote:
>>> Richard Heathfield <r...@see.sig.invalid> writes:
>>>> But performance is clearly one factor. (Not the only factor, as >>>> Richard Gabriel rightly points out.) And although I am no Lisp >>>> expert (in fact, I'm currently a "hello world" kind of guy), it >>>> seems from my (minimal) research on the subject that it is quite >>>> difficult to squeeze enough out of Lisp to get it anywhere near C >>>> in performance terms. >>> If one uses a good Common Lisp implementation (especially one which >>> compiles to native code, as e.g. CMUCL/SBCL, Allegro CL, or >>> Lispworks), fI would expect that for most code the results for >>> equivalent code are >>> not worse than C by a factor of 2 or maybe 3. >> <cough, splutter> Er, okay, I think I'll put Lisp back on the shelf. >> Look, it isn't dirty or anything. Thanks for your time, but I was >> looking for something a little sportier. I mean, I knew it would be >> slower, but a factor of TWO?
> Now, assume you need 10 days to write your program in C, that will run > in 5 minutes. Total: 10 days, 5 minutes to get the answers.
> In Lisp, indeed the program will run in 10 or perhaps 15 minutes. But > you will need only 3 days to write it in Lisp. Total: 3 days 15 > minutes. That's actually 3 times faster!
That assumes the software is only being run once. I've just been doing server sizing for one customer, and they are talking about over 600 users, so if each user only uses the software once that is 600 uses, so...
lisp 10 minutes * 600 = 6000 minutes = 100 hours = approx 4 days So list would be total of 7 days assuming one use only.
C gives 12 days.
Now, how many pieces of software are only run once? This customer will be buying an annual license. So assume only half the users use it on any given day and they only use it once, and a working year of 200 days. Suddenly a much smaller performance improvement becomes well worth while! Oh, and that is one customer among many.
Sometimes performance is important, and spending a few days to save a few seconds can be worth while. -- Flash Gordon
På Sun, 13 Sep 2009 07:14:52 +0200, skrev Pascal J. Bourguignon <p...@informatimago.com>:
> Now, assume you need 10 days to write your program in C, that will run > in 5 minutes. Total: 10 days, 5 minutes to get the answers.
> In Lisp, indeed the program will run in 10 or perhaps 15 minutes. But > you will need only 3 days to write it in Lisp. Total: 3 days 15 > minutes. That's actually 3 times faster!
That is what scripting languages do. This reasoning is not all that relevant for application programming though where it is written one and run 1000 000 times. By your argument I should probably use Python which I find even more productive than Lisp.. I think the point is Lisp is usually fast ENOUGH. Python is 100 times slower than C (or more) so you are much more likely to run into problems here.
> Richard Heathfield <r...@see.sig.invalid> writes:
>> In <87tyz8e3q4....@ma-patru.mathematik.uni-karlsruhe.de>, Nicolas >> Neuss wrote:
>>> Richard Heathfield <r...@see.sig.invalid> writes:
>>>> But performance is clearly one factor. (Not the only factor, as >>>> Richard Gabriel rightly points out.) And although I am no Lisp >>>> expert (in fact, I'm currently a "hello world" kind of guy), it >>>> seems from my (minimal) research on the subject that it is quite >>>> difficult to squeeze enough out of Lisp to get it anywhere near C >>>> in performance terms.
>>> If one uses a good Common Lisp implementation (especially one >>> which compiles to native code, as e.g. CMUCL/SBCL, Allegro CL, or >>> Lispworks), fI would expect that for most code the results for >>> equivalent code are >>> not worse than C by a factor of 2 or maybe 3.
>> <cough, splutter> Er, okay, I think I'll put Lisp back on the >> shelf. Look, it isn't dirty or anything. Thanks for your time, but >> I was looking for something a little sportier. I mean, I knew it >> would be slower, but a factor of TWO?
Ah, a nice neutral, impartial, unbiased... Lisp advocacy site. Furrfu.
> Now, assume you need 10 days to write your program in C, that will > run in 5 minutes. Total: 10 days, 5 minutes to get the answers.
> In Lisp, indeed the program will run in 10 or perhaps 15 minutes. > But you will need only 3 days to write it in Lisp. Total: 3 days 15 > minutes. That's actually 3 times faster!
Now, assume I need two days to write it in C, and it will run in 5 minutes. Total: 2 days 5 minutes to get the answers.
In Lisp, the program may indeed run in 10 or perhaps 15 minutes. But, speaking personally, I will need several months to write the program. Total time: several months and 15 minutes.
-- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
Richard Heathfield <r...@see.sig.invalid> writes: > Now, assume I need two days to write it in C, and it will run in 5 > minutes. Total: 2 days 5 minutes to get the answers.
> In Lisp, the program may indeed run in 10 or perhaps 15 minutes. But, > speaking personally, I will need several months to write the program. > Total time: several months and 15 minutes.
A farmer from Maine was visiting his cousin in Texas. "I can get in my truck at dawn, drive all day, and still not be at the other end of my ranch by sundown," his cousin bragged. The Mainer nodded. "I used to have a truck like that, too."
