World's "Fastest" Small Web Server Released, Based On LISP 502
Cougem writes "John Fremlin has released what he believes to be the worlds fastest webserver for small dynamic content, teepeedee2. It is written entirely in LISP, the world's second oldest high-level programming language. He gave a talk at the Tokyo Linux Users Group last year, with benchmarks, which he says demonstrate that 'functional programming languages can beat C.' Imagine a small alternative to Ruby on rails, supporting the development of any web application, but much faster."
"functional programming languages can beat C" (Score:5, Funny)
In speed and elegance, perhaps. But not on the überprogrammer salary to maintain it.
Re: (Score:3, Interesting)
Dunno about you, buddy, but I find LISP a lot easier to read and write than all the C-like languages (although pure C itself is OK when it sticks to what it's good at - being a set of macros for assembler when programming systems-level stuff).
Re:"functional programming languages can beat C" (Score:5, Insightful)
First, his blog is standing up to a slashdotting. That's impressive.
Dunno about you, buddy, but I find LISP a lot easier to read and write
Right, but we're not talking about you. I wish we were. If your skills were more common we'd have a better world.
Second, I can speak up and I'm not even posting as an ac. It's straightforward to find people who can "program" in a language of their choice. It's tougher to find people who can program well in a language of their choice. It's tougher yet to find people who can program well in a language of your choice. It's very tough to find someone who can code well in C and insanely tough to find someone who can code well in LISP.
It's been my observation -- as someone who has managed to convince many others that he deserves the salary of an "uberprogrammer" -- as I've shifted into running large engineering teams, that perhaps one in twenty programmers can code acceptably in C and perhaps one in two hundred in LISP.
Third, I'd note there are behaviours of his software that surprised and annoyed some readers -- e.g. column treatment. I'd argue that these are generally buried deeper in LISP code than in C, but that's something we could heartily debate.
Finally, his code seems typical of what I've seen from good LISP programmers -- including even at times myself. Poor documentation. The code is simple, elegant, and should "speak for itself". Well it doesn't. Not to someone trying to maintain it.
C programmers -- perhaps because of the nature of the language -- seem less prone to this particular trap, though still bad.
Regards,
-Holmwood
Re:"functional programming languages can beat C" (Score:4, Interesting)
Not unless you're used to desparately overburdened shared hosting. My six dollar a month account from HostMonster has handled multiple simultaneous slashdottings with concommitant reddit and digg traffic several times. One of my customers sustained roughly seven megabits of traffic for several days straight inside a VM with no problems.
Slashdot traffic taking a site down means the site isn't hosted at a reputable host, these days.
As much as Lisp people want to say that Lisp lost because of the price of Lisp machines and Lisp compilers, it actually lost because it isn't a particularly practical language; that's why it hasn't had a resurgance while all these people move to haskell, erlang, clojure, et cetera.
Lisp is a beautiful language. So is Smalltalk. Neither one of them were ever ready to compete with practical languages.
Er, no, it isn't. You just have to know where to look, and to not get stuck in the Silicon Valley highschool mindset, where nerf guns are believed to adequately substitute for health care, and where nobody can name a formal method.
C programmers are the most numerous professional programmers on Earth today, and we're in the highest unemployment for programmers since the dot com bust, with a number of well meaning companies blindly ditching C for whatever the new hotness is (and eventually going right back). Hell, I get C/C++ programmers for things that aren't looking for C work, because they (rightfully) believe they can pick up the other language as they go and do a better job than the natives due to their understanding of actual costs.
If you can't find someone who writes good C, either there's something wrong with how you're attracting staff, or you're not judging them skillfully, or they have some reason to stay away. I'm putting my chip on #3.
Re: (Score:3, Informative)
I dunno. This is what I saw when I tried to read it:
"Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.2.4 (Ubuntu) mod_fastcgi/2.4.2 PHP/5.2.3-1ubuntu6.5 Server at john.freml.in Port 80"
Re:"functional programming languages can beat C" (Score:5, Insightful)
The popularity of Python is essentially about having a LISP that has a more familiar syntax and interfaces well with C programs. Python isn't LISP but it's not very far off.
It is very far off. I'm not sure what criteria you're using to determine what's "not very far off", but if it's first-class functions, then most modern mainstream languages (with notable exceptions of C++ and Java) aren't "far off" from Lisp. But I would say that it's a wrong definition.
What really sets Lisp apart is how the program itself is defined in terms of structures that are fundamental to the language, and how those structures can be easily manipulated in the language itself. Simply put, Lisp - especially Common Lisp (though R6RS is neat, too) - is a pinnacle of metaprogramming so far, and that's what is its defining feature. And Python doesn't come anywhere close to that.
It's also what makes Lisp so hard to work. Yes, you can use macros to enable extremely high level of code reuse, effectively 100% (if theres any kind of pattern in your code, you can write a macro to encapsulate that). But it also means that you're effectively defining your own DSL, and then writing your program in that - and when someone else needs to understand and maintain your code, they'll have to figure out that DSL first.
This isn't really fundamentally different from plain function/class libraries (they are also DSLs), but the expressivity of macros is so much higher than plain function calls (even with Smalltalk/Ruby style blocks and other such facilities) - and, consequently, so is their complexity. Idiomatic Lisp is invariably harder to understand than idiomatic C++, much less Python or Java.
Re:"functional programming languages can beat C" (Score:4, Interesting)
First-class functions, lambda, map and friends, generator expressions, and so on. My criterion is what it feels like to write, and in that sense Python is very close. (I'd go so far as to say it's better, but that's going to be contentious).
What really sets Lisp apart is how the program itself is defined in terms of structures that are fundamental to the language, and how those structures can be easily manipulated in the language itself. Simply put, Lisp - especially Common Lisp (though R6RS is neat, too) - is a pinnacle of metaprogramming so far, and that's what is its defining feature.
Lisp fans always claim this, but I think it's a red herring. TCL takes the same principle even further, and it's nowhere near as popular or admired. Metaprogramming isn't what makes lisp good to program in, it's all in the first-class functions and functional programming flow control tools.
Re: (Score:3, Interesting)
First-class functions, lambda, map and friends, generator expressions, and so on.
By those, virtually any functional language is Lispish - SML/OCaml/F#, Haskell, whatever.
Also, C# 3.0+ would be Lispish (it has everything that you've listed), as well as Scala.
Lisp fans always claim this, but I think it's a red herring. TCL takes the same principle even further, and it's nowhere near as popular or admired.
What does it have to do with being "popular" or "admired"? It is, in general, pretty widely acknowledged in the PL community that Tcl is indeed one of the languages close to the spirit of Lisp, though not its syntax.
Re:"functional programming languages can beat C" (Score:4, Interesting)
That you believe several books over the course of six years constitutes a resurgence, especially given the historic nature of the language, kind of goes a pretty long way towards proving my point about its nearly non-extant market share.
Don't get me wrong, I think LISP is a wonderful language. But, let's not do ourselves the disservice, please, of pretending that it's been a major player since the 1960s. If you look at the list of supposedly dead languages that majorly outpace LISP in real world usage measured either as new code or maintained code (eg Delphi, Clipper, Fortran, Cobol, PL/I, Ada, Forth, ANSI Pascal, Object Pascal, ColdFusion, pre-.NET ASP, all on both metrics) you get a clearer idea of where things actually stand.
If LISP is so amazing, and if LISP has first mover advantage over anything the average programmer has ever heard of, why is it so resoundingly a bit player?
There are downsides to LISP. Lots of them. Serious ones. It hasn't stayed this dead for 60 years because it's the tragic forgotten child of programming; every freshman who wants to sound educated thumps it at their first opportunity, frequently without ever having written a line (which is not to call you a freshman, just to point out how not-unknown it is.)
It's a little like SICP. If it's been that free, that well known and that easily accessable for 20 years, how come it's being discarded by the university that published it for curriculum, and how come its design principles are largely unseen even in the work of people who have read it?
There's a lot to be said for academic languages and academic exercises; they open our eyes to many new approaches to problems.
But don't kid yourself. They died for a reason. Why is it that all the supposedly awful languages and design strategies are dominant?
It's because they work. For all their warts, for all their maintenance problems, for all the infrastructure you have to write, they work.
New practical languages are occurring which adopt many of the lessons of LISP. Ruby got a lot of LISP's problems removed, though it's still got a lot of problems of its own; Haskell can say the same. Erlang's got most of those problems cleared up, and is a practical real world language for a lot of things.
But dude, if the most impressive thing you can find is the application of graph search to a complex web form with credit card processing that the typical college sophomore could throw together in about a month, I mean, I'm really not sure what to tell you. Orbitz is ridiculously slow for the amount of data it processes, its user interface is awful, it copes poorly with unexpected things like uncommon use of the browser back button, and I usually have to go to it first so that I can check everywhere else and then by the time I'm done everywhere else maybe Orbitz has finally finished its first search.
What Orbitz does that's impressive is their ability to negotiate ticket prices. I go there because they get the bottom dollar bid. If that's your idea of something you can hold up to show the success of LISP, I've got to ask you: why have you gotten down to rare occasional me-too projects as your shining beacon?
Yahoo! Stores was lisp too. (Note the past tense.)
Big whoop.
When it gets down to it, you should actually try writing something like that some time in LISP. Then try writing it in another language. It's not really all that different. It'll be maybe the dollar sign instead of the parentheses whose ink wears off on your keyboard, and the whatever other language you write will probably be somewhat bulkier (though if you're working in a language like Erlang, Haskell, Mozart-Oz or Forth, it'll be substantially shorter).
Meh. Ten extra letters to get a three line algorithm done. Trade that for real exceptions and a strong type system, and you've chosen C++. Trade that for the pi calculus (which is hella more expressive than the lambda, and typically completely foreign to the LISPers who preach syntax superiori
Re: (Score:3, Informative)
That's very true, but only one component of their back-end is actually written in LISP - the lowest-fare search engine.
Also, Orbitz did not write that component, called QPX - it was actually written by a company called ITA Software, who licenses it to dozens of other air-fare cross-shopping services.
Despite the other issues with Orbitz, QPX is an excellent example of what can be acc
Re: (Score:3, Interesting)
Most likely because it's much easier to verbalise what a small segment of C is doing compared to a small segment of LISP. When writing C, I us
Re: (Score:3, Insightful)
Or perhaps we are part of the other 95% of the world that aren't American ?
Re:"functional programming languages can beat C" (Score:5, Interesting)
No, definitely not in speed.
He wrote a LISP-based memory-only webserver that could respond to requests roughly 10% faster than lighttpd with php. I promise you, if I wrote a C implementation that performed only the functionality he implemented, it would blow it out of the water. In fact, before anyone else comes out with the "X is faster than C!" claim, I'll leave the challenge out there:
I will prove that anything written in a higher-level language will not be as fast as my implementation of it in C. I leave this challenge out to anyone to take. (*)
Seriously, I'm sick of this crap. Bring it on.
(*) Caveat: It must be a small challenge involving a relatively simple task. I don't have a lot of time to waste on this.
Re:"functional programming languages can beat C" (Score:5, Informative)
He's also right (Score:5, Insightful)
Reason being is that C is the closest high level language to how a processor actually operates. A lot of people get confused, or perhaps never really know how a CPU actually works and that no matter what language you code in, it all gets translated in to machine language in the end.
Now what that means is that there are certain things that, while convenient for humans, have nothing to do with how the processor actually thinks. A good example would be newer replacements for pointers. A lot of people hate pointers, they claim, correctly, that pointers are confusing, and that you can easily cause problems with them. That is all true, however it is also how the CPU actually thinks. The CPU doesn't have advanced concepts of references and of garbage collection and so on. The CPU has data in memory, and pointers to the location of that data. It doesn't even have data types. The data is just binary data. You can store a string, and then run calculations on it using the FPU. Granted you'll get garbage as a result, but there's nothing stopping you from doing it, the CPU has no idea what your data is.
So, the upshot of this is that C is very close to the bare metal of how the system works. Thus if you are good with it, you can produce extremely efficient code. The higher level stuff may be nice, but it all slows things down. When you have a managed language that takes care of all the nasty stuff for you, well it is spending CPU cycles doing that. Now the tradeoff is quite often worth it, since CPUs have loads of power and maintainability of code is important, but don't trick yourself in to thinking it is more efficient.
You have to remember that no matter what, there is one and only one way that the machine actually thinks, one way it actually processes information. All the nifty high level programming shit is just to make life easier for the programmers. That's wonderful, but it doesn't give you the most optimized code. Of the high level languages, C retains that crown, and likely always will, because it is the closest to how a CPU actually works. I've seen the joke that "C is a language with all the speed of assembly and all the ease of use of assembly!" There's some truth to that.
So I have to agree with the grandparent. If the LISP heads think LISP is faster than C, they are kidding themselves. I'm not saying a good LISP program can't be faster than a bad C program, but if you have equal skill in optimization, sorry C will win out because in the end it will generate more efficient machine code and that's all that matters. All the theory of different programming paradigms in the world isn't relevant to how the CPU is actually going to do things.
Mod parent up. Good comment. (Score:3, Insightful)
C was meant to be equivalent to a high-level assembly language. Someone told me that he was worried about coding in assembly language for a particular part of a video driver, but he discovered that, in that case, his C compiler wrote perfect assembly language.
Re: (Score:3, Insightful)
C was meant to be equivalent to a high-level assembly language.
No, it was a general-purpose high-level language. It's just that our definition of "high-level" has changed over the past 40 years. Now we have Python and Ruby.
Re:He's also right (Score:4, Informative)
C is not how a modern processor thinks, with super-scalar instruction issue, cache and pre-fetch memory controls, and speculative branch prediction. In the end, even the C community splits into camps that let the optimizer do everything, versus embed some hand-written assembly or equivalent "machine intrinsics" routines in the middle of their normal C code. In both cases, non-trivial amounts of profiling and reverse-engineering are often needed to coax an appropriate machine code stream into existence, and this machine code is decidedly not how the developers usually think.
The choice of language is not so significant really. You can find Lisp dialects that efficiently use native machine types and have little runtime cost due to having weak type systems (just like C) where casting is easy and the responsibility for crazy results lives with the programmer and the limited ability of the compiler to check some static cases. These dialects will run imperative code quite well, e.g. if you transliterated typical C procedures into equivalent Lisp procedures, you'd get similar performance. Ironically, these systems aren't as fast when you write very high-level or functional Lisp, because those sorts of programs rely on a more elaborate optimization and runtime support layer, e.g. to optimize away recursive function call overheads or frequent allocation and destruction of temporary data like lists. This kind of code also doesn't work well in C, so the programmer has to perform these optimizations at the source level, by writing loops instead of recursion and making use of stack variables and static data structures instead of making many malloc/free calls in inner-loops, etc.
The main difference is the presumed runtime system for the language, the compilation goals, and the core language libraries. This includes things like whether you have garbage collection or explicit memory management, how you compile (whole program versus treating every function/procedure as an ABI symbol), high-level IO abstractions or low-level register (or memory-mapped) IO and interrupt events, etc.
If you're interested in this stuff, you might learn something from reading about PreScheme, which was a lisp dialect designed to allow the runtime system for a full Scheme (lisp dialect) to be written in a more limited Scheme-like language. This is much like the core bits of an OS kernel like Linux are written in carefully controlled subsets of C that do not presume the existence of an underlying runtime environment nor the standard C library.
In reality, many of the compiler and runtime techniques applied to a simple language like lisp could be applied to a C implementation as well. It's really a cultural rather than technical issue which prevents there being C environments that skip the traditional, naive compile and link strategy used in POSIX and UNIX ABIs.
That's a myth. (Score:4, Interesting)
Once you get things like branch prediction, speculative execution and pipelining into the picture, no, C isn't really any closer to how the processors operate. Making efficient use of a modern CPU involves detail at a much, much lower level than C exposes.
The performance killer for high-level languages isn't really the abstraction away from the machine instruction set; it's garbage collection. And even then, it's mostly because GC tends not to play well with memory caches and virtual memory; a simple stop-and-copy garbage collector is actually algorithmically more efficient than malloc/free, but absolutely atrocious with caches and VM.
Re:That's a myth. (Score:5, Insightful)
Once you get things like branch prediction, speculative execution and pipelining into the picture, no, C isn't really any closer to how the processors operate. Making efficient use of a modern CPU involves detail at a much, much lower level than C exposes.
The problem at that level is that you'll be seriously bound to a specific architecture. Even C, which is often called a portable assembler, is designed after a certain kind of assembler.
The somewhat surprising result is that you can also improve performance (compared to plain C) with a higher level language. You need a higher-level perspective to tackle things like vector/parallel processing efficiently.
Re:That's a myth. (Score:5, Insightful)
It's about using the right tool for the job.
Some years, I do heavy computational programming. No so much number crunching, as bashing them into submission.
I can do this *much* faster in a modern Fortran (90 or later) than in C. Not because C can't do the same things, and not because an optimized C can't get to the same results.
The difference is that I can sit down and simply enter near algorithms of matrix math into Fortran, and the optimizer will go to town and give me near perfect code, which will be faster than what I would get with C (which would also take significantly longer to code). A skilled C coder could do a better job, and ultimately get roughly the same performance as I got from Fortran.
This isn't because "Fortran is better than C," but because Fortran is designed and optimized by people who do this kind of stuff *to* do this kind of stuff. It can make very strong assumptions that C can't (and much of the hand-optimizing of C is essentially replicating these assumptions).
OTHO, writing a modern operating system in Fortran *could* be done, but it would be painful, would take far longer to code, and would probably have atrocious performance.
note: I believe that Pr1mos was largely written in FORTRAN IV.
hawk
Re: (Score:3, Interesting)
> The difference is that I can sit down and simply enter near algorithms of matrix math into Fortran, and the optimizer will go to town and give me near perfect code,
Ahhh: a breath of fresh air. As a programmer this is to me exactly how it should work. Not my language is better than your language but the programmer can get on with describing the solution, and leave the compiler to do the boring work !!
Re:He's also right (Score:5, Informative)
Check out Stalin, SBCL, and http://www.cs.indiana.edu/~jsobel/c455-c511.updated.txt [indiana.edu]. You might be surprised at what you find.
Re: (Score:3, Informative)
Re:He's also right (Score:5, Insightful)
However, there is an addendum I'd like to make here:
Some programming languages force you to think in ways that are actually beneficial to the speed of your code, and can outpace the "normal" C program significantly.
For example, a few months ago I was forced to write something concerning an AI algorithm in Prolog. Now, I was cursing and cursing at it, because the constraint solver built into the prolog compiler was so goddamn restrictive, but that's how constraint solving works. Every time I was thinking to myself: "if I'd have been allowed to build this in C, it would be done yesterday, and probably be faster to boot!"
But when I ended up finishing it and running it, it was blindingly fast, and I queried my professor about it. He told me that another student some time ago was thinking the same thing as me, and actually made a C variant. It ran 4x as slow as the prolog equivalent even after spending quite some time optimizing (interchanging algorithms and even looking at the assembler code, he told me).
Then he told me what was causing this discrepancy, as I had always thought that C was the end all be all of performance. It was the restrictive nature of the prolog solver that caused me to put more brain power into the problem, and as such shift work from the computer to the human. Because those same restrictions allowed lots and lots of optimisations (aliasing comes to mind).
Re:He's also right (Score:5, Interesting)
I'll start with the good things. First of all, I like your style of writing - clear, precise and on point (of your choosing). Second, you explain quite well on the scenery here.
Now, to the bad things. I can almost bet you either are not a day-to-day programmer, as opposed to casually writing simple bits of code in C perhaps, or you just do not know either a lot of computing history or latest developments in compilers and technologies in general. Maybe you write niche software and are not interested in these developments, I do not know, but I think it is a bit odd you give such a good and knowledgeable read, yet completely (in my humble opinion) miss the facts overall.
Machines are different too. There is RISC, there is ZISC, there is VLIW and the CISC/RISC hybrid that modern CPUs mostly are. These days we are also starting to think how we can utilize vector processors, which to gamers are quite familiar as their video cards. Everyone has one, either they know it or not, nowadays they install a 500 mFlops graphics card in PCs in use by hotel receptionists.
So, C was designed to go close to the metal yes, but since metal is different, C may shoot or miss depending on the architecture too.
What is far more important, given that today we still use mostly the same instruction set we used when C was invented, is the fact that you are absolutely mistaken if you think high-level languages will not approach C. You overestimate hand-optimization and underestimate modern compilers. It is illogical to assume that a person IN FRONT of the computer terminal will know and benefit from knowing how a program of his writing may be optimized. It is the computer itself, that, based on sufficiently well developed compiler, has the potential to optimize code. The mere fact that in practice it is not always so, is because the field is immature, but not to worry, rapid developments are made.
Also, things like static typing, static code analysis and other logical solutions absolutely negate any benefit C may have. Also, I am surprised you compare garbage collecting to C, given how programs developed with C still need occasionally, depending on their domain, allocate objects on the heap, and how most virtual machines allocate values on the stack under the hood, even those with garbage collector.
Anyways, to cut short here, and perhaps give you a chance to explain and ridicule me :-), I will just say I find your comparison of C to say LISP is grossly oversimplified, and does not work on me. It is in fact programming paradigms that have liberated compiler writers to write increasingly effective compilers. Spend some time reading on theory of computation on Wikipedia for instance, it has given me a whole new look on the state of the art. Bottomline is, teaching computers how to translate human typed grammar more efficiently into their program execution machine is getting much cheaper and much more fruitful than spending time or energy hand-writing C code, and I am not talking about the "compromise of man hours", I am saying both LISP and C programs being equally 'good', they can be equally fast, especially depending on the LISP compiler.
Thank you for your attention, I know how precious it is here on Internetlands.
Re: (Score:3, Insightful)
Oh, it is NOT because they TRY to mimic C, I assure you.
C is closest to the metal, after assembly language. General purpose computing on proprietary vector processors is something new. Naturally, just as with earliest computers, people are careful and the first compiler to pop up is the very straight-forward C-like, which is a natural first (and simplest) choice. C was designed to be close to metal, but this also made for a very simple compilers. C is very efficient in that sense - for RASP (Random Access S
Re:He's also right (Score:4, Interesting)
So I have to agree with the grandparent. If the LISP heads think LISP is faster than C, they are kidding themselves. I'm not saying a good LISP program can't be faster than a bad C program, but if you have equal skill in optimization, sorry C will win out because in the end it will generate more efficient machine code and that's all that matters. All the theory of different programming paradigms in the world isn't relevant to how the CPU is actually going to do things.
It's true that any given piece of code can be written to perform faster (or at least not any slower) in C then in Lisp, Java, C#, or whatever your favorite high-level programming language is.
However, this doesn't mean that applications written in idiomatic, well-written C are necessarily faster than some-other-language. Why? Well, here's a very simple example.
Let's say you need to sort some stuff in an array. In C, you can hand-code a quicksort or a merge sort inline that will blow anything else out of the water... if you're only doing it once. But you're probably not. So you refactor it to a function to reduce code duplication. Good, but now you need to sort different types, and with different comparison logic - so you add a function pointer for a comparison function. In other words, you get the stock qsort:
And at that point you're already slower than C++'s std::sort, because:
1) qsort takes a function pointer and do indirect calls through that, while std::sort will take a function object and inline all calls (in theory a C compiler can inline calls via function pointer as well, but I've yet to see one that does that).
2) The qsort comparer argument always takes its arguments by reference, even when it's some type that's more efficiently passed by value and in a register (e.g. int). std::sort function object doesn't have this limitation - it can take arguments either by value or by reference.
The real problem here is the lack of genericity. If you hand-code the sort for every specific case (type + comparison function), you'll be better off in C, but then you'll get tons of duplicate code, which is bad for maintainability. And C doesn't offer any decent ways for compile-time code generification (only macros, but they are so limited and generally meh), so most people just use the more-generic-but-slower solution and don't bother. And - end up slower than C++.
It should also be noted that the above C vs C++ comparison isn't limited to C++. For example, a direct std::sort analog can be written in C#, fully generic, and all arguments will apply to it as well (JIT will inline the comparer call, and so on).
Re:He's also right (Score:4, Interesting)
C also lacks several important features for optimization, such as static typing,
Surely you jest. C has weak static typing, but it's static typing all the same, and any " + " you see in C code becomes a specific instruction once compiled. Just because that + could be for pointers, doubles or ints doesn't mean it's not static once read in context.
The weakness comes from standard C accepting almost any implicit conversion and cast, which is trivially changed to somewhat strong (but not runtime-enforced) typing by using compiler warnings and errors.
or general reasoning about memory and parallelism.
Parallelism remains fastest in C, especially in OS kernels where the cost of synchronization primitives is close to a bare minimum. If you have a modern compiler that can distinguish vectorisation from its own ass, you'll get healthy use of parallel code pipelines too.
The CPU executes instructions, oftentimes in parallel pipelines, using an instruction cache and branch prediction - none of which are modelled in the C language.
None of which has to be. If you need that kind of performance, you have two options, both with free software:
a) Embed simple non-standard statements to communicate your branch prediction beliefs
b) Use profile-guided optimisation to automatically sample real branching statistics, and recompile based on those
Either way you end up with superior branch prediction performance. Certainly far far superior to what you'd get with LISP or Python.
If you knew even half as about language implementations as you claim to, you'd know that the C language holds it's speed crown simply because it has attracted an _enormous_ amount of research into optimizing compilers, largely because the way C works _isn't_ the way the CPU works.
Ok, so what non-assembly language do you propose that does work the way a CPU works? C is the closest we have, and with modern compilers it's way faster than any other usable language. The effort of writing C is far lower than that of writing assembly, and you generally get better performance unless you know specific SIMD/MIMD instructions to replace a loop or two.
Re:"functional programming languages can beat C" (Score:4, Insightful)
Modded Troll? Come on guys, its a legitimate challenge - I'd really love to have someone take me up on it. If anyone out there thinks they can honestly write faster code in some higher level language than I can in C, I want to put it to the test. It'll be fun, and I'll happily admit defeat if it can be thus proven. (And I'll take up the competing programming language.)
Re: (Score:2)
Re: (Score:3, Insightful)
Re:"functional programming languages can beat C" (Score:5, Interesting)
Actually, you can be faster than C in many cases. C must generate suboptimal code in certain cases because it cannot protect against edge cases like pointer aliasing.
I've seen a LISP compiler generate better loop code in some cases, simply because it can prove arrays are non-overlapping, or that X*X is provably positive.
Re: (Score:3, Informative)
How many C programmers use "restrict" everywhere that it could be used? Zero point zero.
Or how many use it anywhere at all for that matter? Probably like zero point one percent of programmers.
Re: (Score:3, Interesting)
These certainly help, but are often hard-to-use in large programs: a low-level routine may declare it has restricted pointers, but it has no way to enforce that callers follow the rule. So, in big multi-developer systems, you tend to wind up with restricted pointer code kept in internal library functions, not exported functions, and the vast bulk of the app compiled defensively with full aliasing protection. Either that, or the app fails every other Wednesday for some strange reason.
Re: (Score:3, Insightful)
I think you are right that C can take on any higher level programming language in speed. The same could be said with assembly.
The reason of course we don't write everything in low level programming languages is just the cost of maintaining them (LOC, readability, compatability...). I like what John has done in showing what assumptions should be made in a higher level programming language in order not to compromise a whole lot of speed.
Re: (Score:2)
Re:"functional programming languages can beat C" (Score:5, Insightful)
Yes, and your caveat is actually the most important element: for projects that need well definable high-level abstractions, or able to operate on mathematically infinite structures, a functional language wins clearly in comparison with C.
The real question is: allow high profiled lambda abstractions, while keeping space and time complexity as low as an optimized C program.
Well, just to show you that your challenge is easily met... In Lisp, it is easy to write an assembler, which over time allow the same kind of imperative abstractions as are present in C, thus allowing me to write a program with equal speed as in C.
Also, when the nature of the input of a high-level programming language changes, it could optimize its data-structures and algorithms to create a better match with that input. Of course, such a thing could also be implemented in C or Pascal, but requires tremediously more effort.
Re: (Score:2)
Nowhere in my statement did I say that C is therefor the correct language in which to write everything. As projects grow in size and complexity, maintainability is more important than raw speed.
However, in context to the article, the example was "here is something that everyone does in C, but I did it in LISP and it was faster!" And that is my challenge: one, relatively small app written in any higher language will be faster when written in C. There are no restrictions to the challenge based on maintain
Re:"functional programming languages can beat C" (Score:5, Insightful)
The debian language shootout has a few examples of Functional languages being faster than people's best efforts in C, especially when it comes to parallelisation. I suggest you try and write a regex-dna example that's faster than the Haskell implementation for example.
Having said that, the point really isn't that it's faster, it's that it's *as fast* - people should be shedding the ideas that functional languages are slow, and unusable, and trying them out in industry, because now the only real risk is that you have dumb coders (entirely possible).
Re: (Score:3, Informative)
The debian language shootout has a few examples of Functional languages being faster than people's best efforts in C, especially when it comes to parallelisation. I suggest you try and write a regex-dna example that's faster than the Haskell implementation for example.
First of all, you should be careful about using results from the Language Shootout in general, because they often don't know what they're measuring. For example, for quite a while, Haskell scored much higher on the benchmark because the tests were written in such a way that results were computed but then never used; and Haskell compiler is surprisingly good at figuring that out, so it discarded the whole computation part as well. In other words, Haskell tests didn't actually do the same work that C tests di
Re: (Score:3, Interesting)
That's called "lazy evaluation", and it is a language feature. It's the C program's fault for unnecessarily computing values it is never going to use, instead of computing them when demanded.
I know what's it called (in case you missed it, I called it that way in my original post), and I know it's a feature. But if you're measuring sort performance between two different languages, you have to make sure that either one actually, you know, performs the sort. It's good that Haskell compiler is smart enough to figure out the result wasn't used in the test, but it doesn't help you any to determine what the performance will be IRL when you actually do use the sort result.
Re: (Score:3, Insightful)
I find your whole comment rather odd. You're essentially saying "it's not fair, the Haskell compiler optimises code better than the C compiler does". The Haskell compiler has recognised that the task it's being asked to do does not require everything to be evaluated, and hence is optimising that code away.
The bottom line is if you're asked "produce this output", and you do so then it's entirely valid. The fact that Haskell is amenable to massive optimisation like that is something the shootout should be demonstrating.
*sigh*
I'm not saying the test is "unfair". I'm merely saying that it is incorrect.
If the point of the test is to determine actual performance of e.g. sorting algorithm, then the test should at least make sure that the output of sorting is used (e.g. displayed)! It doesn't matter how the compiler does the sorting - let it optimize it the best way it can - but it should be forced to produce the complete sorted sequence either way. Otherwise you aren't really measuring sorting... you're measuring how well the
Re: (Score:2)
You can do the same in C, so the only conclusion from your argument is that neither is faster. Which makes the whole challenge useless if we go down that road.
Again this doesn't say anything about the intrinsic performan
Re: (Score:2)
This is not a troll, and should not be modded as such. The poster has an accessible (spam-protected) email address that I assume is valid. S/He's been posting a long time on slashdot, and his/her assertion is credible and interesting, albeit provocative.
Moreover, I'm inclined to agree with my own caveat: while one can write C that is more rapid than LISP, one can also more rapidly write LISP than C (for a given problem).
I also note my earlier statement, that it's easier (though still quite hard) to find a t
Re: (Score:2)
Re: (Score:2)
Probably true, but not necessarily interesting. You can take a high-level language, compile it to LLVM IR, and then use the C backend for LLVM, and get a C program which will be exactly as fast as the high-level language program. This effectively proves that the C program can always be at least as fast as the original program. The difference comes when you try to maintain it. Programs, over time, gradually accumulate changes, often far outside the scope of the original design. In a (good) high-level la
Re:"functional programming languages can beat C" (Score:5, Interesting)
program co
implicit none
double precision mpi
parameter (mpi=3.141592653589793238462d0/1.024d3)
double complex r(10240)
integer i,j
do j=10,110
do i=-5119,5120
r(i+5120)=sqrt(mpi*i*j)
end do
write(j) r
end do
end
Re: (Score:3, Insightful)
Every language has its own niche and ideal use.
I like your simple example that shows the merits of the oldest high-level language in what it was designed to do best.
Re: (Score:3, Informative)
2) Can we agree on a platform? If I get to name it, its going to be the Xerox 1109, and you're toast.
3) The computer language shootout [debian.org] has some numbers that don't look so good for C. Maybe you'd care to re-implement the thread-ring test? Cause right now it's taking C 164+ seconds to do it, and 9 on haskell. Same thing on the k-nucleotide test.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
What's more without cache! That is, for every request, the PHP webpage is being recompiled. I hope he doesn't call that a fair comparison, as anyone even remotely interested in high throughput takes ten minutes to install a caching system like xcache or one of five other alternatives. I bet you anything that lighty, fastcgi and xcache would serve 1.5-2 times as many requests per second as his homebrew code.
REPOST - with correction (Score:5, Interesting)
Repost - lt should be replaced by lessthan sign...
Trolling sure sounds easy, but...
Gambit-C Scheme vs. C
I'll make it easy for you. It's the two minute litmus test. Even easier -- I'll give you the pseudo-C code:
Task: compute n! for n >= 1000.
In Scheme (Gambit 4.2.8, using infix):
int factorial(int n) {
if (n lt= 0) {
1;
} else {
n * factorial(n - 1);
}
}
compile with: gsc f.six
and run it:
gsi
Gambit v4.2.8
> (load "f")
"/home/user/f.o1"
>(factorial 1000)
4023...0000
Your challenge? Write a C version in two minutes, tested and compiled. Now, as the final icing, run the C version on smaller numbers, and compare the performance -- did you forget to compile in small integer versions? (try factorial(12) a million times).
I'll wait (another two minutes). Compare the performance against the LISP version. Did you have to write two versions -- one for big integers and one for small integers? That is pretty well the only way to keep a speed advantage... I hope you wrote it that way. Did you remember to put in 32/64 bit conditionals to retain your advantage on a 64 bit platform?
I think your C code now looks like this (it should):
#define FACT_LIMIT 12 -- for 32 bit int type, I don't know what the cutoff is for 64 bit. /* This only gets executed a maximum of FACT_LIMIT times; leave it recursive */ /* May wish to rewrite to an iterative form */
#include bignum.h -- I don't want to bother with quoting assume angle brackets
int fact_integer(int n) {
if (n lt= 0) {
return 1;
} else {
return n * factorial(n - 1);
}
}
bignum factorial(bignum n) {
if (compare_lt(n, FACT_LIMIT)) {
return int_to_bignum(fact_integer(bignum_to_int(n)));
}
return bignum_mult(n, bignum_dec(n));
}
You choose the bignum package to use. Or, for more fun, write it yourself. If you wrote it yourself, you remembered to switch to FFT style multiplication at bigger sizes? Or Karatsuba?
Now, we have only coded to a recursive form, but, since bigints are not first-class in C, we don't know about memory reclamation (leakage). I hope you know the gmp library, or can roll up a gee-whiz allocator on your own. The gmp library would be cheating, by the way -- YOU DID CLAIM YOUR IMPLEMENTATION IN C.
If recursion is viewed as a problem, the Gambit-C version can be recoded as:
int factorial(int n) {
int i;
int a;
if (n lt= 0) {
1;
} else {
a = 1;
for (i = 1; i lt= n; ++i) {
a *= i;
}
a;
}
}
I am sure that something equivalent can be done in the C version. But the normal flow of control stuff doesn't know about bignums. We COULD make the incoming parameter an int, I guess... which works for factorial() but may not be as workable for other functions.
Answers:
- gmp does better than Gambit-C on bigint multiply, using FFTs.
- breaking the result into two separate functions is needed for C to come ahead.
- yes, C is faster, at the expense of a lot more programming.
- if I want to, I can simply drop C code into my Gambit-C program on an as-needed basis. The Gambit-C code still looks a
whole lot cleaner than the C version, and ties it for small integer performance. The bigint performance is still a "win" for
gmp, but I can use THAT package directly as well in Gambit-C.
Win:
- Gambit-C. The prototype was finished to spec in two minutes. Optim
A Faster LISP version (Score:3, Insightful)
And now for the grand unveil - the SCHEME (LISP) version, with integrated C code for the "super-speedy" inner loop. Just to illustrate that the SAME optimizations are available for the LISP programmer. This can be further micro-optimized.
Note that it isn't much different from a "C" implementation that has the same optimization. Note the ease of moving between data types (we only worry about in a very cursory way). I am waiting for your pure C implementation.
# In "normal" scheme syntax. Note escape to six sy
Horse to water... (Score:3, Insightful)
We now come to the final post in this series.
The speed in C comes from the direct hardware "low-level" thing. In the domain of "int" types on a 32 bit machine, I would say that the most efficient (well, one of the most efficient) implementations of factorial() would be:
#define factorial(n) ((n) 0 ? 1 : fact_table[n])
int fact_table[] = { 1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880, 39916800, 479001600 };
Can you hear the l33t-speak? I codez the C r3al g00d! My factorial function only takes a nanosecond or
Re: (Score:3, Insightful)
Aw shucks, you caught me out! You AC guys...
Sure, since Gambit-C uses C as its "assembler" level, it is possible to micro-optimize. In Post #2, I illustrate how to deal with that. In Post #3 you see how I deal with the "low-level advantage" issue.
And, in response to you: I challenge that YOU cannot beat Gambit-C, even given six months implementing this stupid little useless program. Without resorting to pre-written code, that is, in which case *I* get to use the same libraries.
To WIN, you have to show a 5%
Re: (Score:3, Insightful)
"What C programmers and programmers fail to realize it that there is something called time to Market, something called budget."
Perhaps, but this thread doesn't support the idea that C programmers "fail to realize" other issues. This is a discussion about speed, not time to market, cost, or maintainability.
oblig (Score:5, Funny)
In speed and elegance, perhaps.
So you agree to the fact that emacs is faster and more elegant than vi, right ? You agree ?
Disgusting (Score:5, Funny)
It's disgusting that these LISPers aren't content with their own perversion, but have to try to attract others to the gay lifestyle.
An alternative (Score:3, Interesting)
You might also be interested in SMLserver [smlserver.org] which embeds Standard ML into Apache, and apparently is pretty fast.
Perl is faster than C, too. (Score:5, Interesting)
And Java is faster too!
(rolls eyes)
Different tools are good for various solving various problems.
Yeah, I know certain library routines in certain languages are better than others.
Interpreted languages, in general, are not faster than compiled languages. Period.
This "faster than C" canard keeps getting trotted out and shot down every time.
Well, there is one language faster: assembly.
Re:Perl is faster than C, too. (Score:4, Insightful)
As you hinted at Common Lisp being an interpreted language, a clarification is in place.
Most Common Lisp implementations are compiled. As it has been for some time now. Some lisp implementation compile the code themselvel (SBCL for instance), others walk around and compile C-code (ecl for instance).
An overview of free CL implementations can be found at http://www.cliki.net/Common%20Lisp%20implementation [cliki.net] .
And what makes you think that LISP is interpreted? (Score:5, Informative)
It can be, but any decent production implementation is compiled to native machine codes -- it just includes compiler (and usually pretty fancy optimizing one!) built into the image and always available.
Try running, say, SBCL one day before spreading misunderstandings...
Paul B.
Re: (Score:2)
Try running, say, SBCL [...] Paul B.
Hi Paul. Is the B short for "Braham"? ;-)
Re: (Score:2)
Nope, different guy! But I do get your joke... ;-)
Paul B.
Re: (Score:3, Insightful)
[Lisp] can be [interpreted]
Actually, Common Lisp cannot be implemented as a pure interpreter -- there are a few features of the language that you cannot implement without performing a pass over each function.
(Scheme, the other dominant dialect of Lisp, can be implemented as a pure interpreter, a pure compiler, or a hybrid design.)
Re: (Score:2, Interesting)
Actually, there are things you can do with Java/C# that you can't do with C period.
C (and even assembly) can't realize that the same inputs to a routine always cause the same output, and therefore cache the return value and just return it (not without a lot of buggy, custom code anyway). (I'm not saying Java/C# DO this, they may--I understand they were working on it... But just trying to give you an idea of what CAN be done)
Java/C# do compile to assembly by the way--only the parts that are run often. And
You can also do that in C (Score:2)
You could also easily implement that in C. Of course it would only apply to purely functional C functions, i.e. ones which behavior only depends on their arguments, an
Re: (Score:2)
Actually, there are things you can do with Java/C# that you can't do with C period.
Really?
C (and even assembly) can't realize that the same inputs to a routine always cause the same output
I think the volatile keyword means an external agent can modify the contents of a variable, and if you don't specify volatile, no such agent can. So for all the non-volatile stuff, the compiler can perform the same static analysis that a Java/C# compiler does to decide whether a function has your specified behavior or not.
And if you're not happy with it, in GCC you can annotate your functions. Wrap the annotation in a portable macro (that does, say, nothing on non-gcc compilers) and Bob's your uncl
Re: (Score:3, Insightful)
C (and even assembly) can't realize that the same inputs to a routine always cause the same output, and therefore cache the return value and just return it (not without a lot of buggy, custom code anyway).
C can't because C is a specification. Now let's talk about implementations. If we're talking two of the popular open source ones, GCC and LLVM, you have __attribute__((const)) and __attribute__((pure)), which mark a function as not reading and not modifying global memory, respectively. A function market with the const attribute will always return the same value given the same inputs.
Of course, these are hacks, and are only required when the compiler can't see the function body and infer these propert
Re:Perl is faster than C, too. (Score:4, Interesting)
The main difference is that C is, and always will be, optimized at compile time. Virtual machine languages can dynamically optimize themselves at runtime. Some of the later iteration of the Java and .NET runtimes can notice patterns at runtime (which is an initial performance hit, obviously), and then make assumptions about further calls, and just making sure that they're not messing up (my understanding is that lately Java has made leaps and bounds in that direction).
Then when the pattern "breaks", it reoptimize the piece of code without the assumption. Depending on the system, that can make tremendous performance improvements. As long as things are optimized at compile time only, you won't be able to go that far. Other examples include system wide memory compacting, doing away with useless locks at runtime, etc.
Re: (Score:2)
Interpreted languages, in general, are not faster than compiled languages. Period.
This "faster than C" canard keeps getting trotted out and shot down every time.
And someday we'll all understand the fact that interpreted languages stopped being interpreted a long time ago and are now compiled before execution, rendering the only difference between a classic compiled language (like, say, C) and an interpreted language (like, say Lisp) is that there's a read-eval-print loop (REPL) interface to the latter. Every time you type an expression into a REPL the compiler gets fired up to process that input into the target language that then gets sent to an execution engine.
World's "Fastest" Small Web Server Released, Based (Score:5, Informative)
Sorry its the third oldest this [wikipedia.org] is the oldest.
Designed by Konrad Zuse [wikipedia.org] who also invented the first program-controlled Turing-complete computer. Fortran is the second oldest programming language.
Re:World's "Fastest" Small Web Server Released, Ba (Score:4, Informative)
I think there is an implied "still in use" in the statement - otherwise this is a list - http://en.wikipedia.org/wiki/Timeline_of_programming_languages [wikipedia.org] suggests there are older ones still, and Lisp wasn't even third by any stretch.
Re: (Score:2)
Plankalkul was first implemented in 2000, so I think it missed the game by a long shot. If we are talking about pretend programming languages, Ada's language still beats out this guy by over 100 years.
Paul Graham argues (Score:2)
that there are really only two very clear style of languages, the C family and the Lisp family, with later languages like Java starting from a C basis but building towards functionalities found in Lisp.
I wonder what is beyond Lisp and other functional languages, though?
Re: (Score:2)
well the same thing as always. forth ;)
Re:Paul Graham argues (Score:4, Interesting)
You aren't looking very closely if you're missing it.
By "c-like" I believe Graham meant elements of syntax and approach.
methods declarations in Java take the form:
return_value name(args)
{
statement;
data_structure.member = assignment;
}
A C function looks like:
return_value name(args)
{
statement;
data_structure.member = assignment;
}
The approach stuff is harder to summarize in a post but think of the differences in the use of macros and differences in binding as good examples
James Gosling is one of the people who called Java a "C-like language that avoided the pitfalls of C++"
(full disclosure: I used to work for Sun as a Senior Java Architect so my opinion may colored by the chip they put in my brain)
Re: (Score:2)
This guy is my new hero.... (Score:4, Insightful)
"Automated garbage collection is rubbish" and "Real men don't use floating point" were two of the most interesting and compelling arguments I've read all week. And using LISP as a web platform framework? Fascinating. There were some great ideas back in the days when computers were in there infancy and a lot of them have been abandoned for the most part. Like trinary computing for instance. The building blocks of the computers that you see today were partially designed because of technological limitations at the time. The mechanical underpinnings of the first computers are still present today. I don't care if I'm really wrong about this point (I've been wrong before), but I think computing really needs to transcend a system based on 0s and 1s. Why not abandon the general purpose cpu altogether or at least reduce it to a single core and focus on multiple cores of different types of chips that are optimized for different types of problems? Larrabee might be an hint of that, though I think that ultimately it will really just be a cost saving measure since the gpu no longer needs to be integrated into the board. I think we may be locked into a future of x86 clones for another 30 years at this rate. The Itanic was a good lesson for intel in how much the market values their older code still being able to run without issue. Forgive my bit of a ramble. Just had a whole bunch of random thoughts there.
Is httpd performance in the userspace code? (Score:5, Interesting)
Based on my theoretical understanding of how computers work, I though HTTP daemon performance depended mostly on
Would someone care to correct me?
Note that TFA (well, the slideshow) measures performance in requests per second. That's a very useful measure, but it's compared to Ruby (Mongrel?) and PHP (Apache?). I'm not sure what that comparison means. Does Apache not support lisp, or only as CGI?
Is there something stopping Apache from being sped up? Is he measuring the performance of LISP, or the performance of a HTTP daemon?
I'm a bit confused...
Re: (Score:2)
The web server can be a significant factor in performance then the server is under load, as winessed by Lighttpd being significantly faster then Apache under some workloads and configuration. There are many things the web server can have some affect on (its own memory use, management of fcgi processes, and so forth)
You say that "requests per second" is a useful measure but without the information you yourself suggest is missing I would not agree that it is. There is a vast range of difference between reques
But C is more readable (Score:3, Funny)
Yeah right. (Score:5, Insightful)
Of course, this guy didn't benchmark against any modern performance kings, such as Nginx, YAWS, htstub or LightStreamer.
There is no reason to believe this is the world's fastest webserver, and I'm sure as hell not holding my breath.
Yeah right... (Score:2)
not that I want to pee all over anybodies accomplishments BUT when I see a pure implementation of BSD sockets using pure LISP and IT beats the C version then and only then will I ACK that SYN statement.
Thufferin' thuckitaz (Score:2)
Oh this makes me happy... (Score:3, Interesting)
His example blog is already Slashdotted... (Score:5, Funny)
... so I guess it's not fast enough.
Re: (Score:3, Funny)
I guess he's not talking with a lisp after all, then, he's just lying through clenched teeth.
Re:Faster anything is good. (Score:5, Funny)
Not at the expense of having to learn LISP! I'd rather use dialup.
Re: (Score:3, Funny)
I remember thinking that there might be something wrong with the dial-up connection the night before the first big project was due, so going into the lab at 2am. The dial-up was not the problem, as it turned out. It was the fact that I wasn't alone in waiting until the last minute to test my code. There were 500 students on that brand new DEC 5400, all writing recursive, interpreted code, and apparently doin
Re: (Score:3, Insightful)
Even though Internet throughput seems to be increasing (bandwidth) in leaps and bounds, the server is often a bottle-neck.
What ? You can buy a quad-core, multi-gigabytes-of-RAM machine for under US$500.
For web serving, if your webserver hardware is the bottleneck, You're Doing It Wrong.
Re: (Score:2)
Re: (Score:2)
Yeah and if it wasn't for their help. We'd still be speaking English!
And without them, what would Ghostbusters II have used to get into the Museum?
Re:Attention Pooftahs and Frenchies (Score:4, Informative)
Today is Memorial Day in the United States of America. We would appreciate you folks taking some time to reflect on our servicemen who gave their lives saving your asses in WW I and II.
We do that on Nov 11, thanks. I don't see why we need to adopt your dates for the purpose.
Re:Attention Pooftahs and Frenchies (Score:4, Funny)
We do that on Nov 11, thanks. I don't see why we need to adopt your dates for the purpose.
But... but... Nov. 11th is a horrible date for outdoor grilling! That would ruin the holiday entirely. I don't think you really grasp what Memorial Day is all about...
Re:Attention Pooftahs and Frenchies (Score:4, Interesting)
Your current soldiers are solid. Your previous soldiers were solid. This isn't a pissing contest, but when it comes to having historically solid troops I think we, at least, have earned the right to reflect on the sacrifices of our respective troops on different days * [wikipedia.org]. Yours on your day, and mine on my day. Which is to say, we know it's memorial day. Your soldiers are and have been heroes, but keep your holiday to yourselves. Just as the rest of us keep ours to ourselves.
* - it's worth noting (though I can't find the citation) that the method by which the cdns held kapyong against the 3-5:1 odds was by calling down artillery on their own position
Re:Attention Pooftahs and Frenchies (Score:4, Informative)
Today is Memorial Day in the United States of America. We would appreciate you folks taking some time to reflect on our servicemen who gave their lives saving your asses in WW I and II.
Hi, I'm from the country formerly called the Soviet Union. We would appreciate you folks learning your history, so that you'd know that USA wasn't "the country that won WW2". You might, for example, want to remember that over 3/4 of all German losses in manpower were on the Eastern front (5.5 million KIA total, 4.3 out of which are on Eastern front), and that over 10 million Soviet soldiers, and twice as many civilians, payed with their lives for that achievement.
Re: (Score:2, Informative)
the LISP language itself is written in C.
Not at all. Lisp implementations are usually written in Lisp.
Re: (Score:3, Informative)
In terms of readability and maintenance it might be a nightmare (looking at the LISP code). The benchmark seams biased anyway, you can't beat C/C++, really, and the LISP language itself is written in C.
Very few implementations of Lisp are written in C. Usually there is only a small kernel, and on top of that kernel sits the standard library and the compiler. The kernel often provides only the memory model, the garbage collector, and links to the OS - only the things that can't be written in Common Lisp are in C. Mind you, they *could* be written in some "lower-level Lisp", but since the passing away of Lisp Machines, which ran Lisp Assembly code, nobody seems to bother with this - portable C compilers are