Author: Remi Meier <remi.me...@inf.ethz.ch>
Branch: extradoc
Changeset: r5211:94a4f114fe63
Date: 2014-05-02 09:31 +0200
http://bitbucket.org/pypy/extradoc/changeset/94a4f114fe63/
Log: minor changes
diff --git a/talk/icooolps2014/position-paper.tex
b/talk/icooolps2014/position-paper.tex
--- a/talk/icooolps2014/position-paper.tex
+++ b/talk/icooolps2014/position-paper.tex
@@ -123,15 +123,15 @@
\section{Discussion}
-\paragraph{dynamic language VM problems}
-XXX:
-- high allocation rate (short lived objects)\\
-- (don't know anything about the program that runs until it actually runs:
arbitrary atomic block size)
+%% \paragraph{dynamic language VM problems}
+%% XXX:
+%% - high allocation rate (short lived objects)\\
+%% - (don't know anything about the program that runs until it actually runs:
arbitrary atomic block size)
\subsection{Why is there a GIL?}
The GIL is a very simple synchronisation mechanism for supporting
-multi-threading in the interpreter. The basic guarantee is that the
+multithreading in the interpreter. The basic guarantee is that the
GIL may only be released in-between bytecode instructions. The
interpreter can thus rely on complete isolation and atomicity of these
instructions. Additionally, it provides the application with a
@@ -139,7 +139,7 @@
on certain operations to be atomic and that they will always be
executed in the order in which they appear in the code. While
depending on this may not always be a good idea, it is done in
-practice. A solution replacing the GIL should therefore uphold these
+practice. A GIL-replacement should therefore uphold these
guarantees, while preferably also be as easily implementable as a GIL
for the interpreter.
[xxx mention that the interpreter is typically very large and maintained
@@ -151,7 +151,7 @@
thread-safe can voluntarily release the GIL themselves in order to
still provide some parallelism. This is done for example for
potentially long I/O operations. Consequently, I/O-bound,
-multi-threaded applications can actually parallelise to some
+multithreaded applications can actually parallelise to some
degree. Again, a potential solution should be able to integrate with
external libraries with similar ease. We will however focus our
argumentation more on running code in the interpreted language in
@@ -277,9 +277,7 @@
recently gained a lot of popularity by its introduction in common
desktop CPUs from Intel (Haswell generation).
-\paragraph{HTM}
-
-HTM provides us with transactions like any TM system does. It can
+\paragraph{HTM} provides us with transactions like any TM system does. It can
be used as a direct replacement for the GIL. However, as is common
with hardware-only solutions, there are quite a few limitations
that can not be lifted easily. For this comparison, we look at
@@ -304,16 +302,14 @@
synchronisation mechanism for the application. It is not possible
in general to expose the hardware-transactions to the application
in the form of atomic blocks because that would require much
-longer transactions.
+longer transactions.
%% - false-sharing on cache-line level\\
%% - limited capacity (caches, undocumented)\\
%% - random aborts (haswell)\\
%% - generally: transaction-length limited (no atomic blocks)
-\paragraph{STM}
-
-STM provides all the same benefits as HTM except for its performance.
+\paragraph{STM} provides all the same benefits as HTM except for its
performance.
It is not unusual for the overhead introduced by STM to be between
100\% to even 1000\%. While STM systems often scale very well to a big
number of threads and eventually overtake the single-threaded
@@ -347,9 +343,9 @@
& \textbf{GIL} & \textbf{Fine-grained locking}
& \textbf{Shared-nothing} & \textbf{HTM} & \textbf{STM}\\
\hline
- Performance (single-threaded) & ++ & + & ++ & ++ & -{-} \\
+ Performance (single threaded) & ++ & + & ++ & ++ & -{-} \\
\hline
- Performance (multi-threaded) & -{-} & + & + & + & + \\
+ Performance (multithreaded) & -{-} & + & + & + & + \\
\hline
Existing applications & ++ & ++ & -{-} & ++ & ++ \\
\hline
@@ -357,7 +353,7 @@
\hline
Implementation & ++ & - & ++ & ++ & ++ \\
\hline
- External libra\-ries & ++ & ++ & ++ & ++ & ++ \\
+ External libraries & ++ & ++ & ++ & ++ & ++ \\
\hline
\end{tabular}
\caption{Comparison between the approaches (-{-}/-/o/+/++)}
@@ -405,7 +401,7 @@
\acks
-Acknowledgments...
+Acknowledgements...
% We recommend abbrvnat bibliography style.
@@ -423,4 +419,3 @@
\end{document}
-
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
https://mail.python.org/mailman/listinfo/pypy-commit
