11–20 of 34 posts
I have not fully digested yet, but seems very similar to Scala Parallel Collections and Java8 Streams. There are databases which implements such interfaces.
How does this differ from BEAM langs which already make concurrency "unreasonably easy"?
For another, they operate via different interfaces. BEAM languages communicate concurrently only via a message passing interface. Haxl lets the author write declarative code specifying what to retrieve, then the library executes it concurrently and in parallel under-the-hood.
Both are properly described as "unreasonably easy" - just for different sorts of things, on different platforms, with different interfaces.
I wonder how long it will be before compilers/interpreters of async-aware languages just do this by default. CPUs and low-level language compilers jump through all kinds of hoops of out-of-order execution, branch prediction, caching, parallel execution, etc. I picture a day maybe 10 years from now where developers in most languages don't even have to think about these things. All the old-timers will still be structur…
Even in Haskell you still have to write some boilerplate to get this by default. Languages that don't separate pure computation from IO (and other side-effects) make it even harder on the compiler. So to answer your question: implementations will do this by default only after pure/constant will become the default for all functions/variables, with side-effecting/mutable clearly marked.
If one looks at things from a 'any technical task can be handled by machine learning, sooner or later' point of view, there seems to be no obvious reason why parallelization, which is a purely technical task, not like say, writing music, could not sooner or later be handled by machine learning algorithms?
I wonder how long it will be before compilers/interpreters of async-aware languages just do this by default. CPUs and low-level language compilers jump through all kinds of hoops of out-of-order execution, branch prediction, caching, parallel execution, etc. I picture a day maybe 10 years from now where developers in most languages don't even have to think about these things. All the old-timers will still be structur…
However for our use case at LumiGuide (reading and writing registers of modbus devices) it wasn't simple enough. We just needed an abstraction for batching and did not need caching and the other features Haxl provides.
So I wrote monad-batcher which as the name implies only provides a batching abstraction (which can also be used to execute commands concurrently). All the other features can be build on top of monad-batcher as separate layers (separation of concerns).
The library is available on Hackage but needs a bit more documentation (a tutorial would be nice):
I wonder how long it will be before compilers/interpreters of async-aware languages just do this by default. CPUs and low-level language compilers jump through all kinds of hoops of out-of-order execution, branch prediction, caching, parallel execution, etc. I picture a day maybe 10 years from now where developers in most languages don't even have to think about these things. All the old-timers will still be structur…
It's unsafe for a compiler to do this in general (i.e. without annotations) because it can't determine dependencies that are external to the program -- e.g. `one=get(); two=get()`. The dependency between one and two is not obvious to a compiler when IO is involved, so it has to assume the two `gets' has to be executed sequentially.
I wonder how long it will be before compilers/interpreters of async-aware languages just do this by default. CPUs and low-level language compilers jump through all kinds of hoops of out-of-order execution, branch prediction, caching, parallel execution, etc. I picture a day maybe 10 years from now where developers in most languages don't even have to think about these things. All the old-timers will still be structur…
It's unsafe for a compiler to do this in general (i.e. without annotations) because it can't determine dependencies that are external to the program -- e.g. `one=get(); two=get()`. The dependency between one and two is not obvious to a compiler when IO is involved, so it has to assume the two `gets' has to be executed sequentially.
As I understood the talk, Haxl doesn't address this either. It depends on you describing an IO operation as a type with set of functionality that can be used to identify those dependencies.
> e.g. `one=get(); two=get()`. The dependency between one and two is not obvious to a compiler when IO is involved, so it has to assume the two `gets' has to be executed sequentially.
A "pure" language will address a lot of this due to referential transparency. Which is to say that if `get` takes no arguments, its instructions for where and how to perform an IO operation are entirely static. Given your literal example, the only way the result could be different is if there were some side effect or if a source of data required by `get` could change during execution time.
Haxl's takes this a bit further by suggesting that if you are performing the same IO request twice "at the same time", you expect to get the same result both times, so it memoizes the request for the duration of your set of IO operations.
Within a `do`, as far as I could grok from the talk and glancing at documentation; it's worth noting I don't know Haskell and have never heard of Haxl before today.
I looked through the slides but not the video and the slides ignore the hard problem: how do you schedule these requests? How do you know how many parallel requests you can issue without hammering the database or service? How do you batch queries so that you get acceptable latency and a query size that will not choke the database? The last question is probably easy for most use cases where you have independent reques…
I think the idea is that with the Haxl approach the scheduling can be dealt with independently from your business logic. By the way, I don't see how Church-Rosser would give you any free parallelism---even in theory. You'd still have to heed Guy Steele's advice (see https://vimeo.com/6624203 ).
Church-Rosser theorem means that all possible reduction sequences lead to the same normal form, so you can β reduce the subterms in parallel.
If you look at Paul Hudak's and SPJ's publications from the late 1980s and early 1990s many of them are actually about trying to exploit this implicit parallelism:
http://sunsite.informatik.rwth-aachen.de/dblp/db/indices/a-t...
http://dblp.uni-trier.de/pers/hd/h/Hudak:Paul
https://pdfs.semanticscholar.org/8912/5be7f9c222793c18b99d06...
This turns out to be a hard problem and fell out of fashion as a research topic. The big problem is managing overhead. There has been some recent work to try to incorporate automatic profiling feedback to adjust the parallelism granularity:
http://dominic-mulligan.co.uk/wp-content/uploads/2015/05/S-R...
I wonder how long it will be before compilers/interpreters of async-aware languages just do this by default. CPUs and low-level language compilers jump through all kinds of hoops of out-of-order execution, branch prediction, caching, parallel execution, etc. I picture a day maybe 10 years from now where developers in most languages don't even have to think about these things. All the old-timers will still be structur…
I wonder how long it will be before compilers/interpreters of async-aware languages just do this by default. CPUs and low-level language compilers jump through all kinds of hoops of out-of-order execution, branch prediction, caching, parallel execution, etc. I picture a day maybe 10 years from now where developers in most languages don't even have to think about these things. All the old-timers will still be structur…
Analysis of real software that has looked for the maximum theoretical implicit concurrency has found that software to have its implicit concurrency level top out very quickly, often not even making it up to 2x. You don't hear about this today not because nobody has tried it, but because it's been tried and it hasn't been found worth the bother. Amdahl's law is a real jerk sometimes. If you want concurrent code, you'r…