A Farewell to FRP • Hacker News Board

Re: A Farewell to FRP

#241

Post by SomeCallMeTim » Fri, May 13, 2016, 4:17 AM UTC

Gaelan wrote: post #179

SomeCallMeTim wrote: post #171

Earlier quoted context omitted.

Funny. I managed to get Haskell to crash within about 20 minutes of first trying it out. OCaml is supposed to be pretty fast, but so far Haskell hasn't impressed me with performance either.

What code did you write?

I wrote some code that iteratively would have just taken a while to run, but because Haskell wasn't using true tail recursion, it ran out of stack space.

I also read a paper that talked about extensive research into optimizing a convolutional network algorithm in Haskell, if I remember correctly. The algorithm even used mutable data structures for speed (because of course you need data to be mutable for speed). Roughly speaking, if you ran it on 16 CPUs, it was only 4x slower than the C algorithm running on one CPU. And Amdahl's Law [1] (as well as the graph in the article) hints that it may never actually be faster than the single CPU C version, no matter how many CPUs you split it onto, because of the overhead of sending the data around.

When people claim "immutability makes it easier to run on more threads, which is the future of optimization!" I just want to cringe. Immutability kills most performance enhancements you can possibly make on nontrivial code, even considering a single thread, having all your data be immutable does nothing at all to improve threading, and forcing all data transferred to another thread to be immutable kills a whole category of optimization.

When dealing with large amounts of data, you save tons of time by not copying it around.

/rant

Sorry. I've been listening to too many people talk about Haskell like it's an amazing silver bullet that will solve all of our problems. But There Is No Silver Bullet. Really.

[1] https://en.wikipedia.org/wiki/Amdahl's_law

Re: A Farewell to FRP

#242

Post by garfieldnate » Fri, May 13, 2016, 5:52 AM UTC

naasking wrote: post #212

iamwil wrote: post #188

I found that while things worked once it compiled, I spend most of my time staring at compilation errors, especially as I refactored. So I'm mostly trading time spend debugging subtle state errors with fixing compile type errors. It feels not as productive, since I'm usually looking at errors. Also, I'm still new to FP, so if you go outside of the Elm architecture, you're going to run into problems, which you're use…

> So I'm mostly trading time spend debugging subtle state errors with fixing compile type errors. It feels not as productive, since I'm usually looking at errors. Strange, because debugging subtle state errors seems far more time consuming to me than fixing compile-time errors. You have to launch debugging sessions or insert logging commands and step through reams of code, where compile-time errors tell you exactly w…

I had trouble because the compiler errors were very hard to understand. If your code compiles then yeah, you can step through it. If your code does not compile and you don't understand what the problem is, then you're stuck. This makes me think it would be interesting to have a step-through compiler. I don't know if that even makes sense, but it sounds helpful.

Re: A Farewell to FRP

#243

Post by naasking » Fri, May 13, 2016, 1:08 PM UTC

garfieldnate wrote: post #242

naasking wrote: post #212

Earlier quoted context omitted.

> So I'm mostly trading time spend debugging subtle state errors with fixing compile type errors. It feels not as productive, since I'm usually looking at errors. Strange, because debugging subtle state errors seems far more time consuming to me than fixing compile-time errors. You have to launch debugging sessions or insert logging commands and step through reams of code, where compile-time errors tell you exactly w…

I had trouble because the compiler errors were very hard to understand. If your code compiles then yeah, you can step through it. If your code does not compile and you don't understand what the problem is, then you're stuck. This makes me think it would be interesting to have a step-through compiler. I don't know if that even makes sense, but it sounds helpful.

Haskell has the option to run your code without type checking [1], so this isn't an inherent limitation to type checking.

[1] https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Re: A Farewell to FRP

#244

Post by infinity0 » Fri, May 13, 2016, 6:37 PM UTC

SomeCallMeTim wrote: post #241

Gaelan wrote: post #179

Earlier quoted context omitted.

What code did you write?

I wrote some code that iteratively would have just taken a while to run, but because Haskell wasn't using true tail recursion, it ran out of stack space. I also read a paper that talked about extensive research into optimizing a convolutional network algorithm in Haskell, if I remember correctly. The algorithm even used mutable data structures for speed (because of course you need data to be mutable for speed). Rough…

Well, FWIW worth that's not the primary reason I like those languages. It's the safety.

After some experience with immutable data structures, you know how to make them efficient. For example most of the time you don't need to copy that much data - if you need to change a small part of a large data structure, you arrange it so you can re-use (re-point to) the parts you didn't change. On average you should be able to reduce your cost down to O(log(n)) which usually is "good enough".

That is the correct trade-off IMO - have a newbie start off writing safe code, that gets quicker and less memory intensive with experience. Not start off be blazing quick but unsafe, then add the safety with experience.

Did you know Rust (which defaults to immutable) is currently head-to-head with C in Debian's "fastest languages" comparison?

https://benchmarksgame.alioth.debian.org/u64q/rust.html

Re: A Farewell to FRP

#245

Post by etherealG » Sat, May 14, 2016, 7:36 AM UTC

marcosdumay wrote: post #217

danek wrote: post #196

Earlier quoted context omitted.

I was also confused by it. However I read the last sentence as the author making a meta-point by using purposefully incorrect grammar, a sort of reversal of the first sentence about c++ code compiling but leading to segfault--like an artistic statement. If it was an accident, then all the better!

:) English is not my first language, and it is a rare construct. I thought it was correct. Out of curiosity, how should it read?

Don't worry too much, I always enjoy little gotcha's like this. It's like your brain has to think twice to understand the meaning, but in the end it does. It's really fun and colourful to read half modified phrases and that's how language evolves.

Re: A Farewell to FRP

#246

Post by julian_1 » Mon, May 16, 2016, 3:40 AM UTC

SomeCallMeTim wrote: post #241

Gaelan wrote: post #179

Earlier quoted context omitted.

What code did you write?

I wrote some code that iteratively would have just taken a while to run, but because Haskell wasn't using true tail recursion, it ran out of stack space. I also read a paper that talked about extensive research into optimizing a convolutional network algorithm in Haskell, if I remember correctly. The algorithm even used mutable data structures for speed (because of course you need data to be mutable for speed). Rough…

Haskell is beautiful - including the syntax and typesystem, but the performance claims made for it are ridiculous.

I switched to Ocaml to avoid the un-evalauted thunk and space complexity overhead.

Ocaml also doesn't compete with well written C or C++, but it's a lot more performant than Haskell for general purpose code.