I'd prefer to change the grep to include a search for GLOBAL_FUNC mpn_name.
Bill. 2009/3/5 <ja...@njkfrudils.plus.com>: > > On Thursday 05 March 2009 16:19:32 Bill Hart wrote: >> Even if it is by filename, it might not recognise them now that they >> are .as files. > > > looks like it just grep's *.asm or *.as for the keyword PROLOGUE(mpn_name) > so perhaps we could put PROLOGUE(mpn_name) in the *.as as a empty macro? > - Show quoted text - > >> >> 2009/3/5 Bill Hart <goodwillh...@googlemail.com>: >> > Don't the M4 macros PROLOGUE(mpn_blah) in the .asm files trigger this? >> > Now that they are .as files with GLOBAL_FUNC mpn_blah instead of >> > PROLOGUE(mpn_blah) it just thinks the functions don't exist. Or does >> > it do by filename. >> > >> > Bill. >> > >> > 2009/3/5 <ja...@njkfrudils.plus.com>: >> >> 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 >> > >> > - Show quoted text - >> > >> >> - Show quoted text - >> >> >> >>> 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 -~----------~----~----~----~------~----~------~--~---
