Dan, thanks for this bug report. I could also see that it probably took you many many tedious hours to find this bug. Amazing work!! Thank you sooo much to taking the time to do it!!!
This is a really subtle bug. I just checked that malloc documentation on several Linux distros, Mac OS X, BSD, and Solaris, and all of them return memory that is aligned to the largest native memory access (i.e. 16bytes for SSE/Altivec/Neon). So, this really is a bug that is most likely to show up on custom allocation systems. However, many of our high-performance packages (such as Dan and Mike's) are going to use their own memory allocation systems to avoid the overhead of calling out to system routines. We shouldn't alienate that user group by just changing the documentation to match MPIR's code. We could modify the x86_64 code to use the MOVDQU instruction whenever the source pointers aren't aligned... just create a second copy of the assembler code block and add a test at the beginning of the function which checks the alignment. If any of the pointers are unaligned, then we use the slower code. Branch hints should prefer the aligned code. This would give us a 2-12 cycle hit at the beginning of the routine, but the throughput shouldn't change for the aligned version. The unaligned code would obviously be slower (MOVDQU is slower than MOVDQA), but that is to be expected. Perhaps we could make the code change along with a suggestion in the documentation to always used 32-byte aligned data (I'm anticipating the 256-bit YMM registers that Intel says are coming in the next CPU generation). Anyway, I'm happy to make the code changes to Jason Moxham's code if the rest of you want me to. However, I thing it's best to leave it to him. I assume that he'll reappear in a week or two. Bill, just let me know if you want me to modify the code. --jason Jason Worth Martin Asst. Professor of Mathematics http://www.math.jmu.edu/~martin On Thu, Dec 10, 2009 at 8:15 PM, Bill Hart <goodwillh...@googlemail.com> wrote: > There's still the question of how we have people who write garbage > allocators recognise that this is a bug. > > Bill. > > 2009/12/10 Cactus <rieman...@googlemail.com>: >> >> >> On Dec 10, 10:20 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >>> Hi Dan, >>> >>> indeed I had inferred that you had done a *lot* of work to track this bug >>> down. >>> >>> It's not immediately clear how we can cause an error message to be >>> output if a custom allocator returns non-aligned pointers. >>> >>> Two possibilities spring to mind: >>> >>> 1) Introduce a make check test which checks that the allocator is >>> doing what we want. But this relies on the allocator failing to do so >>> during the test, which I don't see how to provoke. >>> >>> 2) Introduce code to align data coming from custom allocators. This >>> could probably be done in a handful of cycles per allocation, but >>> would still introduce an overhead. >>> >>> I'm open to further suggestions. >> >> If n-byte alignment for n-byte objects is a target architecture >> requirement, this is surely a memory allocation bug and not an MPIR >> one. >> >> We might think about some sort of debug mode that adds detection or >> defence but I would be against adding overhead that is not going to be >> necessary in normal operation (we should, of course, document the >> issue). >> >> I would take the view that asking a lot of low level code to defend >> against incorrect memory allocation - at possibly heavy cost - is not >> the right approach. Whoever has the job of putting a memory allocator >> on a machine surely has the responsibility for ensuring that it >> complies with any target architecture requirments? >> >> In particular, I would expect to see a debug mode in an allocator for >> testing exactly this sort of issue (I thought that Boehm's GC haad >> this capability). >> >> Brian >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "mpir-devel" group. >> To post to this group, send email to mpir-de...@googlegroups.com. >> To unsubscribe from this group, send email to >> mpir-devel+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/mpir-devel?hl=en. >> >> >> > > -- > > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
