It's definitely not that simple, unfortunately. Jason's assembler code optimises the leadins of all the functions. Even a single cycle difference means the entire function needs to be reoptimised.
Given that there are now scores of assembler functions, you are talking about months of computing time, let alone human hours. Then we'd need the test suite to certify that the functions do actually work for various alignments. The extra code also bloats the binary which currently is getting too large. I don't wish to alienate anyone, however we can't support every possible paradigm. There's a combinatorial explosion after a while. At the very least we need to wait for Jason Moxham to comment on this. Sorry to actually discourage someone from writing code for MPIR, but aren't there other more important things we should do? Bill. 2009/12/11 Jason Martin <jason.worth.mar...@gmail.com>: > 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. > > > -- 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.
