paper update

1 files changed, 35 insertions, 6 deletions

diff --git a/docs/paper.tex b/docs/paper.tex
index 4bb8b267..82b99336 100644
--- a/docs/paper.tex
+++ b/docs/paper.tex
@@ -683,6 +683,40 @@ improve the speed as well, as are improvements to LLVM, the Closure
 Compiler, and JavaScript engines themselves; see further discussion
 in the Summary.
 
+\subsection{Limitations}
+
+Emscripten's compilation approach, as has been described in this Section so far,
+is to generate `natural' JavaScript, as close as possible to normal JavaScript
+on the web, so that modern JavaScript engines perform well on it. In particular,
+we try to generate `normal' JavaScript operations, like regular addition and
+multiplication and so forth. This is a very
+different approach than, say, emulating a CPU on a low level, or for the case
+of LLVM, writing an LLVM bitcode interpreter in JavaScript. The latter approach
+has the benefit of being able to run virtually any compiled code, at the cost
+of speed, whereas Emscripten makes a tradeoff in the other direction. We will
+now give a summary of some of the limitations of Emscripten's approach.
+
+\begin{itemize}
+\item \textbf{64-bit Integers}: JavaScript numbers are all 64-bit doubles, with engines
+      typically implementing them as 32-bit integers where possible for speed.
+      A consequence of this is that it is impossible to directly implement
+      64-bit integers in JavaScript, as integer values larger than 32 bits will become doubles,
+      with only 53 bits for the significand. Thus, when Emscripten uses normal
+      JavaScript addition and so forth for 64-bit integers, it runs the risk of
+      rounding effects. This could be solved by emulating 64-bit integers,
+      but it would be much slower than native code.
+\item \textbf{Multithreading}: JavaScript has Web Workers, which are additional
+      threads (or processes) that communicate via message passing. There is no
+      shared state in this model, which means that it is not directly possible
+      to compile multithreaded code in C++ into JavaScript. A partial solution
+      could be to emulate threads, without Workers, by manually controlling
+      which blocks of code run (a variation on the switch in a loop construction
+      mentioned earlier) and manually switching between threads every so often.
+      However, in that case there would not be any utilization
+      of additional CPU cores, and furthermore performance would be slow due to not
+      using normal JavaScript loops.
+\end{itemize}
+
 \section{Emscripten's Architecture}
 \label{sec:emarch}
 
@@ -997,12 +1031,7 @@ things, compile real-world C and C++ code and run that on the web. In
 addition, by compiling the runtimes of languages which are implemented in C and C++,
 we can run them on the web as well, for example Python and Lua.
 
-Important future tasks for Emscripten are to broaden its
-standard library and to support additional types of code, such as
-multithreaded code (JavaScript Web Workers do not support shared state,
-so this is not possible directly, but it can be emulated in various ways).
-
-But perhaps the largest future goal of Emscripten is to improve the performance of
+Perhaps the largest future goal of Emscripten is to improve the performance of
 the generated code. As we have seen, speeds of around $1/10$th that of
 GCC are possible, which is already good enough for many purposes, but
 can be improved much more. The code Emscripten generates will become faster