On Dec 11, 2:38 am, Jason Martin <jason.worth.mar...@gmail.com> wrote:
> 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.
[snip]
I too, would like to thank Dan for his work on this issue, which has
highlighted an implicit assumption about memory alignment that needs
to be made explicit.
I cannot speak for those who do their work on Linux/Unix/GCC but on
Windows x64 we would not be changing the documentation to match our
code; we would be changing it to ensure that users are aware that our
code depends on applications correctly complying with target
architecture ABI conventions.
Since the whole point of adding assembler code is to provide high
performance, it surely doesn't make a lot of sense to change MPIR in a
way that slows it down? Isn't changing the memoory allocator(s) to
return properly aligned memory the right solution?
However, since (a) the Windows assembler code is seperate, and (b) the
memory alignment requirements on Windows x64 are absolutely clear,
this change can be made for Linux/Unix/GCC without having to be
implemented on Windows. It's not a change I will ever make on the
Windows x64 assembler code as it is completely unnecessary.
However, I notice that Macaulay 2 (Dan's package?) hopes to provide a
native Windows version at some point. I would have thought that any
future high performance package on Windows would need to work on x64,
which would mean that architecture compliant memory allocation will be
needed anyway.
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.
