Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

World's "Fastest" Small Web Server Released, Based On LISP

ScuttleMonkey posted more than 5 years ago | from the more-tools-in-the-tool-belt dept.

Software 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."

cancel ×

502 comments

Sorry! There are no comments related to the filter you selected.

"functional programming languages can beat C" (4, Funny)

Jurily (900488) | more than 5 years ago | (#28085255)

In speed and elegance, perhaps. But not on the überprogrammer salary to maintain it.

Re:"functional programming languages can beat C" (3, Interesting)

Anonymous Coward | more than 5 years ago | (#28085301)

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" (5, Insightful)

Holmwood (899130) | more than 5 years ago | (#28085819)

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" (4, Interesting)

stonecypher (118140) | more than 5 years ago | (#28086107)

First, his blog is standing up to a slashdotting. That's impressive.

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.

If your skills were more common we'd have a better world.

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.

It's very tough to find someone who can code well in C

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:"functional programming languages can beat C" (0, Offtopic)

spydabyte (1032538) | more than 5 years ago | (#28086207)

It's memorial day. Only people that work from home are on slashdot, amirite?

Re:"functional programming languages can beat C" (2, Insightful)

daveime (1253762) | more than 5 years ago | (#28086287)

Or perhaps we are part of the other 95% of the world that aren't American ?

Re:"functional programming languages can beat C" (0)

Anonymous Coward | more than 5 years ago | (#28085527)

In speed *or* elegance, since you can always disassemble their webserver and write C code that produces the same assembly. Highly inelegant C code, but same speed.

Re:"functional programming languages can beat C" (5, Interesting)

epiphani (254981) | more than 5 years ago | (#28085625)

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" (4, Informative)

vivaoporto (1064484) | more than 5 years ago | (#28085737)

Parent post is inflammatory but not troll. He has a point, this implementation is a minimal test case built in order to prove a point. A skilled C programmer could implement the same test case that would perform better than the LISP one, if the task was worthy.

Re:"functional programming languages can beat C" (3, Insightful)

epiphani (254981) | more than 5 years ago | (#28085743)

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:"functional programming languages can beat C" (1)

ID000001 (753578) | more than 5 years ago | (#28085911)

Why not go ahead and do a demonstration?

Re:"functional programming languages can beat C" (2, Insightful)

imbaczek (690596) | more than 5 years ago | (#28086031)

you can't be faster than C, because only C has access to complete 100% of special functionality OS kernels provide, like sendfile(). this challenge is moot and everybody knows it; the point is to _not_ be writing in C and achieve speeds which are respectable and/or fast enough.

Re:"functional programming languages can beat C" (3, Insightful)

Anonymous Coward | more than 5 years ago | (#28085823)

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:"functional programming languages can beat C" (1)

bennomatic (691188) | more than 5 years ago | (#28086103)

Assembly's for wimps! I commit my code one bit at a time!

Re:"functional programming languages can beat C" (4, Insightful)

mauddib~ (126018) | more than 5 years ago | (#28085833)

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:"functional programming languages can beat C" (1)

epiphani (254981) | more than 5 years ago | (#28086009)

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 maintainability or number of lines of code.

Willing to take up the challenge? :)

Re:"functional programming languages can beat C" (1)

rbarreira (836272) | more than 5 years ago | (#28086091)

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.

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.

Of course, such a thing could also be implemented in C or Pascal, but requires tremediously more effort.

Again this doesn't say anything about the intrinsic performance of a language.

Re:"functional programming languages can beat C" (1)

Holmwood (899130) | more than 5 years ago | (#28085933)

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 talented C programmer than a talented LISP programmer.

Re:"functional programming languages can beat C" (1)

K. S. Kyosuke (729550) | more than 5 years ago | (#28086007)

Wonderful. And after you write it, do not forget to send it to Jeffrey Mark Siskind. He will send you a faster implementation written in Stalin. :o)

Re:"functional programming languages can beat C" (0)

Anonymous Coward | more than 5 years ago | (#28086023)

Aight. Please make http://shootout.alioth.debian.org/u32q/benchmark.php?test=chameneosredux&lang=gcc&id=2 execute more quickly than http://shootout.alioth.debian.org/u32q/benchmark.php?test=chameneosredux&lang=ghc&id=2 . Also, after you're done trying, please go and learn a bit about compiler theory, so that you know that C isn't a silver bullet of speed.

Re:"functional programming languages can beat C" (1)

TheRaven64 (641858) | more than 5 years ago | (#28086043)

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 language, it is easy to make big changes and still have something that is fast.

The problem with challenges like this is that they are effectively microbenchmarks, an area where low-level language do very well. In a microbenchmark, a C++ template or a C macro is much faster than a function call or a dynamic message send, for example, but they both increase code size, which increases instruction cache churn, and make the whole program slower. Using macros or inline functions in C makes your code faster when you benchmark a small example, but often makes it slower in a big program. To achieve the same level of flexibility without macros, you need levels of indirection via function pointers, and before you know it you've written a slow implementation of a dynamic language.

The correct challenge isn't 'can you write a program in language X that is faster than the equivalent C program,' it's 'can you maintain a program for 20 years through three complete changes in requirements in C and still have it approach the speed of a written-from-scratch program'.

Re:"functional programming languages can beat C" (0)

Anonymous Coward | more than 5 years ago | (#28086101)

Simple program: A small server that can be updated on the go, without being taken down, aka, code hot-swapping.

I can do this in under 20 lines of code, I'll even have documentation there. Let me know when your C implementation is done, and we'll compare speed.

Re:"functional programming languages can beat C" (1)

epiphani (254981) | more than 5 years ago | (#28086127)

Update exactly what code? I do this all the time using dlopen, if i need to.

But your suggestion places a design constraint and does not define a functional requirement. I don't know anything about what I'm supposed to write. 20 lines of dlopen() wrappers?

Re:"functional programming languages can beat C" (1)

stonecypher (118140) | more than 5 years ago | (#28086161)

Dude, settle down. The primary difference in most cases between HLL and LLL implementations is still algorithm selection and structure. Write a static webserver that competes under load with YAWS and I'll be impressed; otherwise you're just another guy bragging.

Incidentally, a static webserver is several hundred lines of C. It's an extremely simple task, and there's a well defined (and much more satisfactory) benchmarking set under Tsung that will laugh while your server withers under the heat of YAWS. You will not successfully compete with YAWS under the YAWS Tsung test set; timeslicing behavior is way too hard for anyone who would attempt to publically stage a meaningless, undefined "challenge" like this.

As long as you haven't defined the task or the phrase "high level", you've left yourself enough wiggle room to exclude anything that's even slightly challenging. If you want to be taken seriously, produce the competing code, or at least _define_ what challenge you're making.

And, frankly, dude, nobody really cares if you're sick of this crap until you've put up competition. (Don't bother tu quoqueing; I've actually released a webserver.)

Re:"functional programming languages can beat C" (1)

RightSaidFred99 (874576) | more than 5 years ago | (#28086189)

You're right, of course. People like to come up with all kinds of crazy reasons why e.g. Java is "faster than C", when of course it's not. They come up with magic explanations like optimizations and memory management but of course they never quite understand if you wanted to you could make those SAME DAMN optimizations in C.

That said - in most application domains it doesn't make enough of a difference to make up for the other advantages of a language like Java or C#/.NET.

oblig (5, Funny)

olivier69 (1176459) | more than 5 years ago | (#28085689)

In speed and elegance, perhaps.

So you agree to the fact that emacs is faster and more elegant than vi, right ? You agree ?

Re:oblig (0)

Anonymous Coward | more than 5 years ago | (#28085967)

So you agree to the fact that emacs is faster and more elegant than vi, right ? You agree ?

NO! I'll never stop using the devil's editor!

Re:"functional programming languages can beat C" (0)

Anonymous Coward | more than 5 years ago | (#28086221)

In speed and elegance, perhaps. But not on the überprogrammer salary to maintain it.

Über Pro Grammar? Isn't that what the /. grammar nazi's are always pushing on people?

Faster anything is good. (1)

erick99 (743982) | more than 5 years ago | (#28085257)

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.

Re:Faster anything is good. (4, Funny)

InsertWittyNameHere (1438813) | more than 5 years ago | (#28085361)

Not at the expense of having to learn LISP! I'd rather use dialup.

Re:Faster anything is good. (2, Funny)

bennomatic (691188) | more than 5 years ago | (#28086135)

Hah. Last time I used LISP (well, really, Scheme, since it was at Berkeley), I was on dial-up!

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 doing so badly enough that such difficult tasks as accepting a username and password were beyond the abilities of the server.

Re:Faster anything is good. (2, Insightful)

drsmithy (35869) | more than 5 years ago | (#28085645)

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:Faster anything is good. (1)

EdZ (755139) | more than 5 years ago | (#28085813)

You can, but I wouldn't expect it to hold up well under constant heavy use.

Disgusting (5, Funny)

Anonymous Coward | more than 5 years ago | (#28085259)

Imagine a small alternative to Ruby on rails, supporting the development of any web application, but much faster.

It's disgusting that these LISPers aren't content with their own perversion, but have to try to attract others to the gay lifestyle.

Re:Disgusting (1, Funny)

Anonymous Coward | more than 5 years ago | (#28085465)

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're confused fellow AC. That's Apple's territory.

Re:Disgusting (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28085723)

Monday is my busy day. After I get off work as a substitute gym teacher, I have to race across town to the NAMBLA meeting. [nambla.de] Then it's a quick pit stop at McDonald's for a bite and to check out who is having a Happy Meal in Playland.

Afterward I must zip uptown to the Apple Users' Group meeting. Finally by 11:00 pm it's time to head home with my PowerBook and scope out the K12 chat rooms.

As I said, it's my busy day. If it weren't for my Apple computer, I don't know how I could do it all.

An alternative (2, Interesting)

Ed Avis (5917) | more than 5 years ago | (#28085305)

You might also be interested in SMLserver [smlserver.org] which embeds Standard ML into Apache, and apparently is pretty fast.

Attention Pooftahs and Frenchies (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28085385)

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.

That's right, poofters, you'd be reading this post in German right now if it wasn't for Mother Green and her killing machine. And Frenchies, don't even get me started. A car backfires and you are pulling out the surrender flag. You need to think long and hard about how we saved your derriers.

Nuff said. Now get back to your discussion of web servers and linux.

Re:Attention Pooftahs and Frenchies (1)

0100010001010011 (652467) | more than 5 years ago | (#28085461)

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 (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28085519)

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.

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...

McDonaldization being the price (0, Troll)

rs232 (849320) | more than 5 years ago | (#28085521)

"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 [wikipedia.org] of the place ..

Re:McDonaldization being the price (1, Insightful)

osu-neko (2604) | more than 5 years ago | (#28085969)

Actually it was the Soviet Union that broke the back of the German army.

There is a point where oversimplification turns an essentially true idea into an utterly false statement. You passed that point a while back here.

And if you liberated us in 1945, then why are you still occupying the place with military bases.

Because you want us to. If you wanted us to leave, we would. There are numerous examples of this.

The price we are paying being the continued McDonaldization [wikipedia.org] of the place ..

Given that this is happening everywhere in the world along with modernization, even places where no American soldier has ever set foot, your statement linking the two is utterly absurd.

Re:Attention Pooftahs and Frenchies (3, Informative)

julesh (229690) | more than 5 years ago | (#28085695)

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 (4, Funny)

osu-neko (2604) | more than 5 years ago | (#28085855)

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 (3, Interesting)

Morphine007 (207082) | more than 5 years ago | (#28085805)

Hi, I'm from Canada. We're those soft-spoken guys to the North of you who were used as shock troops in both those wars [wikipedia.org] you mention. We did the job when no one else could [wikipedia.org] .

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 (2, Informative)

Whalou (721698) | more than 5 years ago | (#28086251)

From http://www.kvacanada.com/stories_rskap'yong.htm [kvacanada.com]

About 1 a.m. April 25, a Dog Company platoon was attacked from three sides by large numbers of enemy troops. Two Patricias manning a Vickers machine-gun where killed. Waves of Chinese spilled into the company area. It was hand-to-hand-fight-for-your-life combat. Dog Company was on the verge of being overrun. The company commander, Capt. Wally Mills, requested that artillery be fired on his own positions. The New Zealand gunners obliged. The defenders hugged the bottom of their trenches while artillery shells roared in overhead. The shells scoured everything above ground level, driving off the Chinese. But they returned. More artillery fire followed. 2300 rounds hammered Dog Company positions.

This web site was cited in the Wikipedia artical posted by the parent.

Re:Attention Pooftahs and Frenchies (0)

Anonymous Coward | more than 5 years ago | (#28086095)

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.

Perl is faster than C, too. (5, Interesting)

Anonymous Coward | more than 5 years ago | (#28085431)

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. (4, Insightful)

MADnificent (982991) | more than 5 years ago | (#28085593)

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? (4, Informative)

PaulBu (473180) | more than 5 years ago | (#28085595)

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:And what makes you think that LISP is interpret (0)

PaulBu (473180) | more than 5 years ago | (#28085631)

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.

Re:And what makes you think that LISP is interpret (1)

jonaskoelker (922170) | more than 5 years ago | (#28085709)

Try running, say, SBCL [...] Paul B.

Hi Paul. Is the B short for "Braham"? ;-)

Re:And what makes you think that LISP is interpret (1)

PaulBu (473180) | more than 5 years ago | (#28086093)

Nope, different guy! But I do get your joke... ;-)

Paul B.

Re:And what makes you think that LISP is interpret (2, Insightful)

klapaucjusz (1167407) | more than 5 years ago | (#28085801)

[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:And what makes you think that LISP is interpret (1)

mwlewis (794711) | more than 5 years ago | (#28086119)

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?

Re:And what makes you think that LISP is interpret (1)

PaulBu (473180) | more than 5 years ago | (#28086235)

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.

Re:Perl is faster than C, too. (2, Interesting)

bill_kress (99356) | more than 5 years ago | (#28085607)

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 the compile step can know a lot more about the runtime configuration of the system.

Currently these kind of optimizations don't actually have Java running faster than C, currently it runs about 1/2 the speed on average and significantly less for some operations. A very few operations can be faster.

The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster without touching the compiled system.

All I'm really doing is offering a counter to your discussion about assembly being clearly faster--Logically I assumed it would be too--just makes sense--but I assumed wrong.

Re:Perl is faster than C, too. (-1, Troll)

sillybilly (668960) | more than 5 years ago | (#28085793)

And when Java version 13.22.5.pre99.post05-rc4 is finally out, it will also blow the pants off painstaking manually optimized assembly programs too, as far as speed of execution is concerned. You doubt my statement? Then just wait and see for yourself!

You can also do that in C (1)

rbarreira (836272) | more than 5 years ago | (#28085863)

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)

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.

Re:Perl is faster than C, too. (0)

Anonymous Coward | more than 5 years ago | (#28085939)

Same input to a routine SOMETIMES cause the same output.

Side effects period.

If you define "output" as the whole environment, your statement can be true. But to apply caching for values, you would have to map the set of environments to the set of inputs. Additionally, your inputs may come from the environment (think of global variables), so you may have to map the set of environments to itself.

I guess (only guess, I'm not sure) that it would be impractical for imperative languages to implement such a caching mechanism.

However, it may be practical (for functions that are called with a narrow range of inputs) for (pure) functional languages.

Re:Perl is faster than C, too. (1)

jonaskoelker (922170) | more than 5 years ago | (#28085941)

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 uncle.

when Java 7, 8 or 9 comes out, ALL java code will run faster

And what's to stop people from writing a linker which does some "post-production" optimizations on the object code? If the compiled C code stores as much symbolic information as the Java code, I'd guess you could do a lot of stuff that's typically done in the compiler to the object code (dead write elimination if they're not done yet).

Also, note that traversing data structures representing byte code isn't free. If later JVMs do more work to optimize code before running it, I predict they will take longer to start up.

From a theoretical standpoint, your C compiler could be cat(1) if you have a sufficiently sophisticated runtime. Then you can do all sorts of crazy stuff at runtime.

I think the best kind of argument which is similar to yours is "let's look at practical achievements".

Are people shipping fancy linkers that speed up C code? No, they're not. Are JVMs employing fancy optimization techniques at run-time? Yes, they are. Is C substantially faster than Java at run-time? Yes, it is.

The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster [...].

It'll still be slower than all the C code out there.

Here's a car analogy: once $BRAND1 finds a more efficient combustion process, all their cars go from 50 to 60 miles per fuel cell that same day. Let's compare to $BRAND2, whose cars run 100 miles per fuel cell today. Which do you want? 60 or 100? Remember: the biggest number is the best here.

Re:Perl is faster than C, too. (1)

osu-neko (2604) | more than 5 years ago | (#28086079)

Actually, there are things you can do with Java/C# that you can't do with C period.

Are you claiming C isn't Turing-complete, or just making patently false statements to troll?

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).

Ah, I see. You just know so little about C and assembly that such a preposteriously absurd statement seems possible...

In fact, this sort of thing tends to be done more reliably in C or assembly than in any other language, since it doesn't rely on the compiler's guesswork to try and estimate whether to engage in this sort of optimization or not, it instead relies on the programmer's knowledge, and any decent programmer is more knowledgeable than the machine he or she is programming.

Although, if you're a script-kiddie, what you say might be true for you.

Re:Perl is faster than C, too. (1)

jelle (14827) | more than 5 years ago | (#28086187)

"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"

The 'const' function attribute does that and works fine: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html [gnu.org]

And, C compilers have performed such optimization automatically on a much finer scale than functions for ages (common subexpression elimination), and there really is no reason why future versions won't do it just as much, and on all the same scales as java compilers/vm's eventually will.

"The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster without touching the compiled system."

Sure, a future version will beat something that exists today, future versions of java vm's will be faster than current versions (thank $DEITY)... But so will C compilers... C compilers beat java vm's today, and there is nothing about the java language that can't be done with C, see for example http://llvm.org/ [llvm.org]

Quite possibly the future of executables (for certain types of executables) is more towards the VM/jit approach, but that is language independent.

While many languages are much easier to use than C (in their application areas), saving development time, and can be for all intents and purposes as fast as it needs to be, saying they will be faster than C will be, is falsely assuming that C compilers have stopped developing further... Perhaps faster than C is today, but not faster than it will be.

imho, the bucket of gold at the end of the rainbow is there where you can choose your programming language freely, interface across language barriers with ease, and build a final program from such a mixture of languages if needed.

Real programmers.... (0)

Anonymous Coward | more than 5 years ago | (#28085733)

... use a keyboard with 3 keys. 1, 0, enter. Assembly is for n00bs!

Re:Perl is faster than C, too. (1)

pz (113803) | more than 5 years ago | (#28085739)

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. For modern systems, there really isn't much of a difference between interpreted and compiled languages.

To paraphrase one snarky comment to twist it into another, this "interpretated languages are slower than compiled languages" canard keeps getting trotted out and shot down every time.

Re:Perl is faster than C, too. (1)

osu-neko (2604) | more than 5 years ago | (#28086209)

And someday we'll all understand the fact that interpreted languages stopped being interpreted a long time ago and are now compiled before execution,

This is well understood.

... 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.

That's the common misconception. It overlooks the fact that most compiled languages are slower than C, and C is slower than assembly, due not to the fact that one is compiled and one is interpretted, but to the fact that compiler-based guesswork is often sub-optimal to better-informed choices made by intelligent programmers when deciding exactly how to optimize a bit of code. Even C traditionally has the option of inline assembly because C programmers recognized that assembly is faster. It has nothing to do with one being interpreted vs. compiled. It has to do with whether the machine code was produced by an automated system or an intelligent agent, and the degree of closeness of that agent to the machine code. The further the agent abstracts away from it, the less optimal the output can be made.

Re:Perl is faster than C, too. (0)

Anonymous Coward | more than 5 years ago | (#28085843)

Doesn't the argument go something along the lines that higher level languages describe more about the problem and as such are can be optimised to a greater degree than C?

I think it's a good argument, but it does rely on the compiler/JIT being smart and being backed with a lot of good research.

One good example of something a highlevel language can do nicely regards pointer aliasing. In C, prior to the restrict keyword, some optimisations could not be applied since the compiler has to generate code to handle all cases it cannot determine to not happen, including aliased pointers. If you use a high level languages where pointers are hidden (Java), or gone all together (Haskell) the compiler/JIT has a lot more freedom to optimise.

Speed is not all (0, Redundant)

moon3 (1530265) | more than 5 years ago | (#28085469)

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.

Re:Speed is not all (2, Informative)

Anonymous Coward | more than 5 years ago | (#28085601)

the LISP language itself is written in C.

Not at all. Lisp implementations are usually written in Lisp.

Re:Speed is not all (2, Informative)

K. S. Kyosuke (729550) | more than 5 years ago | (#28086271)

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 ubiquitous and the core itself is portable this way. This means that a compiled Lisp program runs essentially very little C, unless it is collecting garbage.

The reason for Lisp being written in Lisp is precisely what you're claiming there (only the other way round): A Lisp written in Lisp is much more maintainable than a Lisp written in C. Besides, compiler often serves as a good test suite for itself.

And as far as "beating C" is concerned, you might want to take a look at Stalin Scheme.

World's "Fastest" Small Web Server Released, Based (4, Informative)

omar.sahal (687649) | more than 5 years ago | (#28085497)

LISP, the world's second oldest high-level programming language.

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 (3, Informative)

pmc (40532) | more than 5 years ago | (#28085763)

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:World's "Fastest" Small Web Server Released, Ba (1)

osu-neko (2604) | more than 5 years ago | (#28086277)

Depends on your definition of "high level". Most of the ones on that list older than LISP and Fortran wouldn't qualify...

Re:World's "Fastest" Small Web Server Released, Ba (1)

Deanalator (806515) | more than 5 years ago | (#28085987)

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.

Re:World's "Fastest" Small Web Server Released, Ba (1)

osu-neko (2604) | more than 5 years ago | (#28086253)

... 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.

Paul Graham argues (1)

rolfwind (528248) | more than 5 years ago | (#28085557)

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:Paul Graham argues (-1, Troll)

H0p313ss (811249) | more than 5 years ago | (#28085647)

later languages like Java starting from a C basis but building towards functionalities found in Lisp

I don't know what it is you're smoking to think that Java starts on a C basis but can you share? Java is a hell of a lot closer to LISP than it is to C.

Disclosure: I know LISP, C and Java (and others: Smalltalk, JavaScript, Scheme, APL, Python etc...)

Re:Paul Graham argues (3, Interesting)

monk (1958) | more than 5 years ago | (#28085893)

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:Paul Graham argues (1)

sillybilly (668960) | more than 5 years ago | (#28086067)

Somehow being labeled as "Senior Java Architect" seems to me like being made fun of. I would only want to be labeled that if it came with a fat salary, and only for the money, because passionate zeal for the topic would still be nonexistent, because the whole thing is so far off into bloated nontransparent bullshit land, that only retards truly believe in it.

Re:Paul Graham argues (1)

larry bagina (561269) | more than 5 years ago | (#28086229)

Java is not, by any reasonable standard, closer to LISP than C.

Let's look at the wankopedia [wikipedia.org] page:

Influenced by: Ada 83, C++, C#,[1] Eiffel,[2] Smalltalk, Mesa,[3] Modula-3,[4] Objective-C

The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities.

The syntax of Java is largely derived from C++

Not one mention of lisp. But what about lisp [wikipedia.org] ?

Newer languages such as Java and Python have incorporated some limited versions of some of the features of Lisp, but are necessarily unable to bring the coherence and synergy of the full concepts found in Lisp.

Of course, there's no citation for that.

Re:Paul Graham argues (1)

monk (1958) | more than 5 years ago | (#28085909)

well the same thing as always. forth ;)

Re:Paul Graham argues (0)

Anonymous Coward | more than 5 years ago | (#28086059)

I'd say logic programming languages, such as prolog, would clearly comprise a third style.

This guy is my new hero.... (3, Insightful)

ZosX (517789) | more than 5 years ago | (#28085569)

"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.

Re:This guy is my new hero.... (0, Offtopic)

AsmCoder8088 (745645) | more than 5 years ago | (#28086133)

Very nice pictures indeed (referring to your sig).

Is httpd performance in the userspace code? (4, Interesting)

jonaskoelker (922170) | more than 5 years ago | (#28085693)

Based on my theoretical understanding of how computers work, I though HTTP daemon performance depended mostly on

  • I/O performance, much of which is controlled by the kernel (in particular the file system).
  • A good caching strategy (to minimize I/O), again done by the kernel.
  • Good networking performance, controlled by the networking stack in the kernel.
  • Database performance, controlled by the RMS-DB, BDSM(R) or whatever it is.
  • Process spawing speed (for CGI), again controlled by the kernel.

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:Is httpd performance in the userspace code? (1)

asdf7890 (1518587) | more than 5 years ago | (#28085889)

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 requests that just pull a single static file and requests that his a script interpreter which in turn needs to hit a database... Even if they state that the requests were for PHP output there are a variety of ways PHP can be called and that will affect performance (at least four: module [most common under Apache], CGI, FCGI [most common under lighttpd], ISAPI [under IIS]). Unless otherwise stated I assume that req/sec measures are referring to requests for static files though any benchmark like that which doesn't describe the environment used in some detail is essentially meaningless.

But C is more readable (2, Funny)

klapaucjusz (1167407) | more than 5 years ago | (#28085735)

C is more readable [jussieu.fr] , though.

Re:But C is more readable (0)

Anonymous Coward | more than 5 years ago | (#28085901)

It's called a function.

Honestly, sure some things are ugly in C [linked lists and the sort for instance] which is why a COMPETENT programmer would factor those out into functions which they would test once and use many times.

That persons code you linked to is a prime example of something that could have been abstracted away with proper code factoring.

In short, the person is a shitty C coder [or their example is just shitty].

Yeah right. (4, Insightful)

stonecypher (118140) | more than 5 years ago | (#28085749)

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.

Re:Yeah right. (0)

Anonymous Coward | more than 5 years ago | (#28086011)

You think nginx is better than apache because of it's speed ? First of all, delivering non static content apache is faster in many cases either way, yet nginx is better because of the memory usage. Who cares about a few miliseconds in loading time, when it can handle a dozen more requests on the same hardware.

Wrong on epoll and AIO (1)

edivad (1186799) | more than 5 years ago | (#28085777)

Since the advent of eventfd(), you can wait for disk AIO (via KAIO), using epoll_wait().

Yeah right... (1)

McNihil (612243) | more than 5 years ago | (#28085783)

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 (1)

AnalPerfume (1356177) | more than 5 years ago | (#28085809)

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.

Oh this makes me happy... (2, Interesting)

Onyma (1018104) | more than 5 years ago | (#28085825)

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!

His example blog is already Slashdotted... (5, Funny)

macraig (621737) | more than 5 years ago | (#28085847)

... so I guess it's not fast enough.

Re:His example blog is already Slashdotted... (0)

Anonymous Coward | more than 5 years ago | (#28085995)

Actually the link given doesn't seem to be using lisp as a server. There error page gives the following :

Apache/2.2.4 (Ubuntu) mod_fastcgi/2.4.2 PHP/5.2.3-1ubuntu6.5 Server at john.freml.in Port 80

Re:His example blog is already Slashdotted... (2, Funny)

macraig (621737) | more than 5 years ago | (#28086141)

I guess he's not talking with a lisp after all, then, he's just lying through clenched teeth.

Web server versus web framework? (0)

Anonymous Coward | more than 5 years ago | (#28085891)

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.

Ediware? (0)

Anonymous Coward | more than 5 years ago | (#28085907)

(a) "Lisp". all uppercase "LISP" went out with flares. Sheesh.

(b) How does it compare to Edi Weitz' excellent http://www.weitz.de/hunchentoot/ [weitz.de] ?

Parenting^H^H^Hhesis (1)

dargaud (518470) | more than 5 years ago | (#28086193)

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
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?