It is actually possible that the bobcat version is faster. I've no idea whether Jason explicitly superoptimised it for bobcat. It's not without precedent anyway.
You can check if the CPU throttling is the problem because tuneup actually reports the CPU speed before it gives the timings. These should be the same when comparing. If so, the values should be accurate. I noticed the non-monotonicity before. By the way, tuning thresholds should not affect the performance of sqr_basecase. The code is called directly, with no adjustment of algorithm related to tuning cutoffs. You can also test out to 100 limbs with -s 1-100 and see if the improvement is maintained to larger sizes. Not that this is relevant in practice. The sqr_basecase cutoff will fairly low (probably around 20-40), so any sizes above that are probably not relevant. Bill. On 24 March 2014 12:12, leif <not.rea...@online.de> wrote: > Bill Hart wrote: > >> Leif said he was going to tune on a bobcat, but hasn't yet. >> > > Well, this of course^TM turned out to be a can of worms... ;-) > > So far it looks like the bobcat version of mpn_sqr_basecase was actually > faster, but I don't really trust the figures. (I played a little with the > "precision" option, but this seems to be logically limited to 2^31. With > the default precision, I occasionally get non-monotonic numbers; not that > one value was exceptionally bad -- as one would expect, but timings about > twice as fast, despite both cores being on "performance", and the machine > mostly idle.) > > Still have to analyze how reliable individual thresholds are. > > > -leif > > > That may be because I mentioned there is an additional step for the >> bobcat. We need to know if mpn/x86_64/bobcat/sqr_basecase.as >> <http://sqr_basecase.as> or mpn/x86_64/sqr_basecase.asm is faster. >> >> >> This can be determined by running: >> >> ./configure >> make >> make clean >> cd tune >> make speed >> ./speed -s 1-40 mpn_sqr_basecase >> >> before and after deleting mpn/x86_64/bobcat/sqr_basecase.as >> <http://sqr_basecase.as> >> >> >> Assuming it is faster after deleting it (smaller numbers are better -- >> and we assume they will be smaller), run make tune and send the results >> to us. >> >> Actually, I just realised, we'd like to know the same thing about >> mpn/x86_64/atom/sqr_basecase.as <http://sqr_basecase.as> on the atom. >> >> >> Bill. >> >> >> On 24 March 2014 11:12, Frithjof Schulze <sfrith...@gmail.com >> <mailto:sfrith...@gmail.com>> wrote: >> >> On Friday, March 21, 2014 5:37:16 PM UTC, Bill Hart wrote: >> >> Note MPIR will run very slow on these machines without proper >> tuning values due to significant recent changes. So we'd >> appreciate any help. >> >> We can also tell you how to do the tuning yourself and send us >> the values (it's really easy). >> >> >> I have a netbook with an E-350 and also an older atom based netbook. >> I could tune MPIR on both, if nobody has done so yet. >> >> --Frithjof >> > > -- > () The ASCII Ribbon Campaign > /\ Help Cure HTML E-Mail > > -- > 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 http://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 http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
