Changeset 2341e9a in git
- Timestamp:
- Sep 28, 2022, 4:59:26 PM (19 months ago)
- Branches:
- (u'spielwiese', 'fe61d9c35bf7c61f2b6cbf1b56e25e2f08d536cc')
- Children:
- 787035145f531ce249dde09cbb3656225517b252
- Parents:
- 1291fb4c2054a2414ab193f6b00166905b065f986386dd1edc45f589c6150f9bb200ee0e74fd6520
- git-author:
- Hans Schoenemann <hannes@mathematik.uni-kl.de>2022-09-28 16:59:26+02:00
- git-committer:
- GitHub <noreply@github.com>2022-09-28 16:59:26+02:00
- Location:
- doc
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/memory/OMALLOC.texi
r1291fb r2341e9a 56 56 57 57 @table @strong 58 @item (1) allocation/deallocation of (small) memory blocks must be extrem ly fast58 @item (1) allocation/deallocation of (small) memory blocks must be extremely fast 59 59 If the allocation/deallocation of a memory blocks requires more than a 60 60 couple of machine instructions it would become the bottleneck of the … … 63 63 @item (2) consecutive memory blocks in linked lists must have a high locality of reference 64 64 Compared with the performed operations on list elements, cache misses 65 (or, even worse, page misses) of memory blocks are extrem ly expensive:65 (or, even worse, page misses) of memory blocks are extremely expensive: 66 66 we estimate that one cache miss of a memory block costs at least ten 67 67 or more list element operations. Hence, if the addresses of consecutive 68 68 list elements are not physically closed to each other (i.e., if 69 69 the linked lists have a low locality of reference), then resolving 70 c hache (or, page) misses would become the bottleneck of computations.70 cache (or, page) misses would become the bottleneck of computations. 71 71 @end table 72 72 … … 103 103 @heading Principles of omalloc 104 104 105 @code{omalloc} is a stand-alone, general-purpose memory manag ment105 @code{omalloc} is a stand-alone, general-purpose memory management 106 106 library which can be used by any program. Its major design goals were 107 107 derived from the memory management requirements of @sc{Singular} (see above). … … 112 112 113 113 @code{omalloc} is specialized in the management of small memory 114 blocks. The manag ment of large memory blocks, i.e., of memory blocks which114 blocks. The management of large memory blocks, i.e., of memory blocks which 115 115 are larger than "one fourth of the page size of the system" (usually 116 116 appr. 1KByte) are (almost) left entirely to the underlying … … 132 132 on the used memory allocation mechanism and its arguments (see 133 133 below). The counter of the page is incremented, and the provided memory 134 block is deque d from the free-list of the page.134 block is dequeued from the free-list of the page. 135 135 136 136 On @strong{memory deallocation}, the address of the memory block is used to … … 139 139 enqued into the free-list. If decrementing the counter yields zero, 140 140 i.e., if there are no more used memory blocks in this page, then this 141 page is deque d from its Bin and put back into a global pool of unused pages.141 page is dequeued from its Bin and put back into a global pool of unused pages. 142 142 143 143 … … 175 175 exclusive. When in its debugging mode, @code{omalloc} is set out to 176 176 catch more than 20 errors in the usage of its API. And, of course, all 177 the common and classical errors are among those which are c ought by177 the common and classical errors are among those which are caught by 178 178 @code{omalloc}. Error reporting can either be directe3d to log files or to 179 179 @code{stderr}. On some platforms, the error reporting does not only … … 184 184 @heading Requirement evaluation of @code{omalloc} 185 185 After explaining its princples of @code{omalloc} let us evaluate 186 @code{omalloc} w.r.t. the requir ments stated above.186 @code{omalloc} w.r.t. the requirements stated above. 187 187 188 188 @table @strong … … 194 194 that this is optimal, i.e., as fast as one possibly could implement 195 195 these operations. 196 @*The other interface levels incur ethe additional overhead of the196 @*The other interface levels incur the additional overhead of the 197 197 determination of the appropriate Bin (using a table lookup); and, for the 198 198 function interface level, the additional overhead of function … … 202 202 @item (2) locality of reference 203 203 Based on its design principles @code{omalloc} provides an 204 extrem ly high locality of reference (especially for consecutive elements204 extremely high locality of reference (especially for consecutive elements 205 205 of linked-list like structures). To realize this, recall that 206 206 @itemize … … 210 210 when it becomes full or empty). 211 211 @item 212 the probabil ty that consecutively allocated memory blocks are also212 the probability that consecutively allocated memory blocks are also 213 213 physically consecutive (i.e., that their physical addresses are consecutive) 214 214 is rather high, since memory pages are spooled-back into the 215 215 pool of unused pages as often as possible, and, hence, are reinitialized 216 as often as possible (notice that allocati ong from a freshly initialized216 as often as possible (notice that allocating from a freshly initialized 217 217 page assures that the physical addresses of consecutively allocated 218 218 memory blocks are also consecutive). … … 225 225 long-lived, often traversed-over data. 226 226 227 @item (3) small maint ainance size overhead227 @item (3) small maintenance size overhead 228 228 229 229 Since @code{omalloc} manages small memory blocks on a per-page basis, there is 230 no maint ainance-overhead on a per-block basis, but only on a per-page230 no maintenance-overhead on a per-block basis, but only on a per-page 231 231 basis. This overhead amounts to 24 Bytes per memory 232 page, i.e., we only need 24 Bytes maint anance overhead per 4096 Bytes,232 page, i.e., we only need 24 Bytes maintenance overhead per 4096 Bytes, 233 233 or 0.6%. 234 234 @*For larger memory blocks, this overhead grows since there might 235 235 be "leftovers" from the division of a memory page into equally-sized 236 236 chunks of memory blocks. Furthermore, there is the additional (but 237 rather small) overhead of keeping Bins and other "global" maint ance237 rather small) overhead of keeping Bins and other "global" maintenance 238 238 structures. 239 @*Nevertheless, on average, we observed a maint anance overhead of239 @*Nevertheless, on average, we observed a maintenance overhead of 240 240 appr. 1% of the total memory usage, which, to the best of our knowldege, 241 241 is unsurpassed by any existing, general-purpose, memory manager. … … 251 251 efficienc/flexibility. 252 252 253 W.r.t. the debugging mode has our experience shown that it is extrem ly253 W.r.t. the debugging mode has our experience shown that it is extremely 254 254 useful to be able to fine-tune the granularity of the debugging under both, 255 255 a lexical, per-file base scope, and under a dynamic scope set at … … 259 259 no recompilations of @code{omalloc} are required to enable one or the other 260 260 mode. As a summary @code{omalloc} debugging features can at least be 261 compared with available memory manag ment debugging libraries (like261 compared with available memory management debugging libraries (like 262 262 @uref{http://dmalloc.com/,dmalloc}) -- our experience has furthermore 263 263 showh that the features are suitable and appropriate for most practical … … 271 271 @heading Performance evaluation of @code{omalloc} 272 272 273 We have no (yet) tho uroughly measured the performance of274 @code{omalloc} in comparison to other memory manag ment273 We have no (yet) thoroughly measured the performance of 274 @code{omalloc} in comparison to other memory management 275 275 systems. Nevertheless, our first experiments yielded the following: 276 276 @itemize … … 282 282 283 283 @item 284 We expect that for programs/computations with similar compu ational284 We expect that for programs/computations with similar computational 285 285 characteristics like those of @sc{Singular} (e.g., multivariate 286 286 polynomial computations, sparse matrix computations, etc), the speed … … 296 296 @heading Status/Copyright of @code{omalloc} 297 297 298 @code{omalloc} is a fully-functional, mature memory manag ment298 @code{omalloc} is a fully-functional, mature memory management 299 299 library. It still has a TODO list, with more or less only one major 300 300 point: Create a detailed technical reference manual (in texinfo),
Note: See TracChangeset
for help on using the changeset viewer.