[Haskell-cafe] Haskell vs GC'd imperative languages, threading, parallelizeability (is that a word? :-D )

[Hugh Perkins]

Haskell vs GC'd imperative languages
===========================

On 8/10/07, Thomas Conway <drtomc at gmail.com> wrote:
>
> > Well, C++ is not really competitive with Haskell, because C++ does not
> have
> > a GC, and it's trivial to corrupt the stack/heap.
>
> Beg to differ. I offer the following proof by contradiction. :-)
>
> In my current job, I had a version-1 implementation in Python which
> had severe performance problems, and was not amenable to concurrency
> (The Python interpreter has a global lock, so you can only execute
> python bytecodes from one thread at a time. :-(). The natural
> alternative implementation language was C++, but I argued successfully
> that a Haskell implementation would be significantly easier to make
> concurrent.
>
>
Well, Python is comparable to Haskell to the extent that it has a GC. OTOH
it is interpreted, and, well, slow.  It's also got a Big Lock around the
core system libraries.

Trying to avoid naming it by name, because there's a lot of elitism against
using mainstream languages that are used by "stupid people", but the fastest
imperative GC'd language that I know of is C#.  Even the opensource mono
version is wickedly fast.  The Microsoft version shaves another 20% off
execution speed or so.

See, I get the feeling that a lot of people are using Haskell not because
they compared it to C# and found it better ,but because they compared it to:

- C -> Haskell is easier
- C++ -> Haskell is easier
- Python -> Haskell is faster

C# -> fast and easy ;-)

Threading
=======

I'm not trolling, despite strong appearances to the contrary ;-)  My primary
objective/goal is to find a way to make threading easy.  Thread management
today is like memory management in the early 90s.  We kindof had tools (new,
delete in C++ for example) to do it.  At some point we started to use things
like Smart Pointers to make it easier, but none of it really worked.  Issues
such as circular referential loops caused this not to work very well.

At some point, someone came out with the idea of a garbage collector, which
is really very simple once you know: all it does is walk the graph of
variables, starting with those we know are definitely used, and delete all
those objects that didnt get walked on.  Simple, easy, magic.

We should do the same thing for threads.  Threading is going to become a
major issue soon, maybe not tomorrow, but there is a GPL'd Niagara 2 out
with 64 threads (I think?), so the time is now.

Haskell solves a huge issue with threads, which is locking, which is a total
PITA in imperative languages, it's of the same order of magnitude of problem
as eliminating memory leaks, without deleting something twice etc, used to
be in pre-GC C++.

Nevertheless, one cannot be interested in threads without being interested
in performance.  There's no point in running a program in 1024 threads, if
the single-core C# version runs faster than that, and often it does!

Parallelizeability
============

Now, I did have kindof a shootout thread with Don and Sebastien, calculating
prime numbers, where Don managed to get to within an order of magnitude of
C# performance (I think he got to about 70-80% of C# performance, cool!) ->
BUT, and its a big but ;-), as far as I can tell, he did that by sacrificing
the Haskell ability to be easily parallelized; his solution was essentially
imperative.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070810/5021105f/attachment.htm