Hi William, thanks for doing these. The figures are quite interesting naturally.
William Stein wrote: > Hi Bill (Hart), > > Here are some timings I've done with the same benchmark as you, but in > PARI, > Maple, Mathematica, GAP, Singular, Magma, Maxima, etc. Recall that the > timings are for "10000 multiplies of degree 255 polynomials with random > positive coefficients of size 1000 bits". You reported these timings: > MAGMA 29.3s > FLINT 27.7s The figures above are derived with a different methodology. I time the multiplication, but subtract any interpreter overheads (FLINT does not have these) and use a different multiplication methodology. It would be unfair to include interpreter overheads for a package which offers an interpreter against one which does not. In the case of MAGMA, the time subtracted was 0.00s for this particular set of multiplications. So, the reason the figure is lower than yours is that I computed the products differently. It makes a big difference if all the polynomials are multiplied in the same portion of memory or not. This has to do with caching. So we re-timed MAGMA with an algorithm that allowed it to perform all its multiplications in the same location of memory should it so choose to (and indeed it does, it turns out to have a very nice memory manager). The FLINT memory manager will do the same thing, though the crude code I implemented to do our timings could hardly be called a memory manager. I am in the process of implementing a more sophisticated one (it's nearly done). That should not impact our timings in either direction but will be more flexible for a wider range of problems. In the case of timng MAGMA one cannot store all the polynomials to be multiplied in just one location in memory in advance (obviously), so one has to subtract the time taken to compute the polynomials and store them in that (one) location in memory. This lowers MAGMA's timing significantly, as you have noted. But it does not lower ours, since we were already (inadvertently) timing ours this way. What I am saying is that MAGMA's sophisticated memory manager contributes to its overall speed as compared with the less sophisticated products, so this must be taken into account when doing timings. > MAGMA 31.5s By the way the current timings are a little better. MAGMA 2.13-5 ---29.30s FLINT v 0.00-0 ---24.35s We are vaguely aiming for a time of 21s, but do not know if that is achievable. It will be interesting to see if the MAGMA group try to compete for speed. I personally think they have more important goals for their product than competing with us, but it will be interesting to monitor nonetheless. It's also interesting that MAGMA emerges as the platform to beat speedwise, though some aspects of their platform are also slow (e.g. factorisation). They certainly do commit resources to speed, and it is obvious from the timings you list even if I hadn't heard that it was actually part of their strategy. It's perhaps more obvious to David and I when we see precisely *how hard* it was to beat MAGMA. Bill. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
