On Mar 6, 12:56 am, Bill Hart <goodwillh...@googlemail.com> 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!!
>
> 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
The native copyi and copyd were a major cause of speed problems on
AMD64 for Windows. They are not now used on the Windows AMD or Core2
builds.
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
-~----------~----~----~----~------~----~------~--~---
