On 12 May 2016 at 20:35, Brian Gladman <b...@gladman.plus.com> wrote:
> On 12/05/2016 19:10, 'Bill Hart' via mpir-devel wrote: > > > > On 12 May 2016 at 20:07, Jean-Pierre Flori <jpfl...@gmail.com > > <mailto:jpfl...@gmail.com>> wrote: > > > > Anyway, is there really any reason to superoptimise on Windows > > itself, why not do it on Linux and use it everywhere, does the noise > > produced by the OS really matter? > > > > That's the best solution in my opinion. > > Yes but it does mean putting in the prologue epilog sequences since (as > you say below0 you won't get the optimisation for small length operands Yes, we would superoptimise it with Windows prologue epilog sequences. The code, once superoptimised, should work on Windows without any further changes. > > The way that GMP do it is (at least when I last looked) is to simply use > their own prologues to swap the different register conventions while > completley ignoring the need for the x64 prolgues and epilogues. That > will work when things go well but I want a system that works in the > worst case on Windows, not only one that works when things aare going in > our favour. > > > Ok, the function call ABI is different (Win64 vs system v), so when > > you enter your function some stuff will be on the stack rather than > > in registers, but apart from that, will anything really change? > > Why not go the GMP way which just add some prologue/epilogue to its > > system v function abi assembly implems to deals with the different > > windows 64 ABI? > > > > > > No this won't work. You must superoptimise with the correct ABI or the > > result will be useless for small operands. Alex's idea of writing code > > to deliberately put the data in the registers required for the Windows > > ABI, then optimise that on Linux is the best, I think. > > > > We basically already did it the way you suggested and it doesn't lead to > > the right speedup on Windows. > > That is what Jason and I found too. The prologue and epilogue code > don't matter much for large operands but the statistics seem to suggest > that short operand performance is critical aand this requires Windows > ABI specific optimisation. > Yep. > > > And there is the stack rewinding or structured exception handling > > stuff that also needs to be dealt with but can't it be done around > > the core assembly implems as for dealing with the different function > > call ABI? > > Sorry but I have just answered that before you asked it :-) > all the best, > > Brian > > PS to Antony, its nice to see your Windows experience showing up on the > list! > > -- > 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 mpir-devel+unsubscr...@googlegroups.com. > To post to this group, send email to mpir-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/mpir-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
