Is Haskell the Cure? • Hacker News Board

Re: Is Haskell the Cure?

#81

Post by gvb » Mon, Oct 03, 2011, 11:21 PM UTC

lobster_johnson wrote: post #54

gvb wrote: post #32

Why is a Fibonacci sequence used as a benchmark for an argument for concurrent programming? The Fibonacci sequence is a recursive algorithm that inherently has dependencies on previous calculations that prevent effective concurrent execution. The Fibonacci algorithm executed concurrently is going to spend an inordinate amount of time creating tasks that do a trivial calculation (add two numbers together). If you want…

He was not benchmarking concurrency, he was pointing out that Node is single-threaded system that essentially implements the old-style cooperative multitasking, where a single task will block everything else. He could have used sleep() and it would have illustrated the same point (and more elegantly, since half of the responses miss the point entirely and focus on the Fibonacci part). Node developers probably don't d…

But he isn't benchmarking web server concurrency because he is doing a single curl

  $ time curl http://localhost:8000
  165580141
  real 0m0.016s
  user 0m0.007s
  sys 0m0.005s

So he is running the Fibonacci (40) once with the web server. The only concurrency / parallelism that is happening is in the recursive Fibonacci algorithm. I stand by my contention that the Fibonacci algorithm is a very poor test of concurrency / parallelism.

I stand by my contention that he should have implemented an algorithm that could be solved in concurrent pieces and then benchmarked node.js against his favorite language. If the algorithm cannot be parallelized effectively, it doesn't matter how many tasks you spawn to solve it (cooperative or otherwise), the algorithm's dependencies will cause all the tasks to block and effectively serialize their execution.

Re: Is Haskell the Cure?

#82

Post by gregwebs » Tue, Oct 04, 2011, 12:24 AM UTC

the_mat wrote: post #74

gregwebs wrote: post #43

Earlier quoted context omitted.

That post is from 2005. The situation is entirely different today w/respect to speed (both the compiler and the addition of ByteString and Text libraries), and productive libraries, particularly for web development. Likewise, it is a rare case that you would run into memory consumption issues. I do agree that there is entirely too much enthusiastic toying around in Haskell and not enough real world users and honesty…

To me, there's a dichotomy between the "if it compiles, it usually works" aspect of Haskell (and how this is often touted as superior to the dynamic typing, test-driven approach) and that you can't get a picture of memory usage until you run and profile the code. In my experience, hard to understand memory consumption issues are common and take effort to solve. Reference: http://blog.ezyang.com/2011/06/pinpointing-sp…

That blog post says nothing about frequency of memory leaks, but shows that there are good tools to help you in your effort to solve them. One thing to keep in mind is that there are memory issues with every language. I just debugged one in Ruby yesterday, and there wasn't a good tool readily available for that effort. Do you know what the memory consumption of your programs are in other languages are before running them?

As a contradictory anecdote, I have never once had a memory consumption issue with Haskell code. Haskell is actually in a nice position w/respect to memory now that enumerators (which always use constant memory) are taking hold. I have no doubt you encountered many memory leaks, but I don't think your experience completely generalises to modern Haskell.

Re: Is Haskell the Cure?

#83

Post by artsrc » Tue, Oct 04, 2011, 12:57 AM UTC

numeromancer wrote: post #40

agentultra wrote: post #16

I don't think Haskell itself is really the answer. If I read the article correctly it's simply a matter of concurrency and parallelism that's important. There are a host of languages that do that quite well and Haskell just happens to be one of them.

I don't think Haskell itself is really the answer. What was the question?

No one has characterized the right task scheduling outcome.

What tool will give us the the best task scheduling outcome, with appropriate effort?

Node schedules each task to run until it is done or you tell it to do something else. This seems simple and honest. The impact of excessive CPU load is obvious.

Other tools offer automatic task preemption and time slicing between tasks. Once CPU load gets high the impact is much less obvious.

Re: Is Haskell the Cure?

#84

Post by jrockway » Tue, Oct 04, 2011, 4:06 AM UTC

jrockway wrote: post #78

microtonal wrote: post #63

Earlier quoted context omitted.

Explain? What would the alternative be? Box the value that is the result of evaluation an expression that calls impure code in IO? This is what I'd expect for calling impure code in third-party libraries.

If the library developer can prove that a C operation is pure, why shouldn't he tell Haskell about that?

And if you don't trust the developer, it's easy to fix his mistake:

    unUnsafePerformIO :: a -> IO a
    unUnsafePerformIO = return

Re: Is Haskell the Cure?

#85

Post by ezyang » Tue, Oct 04, 2011, 6:32 AM UTC

jrockway wrote: post #84

jrockway wrote: post #78

Earlier quoted context omitted.

If the library developer can prove that a C operation is pure, why shouldn't he tell Haskell about that?

And if you don't trust the developer, it's easy to fix his mistake: unUnsafePerformIO :: a -> IO a unUnsafePerformIO = return

Sorry, that doesn't actually work.

    ezyang@ezyang:~$ cat Test.hs
    import System.IO.Unsafe
    unUnsafePerformIO = return
    main = do
      let a = unUnsafePerformIO (unsafePerformIO (putStrLn "boom"))
      a
      a
    ezyang@ezyang:~$ runghc Test.hs
    ezyang@ezyang:~$

Re: Is Haskell the Cure?

#86

Post by lobster_johnson » Tue, Oct 04, 2011, 8:33 AM UTC

gvb wrote: post #81

lobster_johnson wrote: post #54

Earlier quoted context omitted.

He was not benchmarking concurrency, he was pointing out that Node is single-threaded system that essentially implements the old-style cooperative multitasking, where a single task will block everything else. He could have used sleep() and it would have illustrated the same point (and more elegantly, since half of the responses miss the point entirely and focus on the Fibonacci part). Node developers probably don't d…

But he isn't benchmarking web server concurrency because he is doing a single curl $ time curl http://localhost:8000 165580141 real 0m0.016s user 0m0.007s sys 0m0.005s So he is running the Fibonacci (40) once with the web server. The only concurrency / parallelism that is happening is in the recursive Fibonacci algorithm. I stand by my contention that the Fibonacci algorithm is a very poor test of concurrency / paral…

I'm referring to the original post (http://teddziuba.com/2011/10/node-js-is-cancer.html), which did test concurrency. The Haskell guy missed the point entirely and seems to have given up after Haskell is shown to memoize his function.

Re: Is Haskell the Cure?

#87

Post by thesz » Tue, Oct 04, 2011, 10:38 AM UTC

microtonal wrote: post #48

thesz wrote: post #46

Earlier quoted context omitted.

Why use quicksort over arrays when you can do mergesort over lists and get 1) stable behavior and 2) solution to maximum and k-max problems due to laziness? Do you really need arrays? And quicksort for arrays in ST monad wouldn't copy anything unnecessary. Actually, I've seen many claims that some algorithms are inherently mutable. So far none stand close scrutiny. Matrix operations? You better copy intermediate resu…

Why use quicksort over arrays when you can do mergesort over lists Sure, you can do merge sort. Except that the list split step in Haskell is O(n) in time, while it is constant when using arrays. As well as merging lists, since you have to 'reattach' the second list as the tail of the first list. And quicksort for arrays in ST monad wouldn't copy anything unnecessary. You have to copy the data from whatever represent…

>Except that the list split step in Haskell is O(n) in time, while it is constant when using arrays.

Oh, no. You shouldn't split list by calculating length.

Try this instead:

   even (x:_:xs) = x : even xs
   even xs = xs
   odd = even . drop 1

   splitList xs = (even xs, odd xs)

Voila! Completely lazy, O(1).

So for merge. See here: http://lambda-the-ultimate.org/node/608?from=0&comments_... The solution contains proper merge algorithm.

And yes, I never read Okasaki in full. But, I use Haskell semi-professionally from 1999 and professionally from 2006.

Re: Is Haskell the Cure?

#88

Post by jrockway » Tue, Oct 04, 2011, 3:07 PM UTC

ezyang wrote: post #85

jrockway wrote: post #84

Earlier quoted context omitted.

And if you don't trust the developer, it's easy to fix his mistake: unUnsafePerformIO :: a -> IO a unUnsafePerformIO = return

Sorry, that doesn't actually work. ezyang@ezyang:~$ cat Test.hs import System.IO.Unsafe unUnsafePerformIO = return main = do let a = unUnsafePerformIO (unsafePerformIO (putStrLn "boom")) a a ezyang@ezyang:~$ runghc Test.hs ezyang@ezyang:~$

Yes, true. Patch the library if the annotation is wrong :)

Re: Is Haskell the Cure?

#89

Post by gtani » Tue, Oct 04, 2011, 4:07 PM UTC

pjscott wrote: post #80

gregwebs wrote: post #47

Earlier quoted context omitted.

The biggest reason why there are Haskell packages wrapping C libraries is not for performance, but to reuse good C libraries, and because Haskell has an excellent interface for C libraries. Many people prefer to write Haskell for computationally intensive tasks than C/C++. Depending on the problem it is possible to get within 2x the raw speed of C and you much nicer code to maintain and much easier concurrency/parall…

In case anybody is wondering: both Erlang and Haskell have very lightweight user-space threads built in, which are mapped onto a small pool of OS threads to take advantage of however many cores you have. It's very slick and fast, and probably the Right Thing.

Yes, there's also akka which is being incorporated as scala standard lib, and F# MailboxProcessor. The thing is that erlang/OTP and its behaviors have many people pounding on heavily loaded apps in production and improving its toolchain, whereas GHC and akka have recently (last couple years I think) been working ot get the stack working: dispatchers and load balancing (like erland reds), and bring GC up to snuff

Re: Is Haskell the Cure?

#90

Post by pjscott » Wed, Oct 05, 2011, 12:05 AM UTC

gtani wrote: post #89

pjscott wrote: post #80

Earlier quoted context omitted.

In case anybody is wondering: both Erlang and Haskell have very lightweight user-space threads built in, which are mapped onto a small pool of OS threads to take advantage of however many cores you have. It's very slick and fast, and probably the Right Thing.

Yes, there's also akka which is being incorporated as scala standard lib, and F# MailboxProcessor. The thing is that erlang/OTP and its behaviors have many people pounding on heavily loaded apps in production and improving its toolchain, whereas GHC and akka have recently (last couple years I think) been working ot get the stack working: dispatchers and load balancing (like erland reds), and bring GC up to snuff

Akka looks pretty sweet, but it looks like you still have to worry about blocking code in external libraries. In Haskell (and Erlang, IIRC), blocking code is deferred to a background thread automatically so you don't have to be consciously on-guard for it. You also get proper pre-emptive multithreading, while Akka looks like a hybrid of an event loop and a thread pool.

Is this a substantial headache with Akka, in practice?