On Mar 15, 1:16 pm, Jeff Gilchrist wrote:
> So I was unable to run the latest speed tests on the Linux 64bit live
> CD that works on my Q9550 since it only contains Python 2.5 but I did
> get a chance to run some benchmarks one of my GMP programs so we have
> some real-world tests on a subset o
So I was unable to run the latest speed tests on the Linux 64bit live
CD that works on my Q9550 since it only contains Python 2.5 but I did
get a chance to run some benchmarks one of my GMP programs so we have
some real-world tests on a subset of MPIR. You can see a very nice
progression from MPI
On Sat, Mar 14, 2009 at 7:31 AM, Cactus wrote:
> I have updated it again today (14 March) to increase its coverage.
Here is my Core2 Q9550 in Vista 64bit again with the updated version.
Machine: Intel64 Family 6 Model 23 Stepping 7, GenuineIntel
Running: Windows-Vista-6.0.6001-SP1
SPEED CURVE
On Mar 13, 12:12 am, Cactus wrote:
> On Mar 12, 5:31 pm, Cactus wrote:
>
>
>
> > On Mar 12, 5:11 pm, Jeff Gilchrist wrote:
>
> > > On Thu, Mar 12, 2009 at 1:02 PM, Cactus wrote:
> > > > If the parameters change a lot I have found it necessary to repeat the
> > > > process to get the best par
On Mar 12, 5:31 pm, Cactus wrote:
> On Mar 12, 5:11 pm, Jeff Gilchrist wrote:
>
>
>
> > On Thu, Mar 12, 2009 at 1:02 PM, Cactus wrote:
> > > If the parameters change a lot I have found it necessary to repeat the
> > > process to get the best parameters.
>
> > The numbers keep changing so it i
On Mar 12, 5:11 pm, Jeff Gilchrist wrote:
> On Thu, Mar 12, 2009 at 1:02 PM, Cactus wrote:
> > If the parameters change a lot I have found it necessary to repeat the
> > process to get the best parameters.
>
> The numbers keep changing so it is hard to tell which one is "best".
>
> > None of t
On Thu, Mar 12, 2009 at 1:02 PM, Cactus wrote:
> If the parameters change a lot I have found it necessary to repeat the
> process to get the best parameters.
The numbers keep changing so it is hard to tell which one is "best".
> None of the Windows 32-bit parameter files have changed in severa
On Mar 12, 4:39 pm, Jeff Gilchrist wrote:
> On Thu, Mar 12, 2009 at 11:28 AM, Cactus wrote:
> > Tune fails on Windows and it looks like it is an optimisation bug.
>
> > Jeff can you turn off 'whole program optimisation' for the three
> > builds in the VC++ speed project and test tune again?
>
That sounds correct.
2009/3/12 Jeff Gilchrist :
>
> On Thu, Mar 12, 2009 at 11:28 AM, Cactus wrote:
>
>> Tune fails on Windows and it looks like it is an optimisation bug.
>>
>> Jeff can you turn off 'whole program optimisation' for the three
>> builds in the VC++ speed project and test tune aga
On Thu, Mar 12, 2009 at 11:28 AM, Cactus wrote:
> Tune fails on Windows and it looks like it is an optimisation bug.
>
> Jeff can you turn off 'whole program optimisation' for the three
> builds in the VC++ speed project and test tune again?
>
> You need to turn off both 'link time code generato
I just did configure on a core 2 with linux and no probs there either.
This was with a freshly checked out head revision from svn.
I've specifically noticed this issue if either a very old gcc is
present (type gcc -v to check the version) or if gcc needs
LD_LIBRARY_PATH to be set in order for its
On Thursday 12 March 2009 15:56:37 Bill Hart wrote:
> Ah, so specifically the functions in this file are not being used in
> the yasm build because the have native things are not being set!!
>
> Bill.
Yes
doing a
./configure --build=core2-unknown-linux-gnu
is OK on my K8 , so I not sure whats go
Ah, so specifically the functions in this file are not being used in
the yasm build because the have native things are not being set!!
Bill.
2009/3/12 :
>
> On Thursday 12 March 2009 15:12:53 Jeff Gilchrist wrote:
>> I'm not having much luck today. I went to try the latest SVN (1720)
>> code on
The only thing I can think of is the APPLE stuff I put into mpir-h.in.
Any chance you could check out a previous revision and double check.
Usually when I get this error, some path is set incorrectly on my
machine. Checking that the previous revision actually works will
eliminate this possibility
So it is.
We also should implement mpn_add_nc, it is useful for lots of things.
Bill.
2009/3/12 :
>
> On Thursday 12 March 2009 15:12:53 Jeff Gilchrist wrote:
>> I'm not having much luck today. I went to try the latest SVN (1720)
>> code on Linux 64bit on the same Core2 machine and configure f
On Thursday 12 March 2009 15:12:53 Jeff Gilchrist wrote:
> I'm not having much luck today. I went to try the latest SVN (1720)
> code on Linux 64bit on the same Core2 machine and configure fails:
>
> j...@ubuntu:~/mpir/mpir-svn-1720$ ./configure
> checking build system type... core2-unknown-linux-
On Mar 12, 2:31 pm, Bill Hart wrote:
> I'll try to run the linux version on a p4 and see if it looks like a
> general issue or one that only affects the windows code. But it might
> take me a day to get to. Today is another short day.
>
> Bill.
>
> 2009/3/12 Jeff Gilchrist :
>
>
>
> > On Thu, Ma
On Thu, Mar 12, 2009 at 11:17 AM, Bill Hart wrote:
> Is it an Apple system?
No, a run of the mill DELL system. The previous SVN build that I was
doing speed tests for works fine on the same system, something has
changed since then that broke it.
I'm using Ubuntu 8.10 64bit.
Jeff.
--~--~
Is it an Apple system?
2009/3/12 Jeff Gilchrist :
>
> I'm not having much luck today. I went to try the latest SVN (1720)
> code on Linux 64bit on the same Core2 machine and configure fails:
>
> j...@ubuntu:~/mpir/mpir-svn-1720$ ./configure
> checking build system type... core2-unknown-linux-gnu
I'm not having much luck today. I went to try the latest SVN (1720)
code on Linux 64bit on the same Core2 machine and configure fails:
j...@ubuntu:~/mpir/mpir-svn-1720$ ./configure
checking build system type... core2-unknown-linux-gnu
checking host system type... core2-unknown-linux-gnu
checking
On Thursday 12 March 2009 14:23:35 Jeff Gilchrist wrote:
> On Thu, Mar 12, 2009 at 10:20 AM, Cactus wrote:
> > This can happen when tune cannot get a stable result.
> > Does it fail consistently at the same point?
>
> Yes, I just ran it about 6 times and it always fails after it displays
> the #d
On Mar 12, 2:27 pm, Cactus wrote:
> On Mar 12, 2:23 pm, Jeff Gilchrist wrote:
>
> > On Thu, Mar 12, 2009 at 10:20 AM, Cactus wrote:
> > > This can happen when tune cannot get a stable result.
> > > Does it fail consistently at the same point?
>
> > Yes, I just ran it about 6 times and it alwa
I'll try to run the linux version on a p4 and see if it looks like a
general issue or one that only affects the windows code. But it might
take me a day to get to. Today is another short day.
Bill.
2009/3/12 Jeff Gilchrist :
>
> On Thu, Mar 12, 2009 at 10:20 AM, Cactus wrote:
>
>> This can happe
On Mar 12, 2:23 pm, Jeff Gilchrist wrote:
> On Thu, Mar 12, 2009 at 10:20 AM, Cactus wrote:
> > This can happen when tune cannot get a stable result.
> > Does it fail consistently at the same point?
>
> Yes, I just ran it about 6 times and it always fails after it displays
> the #define GCDEXT
If that is what it is, it is a known bug, but a bug nonetheless.
The aim will be to fix that for the service release coming after 1.0.0.
Re-running it *should* work. But please let us know if not. Of course
it will fail more if the machine has heavy load.
Bill.
2009/3/12 Cactus :
>
>
>
> On Ma
On Thu, Mar 12, 2009 at 10:20 AM, Cactus wrote:
> This can happen when tune cannot get a stable result.
> Does it fail consistently at the same point?
Yes, I just ran it about 6 times and it always fails after it displays
the #define GCDEXT_THRESHOLD line. There system is not loaded either
so
Hi Jeff,
does it happen every time you run tune?
Bill.
2009/3/12 Jeff Gilchrist :
>
> On Thu, Mar 12, 2009 at 9:38 AM, Cactus wrote:
>
>> After compiling MPIR and speed you should be able to run run-
>> speed.py. It runs either in build.vc9 or where Linux puts speed.
>
> I'm in the process of
On Mar 12, 2:16 pm, Jeff Gilchrist wrote:
> On Thu, Mar 12, 2009 at 9:38 AM, Cactus wrote:
> > After compiling MPIR and speed you should be able to run run-
> > speed.py. It runs either in build.vc9 or where Linux puts speed.
>
> I'm in the process of building 32bit MSVC Express code. MPIR co
On Thu, Mar 12, 2009 at 9:38 AM, Cactus wrote:
> After compiling MPIR and speed you should be able to run run-
> speed.py. It runs either in build.vc9 or where Linux puts speed.
I'm in the process of building 32bit MSVC Express code. MPIR compiles
using the p4 porject fine but when I run tune,
On Mar 12, 1:08 pm, Jeff Gilchrist wrote:
> On Thu, Mar 12, 2009 at 5:48 AM, Cactus wrote:
> > It requires the new version of speed with my recent 'start(step)end'
> > modification.
>
> > At the moment run-speed.py expects Python 2.6 or later. It expects to
> > run on Linux in the directory in
On Thu, Mar 12, 2009 at 5:48 AM, Cactus wrote:
> It requires the new version of speed with my recent 'start(step)end'
> modification.
>
> At the moment run-speed.py expects Python 2.6 or later. It expects to
> run on Linux in the directory in which speed.exe is located. In the
> Windows VC++ bui
On Mar 10, 1:37 pm, Bill Hart wrote:
> Both of those proposed changes actually sound really useful to me. +1 from me.
>
> Bill.
>
> 2009/3/10 Cactus :
>
>
>
> > Hi All,
>
> > I have been using speed to track down Windows MPIR performance issues
> > and I have made local changes to speed that mi
Both of those proposed changes actually sound really useful to me. +1 from me.
Bill.
2009/3/10 Cactus :
>
> Hi All,
>
> I have been using speed to track down Windows MPIR performance issues
> and I have made local changes to speed that might be of more general
> interest. I hence wnat top get y
33 matches
Mail list logo
