Slashdot Mirror
World's "Fastest" Small Web Server Released, Based On LISP
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."
In speed and elegance, perhaps. But not on the überprogrammer salary to maintain it.
Even though Internet throughput seems to be increasing (bandwidth) in leaps and bounds, the server is often a bottle-neck. Anything that is faster is a welcome addition to life in the very, very fast lane.
http://www.busyweather.com/
It's disgusting that these LISPers aren't content with their own perversion, but have to try to attract others to the gay lifestyle.
You might also be interested in SMLserver which embeds Standard ML into Apache, and apparently is pretty fast.
-- Ed Avis ed@membled.com
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.
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?
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.
Sorry its the third oldest this is the oldest.
Designed by Konrad Zuse who also invented the first program-controlled Turing-complete computer. Fortran is the second oldest programming language.
I'm sure the rest of the world appreciates your sitting on your neutral asses for the first couple of years of each of those wars...
"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"
..
Actually it was the Soviet Union that broke the back of the German army. And if you liberated us in 1945, then why are you still occupying the place with military bases. The price we are paying being the continued McDonaldization of the place
davecb5620@gmail.com
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?
"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.
zosxavius photography
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.
Sorry, was not clear -- had to proof-read. Not only the implementation is compiled (obviously), but everything you (load) or type into the REPL prompt is compiled to native code as well before being executed.
Paul B.
In speed and elegance, perhaps.
So you agree to the fact that emacs is faster and more elegant than vi, right ? You agree ?
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...
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.
Try running, say, SBCL [...] Paul B.
Hi Paul. Is the B short for "Braham"? ;-)
... use a keyboard with 3 keys. 1, 0, enter. Assembly is for n00bs!
C is more readable, though.
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.
StoneCypher is Full of BS
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 suggests there are older ones still, and Lisp wasn't even third by any stretch.
Since the advent of eventfd(), you can wait for disk AIO (via KAIO), using epoll_wait().
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.
[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.)
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 *. 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
Oh god, that woman is John Romero!
Isn't LISP an ideal companion to Python? Thnakes in cartoons talk with lithps after all, and Snagglepuss even. LISP maybe eethy to read but it's not easy to thay, that'th why they call it a lithp.
I first learned LISP using the watered down version included in AutoCAD while writing huge customization projects in the 80's. I loved the language so much I dove into it full force and enjoyed it thoroughly. To me it was so inherently elegant I wanted to use it everywhere. Obviously however making a living meant most of us had to focus our energies elsewhere but something like this makes me all giddy again. I think I have some playing to do!
Play me online? Well you know that I'll beat you. If I ever meet you I'll "/sbin/shutdown -h now" you. -Weird Al, kinda.
... so I guess it's not fast enough.
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...
"Convictions are more dangerous enemies of truth than lies."
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, and that don't have any side effects. But that restriction would also apply to the Java case.
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
This is a terrible summary and for a few minutes I thought the submitter was a complete moron.
Apparently this thing is both a web server and web framework. It also looks to be nothing more than an experiment currently.
It might be faster than Rails but I seriously doubt that it is faster to develop for than Rails. Make a framework that makes DEVELOPMENT easy and solid, THEN make it fast. If the goal of Rails was to be the fastest web framework then it probably WOULD BE.
(a) "Lisp". all uppercase "LISP" went out with flares. Sheesh.
(b) How does it compare to Edi Weitz' excellent http://www.weitz.de/hunchentoot/ ?
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.
Nope, different guy! But I do get your joke... ;-)
Paul B.
You say that like speaking German is a bad thing. It's certainly a hell of a lot better language than that bastardisation of English you use over there.
I really don't know much about LISP, but I'm having a hard time understanding why "performing a pass over each function" rules out being a "pure interpreter." Maybe we just have different definitions of what that means. Could you please clarify?
JOIN US FOR PONG!
One thing( I could never wrap my head around( is that functional languages consider that functions have no side effect.) Which is all fine( for mathematics), but in the real world( everything has a side effect: printf( is a side effect). Serving some html( is a side effect). Anything (that has to do with I/O is a side effect)). It breaks( the whole concept), so we might as well( keep using( a language that doesn't( overburden itself) with insanely( obnoxious and contrived) theoretical considerations))) (that it will break anyway), like...) C
Non-Linux Penguins ?
Interesting, did not know that... What would be an example? I thought that some other Free CL implementations are interpreters, but I might be confused, CLISP does compile to bytecodes, and GCL uses gcc...
Paul B.
This web site was cited in the Wikipedia artical posted by the parent.
English is not this
... the first compiler for it was implemented in 1998.
Plankalkul may have been conceived first, but generally, the age of something is measured from the date of birth, not the date of conception.
"Convictions are more dangerous enemies of truth than lies."
Depends on your definition of "high level". Most of the ones on that list older than LISP and Fortran wouldn't qualify...
"Convictions are more dangerous enemies of truth than lies."
Well, I'll celebrate memorial day when the Americans start celebrating their liberation from the British by the French on October 19th.
Awesome, thanks =)
It's a story that is still (at least 5 years ago when I went through) recounted in infantry officer training for the Canadian military.
Oh god, that woman is John Romero!
Okay, it may be the fastest web server in the world - and it's dependent on the oldest programmers in the world. With most web server applications, you have to worry about computer viruses - with this one, you have to worry about Alzheimer's.
#DeleteChrome
My Informatics Professor swears by it. He uses it for absolutely everything. I was shocked at first, but as the XKCD comic says, it does have a kind of timeless beauty to it =)
It has one and only one error message: "Missing Parenthesis" ;-)
Table-ized A.I.
That all depends on the compilers at hand. Without really advanced code analysis, a C compiler cannot generate code that uses the carry bit, cache prefetch instructions, etc.
Because of that, a higher-level language with built-in higher-level constructs such as 256-bit integers might beat a C compiler in the speed game.
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.
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. (*)
How are you going to prove this dipshit? Do you have some induction step that can prove this? Or a formal proof to offer?
Yes, if I give you Implementation X in LISP of some algorithm, I do believe that given unlimited time and resources you can probably rewrite it faster in C. But I think you're missing the point.
And you don't know shit about the word proof which makes me doubt your other claims.
But Ada's notation was not "high-level". Perhaps the statement should have been "second oldest surviving high-level language". There are also Grace Hopper's experimental languages in the mid 50's that led to COBOL. It may be argued that these be counted with COBOL since they heavily influenced it, although arguments could be made either way.
Perhaps they should have said, "one of the earliest high-level languages", then it won't generate controversy, and we wouldn't be having this side-bars on slashdot. Naw, we like side-bar trivia contests, admit it.
Table-ized A.I.
...so what we have here is a faster algorithm, not a faster programming language.
LISP is better than C for other reasons, not speed...
By the way, why some Slashdot pages are not rendered correctly by Firefox 3 on Windows XP (SP3)? I have to select the text with ctrl+A to see the header of each post.
"... C is the closest high level language to how a processor actually operates."
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.
http://jng.imagine27.com/articles/2009-05-03-195227_i_want_to_believe_in_lisp_performance.html
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.
Are you adequate?
Turing-Completeness only says something about what you can compute, not how efficiently you can compute it.
HAND.
I'm working on embedded systems. Real men don't program desktop computers! :-P
Small embedded systems are often sans FPU. Fixed point arithmetic is orders of magnitude faster on such a platform (I'm not sure what the numbers on desktop processors are but I wouldn't be surprised if it's slightly beneficial even there).
I have a really elegant proof for Fermat's last theorem. If this sig was only a bit longer...
As modern programming languages (Python, Ruby, and Scala) are implementing Common Lisp features (closures, variable capturing) and the online availability of Practical Common Lisp, it seems now is a good time for younger people to learn CL. The icing on the cake here is that there are alternatives for Vim users to develop Lisp without using SLIME.
I really don't know much about LISP, but I'm having a hard time understanding why "performing a pass over each function" rules out being a "pure interpreter." Maybe we just have different definitions of what that means. Could you please clarify?
Sure. A pure interpreter is an implementation that executes the code as it parses it, or at least as it walks the parse tree. An intepreter with a pre-pass is one that first walks the code, does some transformations or caches some data, and only then executes the code.
Suppose you're implementing a BASIC interpreter. A pure interpreter would walk your BASIC program, and execute statements as it parses them. However, it will surely be more efficient to perform a pre-pass and remember the addresses of every line number, so that every GOTO doesn't need to scan the whole program to find its target.
Hi, i'm from Soviet Union. And i'd appreciate if both of you americans reflect on the great sacrifices that our troops have made so that you both can now grill your steaks today in this nice sunny weather.
What would be an example?
There are some restrictions on when macro expanders are allowed to be run which cannot be satisfied without performing a pre-pass. Sorry, I don't recall the details.
I thought that some other Free CL implementations are interpreters, but I might be confused, CLISP does compile to bytecodes, and GCL uses gcc...
CMUCL, CCL (formerly MCL), SBCL, Lispworks and ACL are native compilers. KCL, AKCL and GCL compile to C. CLISP compiles to bytecode. Heck, even Emacs Lisp is compiled (bytecode).
(By the way, have you tried CCL yet? It's a very nice implementation, and since it's only been ported to Linux recently, a lot of people are not aware that it exists.)
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
Just another "Cubible(sic) Joe" 2 17 3061
-5 Ignorant
-5 Wrong
you had me at #!
As a Python, Javascript and PHP programmer, you would think I lean to the Algol style of programming yet I find C brittleness unbearable.
I don't know any Lisp but I was tough C at college and Lisp still looks more readable than C and it's micromanaging tendencies.
I'm pretty sure a Lisp 101 would teach me to write Lisp as good as C in less than a semester.
In short, I don't think the availability of C programmers and scarcity of Lisp programmers is due to Lisp being harder than C is it?
And if it is, how is it? What's so easy about C? What so hard about Lisp?
But... the future refused to change.
Subject says it all. I goofed, and used a less-than sign in the code sample.
Just another "Cubible(sic) Joe" 2 17 3061
From Wikipedia: In 1995, Graham and Robert Morris founded Viaweb, the first application service provider (ASP). Viaweb's software, originally written mostly in Common Lisp, allowed users to make their own Internet stores. In the summer of 1998 Viaweb was sold to Yahoo! for 455,000 shares of Yahoo! stock, valued at $49.6 million.[2] At Yahoo! the product became Yahoo! Store.
Think global, act loco
They're comparing an integrated webserver / web application with a general webserver connected to an independent application through unix sockets.
Of course the first one is much faster, but it's not the same thing at all...
Might one point out that you didn't exactly rush to save anyone in either conflict: both had been going on for years before you decided to join in.
But now, obviously, you're big enough to start your own, pointless, stupid wars.
Please, give it a rest. The USA no more joined in either war to save anyone than the original combatants did.
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 syntax (for the C
# developer. Replace [lt] with less-than before compiling
# Define in-line C function for fast factorial within 32 bit constraint
(c-declare #[lt][lt]c-end
int fast_factorial(int n) {
if (n [lt]= 0)
return 1;
return n * fast_factorial(n - 1);
}
c-end
)
(define fast-factorial
(c-lambda (int) int "fast_factorial"))
# The constant 12 is the largest factorial that can be computed in a 32 bit int.
# Notice the function fast-factorial is also escaped: fast-factorial is actually a C expression.
\int factorial(int n) {
if (n [lt]= 12) {
\fast-factorial(n);
} else {
n * factorial(n - 1);
}
}
Just another "Cubible(sic) Joe" 2 17 3061
But Konrad Zuse doesn't have a beard, so Plankalkül doesn't count.
Hmm, CCL looks nice, thanks for the info!
Will check it out -- but is is SBCL over here, and, after dealing with some quirks, it is actually pretty robust and fast.
Paul B.
LISP is a language that offload the parsing burden onto the reader. Sure is hell easier to write a LISP parser, but humans are taught since first grade to the "OPERAND1 OPERATOR OPERAND2" syntax, and LISP fscks that up. With so many languages available today, LISP is most definitely the wrong answer.
Zuse's computer was not Turing-complete.
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.
It does the same thing in Konqueror 3.5
I'm really annoyed at some of the comments I'm reading here regarding C compared to high level languages such as LISP. Many of the people on here call themselves nerds yet they seem to have no idea how basic functionality of a CPU works!!! I can't even be assed with this post ...
I don't really agree about pointers being confusing. Well, at first, sure, but once you 'get' them, like I did, it's pretty nice to work with them. I actually find the abstraction of pointers to references in languages like JavaScript, Java and .NET annoying because I never know what I'm actually passing along in arguments. That is, if it's the reference or the entire object. Those concepts have bled together in those languages.
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 so! And, it ONLY takes two instructions! No, let's do better. We can DOUBLE the speed of this puppy. Just assume that negative numbers will never be passed in.
#define factorial(n) fact_table[n]
That's one fast function now!
This is 32 bit int type only. Not a very interesting or useful case. 64 bits? Brings us to 20! or so. It is certainly a major benefit to Scheme to have the bignum built-in. Have you finished the C version without gmp yet?
Just another "Cubible(sic) Joe" 2 17 3061
Worldth "Fathtetht" Thmall Web Therver Releathed, Bathed On LITHP
Aren't we comparing an implementation of Ruby to an implementation of Lisp? Excuse me, but I think that saying one programming language is faster than another is like saying English is faster than French. A language is just a set of formalisms for communicating. I'd be more than willing to bet that one could have an implementation of Ruby that could smoke Lisp or and be on par with the likes of C# or .NET. I mean, what if one wrote a Ruby with its guts in straight assembly....
This is my sig.
Hello from an American. I would like to say that there are those down here that do appreciate and value our Northern neighbor! It is easy to forget and mythologize (?) your own history. I know that my relatives who fought in those wars were more than happy to have the assistance of anyone willing.
My grandfather (Pacific theater) and great uncle (Europe) both fought in WWII, but did not talk much about anything except great generalities. I do remember my uncle talking about ow happy they were to hear the bagpipes of a Scottish unit coming to help them. Remembering that others shared in the fight, the loss and glory does not diminish ones self.
Hi, I'm from a country currently called the United States of America, and I'd like to remind yet another citizen of the former Soviet Union that WWII wasn't fought only in Europe.
That threw me right off, plankalkül is a rather obscure claimant, but assembly is the oldest surviving-and-useful high-level language. Now there are third-generation super-high level languages so perhaps it makes sense to call assembly "mid-level" but it sure as heck isnt low level. Low level programming means direct machine code.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
I have a web server which I built from scratch in Java (even built my own Stream buffers). The web server is currently being used to serve http://art.othernet.com/ in addition to some other websites. Benchmarking my server using the same schedtool/ab parameters, spits out 5896 requests/second. This is including dynamic html generation.
C abstracts away details of the machine, which is why it is (barely) a high level language and assembly is not. And Lisp is far older than the only surviving assembly languages I know of: x86 (1978), ARM (1983), and x64 (2003).
Thanks for all the attention guys. I will try comparisons with a couple of servers.
The immediately appearing comments were borked, I've fixed them now. Please give it a shot!
http://john.freml.in/teepeedee2-using
It's uninteresting whether you can, in principle, write something that is as fast or faster.
The interesting metric in many situations is whether, given the same amount of development time, you can produce something that is faster while being as reliable and functional.
> It must be a small challenge involving a relatively simple task.
I think an interesting point is that, for problems larger than small, well-defined tasks (ie. any real world project), then the speed advantages or disadvantages of the language start to get swamped by the choice of algorithms.
I spent some time working through the small programming challenges at projecteuler.net. It is worth noting that the submitted solutions by users, in many languages, vary in execution time over many orders of magnitude, and my casual inspection seemed to show that the thing that correlated with fastest execution speed was not choice of language, but choice of algorithm.
The programmers submitting solutions are amongst the set who are voluntarily spending their own time to do this - hence while they aren't the best programmers out there, they also probably aren't the worst.
My conclusion is that if you can afford to get a good programmer to spend all day optimising a small bit of code, then yes C is going to be fastest. But as soon as the problem gets larger, or as development time is reduced to more normal proportions, then most half-decent programmers choice of non-obviously sub-optimal algorithms is going to swamp that. A high level language that supports discovery and implementation of the right algorithm, by giving the programmer less low-level detail and fewer lines of code to worry about, is going to claw back some ground.
This matches with my own experience of Python. People expect that performance will be terrible, and when we measure it in benchmarks, it is terrible. But in real-world projects, it is great. So what's going on?
Hi, I'm from a country currently called the United States of America, and I'd like to remind yet another citizen of the former Soviet Union that WWII wasn't fought only in Europe.
We know it well enough, since USSR participated in the Pacific Theatre, albeit in a relatively minor way (12,000 KIA - but proportionally it's larger losses than those of U.S. in Europe, for example).
Even so, Pacific theatre was much smaller than European one. Again, if you look at military casualties - Japanese only account for 1/4 of all Axis losses.
Yes, the gap between Memorial Day and November 11th symbolically represents the 2-year gap between the start of WW2 and the US entry into the war. You can keep WW1 by the way as, unlike WW2, it was fought between fascists rather than against them. Now, getting back to the subject of LISP, fast it may be, but if I wanted to write code that was hard to understand I'd use FORTH or a macro assembler, not some god awful mess of brackets that only John McCarthy understands.
what about Assembly vs. C ?? or Assembly vs. LISP
Common LISP source that runs on one interpreter isn't guaranteed to run on another interpreter.
You can have one standard library function that returns the values of an ASCII character represented as a symbol... but those aren't defined in the standard. For example, you can have one interpreter's library have that standard function return #\NewLine while the same standard function returns #\Enter. that's just one tiny example but it bugs the shit out of me.
That's why you see a lot of Common LISP libraries out there have clauses in their functions to run different code depending on which interpreter is running it. Very very annoying, and probably a maintenance hassle.
Has any effort been attempt amongst the maintainers of all the different CLISP interpreters to try to enforce some consistency that was overlooked in the original ANSI standard?
You guys are reading far far too much into an excited guys remarks on his blog. He did achieve a lot by making a 'ancient' 'slow' programing do a task fast. Appreciate him for it.
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...
Grilling? Veterans? Remind me not to come to any barbecue on this date.
C was "general-purpose" only for operating system developers. It is easy to make a C compiler for a new processor. When C was invented, users were developing much more limited programs with very limited processors, and the limitations didn't matter as much.
We know it well enough, since USSR participated in the Pacific Theatre
Declaring war on Japan in August 1945? The USSR "participated" by showing up for the yearbook photo. Typical Stalinist land grab. And quite frankly, it's hard to celebrate the Soviet contribution to the European front when Russia was originally so happy to indulge and assist Hitler. You let a wild dog off the chain, you deserve to get bitten.
So you suffered a two to one loss ratio and are still willing to brag about it? Interesting. I suggest a different strategy next time.
I can't see his implementation as I type, but since it's Lisp, it probably has these two features:
* Compiled from (S-expression-based) markup to machine code
* Can be modified without restarting web server
The first would be really hard in C without a preprocessor. Your markup doesn't have to be S-expressions, but it should be some semi-readable DSL.
The second is very hard in C, as it requires having the compiler around at runtime and dynamic redefinition of code.
If you can do both of those in C, you're really good.
To a Lisp hacker, XML is S-expressions in drag.
Don't you think that that's taking sporting spirit a bit too far ?-)
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Lisp always reminds me of a Gary Larson cartoon. There is a six-year-old sitting in a classroom with one of Larson's typical frumpy teachers with big glasses at the blackboard. The caption reads, "Teacher, may I be excused? My brain is full."
Having gone the Engineering route of getting my CS degree, I have to say that nothing quite fills the brain like Lisp. Not Quantam Mechanics, not Special Relativity, Not Word Problems, Not Linear Transformations, and Not Shakespeare.
At Berkeley they use Lisp to weed out the less than committed, as the very first programming class a Freshman takes one takes is in Lisp. It was quite effective at getting Freshman to drop like flies.
Lisp hurts the brain. There is something not quite right about thinking in lambda functions. Or at least normal in the typical notion. Far be it from me to promote being normal, I'm a big fat weirdo, but the Lisp crowd, it seems to me, is a religious cult and has always used the language as an Elitist barrier. A computer science definition of machismoism: you must claim Lisp is the end all, be all. Paul Graham certainly fits into that elitist crowd. If normal is meant to mean not wanting to aspire to be part of some elitist crowd simply because one's brain is perceived superior by some arbitrary standard, count me normal. Or count my brain as full.
While I agree with most of and the gist of your post, I must take exception to this:
...For example, in days past C was popular because CPU cycles were a lot more important than they are now, and memory sizes were a lot smaller than they are now...
If you think that CPU cycles and memory sizes aren't so important these days, just ask M$ about Vista. If there is any one thing that has made Vista a bust, it is M$ thinking that execution speed and efficiency don't matter much anymore.
Good judgement comes from experience, and experience comes from bad judgement.
- W. Wriston, former Citibank CEO
So you suffered a two to one loss ratio and are still willing to brag about it?
Brag? No, I'm not willing to brag about so many deaths. I just wish to remind that, ultimately, they weren't pointless, and that largely with them the price of victory - for all Allies - was paid.
Or are you willing to claim that superhuman American Rambos could achieve the same 10-to-1 kill ratio against Germans, especially early in the war, as they did against Japanese, if they only tried?
It's also worth remembering that USSR - unlike US or UK - had to fight the Germans on its own land. And we didn't have France's option of surrendering, either, knowing full well what Nazi's plan for Eastern Slavic people was. Furthermore, Eastern Front was much less "civilized" than Western one - keep in mind than Nazis considered Russians untermenschen, and communists Jewish agents, so POWs were routinely massacred on the spot, and prisoner camps for Soviet prisoners were much more brutal than those for Western Allies, and the death rate was much higher.
Germans lost over a million of their soldiers fighting for one city alone - Stalingrad. That's over 1/6 of their total losses in the war - and payed pretty much 1-for-1 with lives of Soviet troops. There was nothing even close to that kind of war grinder in Europe, much less the Pacific, so there's nothing you could possibly compare Soviet losses to, and say, "oh, this really could be done so much easier". Because no-one else was willing or able to actually do it.
Interesting. I suggest a different strategy next time.
In that case the winning move was to strike first. If the USSR did that back then, then, trust me, the Iron Curtain would be much farther to the West - if there would even be one at all. It's not something that you (or me, for that matter) should wish for.
Why is this news ? Seriously, CS teacher have been shouting for 51 years now that Lisp is faster than C (that's right, 14 years before C was invented), and that functional programming is faster than procedural programming. Is it because it's faster (faster it is, but significantly faster, it is not), or because it is in Lisp (nope: the second, or third, or whatever the nth such of it's kind), or because it's fast AND in Lisp ?
Come on... do we really need this ? Is there something new here and in Lisp that's usefull to my profesional career, something classical like a shitty web 'enterprise' application ? I agree, maybe my career has taken a rather 'shitty' course, but is this article somewhat based on reality, or do we just have 'high expectations', that will remain unfullfilled in another 20 years (will web development still be around in 20 years ? I'm sure CS teachers will).
I don't hate CS teachers, by the way.... but this guy:
- wrote his own bechmark platform to test his app.
- says 'automated gc is rubbish'
- tells you to write your business monetary code using.... integers for the pennies calculation !
- prefers command based compilation to inline compile !!
When will we get over with the 70's ? Can we start to finally build something that is useful to someone ? Way yo go /., this really shows you're serious about article selection ! I just guess we'll just have to wait for the next "picobrowser in Scheme released, faster than Chrome but no HTML nor Javascript support, only works in Emacs platforms" super-mega-duper article.
A revisionist definition.
When I was learning CS Assembly was the definitional example of a high level language. Obviously Pascal/C/Lisp etc. are higher level, but all of them are easily distinguishable from true low-level code.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Actually you're not quite right about C... it's not that efficient at all... most C instructions generate many actual machine instructions so C is quite removed from the bare hardware and how "the processor actually thinks" dude. Assembly language is much closer to the metal. Yes it's not a "high level language" but then neither is C, not really! C is a low level systems language.
"Pointers" are not to be feared, mistakes with pointers are what is feared. Many higher level languages simply prevent those mistakes while providing all the usually necessary operational flexibility.
For sure "message sending languages" such as Java and Smalltalk implement programming paradigms that the processor doesn't know about.
Modern processors execute multiple instructions per cycle (instruction level parallelism). The game of speed is all about filling those instruction slots with useful productive instructions and not letting them go to waste unused. EVERY LANGUAGE that aims for any amount of speed must meet the challenge of filling those slots.
C compilers are notorious for NOT filling these instruction slots for each cycle.
Often it's not the compiler's fault since the code they are compiling is too sequential or branches too much to fill all the slots in a cycle. Also all the slots on the cpu are not created equal and may not even be the same across all versions of a manufacturers chip line.
Assembly will almost always beat C even hands down since it's always possible to write better code than the compiler can. It's a matter of HUMAN TIME COST. Assembly usually takes longer to write than C just as C usually takes longer to write than code in higher level languages.
So when you are interested in speed, is that speed of execution or speed of development where dollar and human time cost is paramount?
There are efforts underway to make the compilers for languages like Smalltalk just as fast as C by the use of many techniques including the use of hidden inlining of code (this is effective in Smalltalk since the methods on classes tend to be very short at an average of under nine lines) and custom compilation of methods based on discovered object types. Essentially message sends are eliminated in many cases and types are discovered and specialized versions of the code is compiled for those types - either on the fly or at development time. In languages like Smalltalk all variable references are pointers references so pointers are not to be feared as the spycraft-fu mistakenly asserts. In fact a uniform use of pointers makes the language easier to understand while maintaining a one to one mapping of "object structure" to "how the machine thinks" - you could not have a closer mapping! The advanced work currently being done looks like it could bring Smalltalk compilers to produce code that is consistently at or above the speed of C compilers. Oops.
Remember the game is filling the instruction slots in modern super scalar processors. (http://en.wikipedia.org/wiki/Superscalar).
One of the hidden costs of C is the debugging time when things go wrong.
Recently I undertook the task of updating an 15 year old program written mostly in C and C++ with a good bit of Assembly Language. I didn't have to change the assembly language one iota since it was "well thought out". As for the C and C++, both had many errors of the classic sort one finds with C based languages: buffer overflows left right and center - even where they were not expected! Funny enough one of the bigger non-buffer overflow bugs was found by tracing an unexpected buffer overflow as it did it's damage. It was also interesting that adding any code to "manage" buffer overflows would noticeably slow down (by 10% or more on inner loops) the program which was a heavy data cruncher. Once again the number of lines of code generated for each line of C was many, with numerous possible assembly optimizations still possible.
Sure C might be faster but often that's because the C programmers took too many BIG risks with the
> A revisionist definition.
> When I was learning CS Assembly was the definitional example of a high level language.
Sez you. I'd like to know what school you went to, because assembly does not abstract details of the hardware AT ALL. It is a low-level language.
Labelling. A small thing, but they were one of the vast improvements of assembly over coding directly in binary. Of course you may not count not having to redetermine the memory location of pieces of code and data as code changed size as a hardware abstraction.