Changeset 108f6c32


Ignore:
Timestamp:
Apr 27, 2022, 8:29:23 AM (2 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
ADT, ast-experimental, master, pthread-emulation, qualifiedEnum
Children:
37ef5e41
Parents:
8f94a63
Message:

first proofread of chapter conclusions

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/mubeen_zulfiqar_MMath/conclusion.tex

    r8f94a63 r108f6c32  
    11\chapter{Conclusion}
    22
    3 \noindent
    4 ====================
     3% \noindent
     4% ====================
     5%
     6% Writing Points:
     7% \begin{itemize}
     8% \item
     9% Summarize u-benchmark suite.
     10% \item
     11% Summarize @uHeapLmmm@.
     12% \item
     13% Make recommendations on memory allocator design.
     14% \end{itemize}
     15%
     16% \noindent
     17% ====================
    518
    6 Writing Points:
    7 \begin{itemize}
    8 \item
    9 Summarize u-benchmark suite.
    10 \item
    11 Summarize @uHeapLmmm@.
    12 \item
    13 Make recommendations on memory allocator design.
    14 \end{itemize}
     19The goal of this thesis was to build a low-latency memory allocator for both KT and UT multi-threads systems, which is competitive with the best current memory allocators, while extending the feature set of existing and new allocator routines.
     20The new llheap memory-allocator achieves all of these goals, while maintaining and managing sticky allocation information without a performance loss.
     21Hence, it becomes possible to use @realloc@ frequently as a safe operation, rather than just occasionally.
     22Furthermore, the ability to query sticky properties and information allows programmers to write safer programs, as it is possible to dynamically match allocation styles from unknown library routines that return allocations.
    1523
    16 \noindent
    17 ====================
     24Extending the C allocation API with @resize@, advanced @realloc@, @aalloc@, @amemalign@, and @cmemalign@ means programmers do not make mistakes writing theses useful allocation operations.
     25The ability to use \CFA's advanced type-system (and possibly \CC's too) to have one allocation routine with completely orthogonal sticky properties shows how far the allocation API can be pushed, which increases safety and greatly simplifies programmer's use of dynamic allocation.
     26
     27Providing comprehensive statistics for all allocation operations is invaluable in understanding and debugging a program's dynamic behaviour.
     28No other memory allocator provides comprehensive statistics gathering.
     29This capability was used extensively during the development of llheap to verify its behaviour.
     30As well, providing a debugging mode where allocations are checked, along with internal pre/post conditions and invariants, is extremely useful, especially for students.
     31While not as powerful as the @valgrind@ interpreter, a large number of allocations mistakes are detected.
     32Finally, contention-free statistics gathering and debugging have a low enough cost to be used in production code.
     33
     34The ability to compile llheap static/dynamic linking and optional statistics/debugging provides programers with multiple mechanisms to balance performance and safety.
     35These allocator versions are easy to use because can be linked to an application without recompilation.
     36
     37Starting a micro-benchmark test-suite for comparing allocators, rather than relying on a suite of arbitrary programs, has been an interesting challenge.
     38The current micro-benchmark allows some understand of allocator implementation properties without actually looking at the implementation.
     39For example, dmalloc and ptmalloc3 were quickly identified has having course-grain locking in the Speed micro-benchmark.
     40It was not possible to show how the micro-benchmarks adjustment knobs were used to tune to an interesting test point.
     41Many graphs were created and discarded until a few were selected for the thesis.
     42
     43
     44\section{Future Work}
     45
     46A careful walk-though of the allocator fastpath should yield additional optimizations for a slight performance gain.
     47
     48The micro-benchmarks project requires more testing and analysis.
     49Additional allocations patterns are needed to extract meaningful information about allocators, and within allocation patterns, what are the best tuning knobs.
     50Also, identifying ways to visualize the results of the micro-benchmarks is a work in progress.
     51
     52After llheap is made available on gitHub, interacting with its users to locate problems and improvements, will make llbench a more robust memory allocator.
Note: See TracChangeset for help on using the changeset viewer.