<div class="gmail_extra"><div class="gmail_quote">On 30 April 2012 01:24, Tove <span dir="ltr"><<a href="mailto:tove@fransson.se" target="_blank">tove@fransson.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sunday, 29 April 2012 at 22:13:22 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is it technically possible to have a precise GC clean up all unreferenced<br>
memory in one big pass?<br>
</blockquote>
<br></div>
yes, but unless it's also moving/compacting... one would suffer memory fragmentation... so I would imagine TempAlloc is a better fit?<br></blockquote><div><br></div><div>In some cases I'm comfortable with that type of fragmentation (large regularly sized resources), although that leads me to a gaping hole in D's allocation system...</div>
</div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><OT, but still very important></div><div class="gmail_extra">There is no way to request aligned memory. I can't even specify an alignment on a user type and expect it to be aligned if I create one on the stack, let alone the heap >_<</div>
<div class="gmail_extra">It seems I can request alignment for items within a struct, but I can't align the struct its self. In addition, a struct doesn't inherit the alignment of its aligned members, so the struct is allocated unaligned, and the aligned member fails its promise anyway.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I frequently align to:</div><div class="gmail_extra">16 bytes for basically everything. This facilitates hardware simd, fast memcpy, efficient write-combining, better cache usage.</div>
<div class="gmail_extra">128(ish) bytes for L1 cache alignment (depending on architecture). Frequently used to guarantee ~128byte sized structs will never straddle cache lines (wasting a memory fetch/L1 eviction), and supporting predictable prefetch algorithms.</div>
<div class="gmail_extra">4k(ish) for texture/gpu page alignment (again, depending on architecture). Many GPU resources MUST be aligned for the GPU to access them. Swizzling is applied to aligned pages, resource allocation must match this.</div>
<div class="gmail_extra">4-64k virtual memory pages. Many uses.</div><div class="gmail_extra"><br></div><div class="gmail_extra">And occasionally other alignments pop up, often where they may be useful to help reduce/avoid fragmentation for instance.</div>
<div class="gmail_extra">Sometimes I need to squat some data in a couple of low its in a pointer... requires the pointers be aligned.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Obviously I can manually align my memory with various techniques, and I do, but it's rather fiddly and can also be very wasteful.</div>
<div class="gmail_extra">One fast technique for general allocations is over-allocating by alignment-1, pasting a little header and padding the allocation. Allocating a GPU page for instance would waste another whole page just to guarantee alignment. In that case, you need to allocate a bog pool of pages and implement some pool system to dish them out, but then you need to know the precise number of pages to be allocated in advance in order not to waste memory that way.</div>
<div class="gmail_extra"></OT></div>