5 ms·

I don't see the relation to Lisp, if anything that quote about noticing the semigroup property of parallel fold algorithms speaks to Haskell or ML more than any

by leshow 10y ago

I don't see the relation to Lisp, if anything that quote about noticing the semigroup property of parallel fold algorithms speaks to Haskell or ML more than anything else.

sedachv 10y ago
A lot of early research into parallel algorithms and exploiting associativity for parallelism started at Thinking Machines, a Lisp supercomputer company. Hillis and Steele's 1986 paper in CACM is still one of the best introductions to the subject: http://cva.stanford.edu/classes/cs99s/papers/hillis-steele-data-parallel-algorithms.pdf http://cva.stanford.edu/classes/cs99s/papers/hillis-steele-d...
- lispm 10y ago
  There was quite a lot research into parallel, concurrent and distributed Lisps beginning in the 80s. Thinking Machines with its SIMD computer was just one approach. At some point in time there was a lot of money available for that stuff, including custom hardware. In the US the DoD paid and you can bet that some military/intelligence applications were based on exotic multiprocessor machines running Lisp. http://www.softwarepreservation.org/projects/LISP/parallel http://www.softwarepreservation.org/projects/LISP/parallel Often parallel computers had also a Lisp implementation. Much more than listed above. Parallel Computation and Computers for Artificial Intelligence http://link.springer.com/book/10.1007/978-1-4613-1989-4 http://link.springer.com/book/10.1007/978-1-4613-1989-4 Parallel Lisp: Languages and Systems http://link.springer.com/book/10.1007/BFb0024148 http://link.springer.com/book/10.1007/BFb0024148 Parallel Symbolic Computing: Languages, Systems, and Applications http://link.springer.com/book/10.1007/BFb0018643/page/1 http://link.springer.com/book/10.1007/BFb0018643/page/1
cjhanks 10y ago
C++ programmers using a lot templates have a lot in common with Haskell programmers. Often I will write static methods like.. template<typename Scalar, typename Functor> auto DoSomething(Scalar value, std::size_t k) -> decltype(Functor(Scalar(0)) { ... Functor(value / Scalar(k)); ... } Even though it will probably only be used once. Simply because I don't know what types I am going to need yet... but I know it might need a few operators `+`, `-`, `*`, `/`. Once I figure that out, the code is ready to go and is as fast as anything hand written. If somebody could ever write a great 'Haskell for C++ MetaProgrammers' book describing how you are supposed to understand binary layout, IO, and wtf those hundreds of operators mean... you would probably have a bunch of programmers saying "Oh, I guess I know Haskell". It's also no surprise that a bunch of the STL algorithms structures were easily made parallel in C++17. A lot of developers using the STL correctly could basically change a few lines of code and switch their program from sequential to parallel.
- hellofunk 10y ago
  Are you referring to adding an execution policy to many of the STL fn calls?

by leshow 10y ago

I don't see the relation to Lisp, if anything that quote about noticing the semigroup property of parallel fold algorithms speaks to Haskell or ML more than anything else.

sedachv 10y ago

A lot of early research into parallel algorithms and exploiting associativity for parallelism started at Thinking Machines, a Lisp supercomputer company. Hillis and Steele's 1986 paper in CACM is still one of the best introductions to the subject: http://cva.stanford.edu/classes/cs99s/papers/hillis-steele-data-parallel-algorithms.pdf http://cva.stanford.edu/classes/cs99s/papers/hillis-steele-d...

lispm 10y ago
There was quite a lot research into parallel, concurrent and distributed Lisps beginning in the 80s. Thinking Machines with its SIMD computer was just one approach. At some point in time there was a lot of money available for that stuff, including custom hardware. In the US the DoD paid and you can bet that some military/intelligence applications were based on exotic multiprocessor machines running Lisp. http://www.softwarepreservation.org/projects/LISP/parallel http://www.softwarepreservation.org/projects/LISP/parallel Often parallel computers had also a Lisp implementation. Much more than listed above. Parallel Computation and Computers for Artificial Intelligence http://link.springer.com/book/10.1007/978-1-4613-1989-4 http://link.springer.com/book/10.1007/978-1-4613-1989-4 Parallel Lisp: Languages and Systems http://link.springer.com/book/10.1007/BFb0024148 http://link.springer.com/book/10.1007/BFb0024148 Parallel Symbolic Computing: Languages, Systems, and Applications http://link.springer.com/book/10.1007/BFb0018643/page/1 http://link.springer.com/book/10.1007/BFb0018643/page/1

cjhanks 10y ago

C++ programmers using a lot templates have a lot in common with Haskell programmers. Often I will write static methods like.. template<typename Scalar, typename Functor> auto DoSomething(Scalar value, std::size_t k) -> decltype(Functor(Scalar(0)) { ... Functor(value / Scalar(k)); ... } Even though it will probably only be used once. Simply because I don't know what types I am going to need yet... but I know it might need a few operators `+`, `-`, `*`, `/`. Once I figure that out, the code is ready to go and is as fast as anything hand written. If somebody could ever write a great 'Haskell for C++ MetaProgrammers' book describing how you are supposed to understand binary layout, IO, and wtf those hundreds of operators mean... you would probably have a bunch of programmers saying "Oh, I guess I know Haskell". It's also no surprise that a bunch of the STL algorithms structures were easily made parallel in C++17. A lot of developers using the STL correctly could basically change a few lines of code and switch their program from sequential to parallel.

hellofunk 10y ago
Are you referring to adding an execution policy to many of the STL fn calls?