commit 2a3e42b7b284bc9eb4ef861a324cb1995ac24977
parent 6014a65251290ae396840d28a7884059d2389d12
Author: Ivan Gankevich <i.gankevich@spbu.ru>
Date: Mon, 12 Apr 2021 15:00:43 +0300
paper
Diffstat:
4 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
@@ -14,6 +14,7 @@ all: build/Petriakov-Guile.pdf
all: build/iccsa-21-guile-slides.pdf
build/main.pdf: main.tex
+build/main.pdf: main.bib
build/main.pdf:
@echo " LATEX $<"
@-$(LATEXMK) $(FLAGS) -f main.tex
diff --git a/main.bib b/main.bib
@@ -1,7 +1,7 @@
@InProceedings{llvm,
author = {Lattner, Chris and Adve, Vikram},
- title = {LLVM: A Compilation Framework for Lifelong Program Analysis
+ title = {{LLVM}: A Compilation Framework for Lifelong Program Analysis
\& Transformation},
year = {2004},
isbn = {0769521029},
@@ -11,5 +11,5 @@
and Optimization: Feedback-Directed and Runtime Optimization},
pages = {75},
location = {Palo Alto, California},
- series = {CGO '04}
+ series = {CGO'04}
}
diff --git a/main.tex b/main.tex
@@ -53,19 +53,39 @@ ability to communicate between parallel processes. This communication is the
common denominator on top of which all the frameworks are built, and there is
no universal low-level protocol or language that describes communication.
-TODO expand
+Why such low-level language exists for sequential computations, but does not
+exist for parallel and distributed ones? One of the reasons, which applies to
+both distributed and parallel computations, is the fact that people still think
+about programmes as sequences of steps~--- the same way as people themselves
+perform complex tasks. Imperative languages, in which programmes are written
+as series of steps, are still prevalent in industry and academia; this is in
+contrast to unpopular functional languages in which programmes are written as
+compositions of functions with no implied order of computation. Another reason
+which applies to distributed computations is the fact that these computations
+are inherently unreliable and there is no universal approach for handling
+cluster node failures. While imperative langauges produce more efficient
+programmes, they do not provide safety from deadlocks and fault-tolerance
+guarantees. Also, they are much more difficult to write, as a human have to
+work with mutable state (local and global variables, objects etc.) and it is
+difficult to keep this state in mind while writing the code. Functional
+languages minimise the usage of mutable state, provide partial safety from
+deadlocks (under the assumption that a programmer does not use low-level
+facilities) and can be modified to provide fault tolerance. People understand
+the potential of functional languages, but have not yet realised this potential
+to get all their advantages; people realised the full potential of imperative
+languages, but do not know how to get rid of their disadvantages.
In this paper we describe low-level language and protocol called \emph{kernels}
-which is suitable for distributed and parallel computations. We implement
-kernels in C++ and build a reference cluster scheduler that uses kernels as the
-protocol to run applications that span multiple cluster nodes. Then we use
-kernels as an intermediate representation for Guile programming language, run
-benchmarks using the scheduler and compare the performance of different
-implementations of the same programme.
-
-Spark
-
-Distributed Haskell
+which is suitable for distributed and parallel computations. Kernels provide
+automatic fault-tolerance and can be used to exchange the data between
+programmes written in different languages. We implement kernels in C++ and
+build a reference cluster scheduler that uses kernels as the protocol to run
+applications that span multiple cluster nodes. Then we use kernels as an
+intermediate representation for Guile programming language, run benchmarks
+using the scheduler and compare the performance of different implementations of
+the same programme.
+
+TODO Spark, Distributed Haskell
diff --git a/papers/1932682.1869527.pdf b/papers/1932682.1869527.pdf
@@ -0,0 +1 @@
+../.git/annex/objects/px/Mj/SHA256E-s819318--b9008f326fc1359fb1703c9688dc9797e60c9b4e55e2b594ba42e920e0747b2d.pdf/SHA256E-s819318--b9008f326fc1359fb1703c9688dc9797e60c9b4e55e2b594ba42e920e0747b2d.pdf+
\ No newline at end of file