At present I don't think we have any. This was always difficult to handle in yasm anyway and is an open ticket.
Did you write any? If not, we can safely ignore for now. I'll add a note to the relevant ticket so that gets fixed for any multifunc files in future. Do you want to update the grep in configure and do autoconf, etc. and I'll run mpirbench again to check the 2% comes back. Bill. 2009/3/5 <ja...@njkfrudils.plus.com>: > > On Thursday 05 March 2009 16:29:30 Bill Hart wrote: >> I'd prefer to change the grep to include a search for GLOBAL_FUNC mpn_name. >> > > No problem , how do we multi-function files ? > - Show quoted text - > >> 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 -~----------~----~----~----~------~----~------~--~---
