On Mar 5, 4:01 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> That's not all we've lost. There's 2% gone somewhere on core 2. I
> tried putting align # instead of alignb #,nop and it makes absolutely
> no difference to the times whatsoever.
>
> Dunno where the 2% went, but it is real, not timing fluctuations.
>
> 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 should be able to do a binary compare on *.obj files to see what
is going on.
I used to do this on GMP to check my 32-bit YASM assembly code
Obviously it would help me to know what has happened since it might
impact on the Windows code.
Brian
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
