On 16/04/2013 14:01, Bill Hart wrote:
> Hi Brian,
>
> that's great to hear that everything passes on Windows 64.
>
> I don't think there is any benefit to writing full assembly files for
> these two new functions. The reason is that the function call overhead
> would be about 9 cycles, which would be more than than actual saving
> over the C macros that we have. So in fact, assembly files would likely
> slow it down.
>
> However, I agree that it would be very beneficial if someone were to
> volunteer to write _inline_ assembly for Windows 32 bit, as this would
> give a 5% speedup on that platform. Conversely, if no one is actually
> using this platform then letting support lapse seems to be an option. I
> will continue to maintain MinGW build support for Windows 32 for a while
> and that will at least provide an option for people on that platform.
> But I'm not going to put time into non-essential assembly code for that
> platform as there are simply too many other things to maintain.
>
> I should have a better indication of my future in the next few weeks, at
> which point I should know how much time I can put into MPIR in future.
> Even so, with only two people volunteering we can't hope to accomplish
> much. So I agree, we do need further volunteers!
Another option on Windows x64 is to use the Intel compiler since this
does support inline x64 assembler. I have just tried this with some
assembler support (a bit of a hack right now) and all tests pass. On the
benchmark this gives a 3% overall speed increase.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/mpir-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
