The Great Computer Language Shootout 180
kato writes: "Doug Bagley has posted results from benchmarking of 29 different language implementations solving 25 different problems (he's written ~600 of the 725 programs so far). The languages include C/C++, Perl, Python, Eiffel, BASH, Tcl, and OCaml. The problems range in complexity from "Hello, World!" to the Sieve of Eratosthenes and Matrix Multiplication. The results can be sorted by speed, memory usage, or lines of code. You can also give one particular program more weight than another (if you are doing more client/server code than "Hello, World!") and find the faster/smallest/shortest language implementation. I can see many of my programs being written in OCaml from now on." Update: 07/04 12:42 PM by CT : The site is apparently now redirecting people back here. I guess technically thats an error message, just not a helpful one. Update: 07/05 8:40 PM by M : Please don't email. The link is broken. We know. The guy is running a server at home on a metered connection, and doesn't want any more traffic.
Re:Why OCaml is the holy Grail (Score:1)
Australians (Score:1)
site is down... (Score:1)
Re:End censorship now. Remove the lameness filter. (Score:1)
Re:Mod this up! (Score:1)
--
Mirror time! (Score:1)
The following error was encountered:
Connection Failed
The system returned:
(111) Connection refused
The remote host or network may be down. Please try the request again.
Damn you, you blew it all up!
Re:More importantly... (Score:1)
Combine that with the fact that it's often different developers doing the initial coding and support, and you get the situation where C is preferred to other languages that help you reduce the number of errors earlier on.
Re:Java (Score:1)
Languages like PERL and Python know they're natively slow, so they do all the real work underneath in C/C++ libs (that's how PERL's regexp's fly, and how Python-Numeric is within a small constant factor of number crunching in straight C).
But Java has some *terrible* langauge design choices that really limit speed:
- Everything is an Object. This means that you can't have typed containers (i.e. templates), so you have to do expensive dynamic-downcasts when you remove objects from the container (heh, in C you'd just say "I know it's a struct foo*!" and cast away happily".
- Except *not* everything is an object -- primitive types are second-class citizens, so to use the container library on ints or floats you have to use the heavy capital-I-Integer, etc
- All method calls are virtual. This is a small but insidious memory-lookup on every function call... (can be avoided in most places in C++, but is sometimes necessary).
...
If you really want to go fast, you use OCaML -- C and C++ are relatively speaking very hard languages to optimize. Strong typing (without Java's silly "strongly typed, then throw away the type info!") allows you to do much more rigourous analysis at compile time, so you have a much stronger picture of what the data flow graph is. For example, in C/C++ it's almost impossible to draw the data flow graph anywhere but in the basic block (think "within a set of {}") -- and even to do that the optimizer is making assumptions. In OCaML the data flow diagram contains the whole program, so the compiler can optimize across function calls.
...
Note to the lisp junkies: get over syntax. Someone should write a "straight abstract syntax tree" frontend to OCaML just to make you guys happy. Gee whiz.
Re:programmer matters more than language (Score:1)
The most insightful thing I have read all day on /.
Good show!
Re:How you code the algorithm really does matter (Score:1)
Re:C++ vs C comparisons (Score:1)
Sure -- you are definitely "closer to the metal" with C, at least when you write C++ that looks like C++. But the nice thing about C++ is that it gives you a choice -- you can trade speed for maintainer/programmer efficiency. Or you can write C++ that looks like C. I do both, depending on the context.
The real news in here, for me at least, is the frequent gaps between C and C++ implementations of the same thing. For the few sources I managed to look at (yes, the server is /.'ed to hell) the main culprit seems to be the STL.
I love it, but I agree with your point about the learning curve. I'd recommend "Accelerated C++" as a great book for getting up to speed on it. I've found STL to be vastly superior than the half-assed attempts at container class designs I see in most textbooks (a lot of the authors barely seem to comprehend the fact that linked lists are not random access data structures, making a basic conceptual error in using indices instead of iterators)
I don't like the streams libraries either
Love 'em. Typesafe, fast, extensible. Works for me. As a side note, the printf("hello world") vs cout Does this go to reinforce my position that in this day and age Java is a logical choice for pretty well everything bespoke and not performance critical?
It's too bad it's not standardised. It's a nice "slow" language. I've made a lot of use of reference counted "envelope" classes in C++, and having everything GC'd is certainly a nice idea if performance isn't critical. Unfortunately, for most of my work it is. If there was a mature Java Qt port, I'd consider it.
Re:I've benchmarked 25 spoken languages (Score:1)
Don't you think that not drinking the beer you've been drinking for years just because it suddenly became trendy is just as bad as starting to drink a new beer just because it suddenly became trendy? The original poster did mention that they'd been drinking it "for many years now". How did you form the conclusion that they were a "sophisticed beer drinker", who was only drinking it because it "is the most trendy beer right now"?
Later,
Blake.
P.S. As many people care what they drink as what you think. And at least their post was funny.
--
I'm sure this is flamebait, and should probably be moderated down...
Re:I've benchmarked 25 spoken languages (Score:1)
...
Australian English: "I'm not saying any such thing. Give me a Fosters'."
The Australian version should probably be "Mmmmmmaaaaaaaattttteeeeeee" since one of our not a creative cell in their bodies advertising agencies ripped off the American ads and produced a bunch of crappy lets yell mate ads... the ads sucked enough that I can't even remember what they were for.
Also, Australians don't drink Fosters. We just export the crap to unsuspecting Americans (possibly as revenge for Tom dumping Nicole, opening up the possibility she might actually come back here).
Wait a minute. (Score:1)
--
Re:Never worked with it, but... (Score:1)
Re:Pseudoknot: a fairer contest (Score:1)
Why should this be fairer than the approach taken in the shootout? I think it's better to have several categories/programs. Floating-point performance is the last thing I care about.
Still, it's a better example than a self-confessed beginner trying out toy problems.
You probaly didn't visit the site yet, didn't you? Solutions have been provided by different individuals, usually people actually working with the languages, too.
You disagree with a solution? Provide a better one!
Or... (Score:1)
For real-world use, would you choose a language that is much more apt to the job if it wasn't Java,C or C++?
Can't find the site? (Score:1)
OCaml vs the OO Programmer (Score:1)
Please respond via email - thanks.
Re:What about the foot test? (Score:1)
"With C you can shoot yourself in the foot quite easily. With C++ it is harder, but if you do shoot yourself in the foot, you blow your whole leg off."
Quality of Evaluation (Score:2)
PHP disables this by default, because GCC's optimizer goes nuts on 64-bit targets when building PHP's script execution engine. You could see a 2 to 5 fold increase in execution speed over the posted results by simply configuring PHP using `--enable-inline-optimization'.
When notifying the benchmark author about this issue, he simply replied that he expects most users NOT to checkout any possible optimizations. If a user cares about speed, why would not he try to explore such possibilities? Or was the benchmark author just lazy, trying to cram as many languages into his little benchmark as possible?
Re:End censorship now. Remove the lameness filter. (Score:2)
End censorship now. Remove the lameness filter. (Score:2)
Instead I fought the lameness filter, despite using the 'code' type, and generally proved that Taco can't code for shit.
This is exactly why automatic censorship software is a terrible idea, and must be stopped.
And to top it off, when I attempted to submit this message, I received a screen saying: 'This comment has been submitted already, 276169 hours , 30 minutes ago. No need to try again.' Apparently I posted this message earlier... in 19 fuckin 70.
--
Re:How you code the algorithm really does matter (Score:2)
I think you probably meant:
for(i = some_length_func(); i >= 0; i--)
That's a really scary error, so fundamental, it's the kind of thing that would make me want to hunt out and replace all code written by that developer.
Re:How you code the algorithm really does matter (Score:2)
Although, I must admit I normally use
for (i=0;ia.size();i++)
when I know that a.size() uses cached value
Here are the results of the foot test (Score:2)
Re:Also check out PhoneCode (Score:2)
Chris Cothrun
Curator of Chaos
Re:Can't find the site? (Score:2)
He CNAME'd www.bagley.org to point to www.slashdot.org since his network can't even handle the SYN flood from connection attempts (my guess for the reason). It's probably the guy's home LAN.
Re:Slashdot's responsibility to others... (Score:2)
Maybe Slashdot could start caching the sites they are going to link to beforehand, and then change the links to the cache if there's a problem. It could also be useful in case some site changes their content because of Slashdot referencing them and trying to refute the previous content.
Re:Correctness and Programming in the large (Score:2)
The ratio between languages of those language's propensity to have flaws in programs is not going to be a constant. The ratio will rise with bad programmers and approach 1 with good programmers. Giving the language the chore of accomplishing program correctness indicates a lack of good programmers (as defined above).
Of course I want absolute correctness in air traffic control systems and medical instrumentation systems. So the work in making sure programs are correct is certainly important, and I wouldn't want work to make a better language in this regard to stop. But what about also working to achieve better programmers?
The quality level of programmers coming out of colleges is going down. I'm sure that is significantly due to the larger numbers entering the field. But this also means a college degree is essentially worthless in determining the quality of the programmer. Given that experience is also a factor, that pretty much means something else needs to be done to determine who is, and who is not, the quality programmer.
I propose this solution. In addition to having a language that ensures provable correctness, let's also have a language that has none of those features at all. Force everyone to program in that language first for a few years and use it to weed out the bad programmers. Once we have selected the best and brightest programmers based on not only their education, but also the results of real world programming effort produced from experience, then we have them work in the provably correct languages. Now we'll have the best programmers combined with the best language. This should ensure the best results.
Personally, I'd rather have a good programmer writing in a bad language than a bad programmer writing in a good language. I write in C (considered a bad language in this context) and before that in assembly (probably considered very bad). Of course I'm not perfect and frequently there are bugs in the code I write. But these bugs are typically the result of things like not keeping track of how I change things around (I discover I need 2 variables instead of 1 for something, and forgot to change some of the references to the new one), or misunderstanding the interfaces (there are such things as bugs in documentation and man pages, as well as just unclear and ambiguous writing). But I have gotten better on those things over the years. Experience helps you realize you need to develop correct models for what you are doing ahead of time, be more careful about changes, and be sure the understanding of the interfaces is precise and accurate with no shadow of a doubt.
How can a "correct" language ensure that a programmer does not use the wrong variable? What if I transpose the rows and columns of the output matrix because I exchanged the variables that index where each result is stored in a square matrix? Writing wrong programs correctly is certainly very possible. In real world systems, what's going to happen isn't so much a programmer getting out of the bounds of an array (something a good programmer won't do even in assembly, and something any programmer won't do in a correct language) as it is the programmer simply not understanding what is really going on in the system they are coding for. What if a programmer mistakenly assumes the data is coming in in metric units when really it is coming in in old English units, and he simply doesn't code in the conversion somewhere. We could lose a space probe ... or we could lose an airplane full of people. Think it isn't happening? Systems are often designed to compensate for errors in data measurement all the time, and once deployed may well be functional even without the english->metric conversion in place. But the functional tolerances will now be shifted and performance specifications will be other than intended or documented.
A bad language can still have good code written if the programmer is good. But a bad programmer is a disaster waiting to happen in any language. And if you think the language is going to protect against that, consider that since a correct language does indeed do that protection to an extent, that it now opens the door for even lamer programmers to start doing coding. Eventually, you hit the bottom again and you have someone who is such an idiot, that no language in the world can prevent them from screwing up.
Re:Prove? (Score:2)
> Uh, how is this possible?
Thank you for reinforcing my point.
These benchmarks mean absolutely nothing.
--
C++ vs C comparisons (Score:2)
God I hate that thing. I mean, yes, it's very abstract and nice and fast by abstract library standards. But it has a learning curve like the north face of Everest, FFS. I've coded in C++ for a number of years now and have ended up with a personal style that perhaps more mirrors objective C than anything else, it's starting to look like that wasn't such a bad choice.
I don't like the streams libraries either.
Bjarne Stroustrup would hate me.
Does this go to reinforce my position that in this day and age Java is a logical choice for pretty well everything bespoke and not performance critical? (Slow language made by people that make big computers. Hmmmmmmm)
Dave
Re:Java vs. VB (Score:2)
Reason 2, VB will not pay off your mortgage as fast as Java. See "enterprise" and "churn" above.
Other than that I agree whole heartedly. With the possible exception of using php server side. Now _there_ is a language that doesn't know shit about object orientation.
Dave
Re:Quality of Evaluation (Score:2)
To a certain extent I agree with him. I suspect there's a lot of php code that will be run on 'off the shelf' Cobalts etc. where rebuilding the interpreter is not really a practical proposition.
Besides, you have to draw a line in the sand somewhere, and that's the simplest.
Too many languages? Yeah, I think so. I would've been happier with just C, C++, Java and possibly Python myself. Must be some mileage in comparing entire web application platforms too:
Homepage favourite: Apache+PHP+MySQL
Red Hat: Apache+PHP+PostgreSQL
Java trendies: Apache+Jakarta+JSP+Oracle
MS compliant: IIS+ASP+SQL7
For instance.
Dave
Re:Wait a minute. (Score:2)
Re:Wait a minute. (Score:2)
E.g.: I am a Python freak, but for some things, 'regular' Python idioms (like for loops) are slow, but functional Python features (like map()) are much faster. I would use map() but that would be cheating, 'coz I wouldn't know the same shortcut for Perl, for example...
Re:Java (Score:2)
Re:Java (Score:2)
2. Yeah, lots of people seem to have jumpedon the java bandwagon and dumped code into the public domain.
3. Encountered this already, people who want Java for an obvious perl job (text manipulation) because it means they can hire any old Java programmer to maintain it. Not sure I agree with this motivation but I guess its out there
4. Fair enough.
Thanks for the info
Re:Java (Score:2)
Java (Score:2)
1. Portability
Ok, everyone raves about how portable Java is, but well, so is perl (interpretor on numerous platforms, bytecode compiler too)
2. Large publically available codebase
Erm. CPAN?
3. Rapid development
Ok, In my opinion, there are very few things that could be built as fast or faster in Java (by an expert Java programmer) than in perl (by an expert perl programmer). I say this for several reasons:
- Terse syntax under perl, less typing (cheap shot, but valid none the less)
- extremely flexible types mean easy reusability and a total lack of numeric problems
- Built-in high-level data structures (hashes, arrays) and the syntax to operate efficiently on them (list assignment)
4. Speed, ok, admittedly fo the most part, people maintain that java is slow. I am aware that this is considered to be a VM issue more than a language issue, however I think its worth pointing out that in many cases, the data types used most often in large applications are slow because they're written in Java. Take the classic hash for instance. Perl has it built in. C has it in a library which gets nicely compiled, C++ in a template, again compiled. Java on the other hand, has all its high level data types written in Java. An enormous performance hit considering the amount of use these kind of types get in heavy duty applications.
Now, again in my opinion, a JIT could make up for the speed issue, and I only claim that perl is plenty portable, not that it has an advantage over Java in this respect.
I am willing to concede that there is more Java code out there than perl code, but I don't believe there is so much that it makes a big difference.
This being the case, and assuming my assertion about speed of development is true, why are people using Java? What benefits do Java programmers believe they gain (technical, not $$
Except that it doesn't. (Score:2)
Problems there:
The FAQ at the SGI STL site discusses this further. It's good reading.
Re:Wait a minute. (Score:2)
I agree that the results cannot be considered definitive, but they are very far from "completely worthless". It is as important how a programming language fares in the hands of its average programmers as in the hands of its gurus.
Re:Pseudoknot: a fairer contest (Score:2)
I don't object to the solutions so much, since he is taking submissions. I object to the problems, which are all trivial. Floating point performance may be the last thing that you care about. Personally, I find performance in computing Ackermann's function slightly less important.
Pseudoknot is real-world, CPU-intensive and hard. Yes, it's not a complete benchmark suite. I believe that I said as much. My main point is that shootouts based on the ability to solve trivial toy problems are useless.
Off the top of my head, these are the sorts of things I want to see in a "real world" benchmark suite:
I'm sure you have your own pet ideas too.
The spirit of the Prophet... (Score:2)
-Ted
Re:Wait a minute. (Score:2)
Also check out PhoneCode (Score:2)
Doug's project is much more ambitious, but since he wrote most of the code it may not be as competitively written.
Java or nothing ? (Score:2)
Java is a logical choice for pretty well everything bespoke and not performance critical?
Absolutely.
I'm a researcher on RDF and Semantic Web apps, with a real-world site to build too. Most of our current work is IIS/ASP/JScript, and this is excruciating to work with compared to some of the newer stuff we've done (Servlets). The reason is simple, but compelling; availability of existing high-quality open sourced code libraries. The smartest people out there are building what I need, they're letting me use it, and they're doing it for Java.
Re:How you code the algorithm really does matter (Score:2)
Well... (Score:2)
Lisp is a cool language; there's no war here (as there might be with the C++ folks
What was the point? (Score:2)
Besides becoming fodder for flamewars I can't see what good a novice writing "Hello World" and it's equivalents in a dozen or so languages and claiming that it is a benchmark is supposed to achieve.
--
Nope (Score:2)
Why OCaml isn't perfect (nor is anything else) (Score:2)
Because it's not as elegantly simple and consistent as other languages (i.e. Smalltalk or Self).
I know what's it's like to be a language bigot (i'm one too), but no language is perfect.
Re:How you code the algorithm really does matter (Score:2)
Well, speaking as a Java programmer, I check the Java library source code all the time for issues just like this... and Vector.size() simply returns a counter variable, so there's no calculation, just method call overhead to worry about. Actually I avoid using Vectors altogether as they are synchronized; ArrayLists are much faster for single threaded access. (And take up less memory to boot)
Re:Java vs. C++ (Score:2)
But I'd point out that in an enterprise situation, one trip to the database can easily use up more time that is spent doing raw calculation to service a typical request. It is much better optimize database design and queries, and to optimize the system to do fewer queries, than to squeeze out a few CPU cycles. When optimizing a system, go for the big lumps first.
Re:Java vs. C++ (Score:2)
But I disagree that Java doesn't handle threading well, compared to C++.
I may be off base, because I have not done a lot of multithreaded development in C++. I used to develop ActiveX controls, which followed "apartment model" threading. This meant that Windows guaranteed instances would only be accessed by one thread at a time. Only data static to the class needed synchronization. I only used "critical section" code a few times, but I thought I remembered it being part of the Windows API, rather than C++ itself. Some guru will correct me if I am wrong.
It is true in Java that you must think about synchronization, if your object will be accessed by more than one thread. But the language provides for synchronized methods, and more generally for synchronizing on any desired object.
Not transparent, but pretty convenient and flexible. If you design your interfaces well, you can make your system thread-safe object by object.
Re:He better have a good email server (Score:2)
He's not exactly a newbie I think, he just isn't a guru in every programming language ever implemented. I don't think any of us are.
--
Re:He better have a good email server (Score:2)
Re:What about the foot test? (Score:2)
Re:programmer matters more than language (Score:2)
I'd agree with that. I've often seen programmers introduce early twists and turns into basic data flow in hopes of creating some performance improvement down the line. In real life, most performance problems are unanticipated and need to be determined by empirical measurement, not by convoluting the architecture.
Of course, there are some obvious performance problems that can be found by early design review, before coding even starts, but usually those are in areas where the problem is well understood. For instance, in a process system, you know that context switch is going to be a performance bottleneck, so you don't introduce 2K data copies at each switch, and in a B-tree system, you know that you want the index blocks to carry as many items per block as possible, so you don't have a 32-byte key when a 4-byte key will do. (These are both real-world examples of performance problems in Apple software which could have been headed off by review.)
Tim
Re:Java (Score:2)
Hope this helps. In the end, I choose Java because it is a very nice balance of strong OO syntax, good packaging options, and VERY strong industry support. However, it's not the best tool for everything (today). There are times when C/C++ (for example) makes more sense (i.e. when you have to do something very close t othe hardware). However, I find that 90% of what I need I can do in Java.
Re:[[O'caml] AAAAAHAHAHAHAH!!!] Au contraire... (Score:2)
Ok, about O'caml [O'caml = Objective Caml = a variant of ML with objects]. I had to use it for a PL class last semester. It's kind of nice, but don't expect it to be in any way like any language you've ever used (unless you know some other ML variant, of course).
This is true -- it's unlike anything you've ever used before. But that's not a bad thing, necessarily! This is a different way of thinking about programming, and many people feel it's better than the traditional procedural models.
In many ways it's very nice. In other ways it will drive you absolutely insane. For example, O'caml has very strong typing rules (which are good). It has almost no diagnostics when it decides it doesn't like your code (which is very very bad). It also apperantly sometimes gets very confused. For example, sometimes you'll get something like this:
Almost no diagnostics? Did you use the debugger? ocamldebug has many features of gdb, supposedly. Although i'll admit i have little experience with it, from what i've seen, it provides a comprehensive debugging environment.
Granted, the interactive interpreter has few debugging features, but it's not really meant for debugging large chunks of code -- that's why they have a debugger
foo.ml, line 100, chars 16-30: this expression has type int, but is used here with type int
This can be a little maddening after a few hours.
This happens when you write screwy code -- the types may have the same name, but they aren't the same underneath. That's another thing you have to look out for -- things don't change, they just get new environments. This is what functional programming is all about, and why it's much better for certain tasks (like things where you have to step back, or undo -- think web browser, text editor...). Incidentally, i doubt it happens with built-in types like int...
Other annoyances: no function overloading. So to print a string, use print_string. To print an int, use print_int. And so on. This is just how it works (I think you can write a wrapper which will check the type and dispatch the right call, but that's fairly irritating in and of itself).
No function overloading equates to good type-checking. If you allow functions or operators to be overloaded, you compromise the type inference system, which is one of the nicest features of O'Caml. (Besides, you can do things like print_string "n = " ^ (string_of_int n). You just have to be a bit more cognizant of what you're passing around...)
mjd (of perl fame) actually gave a nice talk on why strong typing is so cool [plover.com] -- ML's type system was able to prevent an infinite loop bug! The anecdote starts at slide 27 [plover.com], though for full effect, i'd recommend you read the entire talk [plover.com]
Another thing that irritates me (probably just because I'm from a C/C++/Perl background), is that sometimes you use no ';' to end a statement, sometimes one, sometimes a pair.
You only use a single semi-colon when you want to throw away the return-value of an expression -- it's an imperative feature. That's what's so cool about O'Caml: it doesn't tie you down to any one paradigm, but rather it supports them all -- functional, imperative, object-oriented,
And the double semi is for when the compiler can't tell you've started a new statement. It actually makes quite a bit of sense once you understand the reasoning behind it.
Also, I found the documentation to be very erratic (the modules docs are quite complete, but try finding simple examples of how to do OO, without reading the BNF grammar they put in the docs - that's no way to learn a language).
Unfortunately, i'm inclined to agree with you here. Their documentation is very erudite, and difficult to comprehend. And regrettably, there are almost no good books on the language. (My professor pointed me to The Functional Approach to Programming, by Couisneau and Mauny, but it's more of a textbook, and doesn't cover the object-oriented features of the language.) Presumably this is due to the fact that big businesses don't recognize O'Caml by name (case in point: how many good C books are there? what about LISP?).
Nice stuff: strong typing, cool type matching stuff, bytecode and native compilers, seems like a decent module system.
Regarding the module system, i don't have enough experience to say anything intelligent about it myself, but all my professors are in love with it. They say it's more advanced than anything available, even in Java (the other language they teach us).
But if you don't already know it, good luck. You'll need it.
You make it sound so painful!
majiCk
Re:He better have a good email server (Score:2)
Re:Well... (Score:2)
Well, there isn't static typing in Lisp. There is strong typing, but not static. Some implementations (CMUCL, for example) have some ability to make such static checks. But an implementation needn't, and in fact, may not be able to. For example, in your second example, what if we do (bar (read *standard-input*))? There's no way to know at compile time what type of data read is going to return, so reasonable static checking seems somewhat impossible here.
Also, the second example doesn't have to error. If you look here [xanalys.com] for example, you will see that if we do something like (bar 0) the spec. declares that the consequences are undefined. If you then check the definitions here [xanalys.com], you'll see that this doesn't necessarily mean that an error is signaled. It may be, but it needn't be.
Pluses and Minuses about Ocaml (Score:2)
Yes, it is frustating in programming in Ocaml. It has a lousy GUI except if you have the emacs binding (which is pretty cool). Debugging it can be very frustating since the error message is vague. The documentation is erroneous. Learning Ocaml can take a lot of time, especially if you have never touched functional language realm. But...
In Ocaml you can do a lot of nice things: throwing out functions of functions. Which can simplify a lot of things. This is a significant feature of functional language. It supports a pattern matching like Perl (although not as sophisticated). You can build AST, trees, hashtables, and other ADTs effortlessly using the language's basic construct (unlike C/C++ or Java which supports that in the library). Thus, this is very ideal for theoretical and compiler researches.
I think that you guys C/C++ gurus should try to both reverse engineer the binary output of OCAML and look the code generation phase why it is so fast. Try here [inria.fr] for further reference on Ocaml.
Re:[O'caml] AAAAAHAHAHAHAH!!! You are so wrong!!! (Score:2)
Re:C++ vs C comparisons (Score:2)
please check your own facts (Score:2)
Some specific points:
I always thought, and I still think, that Lisp is a great idea, and specific implementation have been wonderfully productive for me. I do hope that someone will start a project like O'CAML for a full-features modern Lisp system: something with the clean design of Scheme, but with some more practical design choices (e.g., no call/cc, more built-in types, etc.).
that's a problem with C (Score:2)
Re:CMUCL doesn't make me happy (Score:2)
As for type declarations, they're there both for speed and correctness. The optional type declarations in CMUCL can serve both purposes. There is a tradeoff here: on the one hand, the need to keep track of the type information is a burden on the programmer when it is inessential to the logic of the program; OTOH, compiler needs this information to produce compact code and sometimes, catch errors. I like the CL's approach the best: it provides you with the option ONLY when you need it. Also, when programming in CL, I find type errors are rare; most bugs are logical.
Python is a very nice language, especially for beginners. But I doubt anyone who know CL well will prefer Python over CL. The expressiveness, the flexibility, the speed, the maturity of compiler and runtime system technologies; those are enough reasons for me to stick with CL.
As an aside: I like Python, and I've been watching Python's development for a while; however, I've yet to see a PEP (Python Enhancement Proposal) which cannot be implemented *within* the language in CL with a page or two using Macro, MOP, etc. Therefore I concluded that it is much less effort to bring libraries to CL, than it is to bring Python up to the level of CL in terms of language maturity.
In short, I think it is much easier to find happiness in CL! I believe most people will feel the same, too, if they're persistent enough to master the few beautiful concepts underlying the design of CL.
CPU speed (Score:2)
Hrm. Never even heard of Ocaml. Have to look that one up. If you give Lines of Code a '1' multiplier in addition to CPU Speed, it comes out on top in both native and non-native implementations. Java also ranks suprisingly high. Eiffel ranks pretty low. Oh well. Can't have everything.
Too many implementations of Scheme, though. How many do you need? =P
Why this is a worthwhile project (Score:2)
It gives several examples of working code in each language.
It demonstrates an innovative way to deal with being slashdotted :)
Measuring the wrong thing (Score:3)
I am not dismissing the value of this work, but so long as developer & maintainer time is more valuable than processor time, when you choose a language, you should consider how well each language will make the developers' and (especially) the maintainers' jobs easier.
An example of how this can be considered is found in the appendices of "A Gentle Introduction to Software Engineering" [af.mil] (2,565 KB; MS Word format) by the Air Force's Software Technology Support Center (STSC). The appendices come from a document written in March 1996, so it's a little dated (predates the C++ standard, does not address Java, Python, or Perl), but the idea is there. (I like that it keeps repeating "Bad programmers can write bad code in any language, but a good language facilitates the production of good code by good programmers.".)
Including the performance achievable with each language is already in the formulation offered by STSC. The obvious caveat is that you look at the performance of benchmarks related to your application.
cb
Re:Why OCaml is the holy Grail (Score:3)
http://pauillac.inria.fr/~furuse/generics/ [inria.fr]
More importantly... (Score:3)
IT has a misplaced fixation on speed.
--
No good. (Score:3)
And he forgot to test each implementation in single processor, SMP, or Beowulf cluster (Imagine one!) on his platform.
For that matter, he forgot to test it on many different platforms.
And with different hard drive an memory types too.
And at different elevations... computing runs faster in the Colorado air...
And he forgot to test it with or without water cooling or a Peltier cooler... or both...
Finally, he forgot what the sun looks like.
Pseudoknot: a fairer contest (Score:3)
A much fairer contest is the pseudoknot benchmark [soton.ac.uk]. The idea is to take one real-world task (not a partial task like matrix multiplication), and get experienced programmers to write a program to solve the problem in whatever is the most natural way for some language. The results are then benchmarked on equivalent hardware.
Of course it's not representative of all programs. Pseudoknot is a floating point-intensive search problem, which is not the sort of thing that I do most of the time. Still, it's a better example than a self-confessed beginner trying out toy problems.
Other "real" measures (Score:3)
Or how difficult it would be to fix a bug or add a new feature. Or how robustly it would perform in the presence of other kinds of failure (e.g. unexpected input, hardware failure etc). Or how easy or difficult it would be for a larger group of people to work on the same program. Or how easy it would be to adapt his programs to work with other pre-existing programs.
Re:What was the point? (Score:3)
Re:Wait a minute. (Score:3)
I think the important metric is not that the programs are optimal, but that they are representative of what a programmer of average skill in a particular language would produce. After all, one of the benefits of a good language is how easy it is to use -- and we presume that this ease of use will be reflected by better-written benchmarks. It's a lot easier, for instance, to write good code in Java or Smalltalk than in assembly, so why shouldn't those languages be able to show some benefit from that in a test like this?
Of course, ease of use is impossible to quantify in a test like this, but I'd argue that shooting for optimal (i.e. written by somebody far more skilled than an average programmer) will seriously distort one's expectations of real-world usability of these languages.
How you code the algorithm really does matter (Score:3)
for(int i = 0; i < vector.size(); i++)
do_something(vector.element_at(i));
This code potentialy has a O(n^2) complexity if the size of vector is calculated dynamically each time size() is called versus
int size = vector.size();
for(int i = 0; i < size; i++)
do_something(vector.element_at(i));
which should have O(n) complexity with regards to traversing the vector. The interesting thing is that the previous version could potentially be O(n) depending on how the size() method is implemented in the vector class. But how many people actually know if the size() method in the vector class in whatever library they use (e.g. Java, C++, etc) actually use lazy evaluation or overeager evaluation? <br><br>
NOTE: Regardless of which language used. If a benchmark is run using vectors which dynamically calculates their size and contain a large amount of elements then the code in the first part will ALWAYS run slower than the code in the second part even if the comparison is Java and C/C++.
--
Overeager evaluation (Score:3)
Evaluation is deemed overeager or eager if the value is computed as you go along instead of just when it is needed. The fact that the C++ vector implementation increments and decrements a counter on pushes and pops instead of when size() is called is eager evaluation .
--
He better have a good email server (Score:3)
Me thinks that his email server will be slashdotted before his website is with every geek in teh world telling him how to improve the programs he wrote.
Which is a good thing - I'd love to see before and after results with after being after all teh /.'er changes are added - course that assumes /.ers would be able to agree on the best route of action. ROFLMAO!
Seriously - very interesting project - he'll ctach flack for being a newbie I'm sure - but a great endeavour all around. More power to him!
CMUCL doesn't make me happy (Score:3)
Furthermore, type declarations are not there for speed, they are there for correctness. ML programs (O'CAML or SML) usually run correctly once they compile; with CL, you spend a lot of time unit-testing for silly type errors.
I think an updated version of CL would be great, something that is based on UNICODE, throws out the old pathname and character set cruft, gets rid of some other obsolete features, defines error handling and reflection carefully, and adds threads, sockets, and binary I/O. But I don't see it happening. Most of the people who want CL-like interactivity are now using Python or Java+Beanshell. The syntax isn't as nice, but they are so much more practical.
what about the real measure of a language? (Score:3)
[O'caml] AAAAAHAHAHAHAH!!! You are so wrong!!! (Score:4)
Ok, about O'caml [O'caml = Objective Caml = a variant of ML with objects]. I had to use it for a PL class last semester. It's kind of nice, but don't expect it to be in any way like any language you've ever used (unless you know some other ML variant, of course).
In many ways it's very nice. In other ways it will drive you absolutely insane. For example, O'caml has very strong typing rules (which are good). It has almost no diagnostics when it decides it doesn't like your code (which is very very bad). It also apperantly sometimes gets very confused. For example, sometimes you'll get something like this:
foo.ml, line 100, chars 16-30: this expression has type int, but is used here with type int
This can be a little maddening after a few hours.
Other annoyances: no function overloading. So to print a string, use print_string. To print an int, use print_int. And so on. This is just how it works (I think you can write a wrapper which will check the type and dispatch the right call, but that's fairly irritating in and of itself).
Another thing that irritates me (probably just because I'm from a C/C++/Perl background), is that sometimes you use no ';' to end a statement, sometimes one, sometimes a pair.
Also, I found the documentation to be very erratic (the modules docs are quite complete, but try finding simple examples of how to do OO, without reading the BNF grammar they put in the docs - that's no way to learn a language).
Nice stuff: strong typing, cool type matching stuff, bytecode and native compilers, seems like a decent module system.
But if you don't already know it, good luck. You'll need it.
The server? (Score:4)
Re:What about the foot test? (Score:4)
shoot($foot);
Thanks perl!
Java vs. C++ (Score:4)
-
The combination of jar-file packaging, pure interfaces, and dynamic class-loading by name make it easy to use a "pluggable component" approach. In my opinion, this goes beyong traditional OO development in making large-scale development manageable.
-
Automatic memory management and no pointers, love it or hate it, saves boatloads of time in chasing down those old runaway pointer bugs. Of course, you can still leak memory, but you have to work a little harder to do it.
-
The built-in Java libraries are as good as or better than the C runtime, if you ask me.
-
It looks damned nice on the resume these days.
Of course, if you need to write anything that is CPU-bound and has to be balls-to-the-wall fast, you are still better off using C++, or probably C or assembler. But most "enterprise" applications are not CPU bound, anyway.Prove? (Score:4)
Uh, how is this possible? Even if the semantics of all these languages were formally specified (which, of course, they're not) and even if the semantics included execution time information (which I've never ever seen before), the task of proving optimality seems impossible. No, I take that back, it is impossible.
Re:Why OCaml is the holy Grail (Score:4)
Because code transformation in OCaml is not pretty. Owning to CL's clean and uniform syntax, macro in CL is simple and elegant; this metaprogramming capability provides it with unlimited expressiveness and adaptibility.
Because OCaml doesn't provide the option to delay deciding types. In CL, I write generic code to speed up development; I then (optionally) declare types in bottleneck code segments to speed up program execution -- it makes perfect sense (remember the 90/10 rules).
Because OCaml doesn't have a Meta Object Protocol.
CMUCL is a highly optimized, Free compiler and execution system for Common Lisp (http://cmucl.cons.org/cmucl). Please come and help making it better (http://www.telent.net/cliki)!
What about the foot test? (Score:5)
What I'm missing from the list... (Score:5)
Slashdotted already, try the google cache... (Score:5)
Neat Idea; Unfortunately Near Worthless (Score:5)
The results [berkeley.edu] are interesting for a number of reasons.
(1) The "naive" algorithm, even with optimization, performed at about 50 MFlops (the Suns we used had a theoretical peak of 333 MFlops).
(2) With excellent optimization, pulling out all the stops, and using all the tricks available (unrolling loops, deallocating pointers to local variables, etc.), teams of just two students working for a week could get EXCELLENT performances (ie, within 10-20% of theoretical peak), approaching those of Sun's built-in library, and exceeding those of some existing libraries (like PHiPAC).
(3) Different groups with different approaches got very widely disparate results -- some barely exceeding those of the naive algorithm.
In sum, how ones goes about coding an algorithm can make ENORMOUS differences in the performance of a code. This is particularly true with numerical algorithms in C and other languages with pointers, where some compilers have great trouble optimizing routines using pointers, since the values are not known at compilation time. Taking this into account, I wouldn't give this guy's results much credence at all.
However, with the help of a lot of experts in the various languages, it will be possible to get a much better appraisal of the relative performances of different languages. A close analogy exists with these benchmarks and the SPEC [slashdot.org] open standards evaluations for CPUs. The only fair way they found, to compare across all CPUs and compilers, was to allow a very strict non-optimal compilation, and no-holds barred compilation. The same is true here -- we need to get teams to go no-holds barred in the creation of the best possible codes for each language.
Bob
Re:Slashdotted already, try the google cache... (Score:5)
Re:CPU speed (Score:5)
It's the Irish version of Perl. (ouch.)
--
Never worked with it, but... (Score:5)
Why OCaml is the holy Grail (Score:5)
Because it has a wonderful OO model which can make all OO programmers happy.
Because it has super fast compilers that can make C and C++ programmers happy.
Because it is great for imperative programming and for functional programming.
Because it is great for procedural programming and for OO programming.
Because it is as multiplatform and portable as Java.
Because it is designed to please everyone without compromising on anything, and, put more simply, because it can reconciliate the C, Java, Lisp and C++ community.
Because it can even be used indifferently as a scripting or a system language.
Because it is great for teaching AND for the real world.
Because its compilers are libre software and its design and developement are made in a very open fashion.
I've benchmarked 25 spoken languages (Score:5)
American English: "Wuzzzzzzzzzzzzzahhh!"
British English: "What is up?"
Japanese: "Konichiwaaaaaaaaaaaaa!"
Spanish: "Holaaaaaaaaaaaaa!"
Welsh: "Wyffffffwyfffffffffffff!"
The binary language of water vaporators:
"0100000000000000000000000000000000"
Australian English: "I'm not saying any such thing. Give me a Fosters'."
Irish English: "I'm not saying any such thing. Give me another pint of Guiness."
Javanese: " I'm not saying any such thing. Give me another pint of Guiness. No, I'm not the Irish guy in Javanese traditional dress, I'm from Java!"
programmer matters more than language (Score:5)
In other words, if engineers spent more time studying best practices and efficient algorithm design, that might well improve performance more than spending time in religious wars about the merits of pet languages.
In my experience, basic performance tuning can easily create an order of magnitude improvement regardless of the language. And in my experience, most engineers don't know how to do basic performance tuning. That's got to be more important than language selection in the average case.
Tim