git clone https://git.igankevich.com/iccsa-21-guile.git
Log | Files | Refs

commit 211bbed34ac77da0e819b598c06d80dd18a3cd32
parent 221f6d9dbcffc4c237cc010da7a0f5253fc123ed
Author: Ivan Gankevich <i.gankevich@spbu.ru>
Date:   Thu,  6 May 2021 18:14:12 +0300

Title, discussion.

main.tex | 26++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/main.tex b/main.tex @@ -42,14 +42,14 @@ \begin{document} -\title{TODO +\title{Functional programming interface for parallel and distributed computing% \thanks{Supported by Council for grants of the President of the Russian Federation (grant no.~\mbox{MK-383.2020.9}).}} \author{% Ivan Petriakov\orcidID{0000-0001-5835-9313}\and\\ Ivan Gankevich\textsuperscript{*}\orcidID{0000-0001-7067-6928} } -\titlerunning{TODO} +\titlerunning{Functional programming interface} \authorrunning{I.\,Petriakov et al.} \institute{Saint Petersburg State University\\ @@ -621,6 +621,22 @@ in Guile with kernels and in Guile without kernels. \section{Discussion} +Computing procedure arguments in parallel is a natural way of expressing +parallelism in functional language, and in our tests the performance of the +programme is close to the one with manual parallelism. Lower performance is +explained by the fact that we introduce more overhead by using asyncrhonous +kernels to compute procedure arguments where this does not give large +performance gains (even with ideal parallelism with no overhead). If we remove +these overheads we will get the same time as the original programme with manual +parallelism. This is explained by the fact that the main loop of the programme +is written as an application of \texttt{map} form and our interpreter makes it +parallel. Executing this loop in parallel gives the largest performance gains +compared to other parts of the programme. We expect that the difference between +automatic and manual parallelism to be more visible in larger and more complex +programmes, and in future plan to benchmark more algorithms with known parallel +implementations. + + \section{Conclusion} Using procedure arguments to define parallel programme parts gives new @@ -640,6 +656,12 @@ the shortcomings of parallel and distributed computations allowing the programmer to focus on the actual problem being solved rather than fixing bugs in his or her parallel and distributed code. +Future work is to re-implement LISP language features that are relevant for +parallelism in a form of C++ library and use this library for parallelism, but +implement the actual computations in C++. This would allow to improve +performance of purely functional programmes by using the functional language +for parallelism and imperative language for performance-critical code. + \subsubsection*{Acknowledgements.} Research work is supported by Council for grants of the President of the Russian Federation (grant no.~MK-383.2020.9).