<div dir="ltr">On 24 September 2013 09:21, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 9/23/13 3:12 PM, Peter Alexander wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Monday, 23 September 2013 at 21:27:36 UTC, Andrei Alexandrescu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That allocator would allocate more memory (I suspect there's a gcd<br>
calculation somewhere :o)) and then adjust the starting pointer of the<br>
allocated block to reach the requested alignment.<br>
</blockquote>
<br>
That's quite an inefficient use of memory for large alignment sizes.<br>
</blockquote>
<br></div>
I don't see a way around it unless the allocator natively provides a large alignment size, which it would then advertise in its "alignment" constant. The problem is independent of this particular design.</blockquote>
<div><br></div><div>There's an important distinction between an allocator advertising a large allocation size (which it always uses), and an allocator being capable of allocating a larger aligned block if requested.</div>
<div>Surely the advertised alignment is the alignment you will get in all cases, even if you request a small alignment.</div><div>You should advertise a minimum and maximum alignment if that is your solution.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, how does it work with your deallocate interface? Suppose I request<br>
an 0x100 aligned block of 0x100 bytes. Your alignment allocator requests<br>
0x200 from the GC, which maybe returns [0xffff0040-0xffff0240] and then<br>
returns an aligned buffer from that [0xffff0100-0xffff0200]. Later, I<br>
try to deallocate that buffer, which means your alignment allocator has<br>
to deallocate the original buffer. Where does the alignment allocator<br>
store the original GC-provided buffer ptr + size? It cannot be<br>
determined from the buffer I gave it.<br>
</blockquote>
<br></div>
Walter noted the same issue. I'd need to think about it. A simple solution is to simply store the size just before the pointer returned, in a dope block manner.</blockquote><div><br></div><div>This means if the allocator returns you memory that is already of the desired alignment, you need to waste an entire aligned block just to store the offset, which would have been 0.</div>
<div>I solve this problem by storing my allocation table in a separate hash table, and entries in that table associate the size and also the alignment offset. But it's not a good solution, it's still wasteful. It's just the best option you have if you don't have any control over the system allocator.<br>
</div><div><br></div><div>I also use large alignments which I've detailed in prior discussions.</div><div>Common ones are cache line (~64-256 bytes), and gpu memory page (~4k).</div><div>You can't go wasting GPU memory by overallocating every block.</div>
<div>It's definitely important that allocator's are able to receive an alignment request, and give them the opportunity to fulfill a dynamic alignment request without always resorting to an over-allocation strategy.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd need a handful of good examples where the alignment must be known<br>
at runtime. Can you link to some?<br>
</blockquote>
<br>
mprotect requires a pointer that is a multiple of the system page size,<br>
which isn't constant.<br>
<br>
<a href="http://linux.die.net/man/2/mprotect" target="_blank">http://linux.die.net/man/2/<u></u>mprotect</a><br>
</blockquote>
<br></div>
Thanks! I see posix_memalign is a corresponding call that returns a page-aligned chunk of memory. I assume calls like mmap also return page-aligned chunks. Indeed it is a problem for the current design that the alignment must be known during compilation.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Reading a file without buffering on Windows requires that you align the<br>
destination buffer on volume sector size boundaries, which is not known<br>
at compile time (although many just assume 4096).<br>
</blockquote>
        ><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/cc644950(v=vs.85).aspx" target="_blank">http://msdn.microsoft.com/en-<u></u>us/library/windows/desktop/<u></u>cc644950(v=vs.85).aspx</a><br>
</blockquote>
<br></div>
I see there's a difference between x86 and Itanium in page size...<br>
<br>
I'm trying to lean toward handling these as rare/exotic cases without outright eliminating them, while providing simple and efficient handling of alignment for the frequent cases (i.e. allocate ints at addresses multiple of 4 etc).<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I mentioned previously, you may want to also align to the cache line<br>
size (for performance). This is not known at compile time (although<br>
again, is often assumed in practice).<br>
</blockquote>
<br></div>
Indeed.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Andrei<br>
<br>
</font></span></blockquote></div><br></div></div>