On Thursday 05 March 2009 16:10:04 Bill Hart wrote: > Then this surely affects the Windows bench as well as the linux one. I > see it is used in Toom multiplication. > > Happy days. There's your 2% missing for Windows! >
I'm not so sure , the problem is in configure.in , before configure generates config.h with our HAVE_NATIVE_mpn_addlsh1_n etc , and now its empty > Bill. > > 2009/3/5 <ja...@njkfrudils.plus.com>: > > On Thursday 05 March 2009 16:05:46 Bill Hart wrote: > >> Would the loss of these also affect the mpirbench? > > > > yes > > - Show quoted text - > > > >> Bill. > >> > >> 2009/3/5 <ja...@njkfrudils.plus.com>: > >> > The conversion from gas to yasm have lost the defines > >> > HAVE_NATIVE_* > >> > so that addlsh1_n etc dont appear in speed or try > >> > > >> > > >> > > >> > On Thursday 05 March 2009 13:38:29 Bill Hart wrote: > >> > - Show quoted text - > >> > > >> >> 2009/3/5 <ja...@njkfrudils.plus.com>: > >> >> > On Wednesday 04 March 2009 23:56:48 Bill Hart wrote: > >> >> >> I've had a think, especially considering the 10's of thousands of > >> >> >> people who will be using MPIR in Sage, not to mention the sponsor, > >> >> >> and I think we need to write try tests for the mpn functions we > >> >> >> use. > >> >> >> > >> >> >> We could divide the work in half by one person writing the > >> >> >> reference tests and the other writing the lt-try tests. I > >> >> >> volunteer to write the reference tests. I may be able to start > >> >> >> this tomorrow after I finish with converting the core 2 code to > >> >> >> yasm. > >> >> > > >> >> > I can do half or all if you want ,although if may be better if I > >> >> > didn't write either , so if I have made a mistake , you are > >> >> > unlikely to repeat the same mistake . > >> >> > Note: > >> >> > lshift1,rshift1 are just macros on non-amd systems > >> >> > lshift1,rshift1 overlap requirements are same or separate ONLY > >> >> > redc_basecase,sumdiff has a mpn/generic written by someone else > >> >> > addsub returns int not limb > >> >> > > >> >> > looking at try it allready has tests for sumdiff ,addlsh1 ,sublsh1 > >> >> > >> >> None of those appear in the list when you run try without parameters. > >> >> We should add those to the list. > >> >> > >> >> > so we only need new tests for > >> >> > redc_basecase,lshift1,rshift1,addadd,addsub > >> >> > >> >> Cool. Do you want to add some tests assuming there is a reference > >> >> implementation available to test against, and I'll write the > >> >> reference implementation. That's good enough for me. If a different > >> >> person writes the reference implementation to the original then it's > >> >> a pretty good test. > >> >> > >> >> Bill. > >> >> > >> >> > - Show quoted text - > >> >> > > >> >> >> Bill. > >> >> >> > >> >> >> 2009/3/4 <ja...@njkfrudils.plus.com>: > >> >> >> > On Wednesday 04 March 2009 23:24:59 Bill Hart wrote: > >> >> >> >> Is there a test for lshift1, rshift1, addlsh1, addrsh1, addadd, > >> >> >> >> addsub, sumdiff, divebyff or redc_basecase? > >> >> >> >> > >> >> >> >> Do we need tests for these? > >> >> >> >> > >> >> >> >> I know we use addadd and addsub. Do we use any of the others > >> >> >> >> yet? > >> >> >> > > >> >> >> > we use lshift1 rshift1 addlsh1 sublsh1 sumdiff redc_basecase > >> >> >> > we dont use divebyff > >> >> >> > make check run tests for all these , but nothing in ./try > >> >> >> > - Show quoted text - > >> >> >> > > >> >> >> >> Bill. > >> >> >> >> > >> >> >> >> 2009/3/4 Bill Hart <goodwillh...@googlemail.com>: > >> >> >> >> > 2009/3/4 <ja...@njkfrudils.plus.com>: > >> >> >> >> >> On Wednesday 04 March 2009 22:40:18 Bill Hart wrote: > >> >> >> >> >>> I'd like to propose a code freeze on all K8/K10 assembly > >> >> >> >> >>> code, which I have now converted to yasm format, unless > >> >> >> >> >>> serious bugs are uncovered. > >> >> >> >> >>> > >> >> >> >> >>> If we freeze the code then we can begin testing. I propose > >> >> >> >> >>> we wear out each and every file with /tests/devel/try > >> >> >> >> >>> including many small operands and as many different types > >> >> >> >> >>> of data as try can throw at it. > >> >> >> >> >> > >> >> >> >> >> There no point both of us running the same test on cuda1 say > >> >> >> >> >> , so who does which machine? > >> >> >> >> > > >> >> >> >> > I am currently running tests on a K8. > >> >> >> >> > > >> >> >> >> > Do you want to do cuda? > >> >> >> >> > > >> >> >> >> > That will be enough. > >> >> >> >> > > >> >> >> >> > Let me just check that: > >> >> >> >> > > >> >> >> >> > wbh...@host-57-44:~/mpir-trunk/tests/devel$ ./try -s 1-50 -r > >> >> >> >> > 10 -S 1-50 mpn_blah blah blah > >> >> >> >> > > >> >> >> >> > does something sensible according to you? > >> >> >> >> > > >> >> >> >> >>> On my machine the K8 code gets a bench of 15283 which is > >> >> >> >> >>> what it got before the conversion. Also on K10 I did cycle > >> >> >> >> >>> timings of all the functions we care about and they did not > >> >> >> >> >>> change (to within tolerances due to variations between runs > >> >> >> >> >>> of course). > >> >> >> >> >>> > >> >> >> >> >>> I'm inclined to finish the core 2 code conversion tomorrow, > >> >> >> >> >>> do some cleaning up of the C code (insert some whitespace > >> >> >> >> >>> :-)) and then release 1.0.0. It's just about as much work > >> >> >> >> >>> as releasing 0.9.1. > >> >> >> >> >> > >> >> >> >> >> wasting precious bytes with whitespace :) > >> >> >> >> > > >> >> >> >> > Now we know what is causing that 2 Trillion dollar debt!! > >> >> >> >> > > >> >> >> >> >> I thought I ran my C-code thru indent first , to use the > >> >> >> >> >> standard format , perhaps I missed some files. I really find > >> >> >> >> >> difficult to believe that people read code formated with the > >> >> >> >> >> standard amount of whitespace , I'm forever scrolling up and > >> >> >> >> >> down to try to see the rest of the > >> >> >> >> >> function.First thing I do when reading code now is to delete > >> >> >> >> >> most whitespace. > >> >> >> >> > > >> >> >> >> > Maybe I won't have much to do. I did see some code the other > >> >> >> >> > day that I would instinctively do some things to however. > >> >> >> >> > It's just a knee-jerk reaction. > >> >> >> >> > > >> >> >> >> > I used to despise whitespace too. However I did change my > >> >> >> >> > mind after certain other programmer told me my code was > >> >> >> >> > sending them crosseyed. Now I like the sense of peace that > >> >> >> >> > one gets from the whitespace. It's like having a spacious > >> >> >> >> > office as opposed to clutter. Obviously I accept it is a > >> >> >> >> > matter of preference and irrelevant in the scheme of things. > >> >> >> >> > However I have observed that the majority tend to go for > >> >> >> >> > space. > >> >> >> >> > > >> >> >> >> >>> By the way, make check still runs the yasm tests. > >> >> >> >> >> > >> >> >> >> >> It was quite a job do disable all the tests , so I left it , > >> >> >> >> >> as it doesn't effect the correctness > >> >> >> >> >> - Show quoted text - > >> >> >> >> > > >> >> >> >> > That's fine. No problem by me. > >> >> >> >> > > >> >> >> >> > Bill. > >> >> >> > > >> >> >> > - Show quoted text - > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@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 -~----------~----~----~----~------~----~------~--~---
