Slashdot Mirror

being Microsoft it will probably not run on 95% of our compute clusters

F# specifically supports Mono on Linux and OS X. I somehow doubt it's good enough for clusters, though...

In any case, I don't think that's the intended use case. It's not for computationally intensive stuff - you'd still want Fortran or C/C++ there, as you've rightly noted - but for the kind of computations that you do on your own box. These guys provide some supplement tools.

That said, it can still be used to massively parallelized, scalable tasks, since it has some stock parallelization primitives, and can also use .NET Parallel Framework (which is task/taskgroup-based automatic scheduler on lower level, and automatic parallelization of queries and transforms over sequences on higher level).

Therefore... Why should I care? What does F# do, for me as a scientist, that I should invest my time into it?

Do you, as a scientist, use Haskell or ML? If so, you can think of F# as the same kind of thing, but with first-class IDE and debugging support, and ability to quickly throw together UI frontends in WPF (it's pretty good for rather advanced visualization).

SML ray tracer vs. C++ ray tracer.

High-level "nifty shit" language is 30% faster than C++.

http://www.ffconsultancy.com/languages/ray_tracer/comparison_cpp_vs_sml.html

The debian language shootout has a few examples of Functional languages being faster than people's best efforts in C, especially when it comes to parallelisation. I suggest you try and write a regex-dna example that's faster than the Haskell implementation for example.

First of all, you should be careful about using results from the Language Shootout in general, because they often don't know what they're measuring. For example, for quite a while, Haskell scored much higher on the benchmark because the tests were written in such a way that results were computed but then never used; and Haskell compiler is surprisingly good at figuring that out, so it discarded the whole computation part as well. In other words, Haskell tests didn't actually do the same work that C tests did. They've fixed it since then, AFAIK, but many articles on the Web that reference "Haskell beating C in the Shootout" are from before the fix. Here'a a much more realistic and interesting benchmark, in which Haskell didn't exactly do well (so far the best achievement is being 3 times slower than OCaml), despite the problem - ray tracing - being very well suited for functional languages.

The other problem with Haskell is that it is very hard to tell how efficient your code is, both time- and memory-wise, from just looking at it. Because of the pervasive lazy evaluation, "neat" and innocent-looking code can be a performance deathtrap (that classic quicksort implementation in Haskell is one such example). It's extremely easy to get quadratic performance out of something that is defined in the simplest and most concise manner possible, and really shouldn't be more than linear.

What matters is how well Haskell performs in real-world projects. Judging by how Darcs performs, it's pretty meh (how many projects have migrated off Darcs already because of performance reasons? heck, GHC team itself have dropped Darcs in favor of Git!).

Why would LISP be interpreted? (that is your implication, is it not?).

http://www.ffconsultancy.com/languages/ray_tracer/index.html

Scheme (unadorned) is 30% slower that g++.

http://dan.corlan.net/bench.html

Choice quotes from the last page:

" Programming a 1 GHz Pentium [fastest, 1000$, 2002 PC] in Perl is like programming a 10 MHz something [overclocked, 50$, 1982 Z80-based ZX Spectrum] in FORTRAN!

This is no big surprise as we are looking at the classical trade-off between the power of a language (allowing the programmer to express something in a compact way) and the performace of an implementation (which classically was related to the language being close to the machine representation).

However, the huge exception is CommonLisp. Lisp is the most powerful language that is, representing the classical extreme choice for expressive power instead of efficient implementation. ...
For new projects in which one is free to choose the language, one should choose Lisp."

Here's one where Visual Basic .NET beats C:

http://www.fourmilab.ch/fourmilog/archives/2005-09/000588.html

Java beating C:

http://openmap.bbn.com/~kanderso/performance/java/index.html

Of course C is an extremely primitive language. It is possible to (on current hardware) write a C program to best most other systems. But, a proper program is much more difficult!

Perhaps the best thing is that existing Mathematica packages run incredibly well in the new version of Mathematica, much faster and with awesome graphics!

If you want to be serious, take a look at this C++/OCaml raytracer comparison and a random benchmark.

Functional languages will let us utilize multiple cores without the headaches and performance is acceptable, to claim otherwise is plain short-sighted. Programmers are not going to be doing manual memory management or thread handling in application level code.

Please try to read my posts before replying to them.

"When I'm talking about safety vs. flexibility, I'm really talking about the sort of low-level fiddling common in systems programming and high-performance fields. Either you can ignore things like type systems and just twiddle bits and hack memory, or you can't. If you can, your language is flexible in this sense but unsafe. If you can't, your language may be safer, but it will not allow some flexibility. There is a fundamental dichotomy here"

I figured as much. Unsafe pointers are not flexability, they are a way to gain performance. You can still do what you want without them, it just might not perform as well. Flexability is languages like ocaml and nemerle, allowing you to use any programming paradigm you want when you want, and combining powerful features like macros in a sane and usable way. Like I said, this is irrelivant. I asked why you think a well designed language is a language without unsafe pointers. I never said anything about unsafe pointers, and like I said, C has them too, but its well designed. Same with D.

I don't have arguments for fortran and asm. Like I said, you shouldn't use them. Just like you shouldn't use C++. I was just pointing out how from your little vantage point, you see fortran and ASM as ridiculous options that would be awful to use. From the standpoint of anyone who's use a nice language, C++ is right there with fortran and asm.

Yes, fortran can be wrapped up and called from C++. Just like you can write your unsafe, bit twiddling, pointer abusing code in C, and then call it from ocaml which you use for the rest of your code. Use two good languages for the tasks they are good at, instead of using one awful language to try to do both. This is my point.

Again, give me actual concrete reasons why D is not acceptable, but C++ is. D lets you do unsafe things, high performance pointer and bit twiddling tasks, embedded asm, etc, etc. What is the problem? The gnu D compiler should work just fine on your platform, or are you seriously using some ancient 30Mhz motorola 88k based machines or something? Are you really using a platform that gcc doesn't support?

"As for OCaml and getting performance out of functional code, I will simply ask you to provide a single, non-trivial example where this has been shown to be the case."

Several of the examples you just gave of imperative code used functional code. You seem to be confused. You are saying that you are all about the best tool for the job, but yet all ocaml code must be pure functional code for no reason? Ocaml lets you use functional, imperative and OO code all at the same time for a reason. Take this for example:

http://www.ffconsultancy.com/free/ray_tracer/langu ages.html

The code is mostly functional, including recursion. It just has an imperative "main" function with a few for loops in it. Look how little code that is too, its almost like the language was meant to help you instead of hinder you. You are saying that doesn't count because of the imperative main? Even though that's the whole point of ocaml? If you want pure functional try haskell or clean. Clean is a better example of good performance from a pure functional language.

Of course, all this is irrelivant, as I said. The question here is why do you pretend that its ok for C++ to be a pile of shit, and assume that any well designed language must be taking away your precious pointers? Neither C nor D take pointers away from you. They are both nice, well designed languages. Either explain why D is not good enough for you, or stop pretending C++ is magical and that programmers should just start being perfect and never make mistakes again. C++ takes brain power away from doing the job, and puts it on dealing with C++. This is a bad thing, and its why you can do much more in much less time with D, even though its not really higher level.

But what is really missing from your rant is an alternative. It would be the most beautiful rant in the world if it ended with "And it doesn't have to be this way, CSuperDuperDoublePlus does everything C++ does without the problems!".

OCaml gets within a few percentage points of the performance of C/C++, without any of the associated problems.

In some cases it's faster and the code is smaller.

Rich.

You may want to check out OCaml. You can use C++ libraries from it using something like SWIG (and the libraries of other languages too, using something like Pycaml for Python, and there's an interface for Perl too).

Here's a nice comparisong of a ray tracer written in C++ and one written in Ocaml.

And here are many more comparisons and information on why OCaml is so great. :)

Oh, by the way, OCaml is much safer than C++, infinitely more elegant, faster to develop in and more readable.

While C++ is more strongly typed than C, C++ is not type safe. Type safety means that the language ensures that no operation will ever be applied to a variable of the wrong type. However, C++ supports the ability to access arbitrary memory locations, allows type casting, and automatically converts types in many instances. Java is more strongly typed than C++, as it doesn't allow access to arbitrary memory locations, but it also supports casting and automatic conversions, and so is not type safe. If you want type safety, try a language like Ocaml or SPARK Ada.