prolly the FFT, where it is doubtlessly crucial. But it is almost all
incs and decs, which kill core2.

Bill.

2009/3/6  <ja...@njkfrudils.plus.com>:
>
>
> mpn_copy is hardly used in MPIR , so I dont understand how they could make
> that much difference.
> - Show quoted text -
> On Friday 06 March 2009 01:09:57 Bill Hart wrote:
>> Deleting them doesn't make any difference that I can see. mpirbench is
>> still 15600 on my Opteron, which is what I think it was before.
>>
>> Bill.
>>
>> 2009/3/6 Bill Hart <goodwillh...@googlemail.com>:
>> > Doing that right now.
>> >
>> > 2009/3/6  <ja...@njkfrudils.plus.com>:
>> >> On Friday 06 March 2009 00:56:42 Bill Hart wrote:
>> >>> That was it. Time jumps back to 10300 if I delete those two files.
>> >>>
>> >>> I recommend getting rid of those, or optimising them. :-)
>> >>>
>> >>> Phew!!
>> >>
>> >> I moved them as fat build needs a native copyi/d , if not we have to
>> >> write a wrapper like for mul_basecase , no problem, I'll do it in a mo
>> >> I'm more surprised they make that much difference , I think we better
>> >> check they are faster on AMD as well??
>> >
>> > - Show quoted text -
>> >
>> >> - Show quoted text -
>> >>
>> >>> Bill.
>> >>>
>> >>> 2009/3/6  <ja...@njkfrudils.plus.com>:
>> >>> > On Friday 06 March 2009 00:33:57 Bill Hart wrote:
>> >>> >> I checked all the speed times we have for this machine and they've
>> >>> >> not changed. But something is broken. Before the commit you did we
>> >>> >> have 10100, now 9500. Of course before the yasm changeover it was
>> >>> >> 10300.
>> >>> >
>> >>> > r1671 I  moved amd copyi/d  to x86_86 directory , so now they are
>> >>> > used on core2 , but even if they were junk , you wouldn't get a
>> >>> > slowdown like that
>> >>> >
>> >>> > I'm mystified
>> >>> > - Show quoted text -
>> >>> >
>> >>> >> And yeah, I mean mpirbench.
>> >>> >>
>> >>> >> Bill.
>> >>> >>
>> >>> >> 2009/3/6  <ja...@njkfrudils.plus.com>:
>> >>> >> > On Thursday 05 March 2009 23:02:50 Bill Hart wrote:
>> >>> >> >> I just don't get this. We are 10% down on what we had before on
>> >>> >> >> sage.math. I've tried deleting the files that you say we being
>> >>> >> >> left out before and that doesn't change anything.
>> >>> >> >
>> >>> >> > Welcome to the wacky world of assembler !!!!!
>> >>> >> >
>> >>> >> >> What else got changed?
>> >>> >> >
>> >>> >> > I assume you mean mpirbench ?
>> >>> >> > I cant see any differences in times for speed for
>> >>> >> > add,mul,mulbase,sqrbase - Show quoted text -
>> >>> >> >
>> >>> >> >> Bill.
>> >>> >> >>
>> >>> >> >> 2009/3/5  <ja...@njkfrudils.plus.com>:
>> >>> >> >> > On Thursday 05 March 2009 21:05:32 Bill Hart wrote:
>> >>> >> >> >> Yeah I suspect we'll have lot's of opportunity to speed up
>> >>> >> >> >> core 2 eventually.
>> >>> >> >> >>
>> >>> >> >> >> If I recall correctly it was about 4.5 c/l for core 2. Does
>> >>> >> >> >> anyone know if this is optimal?
>> >>> >> >> >
>> >>> >> >> > I've got a 4.4c/l , Agner Fog's says the thruput on 64 bit mul
>> >>> >> >> > is 4c/l , but in another section it says you can issue one
>> >>> >> >> > every cycle , if the latter section means 32bit then , 4c/l
>> >>> >> >> > could be right ( I say could not would as consider the K8) , I
>> >>> >> >> > expect I can do a bit better than 4.4c/l , but who knows.A lot
>> >>> >> >> > of the speed comes from reducing the overhead in mul_basecase.
>> >>> >> >> >
>> >>> >> >> > It quite a wide cpu , I would expect the combined
>> >>> >> >> > functions(like addlsh1) to make a real difference on it.
>> >>> >> >> > - Show quoted text -
>> >>> >> >> >
>> >>> >> >> >> Supposedly you can do 4 or even 5 instructions at once with
>> >>> >> >> >> instruction fusion.
>> >>> >> >> >>
>> >>> >> >> >> Bill.
>> >>> >> >> >>
>> >>> >> >> >> On 05/03/2009, ja...@njkfrudils.plus.com
>> >>> >> >> >> <ja...@njkfrudils.plus.com>
>> >>> >> >
>> >>> >> > wrote:
>> >>> >> >> >> > the functions missed out were
>> >>> >> >> >> > addadd
>> >>> >> >> >> > addsub
>> >>> >> >> >> > addlsh
>> >>> >> >> >> > sublsh
>> >>> >> >> >> > the 2% due to them is not bad , considering they were
>> >>> >> >> >> > written for an AMD chip.
>> >>> >> >> >> > The other new functions like redc,sumdiff are used
>> >>> >> >> >> > unconditionally
>> >>> >> >> >> >
>> >>> >> >> >> > I think sumdiff is still in the optional section of
>> >>> >> >> >> > configure , must change this some time , it's confusing ,
>> >>> >> >> >> > but it doesn't hurt.
>> >>> >> >> >> >
>> >>> >> >> >> > On Thursday 05 March 2009 18:42:20 Bill Hart wrote:
>> >>> >> >> >> >> If the mpirbench is about 10300 on sage.math then it
>> >>> >> >> >> >> worked.
>> >>> >> >> >> >>
>> >>> >> >> >> >> I can't check it till I'm home.
>> >>> >> >> >> >>
>> >>> >> >> >> >> Bill.
>> >>> >> >> >> >>
>> >>> >> >> >> >> On 05/03/2009, ja...@njkfrudils.plus.com
>> >>> >> >> >> >> <ja...@njkfrudils.plus.com>
>> >>> >> >> >> >>
>> >>> >> >> >> >> wrote:
>> >>> >> >> >> >> > commited , and I think I should be
>> >>> >> >> >> >> >
>> >>> >> >> >> >> > On Thursday 05 March 2009 17:50:59
>> >>> >> >> >> >> > ja...@njkfrudils.plus.com
>> >>> >
>> >>> > wrote:
>> >>> >> >> >> >> >> Done it , just cant commit at the moment !!!
>> >>> >> >> >> >> >>
>> >>> >> >> >> >> >> On Thursday 05 March 2009 17:43:04 Bill Hart wrote:
>> >>> >> >> >> >> >> > Damnit I am still not getting anything in config.h. I
>> >>> >> >> >> >> >> > must be doing something wrong. I'm going to let Jason
>> >>> >> >> >> >> >> > fix this. Perhaps dos2unix isn't doing the job.
>> >>> >> >> >> >> >> >
>> >>> >> >> >> >> >> > I have to go out for a few hours.
>> >>> >> >> >> >> >> >
>> >>> >> >> >> >> >> > Bill.
>> >>> >> >> >> >> >> >
>> >>> >> >> >> >> >> > 2009/3/5 Bill Hart <goodwillh...@googlemail.com>:
>> >>> >> >> >> >> >> > > It's not clear to me why WinSCP didn't change the
>> >>> >> >> >> >> >> > > line endings. It probably didn't identify the files
>> >>> >> >> >> >> >> > > as text files.
>> >>> >> >> >> >> >> > >
>> >>> >> >> >> >> >> > > Bill.
>> >>> >> >> >> >> >> > >
>> >>> >> >> >> >> >> > > 2009/3/5 Bill Hart <goodwillh...@googlemail.com>:
>> >>> >> >> >> >> >> > > - Show quoted text -
>> >>> >> >> >> >> >> > >
>> >>> >> >> >> >> >> > >> Should do the same for all files in
>> >>> >> >> >> >> >> > >> /mpn/x86_64/core2, /mpn/x86_64/amd64 and
>> >>> >> >> >> >> >> > >> /mpn/x86_64/amd64/k10
>> >>> >> >> >> >> >> > >>
>> >>> >> >> >> >> >> > >> It's just a matter of running dos2unix *.as in each
>> >>> >> >> >> >> >> > >> dir I think.
>> >>> >> >> >> >> >> > >>
>> >>> >> >> >> >> >> > >> Bill.
>> >>> >> >> >> >> >> > >>
>> >>> >> >> >> >> >> > >> 2009/3/5  <ja...@njkfrudils.plus.com>:
>> >>> >> >> >> >> >> > >>> On Thursday 05 March 2009 17:37:31 Cactus wrote:
>> >>> >> >> >> >> >> > >>>> On Mar 5, 5:37 pm, ja...@njkfrudils.plus.com
> wrote:
>> >>> >> >> >> >> >> > >>>> > must be Brian script , they are all full of
>> >>> >> >> >> >> >> > >>>> > "\r" which of course means the matching name is
>> >>> >> >> >> >> >> > >>>> > mpn_name\r not mpn_name removing the "\r" is
>> >>> >> >> >> >> >> > >>>> > easy on all files, but we will probably hit the
>> >>> >> >> >> >> >> > >>>> > problem again , and/or I can put a tr -d "\r"
>> >>> >> >> >> >> >> > >>>> > to delete all "\r" in that specific piece of
>> >>> >> >> >> >> >> > >>>> > configure We could hit the problem in other
>> >>> >> >> >> >> >> > >>>> > places!!!
>> >>> >> >> >> >> >> > >>>>
>> >>> >> >> >> >> >> > >>>> Only because you got me to run it on Windows. My
>> >>> >> >> >> >> >> > >>>> guess is that it
>> >>> >> >> >> >> >> > >>>> would produce the right line endings if the
>> >>> >> >> >> >> >> > >>>> Python code was run on Linux
>> >>> >> >> >> >> >> > >>>
>> >>> >> >> >> >> >> > >>> Great , if it only those few that Bill asked you
>> >>> >> >> >> >> >> > >>> to convert , then
>> >>> >> >> >> >> >> > >>> I'll delete the \r and leave the configure script
>> >>> >> >> >> >> >> > >>> alone - Show quoted text -
>> >>> >> >> >> >> >> > >>
>> >>> >> >> >> >> >> > >> - Show quoted text -
>> >>> >> >> >> >> >> > >>
>> >>> >> >> >> >> >> > >>>>     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
-~----------~----~----~----~------~----~------~--~---

Reply via email to