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

Comments

McDonaldization being the price

[rs232]

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

Re:He's also right

[QuantumG]

ha. LISP is pre-parsed.. as in, you're programming in the god damn intermediate language. () does not a syntax make.

Re:"functional programming languages can beat C"

[stonecypher]

Despite the other issues with Orbitz, QPX is an excellent example of what can be accomplished by highly skilled LISP programmers - an exceedingly fast, flexible, and successful search algorithm that they have been able to maintain as the industry leader since it's invention over twelve years ago.

You seem to have missed the point entirely. Nobody said LISP wasn't powerful enough to express complex algorithms. (I'd be interested to learn what industry you think is being led by ITA, though; the Orbitz engine would be lightning fast using simple iterated A* and a creative distance metric.)

As far as your assessment of "Orbitz is ridiculously slow for the amount of data it processes" I beg to differ. Having worked for ITA in the past, let me tell you the amount of data searched through is staggering, especially when you consider that that data set is updated continuously, in nearly-real-time (I could claim real-time, but I like being accurate)

It shouldn't be. Fares just aren't that complex. It's a straightforward directed graph. Your fare search should be several orders of magnitude cheaper than Google Maps' generating a driving path from Boston to Los Angeles, yet Google Maps is done in under a second and Orbitz typically takes 20+ seconds.

If you used to work for ITA, contact me in private and help me understand algorithm context. I used to write Gameboy Color games; you don't know anyone who squeezes speed like I do. There may be a profitable contracting endeavour which we could split 50/50.

Let's be clear: if you have ten thousand airline vendors offering each one hundred thousand flights per day, most staggered across gates, and you need to satisfy group constraints like having N minutes between connections so that someone can travel between terminals, and you have seating constraints and time constraints, and on top of that you have to make fare and time balanced searches - and that's way, way more data than an orbitz fare search should need - you should still be clocking in around one tenth of a second of cpu time.

I'm going to say it again: I have set upper bounds that are unrealistic given the real world commercial environment (there's no way there are that many airlines making that many flights), and I still openly reject the claim that the processing time here is in any way reasonable.

Talk to me. If you can set up contact and communicate the problem constraints to me, we can package benchmarks of a replacement with that Google paper about one second delay causing 40% traffic loss, and make ourselves a nice little pile of money.

My blog has my email address.