Parallel reduce: Hopac, Asyncs, Tasks and Scala's Futures
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgR0RD2CaYX8CdCRV2kT47xgtDQrc-4bvKBRQPyUPEeo0pYVUDW9982ail4n7rvS6rzecAH0Tsz0IRBvBd6DJR5x4Ga1jUpNGkNavKQg9fEdb22dLlJ68wl5TnmAeEkR1RC3a8-qSAhKNoX/s1600/%D0%91%D0%B5%D0%B7%D1%8B%D0%BC%D1%8F%D0%BD%D0%BD%D1%8B%D0%B9.png)
Tuomas Hietanen posted a parallel reduce function that uses TPL Tasks. I found it interesting to compare performance of this function with analogues implemented using F# Asyncs, Hopac Jobs and Scala Futures. The author uses noop long-running reduce function to show that it's really run in parallel. In this blog post we are benchmarking another aspect of the implementations: how much extra cost is introduced by a particular parallezation mechanism (library) itself. We translate the original code almost as is to Tasks and Hopac: And Scala's Futures: The results (Core i5, 4 cores): Sequential List.reduce: Real: 00:00:00.014, CPU: 00:00:00.015, GC gen0: 0, gen1: 0, gen2: 0 Tasks: Real: 00:00:01.790, CPU: 00:00:05.678, GC gen0: 36, gen1: 10, gen2: 1 Hopac: Real: 00:00:00.514, CPU: 00:00:01.482, GC gen0: 27, gen1: 2, gen2: 1 Asyncs: Real: 00:00:37.872, CPU: 00:01:48.405, GC gen0: 90, gen1: 29, gen2: 4 Scala Futures: 4.8 seconds (Hopac - 3.4 time