11–20 of 24 posts
Earlier quoted context omitted.
So... a Haskell approach?
I'm not very literate with Haskell, but didn't OP have to do a quirky hack with reading the length of the file into the void in order to get rid of open file handles? That doesn't seem to me like Haskell is well designed at letting me take over resource management if the need arises.
Earlier quoted context omitted.
Laziness (lazy IO, in this case) has nothing to do with a language being functional or not. It has everything to do with a language being strict or lazy. There are strict functional languages. Most are, in fact.
Lazy/strict is just one property that can be problematic in a high performance context. The biggest one to me is mutability. Basically it's a simple test: Can I swap pointers? (e.g. 'model_current' and 'model_next_timestep'). If not, I can't use it, it would slow down numerical solvers tremendously to allocate and free the required memory for each step. However, if I can just have the time iteration in an imperative…
I suspect HPC will always be more gnarly than elegant, since by definition HPC is about spending money on making code go fast in very specialized apps.
Earlier quoted context omitted.
So... a Haskell approach?
I'm not very literate with Haskell, but didn't OP have to do a quirky hack with reading the length of the file into the void in order to get rid of open file handles? That doesn't seem to me like Haskell is well designed at letting me take over resource management if the need arises.
There are real non-brittle solutions to streaming I/O, pipes[1], conduit[2], or io-streams[3] being the most popular AFAICT. (The latter is probably the easiest to use, but is somewhat less 'composable' than the other two, especially if you have monad transformer stacks, etc.) Either that, or just use strict I/O if you're just working with smallish files.
Essentially lazy I/O was a mistake that's unfortunately very hard to fix nowadays without presumably breaking a lot of working-but-potentially-brittle code. Perhaps the time is ripe for starting to actually deprecate them officially... at least almost everyone in the Haskell community seems to agree that it was a mistake and they are a constant trap for newbies.
[1] http://hackage.haskell.org/package/pipes
Earlier quoted context omitted.
Lazy/strict is just one property that can be problematic in a high performance context. The biggest one to me is mutability. Basically it's a simple test: Can I swap pointers? (e.g. 'model_current' and 'model_next_timestep'). If not, I can't use it, it would slow down numerical solvers tremendously to allocate and free the required memory for each step. However, if I can just have the time iteration in an imperative…
There are various ways get the effect (with similar space and performance chacteristic), but there are different approaches for different FP languages. For example, persistent data structures, non-pure primitives (eg Clojure's atoms), monads, etc. For Haskell, these sound relevant if you're set on using strict dense matrices: https://wiki.haskell.org/Monad/ST https://hackage.haskell.org/package/bed-and-breakfast I su…
Earlier quoted context omitted.
There are various ways get the effect (with similar space and performance chacteristic), but there are different approaches for different FP languages. For example, persistent data structures, non-pure primitives (eg Clojure's atoms), monads, etc. For Haskell, these sound relevant if you're set on using strict dense matrices: https://wiki.haskell.org/Monad/ST https://hackage.haskell.org/package/bed-and-breakfast I su…
could you expand on persistent data structures? How do they give me 'free' memory with neither allocation nor mutable data? Or is that outside of pure FP?
Here's a good start about Clojure's persistent vector: http://hypirion.com/musings/understanding-persistent-vector-...
> Putting too many functions that are relatively complex in the where clause is a bad idea, because you lose the explicit type signature… Note that it’s possible to give type signatures for definitions in “where” clauses: twice :: Int -> Int twice x = two * x where two :: Int two = 2 However, you may need the ScopedTypeVariables extension[1] in order to be able to express the correct type signature. (This extension w…
For me it's always a toss up. I like to make things local where possible to give some indication that the definitions need not be looked over with a fine-toothed comb -- they aren't used extensively. On the other hand, it does often lead to implicit dependencies. It would be nice to have scope highlighting - color every identifier based on the distance from the scope it's defined in. This idea shamelessly stolen from Doug Crockford in https://www.youtube.com/watch?v=b0EF0VTs9Dc
The author of "corrode"[1] wrote it in Haskell because there already was a C parser available. As always, the importance of libraries.
[1]: http://jamey.thesharps.us/2016/10/corrode-update-support-fro...
Earlier quoted context omitted.
I'm not very literate with Haskell, but didn't OP have to do a quirky hack with reading the length of the file into the void in order to get rid of open file handles? That doesn't seem to me like Haskell is well designed at letting me take over resource management if the need arises.
It's easily avoided: Just never use the lazy I/O functions. (Not sure if hlint perhaps has a warning you can apply here. It probably should.) There are real non-brittle solutions to streaming I/O, pipes[1], conduit[2], or io-streams[3] being the most popular AFAICT. (The latter is probably the easiest to use, but is somewhat less 'composable' than the other two, especially if you have monad transformer stacks, etc.)…
Earlier quoted context omitted.
It's easily avoided: Just never use the lazy I/O functions. (Not sure if hlint perhaps has a warning you can apply here. It probably should.) There are real non-brittle solutions to streaming I/O, pipes[1], conduit[2], or io-streams[3] being the most popular AFAICT. (The latter is probably the easiest to use, but is somewhat less 'composable' than the other two, especially if you have monad transformer stacks, etc.)…
I wouldn't want to see lazy IO disappear altogether because if you are just processing a file line by line then its a quick and dirty solution that will work fine in practice. However I agree it should come with health warnings and pointers to more scaleable solutions.
Earlier quoted context omitted.
Laziness (lazy IO, in this case) has nothing to do with a language being functional or not. It has everything to do with a language being strict or lazy. There are strict functional languages. Most are, in fact.
Lazy/strict is just one property that can be problematic in a high performance context. The biggest one to me is mutability. Basically it's a simple test: Can I swap pointers? (e.g. 'model_current' and 'model_next_timestep'). If not, I can't use it, it would slow down numerical solvers tremendously to allocate and free the required memory for each step. However, if I can just have the time iteration in an imperative…