summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--Makefile4
-rw-r--r--a6/au_BentBisballeNyeng_A6.tex51
2 files changed, 31 insertions, 24 deletions
diff --git a/Makefile b/Makefile
index c7c115d..6dde807 100644
--- a/Makefile
+++ b/Makefile
@@ -44,7 +44,11 @@ A5:
rm -f ${PRE}$@.aux ${PRE}$@.log
A6:
+ zip ${PRE}$@.zip a4/Makefile
+ zip ${PRE}$@.zip a4/*.cc
+ zip ${PRE}$@.zip a4/*.h
make -C a6 ${PRE}$@.pdf
+ cp a6/${PRE}$@.pdf .
Tour3_Log:
xelatex -halt-on-error -jobname=${PRE}$@ tour3_log/tour3_log.tex
diff --git a/a6/au_BentBisballeNyeng_A6.tex b/a6/au_BentBisballeNyeng_A6.tex
index 107e62a..6acd180 100644
--- a/a6/au_BentBisballeNyeng_A6.tex
+++ b/a6/au_BentBisballeNyeng_A6.tex
@@ -40,7 +40,7 @@ allocations (such as smart-pointers), but can still be used for
managing other types of resources, such as locks or hardware
peripheral access.
-\subsection{Dynamic Memory Allocation}
+\subsection{Dynamic Memory Allocation}\label{dyn}
There can be many reasons for not allocating on the free-store, either
by convention; ``no allocations allowed after the engines has
@@ -52,7 +52,7 @@ memory depletion\cite{weis}.
In the case of memory fragmentation one might argue that it is not the
allocation that is the problem but rather the free'ing since this is
-when the fragmentation happens. This problem is shown in
+when the fragmentation happens. The problem is shown in
figure \ref{frag}, which might be possible to circumvent in singular
concrete cases, but cannot be solved in general without the page
indirections of the virtual memory\cite{weis}.
@@ -69,17 +69,19 @@ fragmentation.}}
\label{frag}
\end{figure}
-This can to some degree be prevented by monotonic allocations which
-might work for not very practical in real-world
-software and certainly not for the dynamic allocations in the STL or
-the core-language.
+This can to some degree be prevented by monotonic allocations where
+each allocation always has the same size and therefore can be re-used
+directly after being freed. This might work for some special usecases,
+where objects of similar size are being stored in a pool may not be
+applicable in software in general and certainly not for the dynamic
+allocations in the STL or the core-language.
In particular, a lambda stored in a \texttt{std::function} might
-allocate memory on the free-store if the lambda exceeds the size of
-the (compiler dependent) small-buffer optimization (SBO) buffer inside
-the \texttt{std::functions}\cite{elbeno}. In much the same way as
-the \texttt{std::string} has its small string optimization (also
-compiler dependent).
+allocate memory on the free-store if the lambda captures exceeds the
+size of the (compiler dependent) small-buffer optimization (SBO)
+buffer inside the \texttt{std::functions}\cite{elbeno}. In much the
+same way as the \texttt{std::string} has its small string optimization
+(SSO) which are also compiler dependent in size.
\subsection{Free-Standing}
@@ -142,18 +144,18 @@ There exists a \texttt{-ffreestanding} argument, but this follows the
old (current) definition of free-standing and as such allows
dynamic allocation so it cannot be used.
-Some constructs have built-in optimizations that make them store their
-data in local members, instead of on the free-store through a pointer,
-until som limit is reached making it possible to use for
-example \texttt{std::string}s or \texttt{std::function}s as long as
-they don't require more than $N$ bytes, where $N$ is a compiler
-dependent.
+As mentiond in section \ref{dyn}, some constructs have built-in
+optimizations that make them store their data in local members,
+instead of on the free-store through a pointer, until som limit is
+reached making it possible to use for example \texttt{std::string}s
+or \texttt{std::function}s as long as they don't require more than $N$
+bytes, where $N$ is a compiler dependent.
-To detect if a free-store allocation is done a simple overload
+To detect if or when a free-store allocation is done a simple overload
of \texttt{new} is made, which simply throws an exeption if called.
-This will lead to a run-time error and not a compile-time one as would
-have been the ideal solution, but at least it can assists in finding
-the $N$ for a specific compiler.
+This will lead to a run-time error and not a compile-time one, which
+would otherwise have been the ideal solution, but at least it can
+assists in finding the $N$s for a specific compiler.
The code could simply look something like this:
@@ -164,11 +166,12 @@ void* operator new(std::size_t)
}
\end{lstlisting}\normalsize
-The code for this experiment can be found in the \texttt{noalloc.cc}
-file.
+The complete code for this experiment can be found in
+the \texttt{noalloc.cc} file.
The following table shows the impirically deduced sizes of $N$ wherever
SSO or SBO is available along with comments about the general component
-behaviour.\\
+behaviour. The sizes were simply increased until the compiled program
+started throwing the \texttt{std::bad\_alloc} exception.\\
\noindent\begin{tabular}{| l | c | l |}
\hline