Thanks, it works ok now, both "core2" and "nocona". However, the
benchmark seems to favor using "nocona" for a very slight margin, even
if nocona will not include lahf/sahf code, but it includes core2 asm
code otherwise. This must be the gcc optimization with -mtune=nocona
instead of -mtune=core2.
On Sun, Mar 15, 2009 at 1:36 PM, Jason Moxham wrote:
>
> On Sunday 15 March 2009 17:29:30 Jason Martin wrote:
>> > On Sunday 15 March 2009 17:03:51 Jason Martin wrote:
>> >> Hi Guys,
>> >>
>> >> Sorry for the late reply, but I've been camping for the last couple
>> >> days...
>> >>
>> >> I believ
On Sunday 15 March 2009 17:29:30 Jason Martin wrote:
> > On Sunday 15 March 2009 17:03:51 Jason Martin wrote:
> >> Hi Guys,
> >>
> >> Sorry for the late reply, but I've been camping for the last couple
> >> days...
> >>
> >> I believe that I can rewrite the core2 code to avoid the lahf/sahf
> >> i
> On Sunday 15 March 2009 17:03:51 Jason Martin wrote:
>> Hi Guys,
>>
>> Sorry for the late reply, but I've been camping for the last couple days...
>>
>> I believe that I can rewrite the core2 code to avoid the lahf/sahf
>> instructions without any performance lost. If there is still an
>> inter
On Sunday 15 March 2009 17:03:51 Jason Martin wrote:
> Hi Guys,
>
> Sorry for the late reply, but I've been camping for the last couple days...
>
> I believe that I can rewrite the core2 code to avoid the lahf/sahf
> instructions without any performance lost. If there is still an
> interested or
Hi Guys,
Sorry for the late reply, but I've been camping for the last couple days...
I believe that I can rewrite the core2 code to avoid the lahf/sahf
instructions without any performance lost. If there is still an
interested or need, let me know and I'll have a go at it.
--jwm
On Sun, Mar
On Sunday 15 March 2009 04:55:39 Gonzalo Tornaria wrote:
> As I mentioned, in current tr...@1739, my nocona is detected as a
> "core2" by config.guess, since it does include lahf.
>
> However, I tried hacking config.guess so that my cpu returns "nocona"
> instead --- just because I wanted to bench
Done ,
remove crlf from old add/sub_n and remove yasm macros from GLOBAL_FUNC names
On Sunday 15 March 2009 06:05:04 Bill Hart wrote:
> Damn. It's grepping for GLOBAL_FUNC and finding yasm macros and not
> expanding them I think. Hopefully we can fix that.
>
> Bill.
>
> 2009/3/15 Gonzalo Tornar
Damn. It's grepping for GLOBAL_FUNC and finding yasm macros and not
expanding them I think. Hopefully we can fix that.
Bill.
2009/3/15 Gonzalo Tornaria :
>
> As I mentioned, in current tr...@1739, my nocona is detected as a
> "core2" by config.guess, since it does include lahf.
>
> However, I tr
As I mentioned, in current tr...@1739, my nocona is detected as a
"core2" by config.guess, since it does include lahf.
However, I tried hacking config.guess so that my cpu returns "nocona"
instead --- just because I wanted to benchmark it that way (and also
would be a test of what happens when co
Thanks for the help with mpirbench. I wouldn't call that "just work",
so I redid the script to be more "automatic". It's pretty small when
binaries are not included (hint, hint), so I'm attaching it (I hope it
will make it through the lists).
To use
1) untar it
2) ./runbench
This figures out wh
On Sunday 15 March 2009 01:32:23 Bill Hart wrote:
> I was thinking of the original yasm one we had from converting
> Pierrick Gaudry's code, i.e. what was there before we switched to your
> code. It was probably in the amd64 directory before you revolutionised
> it.
>
> Bill.
>
Done
> 2009/3/
mpirbench will definitely be released as part of or very shortly after
mpir-1.0.0 (due out on Monday I believe), but as a separate package on
the website. It should "just work TM".
Roughly speaking here is what you have to do to get it going atm:
1) download the mpirbench-0.1.tar.gz from the fil
My nocona with lahf is now a "core2-unknown-linux-gnu". Thanks for
upgrading it for me... I hope it still keeps my office warm in winter
:-)
Gonzalo
On Sat, Mar 14, 2009 at 10:29 PM, Jason Moxham
wrote:
>
> On Sunday 15 March 2009 00:49:33 Bill Hart wrote:
>> We can do similar to Brian and put
I was thinking of the original yasm one we had from converting
Pierrick Gaudry's code, i.e. what was there before we switched to your
code. It was probably in the amd64 directory before you revolutionised
it.
Bill.
2009/3/15 Jason Moxham :
>
> On Sunday 15 March 2009 00:49:33 Bill Hart wrote:
>>
On Sunday 15 March 2009 00:49:33 Bill Hart wrote:
> We can do similar to Brian and put the old assembler in for add_n and
> sub_n for nocona.
>
svn, and commited , the nocona with no lahf will use mpn/x86_64/add_n.as ,
which at the moment is GMP's old one.I assume you mean an other one.
> He
On Sat, Mar 14, 2009 at 3:13 PM, Bill Hart wrote:
>
> OK, but I'm still unclear why it doesn't pick up the files in the
> core2 directory. That is what it should do based on the code that is
> there. This means noconas are giving a generic C build, which I am
> sure Gonzalo would have complained
Amazing that someone implemented transcendental functions on the 6502,
which didn't have even a multiply unit.
http://www.6502.org/source/
Bill.
2009/3/15 Jason Moxham :
>
> On Sunday 15 March 2009 00:49:33 Bill Hart wrote:
>> We can do similar to Brian and put the old assembler in for add_n an
On Sunday 15 March 2009 00:49:33 Bill Hart wrote:
> We can do similar to Brian and put the old assembler in for add_n and
> sub_n for nocona.
>
> Heh, I've just been reading instruction sets for old CPU's. I think
> the 8086 must have been the first main processor of Intel's to have a
> mul instru
We can do similar to Brian and put the old assembler in for add_n and
sub_n for nocona.
Heh, I've just been reading instruction sets for old CPU's. I think
the 8086 must have been the first main processor of Intel's to have a
mul instruction. I hadn't realised that.
I wonder if there were earlie
On Saturday 14 March 2009 23:11:07 Bill Hart wrote:
> I think we should examine the feature flag in config.guess for
> LAHF-SAHF. Here is an incomplete list of 64 bit Pentium 4's without
> the feature:
>
> Pentium 4 506 E0
> Pentium 4 516 E0
> Pentium 4 511 E0
> Pentium 4 519K E0
> Pentium 4 HT 52
I think we should examine the feature flag in config.guess for
LAHF-SAHF. Here is an incomplete list of 64 bit Pentium 4's without
the feature:
Pentium 4 506 E0
Pentium 4 516 E0
Pentium 4 511 E0
Pentium 4 519K E0
Pentium 4 HT 521
Pentium 4 HT 531
Pentium 4 HT 541
Pentium 4 HT 551
Pentium 4 HT 561
On Mar 14, 7:42 pm, Bill Hart wrote:
> OK, can you try autotools and commit again. I went back to revision
> 1730 and made the changes again, this time hopefully without breaking
> everything else.
>
> Really odd it didn't tell me my revision was out of date. It usually
> does if commits cross
Well that is bizarre. It is totally fine after deleting the directory
and checking it out again. Somehow my files had gotten corrupted. It's
all good now though.
configure, make, make check all pass on sage.math.
Bill.
2009/3/14 Bill Hart :
> Hmm, currently configure is well and truly broken on
Hmm, currently configure is well and truly broken on sage.math. Did
something go wrong during autoconf.
Bill.
2009/3/14 Jason Moxham :
>
> On Saturday 14 March 2009 19:42:33 Bill Hart wrote:
>> OK, can you try autotools and commit again. I went back to revision
>> 1730 and made the changes again
On Saturday 14 March 2009 19:42:33 Bill Hart wrote:
> OK, can you try autotools and commit again. I went back to revision
> 1730 and made the changes again, this time hopefully without breaking
> everything else.
>
done
> Really odd it didn't tell me my revision was out of date. It usually
> doe
OK, can you try autotools and commit again. I went back to revision
1730 and made the changes again, this time hopefully without breaking
everything else.
Really odd it didn't tell me my revision was out of date. It usually
does if commits cross in the aether.
Bill.
2009/3/14 Bill Hart :
> Oh d
Oh dear, I think I didn't. I'll back it out and try again.
Bill.
2009/3/14 Jason Moxham :
>
> On Saturday 14 March 2009 19:14:50 Bill Hart wrote:
>> That's an excellent solution. Now we just need to fix linux so that it
>> still works on these systems. Oh joy!
>>
>> Bill.
>>
>> 2009/3/14 Cactus
On Saturday 14 March 2009 19:14:50 Bill Hart wrote:
> That's an excellent solution. Now we just need to fix linux so that it
> still works on these systems. Oh joy!
>
> Bill.
>
> 2009/3/14 Cactus :
> > On Mar 14, 7:03 pm, Jason Moxham wrote:
> >> On Saturday 14 March 2009 18:35:32 Bill Hart wrote
That's an excellent solution. Now we just need to fix linux so that it
still works on these systems. Oh joy!
Bill.
2009/3/14 Cactus :
>
>
>
> On Mar 14, 7:03 pm, Jason Moxham wrote:
>> On Saturday 14 March 2009 18:35:32 Bill Hart wrote:
>>
>> > OK, found the problem. Nocona now builds with core
Yeah the newer versions of autotools work fine for me, they just break
the build on Darwin for reasons beyond me (actually I have a
theory) . At least we know the old version doesn't screw anything
up.
Bill.
2009/3/14 Jason Moxham :
>
> On Saturday 14 March 2009 18:35:32 Bill Hart wrote:
>>
On Mar 14, 7:03 pm, Jason Moxham wrote:
> On Saturday 14 March 2009 18:35:32 Bill Hart wrote:
>
> > OK, found the problem. Nocona now builds with core2 code. Can you
> > autoconf this and commit.
>
> I can install my old autotools on another machine, in a few hours.
> The new autotools require
On Saturday 14 March 2009 18:35:32 Bill Hart wrote:
> OK, found the problem. Nocona now builds with core2 code. Can you
> autoconf this and commit.
>
I can install my old autotools on another machine, in a few hours.
The new autotools require ylwrap , which I added with
automake --add-missing
yl
And I agree, I think we should clean up the whole
config.guess/configfsf.sub and configure.in for a service release.
Bill.
2009/3/14 Bill Hart :
> OK, found the problem. Nocona now builds with core2 code. Can you
> autoconf this and commit.
>
> So now we need to exclude those broken models after
OK, found the problem. Nocona now builds with core2 code. Can you
autoconf this and commit.
So now we need to exclude those broken models after all. :-)
No need for a full round of testing. We only need to check that
configure still works on all the machines we've tested for and just
randomly te
On Saturday 14 March 2009 18:13:00 Bill Hart wrote:
> OK, but I'm still unclear why it doesn't pick up the files in the
> core2 directory. That is what it should do based on the code that is
> there. This means noconas are giving a generic C build, which I am
> sure Gonzalo would have complained a
OK, but I'm still unclear why it doesn't pick up the files in the
core2 directory. That is what it should do based on the code that is
there. This means noconas are giving a generic C build, which I am
sure Gonzalo would have complained about by now if it was the case,
because he has a nocona.
Bi
On Saturday 14 March 2009 18:07:59 Bill Hart wrote:
> I get:
>
> wbh...@sage:~/mpir-test$ ./configure --build=nocona-unknown-gnu-linux
> checking build system type... Invalid configuration
> `nocona-unknown-gnu-linux': machine `nocona-unknown-gnu' not
> recognized
> configure: error: /bin/bash ./c
I was going to suggest a reorganization of the x86_64/32? because its a mess ,
but I was waiting until after MPIR-1.0.0 was release.
Do we want to change now or wait till after?
On Saturday 14 March 2009 18:02:14 Bill Hart wrote:
> I think we should have 64 bit amd's identify as amd64 not x86
I get:
wbh...@sage:~/mpir-test$ ./configure --build=nocona-unknown-gnu-linux
checking build system type... Invalid configuration
`nocona-unknown-gnu-linux': machine `nocona-unknown-gnu' not
recognized
configure: error: /bin/bash ./config.sub nocona-unknown-gnu-linux failed
I think config.sub is
I think we should have 64 bit amd's identify as amd64 not x86_64, then
use i786 and/or x86_64 to identify these broken chips.
As for p4mmxsse2, the current configure.in seems to get around this by
assuming all p4's support sse2. Not sure if that is actually true. So
that is probably broken.
Bill
On Saturday 14 March 2009 17:59:00 Bill Hart wrote:
> Are you sure about that:
>
> case $host in
> x86_64-*-* | i786-*-*)
> path_64="x86_64/amd64 x86_64" ;;
> k10-*-*)
> path_64="x86_64/amd64/k10 x86_64/amd64 x86_64" ;;
> nocona-*-* | core2-*-*
On Mar 14, 5:53 pm, Bill Hart wrote:
> This problem is quite difficult to deal with. I thought about it on
> the way home, and I don't want to have config.guess return:
>
> nocona-lahf-unknown-gnu-linux
>
> How does the 32 bit code decide if MMX is available etc? I suppose
> config.guess return
Are you sure about that:
case $host in
x86_64-*-* | i786-*-*)
path_64="x86_64/amd64 x86_64" ;;
k10-*-*)
path_64="x86_64/amd64/k10 x86_64/amd64 x86_64" ;;
nocona-*-* | core2-*-*)
<<-
path_64="x86_
On Saturday 14 March 2009 17:41:58 Jason Moxham wrote:
> Early Intel CPUs with Intel 64 lacked LAHF and SAHF instructions available
> in AMD64 until introduction of Pentium 4 G1 step in December 2005. LAHF and
> SAHF are load and store instructions, respectively, for certain status
> flags. These
This problem is quite difficult to deal with. I thought about it on
the way home, and I don't want to have config.guess return:
nocona-lahf-unknown-gnu-linux
How does the 32 bit code decide if MMX is available etc? I suppose
config.guess returns p4mmx. That's just nasty. Feature flags should be
Early Intel CPUs with Intel 64 lacked LAHF and SAHF instructions available in
AMD64 until introduction of Pentium 4 G1 step in December 2005. LAHF and SAHF
are load and store instructions, respectively, for certain status flags.
These instructions are used for virtualization and floating-poi
On Sat, Mar 14, 2009 at 1:45 PM, Jason Moxham wrote:
>
>
> I pretty sure all core2 cpus have lahf,sahf , it's just some Pentium D dont
> have it . You can test the lahf_lm feature bit in cpuid to see if it's got it
Tested in:
My laptop: model 6 / family 15 (core 2 duo T5300).
My desktop is fami
On Mar 14, 4:45 pm, Jason Moxham wrote:
> I pretty sure all core2 cpus have lahf,sahf , it's just some Pentium D dont
> have it . You can test the lahf_lm feature bit in cpuid to see if it's got it
>
> On Saturday 14 March 2009 16:40:10 Cactus wrote:
>
> > The Core2 assembler code for mpn_add_n
I pretty sure all core2 cpus have lahf,sahf , it's just some Pentium D dont
have it . You can test the lahf_lm feature bit in cpuid to see if it's got it
On Saturday 14 March 2009 16:40:10 Cactus wrote:
> The Core2 assembler code for mpn_add_n (and mpn_sub_n?) uses the lahf
> and sahf op codes
50 matches
Mail list logo
