commit 211bbed34ac77da0e819b598c06d80dd18a3cd32
parent 221f6d9dbcffc4c237cc010da7a0f5253fc123ed
Author: Ivan Gankevich <i.gankevich@spbu.ru>
Date: Thu, 6 May 2021 18:14:12 +0300
Title, discussion.
Diffstat:
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).
