diff options
| -rw-r--r-- | Makefile | 4 | ||||
| -rw-r--r-- | a6/au_BentBisballeNyeng_A6.tex | 51 |
2 files changed, 31 insertions, 24 deletions
@@ -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 |