> Okay, so some of us like C and some of us like LISP. We each have our > own reasons and experiences to back up our decision. Can we please, > please stop posting about it? I hate to "kill" a certain thread because > I feel that sometimes I might miss something that makes me a little > wiser, but I also hate the way this thread has gone. This is basically a > "na na na nanana, my language is better than yours" thread and is > begging to get a little sickening. > No one, of course, has to stop posting, but please drop it. The whole > newsgroup is getting cluttered up with this. > What I have learned from this newsgroup is that C programmers are > going to program in C and that LISP programmers are going to program in > LISP. That's all. Nothing else.
> THankyouverymuch, > Jose
It is not so bad, actually. Before I followed flamewar just like this I had no idea that numerical code in Lisp may be as efficient as in C and that Lisp can do a lot of other thing I never suspected before. There are probably a lot of lurkers that will learn some new things about Lisp that they would never learn otherwise and give it a try.
Of course it would help if exchange would be less emotional.
In article <3063183095872...@naggum.no> Erik Naggum <e...@naggum.no> writes: >* Scott Schwartz >| Just to be fair, you ought to measure the same thing. In the first >| case you measure the time to load and initialize the C runtime system. >| In the second case you already have Lisp fired up, so you omit the >| measurements for the cost of doing that. Let's see the time for the >| a.out generated by ACL or CMUCL, starting at the shell prompt. >right. the usual reaction from "C just _has_ to win"-people is to force >everything to fit its paradigm. when C loses by a factor of 2, it has to >be explained away with some nonsense like the above.
I'm probably not the only one who feels you are arrogant. The concern over your biased benchmarking is well placed, whether or not your revised benchmarkings bring significant differences.
>a Lisp system is like a shell. in Unix, the shell evaluates your command >line, including forking and running programs and whatnot. in Lisp systems, >Lisp evaluates your expressions. if you goal in life is to get something >done efficiently, you measure what is natural in each environment. if your >goal in life is to execute a.out files efficiently, never mind what they >do, then, and only then, should you generate a.out files for all test >cases.
I agree. On a given system, if Lisp is already available at no further cost in time or space to the user, the inherent advantage should not be factored out. However, if Lisp on your system must be loaded (like archaic MS-DOS BASIC interpreters, for instance), factoring out the load time is unfair.
>but let's see what difference the runtime system _does_ make. ACL has a >nice foreign function interface that should even out the costs:
[...]
Since you bothered enough to do it anyway, why bother with the two previous paragraphs? I'm not following very closely, but I think DJ Bernstein provided C solutions that has undergone some algorithmic optimizations. Have you examined those?
Okay, so some of us like C and some of us like LISP. We each have our own reasons and experiences to back up our decision. Can we please, please stop posting about it? I hate to "kill" a certain thread because I feel that sometimes I might miss something that makes me a little wiser, but I also hate the way this thread has gone. This is basically a "na na na nanana, my language is better than yours" thread and is begging to get a little sickening. No one, of course, has to stop posting, but please drop it. The whole newsgroup is getting cluttered up with this. What I have learned from this newsgroup is that C programmers are going to program in C and that LISP programmers are going to program in LISP. That's all. Nothing else.
In article <8gd8uuxpo2....@galapagos.cse.psu.edu> schwa...@galapagos.cse.psu.edu.NO-SPAM "Scott Schwartz" writes:
> In article <3063147946409...@naggum.no> Erik Naggum <e...@naggum.no> writes: > | $ time lotto > | in ACL, (time (lotto 35 7)) reports:
> Just to be fair, you ought to measure the same thing. In the first > case you measure the time to load and initialize the C runtime system. > In the second case you already have Lisp fired up, so you omit the > measurements for the cost of doing that. Let's see the time for the > a.out generated by ACL or CMUCL, starting at the shell prompt.
This is silly. A Lisp programmer could just as easily ask how easily you can write a C program that can extend itself at runtime (not always a typical use of Lisp, but it can be done), and how general your solution would be, and how efficient the code it generated would be.
There's nothing to stop Erik from running the lotto code within an alreday running Lisp environment. A "fair comparison" that you ask for should perhaps compile the C code before running it. I'm that too would add to the run time.
Here's a more realistic example (one that I know Erik will be familiar with). Imagine that the lotto code is run from a web server. The C code might well be run as a new process, adding to the loading of the machine. A web server that uses Lisp could just call the function.
Of course, there are ways of doing this in C (ISAPI, etc), but the "process vs language environment" comparison is not very meaningful, unless you have a specific application in mind that demands one approach and excludes the other, i.e. a contrived example that only tells us about the demands of that one example.
I sometimes suspect that both C _and_ Lisp people are guilty of this mistake. If you're fortunate enough to find a tool that works well for you, that's great. However, please don't assume that what works for you will be equally good for everyone else. Similarly, please don't assume that what fails for you will fail for everyone else.
Humans and dolphins. -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Martin Rodgers | Developer and Information Broker | London, UK Please remove the "nospam" if you want to email me. "Blow out the candles, HAL."
In article <2937085...@hoult.actrix.gen.nz> Br...@hoult.actrix.gen.nz (Bruce Hoult) writes: >> In some contexts that's undoubtedly a feature, but not in the >> context of writing mission-critical user-level applications. >> Forcing the programmer to make a manual check for overflow every >> time a calculation is made makes for wasteful and inefficient >> development.
>I'm not sure that I agree.
>The vast majority of integer calculations made in programs simply *can't* >overflow, unless some grave logic error has been made that will prevent the >program working at all. Programmers well know when they're writing a line >of code of which the size of the result is sufficiently unknown that it >might overflow. They need to *think* about whether it can overflow or not, >and what to do about it if it does. Automatic checks for overflow might be >useful as an ambulance at the bottom of the cliff, but any programmer who >allows the automatic overflow machinery to kick in on a machine integer >calculation in a mission-critical application has badly failed in his duties.
I think this is silly. It's tough enough for an expert programmer to build a non-trivial program that doesn't have any bugs in normal cases. Let alone your average programmer trying to deal with obscure cases. At least if the language gives an error, someone might find a problem like this in the testing phase. If it's silently ignored, then nobody will even know that there was a problem in the program during development *or* deployment. Or if it is noticed it will be sufficiently difficult to find that it will be ignored anyway.
The right answer for 99% of cases has got to be to use a language with safe arithmetic, and then hand optimise for performance problems, possibly using something like the lisp macro someone else described.
> ...as soon as you have your values... > if( (u > MAXUINT-10) || (v > (MAXUINT / (u+10)) - 4) ) { > error_function("An error occurred at *this* point."); > /* The expression below is *not* an error. */ > }
> ...sometime later...
> v = ((u + 10) * (v + 4));
>See, I think the issue of security/safety is not a language issue, but >a programming issue.
Are you joking? How many C programmers even *know* about MAXUINT, let alone know exactly how to use it to find arithmetic errors, *let alone* are able to get it right consistently with lots of complicated calculations.
In article <3063227791126...@naggum.no> Erik Naggum <e...@naggum.no> writes: >* Scott Schwartz >| I don't think it does even out the costs. For one thing, you didn't >| measure the cost of (load "lotto.o"). >you're being stupid on purpose. you don't include compilation, assembling, >and linking time in C programs, so why do you do it for Lisp? go away.
Question: Do you recompile, assemble, and link your C executable every time you need to run it?
Question: Do you need to load your Lisp program every time you run it? (How often is it already in memory?)
An accurate benchmark must first simulate the usual working environment, and the usual working environment for C is that the program is already compiled to an executable, sitting perhaps on disk. I am not familiar with the usual Lisp environment, so that part is up to you.
Unless your Lisp code is usually already in memory, "load" is not without cost, and any fair benchmarking must include that cost, however minute its contributions. Calling other people stupid is not going to win any points. Remember also that enough "negligible" costs ignored can add up to an inaccurate benchmark.
> > While Alan Perlis once said that, "Lisp programmers know > > the value of everything and the cost of nothing", he could > > just easily be paraphrased, "C programmers know the cost > > of everything and the value of nothing".
> Actually, you don't need to paraphrase; he said this much more directly. > The quote - I heard it many times, in, most likely, all four of the > different forms implied by the following - was:
> "[C|Unix] has set back the state of computer science [10|15] years".
The worse thing is: Bill Gates came and pushed Basic/DOS, and this certainly is the way back to the early 50th (certainly to a date before Lisp was invented ;-).
But as C and Unix were hacker projects around '70 and got public (in the broader sense) at around '80, a step back by 10 years should be expected, anyway. Basic was a Hacker project in the 60th, and DOS was crap only. And that's what many people use now, although it's cluttered with Windows, the worst GUI incarnation (from the CS point of view) the world has seen yet.
* Steven Huang | Question: Do you recompile, assemble, and link your C executable every | time you need to run it?
of course not.
| Question: Do you need to load your Lisp program every time you run it? | (How often is it already in memory?)
of course not.
| An accurate benchmark must first simulate the usual working environment,
sigh. what were we measuring? were we measuring the time from we put the phone down after ordering a brand new computer all the way through getting the number of combinations on a lotto coupon, or were we measuring how fast a single function ran? I was measuring the latter. I think this goes beyond the bloody obvious.
| I am not familiar with the usual Lisp environment, so that part is up to | you.
depends on your needs. if it the function always needed in your Lisp programs, you link the Lisp image with it (in case of a .o file), or you dump a new lisp image with it (in case of a Lisp function). if it is not very frequently used, but often enough that you want to have it available, you could autoload it or load a stub function. if it is rarely necessary, you typically load the .o or compiled Lisp function before you start using it. in either case, it is in memory when you call it, and it will stay in memory. you also typically have a Lisp running throughout your whole session, just like X or xterm or the shell or Emacs. not all applications under Unix are as ephemeral as say, an `ls' command.
there is no theoretical upper limit to how much time must have elapsed before you can determine that some process has started (except for the beginning of time, which we don't know how far back is). if I say that I include the time it took to load a file from disk, you could argue that the disk needs to reach its calibrated spin speed, which could be a significant number of seconds. it gets sillier and sillier, of course, but if you don't want to limit the timing to the smallest possible timable event, you will never, and I mean _never_ in the absolute sense, get two people to agree on _any_ timing statistics. which I assume is _your_ point. mine was trying to show a useful correspondence between compiled code in two languages. I repeat myself, but please go away.
#\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.
Chris Bitmead <Chris.Bitm...@Alcatel.com.au> wrote:
: Actually, the really correct way to do it, is to specify precicely : what range to support. Like int:-2000,75000 or some such to specify : exactly what range you will use. Then if there is some hypothetical : machine with 20bit words, you don't have to upgrade to 32 bits when : porting just for safety's sake. Oh, and a nice implementation would : have a checking mode to tell you when you've exceeded your : self-imposed limit. Better than having a limited exception facility : where the only boundaries you can impose are 16, 32 and 64 bits.
I think that sounds rather like the (experimental) language "NewSpeak" that was being developed at, I think, RSRE (a UK defence establisment) for "verified" applications.
-- -------------------------------------------------------------------------- david shepherd SGS-THOMSON Microelectronics Ltd, 1000 aztec west, bristol bs12 4sq, u.k. tel/fax: +44 1454 611522/617910 email: d...@bristol.st.com "whatever you don't want, you don't want negative advertising"
> The example of proper string handling, on the other hand, is > something that can be efficiently and easily implemented in C.
However, this is not a part of the standard libraries, and result in a lot of reinvented wheels (to every man (*and* woman...) his own support library, with strings and containers!).
But of course, you refer to this, further down: [snip!]
>> Obviously, something makes C "not great for writing big applications." > The poverty of the standard libraries, the lack of strong type > checking, the lack of garbage collection, the lack of scheduling, > sure, lots of reasons. Like I said, I like Smalltalk.
Oh come on, Peter, you know that C's macros are annoyingly limited. Suppose you wanted this macro to only evaluate u once? C's macro language gives the impression of being designed to be just powerful enough to implement getchar(), but no more.
Inline functions sometimes do the trick, but there are plenty of cases where you just can't do what you want with either macros or functions, especially in the cases where you are effectively "extending the language" to overcome problems like C's second-class arrays.
-- Richard -- "The Socialists had many branches in America, and the deceased had no doubt infringed their unwritten laws" - A Study in Scarlet
In article <3063405313554...@naggum.no> Erik Naggum <e...@naggum.no> writes:
[...]
>there is no theoretical upper limit to how much time must have elapsed >before you can determine that some process has started (except for the >beginning of time, which we don't know how far back is). if I say that I >include the time it took to load a file from disk, you could argue that the >disk needs to reach its calibrated spin speed, which could be a significant >number of seconds. it gets sillier and sillier, of course, but if you >don't want to limit the timing to the smallest possible timable event, you >will never, and I mean _never_ in the absolute sense, get two people to >agree on _any_ timing statistics.
You are incorrect. You can easily get consensus on the fairness of a comparison. This means that your audience is convinced that your method is sound and you aren't biased against one of the solutions. IOW, the error margin should be small enough to be acceptable, and that goal is far from "never" reached.
Numerous benchmarks for CPUs are available and accepted by the industry. "Accepted" doesn't mean that one cannot nitpick and point out small differences, but it does mean that the industry will take the results from such acceptable tests and benchmarks as relevant statistics and these small differences as side notes to those statistics.
It is your duty as a person making an assertion to provide satisfactory proof that your methods are sound, but your impatience and arrogance prevents this step from being carried out.
>which I assume is _your_ point. mine >was trying to show a useful correspondence between compiled code in two >languages. I repeat myself, but please go away.
If this is the only thing you can say to somebody who questions your method, then I feel sorry for you. I will go away, and you are free to feel victorious in an argument against everyone you ordered to go away.
* Steven Huang | You can easily get consensus on the fairness of a comparison.
so what went wrong when you think my comparison is unfair, and I think you're being silly about it? sure doesn't look like "easily" to me, but your answer to this no doubt lies in your attitude to what I say: it is important to you to say that I'm wrong regardless of what I'm saying, and the most important thing to you now is how impatient and arrogant I am.
| It is your duty as a person making an assertion to provide satisfactory | proof that your methods are sound, but your impatience and arrogance | prevents this step from being carried out.
really? how come you fail to read answers to your questions?
my experience tells me that a minority of people get much more upset with what they perceive as "impatience" or "arrogance" than anything else I do and they will make a hell of a stink about it -- in fact, they get much more upset that somebody, somewhere in this world can dare to be arrogant than any other possible ill or evil on the whole planet. morover, I hear complaints about my technical expertise _only_ from people who have already jumped to the conclusion that I'm arrogant or impatient or worse. I have yet to figure out why it is so important to such people to point this out -- they surely cannot think they have made a significantly new discovery?
if you had not failed to look for more than "proof" of your prejudice, you would have found answers to your questions. you ignore them, and I ask you to go away because I still try to discuss the topic of this thread, not whether I'm impatient and arrogant. really, that's common knowledge.
#\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.
In article <3063474382854...@naggum.no> Erik Naggum <e...@naggum.no> writes:
[...]
>... and I ask you >to go away because I still try to discuss the topic of this thread, not >whether I'm impatient and arrogant. really, that's common knowledge.
>#\Erik
Well, now that everyone knows that you are impatient and arrogant, have you ever thought about changing that?
-- den...@netcom.com (Dennis Yelle) "You must do the thing you think you cannot do." -- Eleanor Roosevelt
In article <whraj5x1vq....@tyr.metis.no>, Steinar Bang <s...@metis.no> wrote:
> >>>>> pe...@nmti.com (Peter da Silva): > > The example of proper string handling, on the other hand, is > > something that can be efficiently and easily implemented in C. > However, this is not a part of the standard libraries, and result in a > lot of reinvented wheels (to every man (*and* woman...) his own > support library, with strings and containers!).
That is a real problem. It's not, however, a shortcoming in the language.
In article <3063475763718...@naggum.no>, Erik Naggum <e...@naggum.no> writes:
> * Bernd Paysan >| But as C and Unix were hacker projects around '70 and got public (in the >| broader sense) at around '80, a step back by 10 years should be expected, >| anyway. Basic was a Hacker project in the 60th, and DOS was crap >| only. And that's what many people use now, although it's cluttered with >| Windows, the worst GUI incarnation (from the CS point of view) the world >| has seen yet.
> a while ago, somebody posted a summary of programming cultures, noting that > Microsoft is basically growing a whole new culture from scratch, rejecting > all other cultures and what they have built. considering that it has taken > 50+ years of research and very serious thinking by many more good people > than Microsoft could ever hire,
I think you are seriously underestimating Microsoft's profits. Bill is spending BIG bucks hiring as many big named researchers as he can.
In article <5cihvb$...@hnssysb.hns.com>, sthu...@hns.com (Steven Huang) wrote: > I agree. On a given system, if Lisp is already available at no further > cost in time or space to the user, the inherent advantage should not be > factored out. However, if Lisp on your system must be loaded (like > archaic MS-DOS BASIC interpreters, for instance), factoring out the load > time is unfair.
Huh? Sure you can measure startup time for some runtime system and compare it. But this has nothing to do with benchmarking what a C or Lisp compiler generates of some source code. I wonder how people are doing their benchmarks? If I want to know how efficient a compiler handles recursion and integer arithmetic, what has that to do with startup times of whatever???
> >but let's see what difference the runtime system _does_ make. ACL has a > >nice foreign function interface that should even out the costs: > [...]
> Since you bothered enough to do it anyway, why bother with the two > previous paragraphs? I'm not following very closely, but I think > DJ Bernstein provided C solutions that has undergone some algorithmic > optimizations. Have you examined those?
Again, the question is not whether you can find better solutions for computing these results - the question was how fast some comparable source code for C and Common Lisp is. That is all. If he tries to use loops or arrays implementing it differently - that is fine. But what do you expect - the same recodings in Common Lisp will also run faster. That is no big deal.
The real question is, why are people still (maybe forced) using C for high-level programming, even where it is not adequate. Have the C programmers failed to build an environment which can be extended with non-low-level languages and libraries in a seamless way? Doing unsafe arithmetic in real world software is just one of those jokes. Everything that is not C-like and is not modelled the C-way is currently harder then necessary. What is the result? People are forced to use low-level languages like C with poor abstraction capabilities, which are really portable assemblers. Additionally users are really beta testers.
> An accurate benchmark must first simulate the usual working environment, > and the usual working environment for C is that the program is already > compiled to an executable, sitting perhaps on disk. I am not familiar > with the usual Lisp environment, so that part is up to you.
> <snip>
No!
The majority of people are interested in more than one aspect of a system but it is impractical to develope benchmarks that test all aspects of a system with the same weight of importance that an arbitrary user would give them. As a result no one benchmark is sufficient, but that does not mean that it is inaccurate. An accurate benchmark must carefully document what it is benchmarking, and maintains consistency in its application from one system (environment) to another. The user can then attempt to give the benchmark its appropriate weight. This can be difficult, however, if there are no other benchmarks available that test other aspects of the system.
For programming language development systems there are a number of aspects of interest and the aspects of interest will vary from user to user, sometimes from language to language, and environment to environment. For developers the compile, link, debug cycle time can be of greater interest than the final code performance. For isolated end users, the final code performance can be more important. As a result it is not uncommon for developers to rely on two or more environments, one well suited for most stages of development and another that is better at optimizing code. For small applications the load time might be important, for large ones the run time dominates. In addition less quantifieable aspects of the system, robustness, documentation, support, flexibility, are also of great interest.
Unfortunately most language benchmarks give only execution time, and for interlanguage comparisoons it is often not clear whether the compared code should be as close as possible or reflect typical language idioms.
> Unless your Lisp code is usually already in memory, "load" is not without > cost, and any fair benchmarking must include that cost, however minute > its contributions. <snip>
This comment make implicit assumptions about the use of Lisp (i.e., because it is not C, it must not be used like C) that you should be aware of. Your whole message is not truly complaining about an inaccuracy, but about incompleteness, but the additional information that you desire is not made fully explicit. For example your questions are posed in terms of how Eric uses his environment, not in terms of how you would use the environment.
Note I have deleted comp.arch from my posing and followups.
--
William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclod...@lanl.gov
In article <1997Jan2506.19.04.16...@koobera.math.uic.edu> d...@koobera.math.uic.edu "D. J. Bernstein" writes:
> David H. Thornley <thorn...@cs.umn.edu> wrote: > > this works as a statement, not as an embedded expression, > [ ... ] > > the macro can evaluate u twice,
> Apparently you're unaware that C programmers use lowercase for macros > that simulate functions, uppercase for macros that don't.
This is not only irrelevant, as conventions don't stop a macro from evaluation an argument more than once, but it isn't even a universal convention. Not everyone uses upper case for function names.
A side effect is is a side effect, and quite possibly a bug, too. -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Martin Rodgers | Developer and Information Broker | London, UK Please remove the "nospam" if you want to email me. "Blow out the candles, HAL."
In article <8gafpx6ogz....@roke.cse.psu.edu> schwa...@roke.cse.psu.edu.NO-SPAM "Scott Schwartz" writes:
> Erik Naggum <e...@naggum.no> writes: > | you're being stupid on purpose. you don't include compilation, assembling, > | and linking time in C programs, so why do you do it for Lisp? go away.
> That's uncalled for. My point is valid: you want to treat lisp like a > shell, but then ignore the cost of doing so when the overhead is in > question. In contrast, the time you gave for the a.out version > includes the cost of dynamically loading all the shared libraries.
While I agree that Erik's "go away" is uncalled for, I think that you're ignoring the value of using Lisp as a shell. Could this be because you can't do this in C? I don't know. Most C implementations can't do it, while most Lisps can. Go figure. -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough Martin Rodgers | Developer and Information Broker | London, UK Please remove the "nospam" if you want to email me. "Blow out the candles, HAL."
* Bernd Paysan | But as C and Unix were hacker projects around '70 and got public (in the | broader sense) at around '80, a step back by 10 years should be expected, | anyway. Basic was a Hacker project in the 60th, and DOS was crap | only. And that's what many people use now, although it's cluttered with | Windows, the worst GUI incarnation (from the CS point of view) the world | has seen yet.
a while ago, somebody posted a summary of programming cultures, noting that Microsoft is basically growing a whole new culture from scratch, rejecting all other cultures and what they have built. considering that it has taken 50+ years of research and very serious thinking by many more good people than Microsoft could ever hire, we should _expect_ that programmers under constant pressure to release products are no match for researchers. it's just like C and DOS and those other products they build: they effectively fail to recognize that cultures can be built "vertically", and instead build them "horizontally".
#\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.
> Chris Bitmead <Chris.Bitm...@Alcatel.com.au> wrote:
> : Actually, the really correct way to do it, is to specify precicely > : what range to support. Like int:-2000,75000 or some such to specify > : exactly what range you will use. Then if there is some hypothetical > : machine with 20bit words, you don't have to upgrade to 32 bits when > : porting just for safety's sake. Oh, and a nice implementation would > : have a checking mode to tell you when you've exceeded your > : self-imposed limit. Better than having a limited exception facility > : where the only boundaries you can impose are 16, 32 and 64 bits.
> I think that sounds rather like the (experimental) language "NewSpeak" > that was being developed at, I think, RSRE (a UK defence establisment) > for "verified" applications.
I think that PLANC had this, and also a similar mechanism to specify the precision of reals. PLANC (Programming Language for Nord Computers) was the "systems" programming language used on minis from Norsk Data (remember them?) Wonderfully quirky --- both the language and the machines it ran on.
BTW: doesn't "NewSpeak" carry some fairly unpleasant associations, though?
* Mike McDonald | I think you are seriously underestimating Microsoft's profits. Bill is | spending BIG bucks hiring as many big named researchers as he can.
I know. what are the results?
#\Erik -- 1,3,7-trimethylxanthine -- a basic ingredient in quality software.
