Loading ...
Sorry, an error occurred while loading the content.
 

Re: GGNFS on PowePC64 (970)

Expand Messages
  • Mark Rodenkirch
    I think that the problem is with gcc. I had the same problem on MacIntel, but when I changed src/makefile to use -O2 instead of -O3, the problem went away.
    Message 1 of 27 , Dec 4, 2007
      I think that the problem is with gcc. I had the same problem on MacIntel, but when I
      changed src/makefile to use -O2 instead of -O3, the problem went away.

      I'm doing some more tests to see if any other problems crop up.

      BTW, I see that the sqrt() bug hasn't been resolved. This was last discussed in 2006. The
      bug runs sqrt() and stops because r1=1 or r2=1. I have both a MacPPC and MacIntel and
      will run some comparisons in an effort to determine where the problem is. On MacPPC I
      see this bug crop up off. I haven't run a test through from start to finish on MacIntel, but
      if it factors the same input that MacPPC doesn't, then it will give me something to work
      on. My first attempt will be to change optimization to -O2 on MacPPC to see if it solves
      the problem.

      --Mark

      --- In ggnfs@yahoogroups.com, Croco Dille <cobete1@...> wrote:
      >
      > I'm using gcc 3.3.3 on Suse Linux Enterprise Server 9.
      > Kernel version 2.6.5-7.244-pseries64.
      > Latest sources on cvs (anonymous).
      > Thanks
      >
      > PD: Sending again because yahoo messed the previous message.
    • Mark Rodenkirch
      OK, I just discovered that I was too hasty with this conclusion. It appears that the last step of make calls strip which removes all symbols from the object
      Message 2 of 27 , Dec 4, 2007
        OK, I just discovered that I was too hasty with this conclusion.  It appears that the last step of make calls "strip" which removes all symbols from the object file.  I removed the strip step from src/Makefile and it was able to get past procrels.  Unfortunately it does not resolve the sqrt() bug.

        In other words, I completed a factorization on MacIntel after removing strip from src/Makefile.  MacIntel factors tst250 correctly while MacPPC demonstrates the sqrt() issue.  I will spend some time on this tomorrow in hope of discovering where the problem is in sqrt() or at least narrowing it down.

        --Mark

        On Dec 4, 2007, at 8:19 PM, Mark Rodenkirch wrote:

        I think that the problem is with gcc. I had the same problem on MacIntel, but when I 
        changed src/makefile to use -O2 instead of -O3, the problem went away.

        I'm doing some more tests to see if any other problems crop up.

        BTW, I see that the sqrt() bug hasn't been resolved. This was last discussed in 2006. The 
        bug runs sqrt() and stops because r1=1 or r2=1. I have both a MacPPC and MacIntel and 
        will run some comparisons in an effort to determine where the problem is. On MacPPC I 
        see this bug crop up off. I haven't run a test through from start to finish on MacIntel, but 
        if it factors the same input that MacPPC doesn't, then it will give me something to work 
        on. My first attempt will be to change optimization to -O2 on MacPPC to see if it solves 
        the problem.

        --Mark

      • gchil0
        This sqrt bug is the main thing that prompted me to abandon the GGNFS post-processing tools as soon as msieve was capable of finishing the factorizations.
        Message 3 of 27 , Dec 4, 2007
          This sqrt bug is the main thing that prompted me to abandon the GGNFS
          post-processing tools as soon as msieve was capable of finishing the
          factorizations. It's an extra step to prepare the input files for
          msieve, but not having to worry if I'll get the factors in the end is
          worth it. Not to mention that msieve's block Lanczos implementation
          is much faster.

          When I get time, I plan to modify factLat.pl to use msieve for the
          postprocessing automatically, but that probably won't happen for a
          month or so.

          Greg

          --- In ggnfs@yahoogroups.com, Mark Rodenkirch <mgrogue@...> wrote:
          >
          > OK, I just discovered that I was too hasty with this conclusion. It
          > appears that the last step of make calls "strip" which removes all
          > symbols from the object file. I removed the strip step from src/
          > Makefile and it was able to get past procrels. Unfortunately it does
          > not resolve the sqrt() bug.
          >
          > In other words, I completed a factorization on MacIntel after removing
          > strip from src/Makefile. MacIntel factors tst250 correctly while
          > MacPPC demonstrates the sqrt() issue. I will spend some time on this
          > tomorrow in hope of discovering where the problem is in sqrt() or at
          > least narrowing it down.
          >
          > --Mark
          >
          > On Dec 4, 2007, at 8:19 PM, Mark Rodenkirch wrote:
          >
          > > I think that the problem is with gcc. I had the same problem on
          > > MacIntel, but when I
          > > changed src/makefile to use -O2 instead of -O3, the problem went away.
          > >
          > > I'm doing some more tests to see if any other problems crop up.
          > >
          > > BTW, I see that the sqrt() bug hasn't been resolved. This was last
          > > discussed in 2006. The
          > > bug runs sqrt() and stops because r1=1 or r2=1. I have both a MacPPC
          > > and MacIntel and
          > > will run some comparisons in an effort to determine where the
          > > problem is. On MacPPC I
          > > see this bug crop up off. I haven't run a test through from start to
          > > finish on MacIntel, but
          > > if it factors the same input that MacPPC doesn't, then it will give
          > > me something to work
          > > on. My first attempt will be to change optimization to -O2 on MacPPC
          > > to see if it solves
          > > the problem.
          > >
          > > --Mark
          >
        • mgrogue@wi.rr.com
          That would be awesome. Please keep up posted on your progress. --Mark
          Message 4 of 27 , Dec 5, 2007
            That would be awesome. Please keep up posted on your progress.

            --Mark

            ---- gchil0 <jgchilders@...> wrote:
            > This sqrt bug is the main thing that prompted me to abandon the GGNFS
            > post-processing tools as soon as msieve was capable of finishing the
            > factorizations. It's an extra step to prepare the input files for
            > msieve, but not having to worry if I'll get the factors in the end is
            > worth it. Not to mention that msieve's block Lanczos implementation
            > is much faster.
            >
            > When I get time, I plan to modify factLat.pl to use msieve for the
            > postprocessing automatically, but that probably won't happen for a
            > month or so.
            >
            > Greg
          • Bob Backstrom
            ... Totally agree. A fantastic improvement. I use it all the times that I can. Occasionally it complains about not enough rels even if GGNFS is at the end
            Message 5 of 27 , Dec 5, 2007
              --- In ggnfs@yahoogroups.com, "gchil0" <jgchilders@...> wrote:
              >
              > This sqrt bug is the main thing that prompted me to abandon
              > the GGNFS post-processing tools as soon as msieve was capable
              > of finishing the factorizations. It's an extra step to prepare
              > the input files for msieve, but not having to worry if I'll get
              > the factors in the end is worth it. Not to mention that
              > msieve's block Lanczos implementation is much faster.

              Totally agree. A fantastic improvement. I use it all the times
              that I can. Occasionally it complains about not enough rels even
              if GGNFS is at the end and running Matsolve :-(

              > When I get time, I plan to modify factLat.pl to use msieve for
              > the postprocessing automatically, but that probably won't
              > happen for a month or so.

              I posted my "makems" script a month ago on the XYYXF Group, so
              you don't really have to wait "a month or so" :-) It works now...

              Rgds,
              --Bob.

              > Greg
              >
              > --- In ggnfs@yahoogroups.com, Mark Rodenkirch <mgrogue@> wrote:
              > >
              > > OK, I just discovered that I was too hasty with this
              conclusion. It
              > > appears that the last step of make calls "strip" which removes
              all
              > > symbols from the object file. I removed the strip step from
              src/
              > > Makefile and it was able to get past procrels. Unfortunately it
              does
              > > not resolve the sqrt() bug.
              > >
              > > In other words, I completed a factorization on MacIntel after
              removing
              > > strip from src/Makefile. MacIntel factors tst250 correctly
              while
              > > MacPPC demonstrates the sqrt() issue. I will spend some time on
              this
              > > tomorrow in hope of discovering where the problem is in sqrt()
              or at
              > > least narrowing it down.
              > >
              > > --Mark
              > >
              > > On Dec 4, 2007, at 8:19 PM, Mark Rodenkirch wrote:
              > >
              > > > I think that the problem is with gcc. I had the same problem
              on
              > > > MacIntel, but when I
              > > > changed src/makefile to use -O2 instead of -O3, the problem
              went away.
              > > >
              > > > I'm doing some more tests to see if any other problems crop up.
              > > >
              > > > BTW, I see that the sqrt() bug hasn't been resolved. This was
              last
              > > > discussed in 2006. The
              > > > bug runs sqrt() and stops because r1=1 or r2=1. I have both a
              MacPPC
              > > > and MacIntel and
              > > > will run some comparisons in an effort to determine where the
              > > > problem is. On MacPPC I
              > > > see this bug crop up off. I haven't run a test through from
              start to
              > > > finish on MacIntel, but
              > > > if it factors the same input that MacPPC doesn't, then it will
              give
              > > > me something to work
              > > > on. My first attempt will be to change optimization to -O2 on
              MacPPC
              > > > to see if it solves
              > > > the problem.
              > > >
              > > > --Mark
              > >
              >
            • gchil0
              ... I want to do more than just convert the GGNFS files to msieve and run it. I want to completely replace factLat.pl, so that starting with either a *.n or
              Message 6 of 27 , Dec 5, 2007
                --- In ggnfs@yahoogroups.com, "Bob Backstrom" <bobb7772004@...> wrote:
                > > When I get time, I plan to modify factLat.pl to use msieve for
                > > the postprocessing automatically, but that probably won't
                > > happen for a month or so.
                >
                > I posted my "makems" script a month ago on the XYYXF Group, so
                > you don't really have to wait "a month or so" :-) It works now...

                I want to do more than just convert the GGNFS files to msieve and run
                it. I want to completely replace factLat.pl, so that starting with
                either a *.n or *.poly file, the script will find a poly using the
                GGNFS tools if starting with *.n, grab reasonable parameters, automate
                the sieving, and do all of the postprocessing with msieve. It should
                be fire and forget just as factLat.pl is now.

                Basically, I plan to start with the current factLat.pl, strip out all
                references to the GGNFS postprocessing, and replace them with
                appropriate msieve calls. I also want it to not even try
                postprocessing until there are enough relations that it has a
                reasonable chance of succeeding. I plan to do this next month, but if
                someone else wants to do it now, I certainly have no objections! :-)

                Greg
              • James Wanless
                Yes, I ve been helped by Bob s makems... mind, Greg s offering sounds great! - I ll await eagerly- thanks! J
                Message 7 of 27 , Dec 5, 2007
                  Yes, I've been helped by Bob's makems...
                  mind, Greg's offering sounds great! - I'll await eagerly- thanks!
                  J

                  On 5 Dec 2007, at 19:42, gchil0 wrote:

                  --- In ggnfs@yahoogroups. com, "Bob Backstrom" <bobb7772004@ ...> wrote:
                  > > When I get time, I plan to modify factLat.pl to use msieve for
                  > > the postprocessing automatically, but that probably won't
                  > > happen for a month or so.
                  >
                  > I posted my "makems" script a month ago on the XYYXF Group, so
                  > you don't really have to wait "a month or so" :-) It works now...

                  I want to do more than just convert the GGNFS files to msieve and run
                  it. I want to completely replace factLat.pl, so that starting with
                  either a *.n or *.poly file, the script will find a poly using the
                  GGNFS tools if starting with *.n, grab reasonable parameters, automate
                  the sieving, and do all of the postprocessing with msieve. It should
                  be fire and forget just as factLat.pl is now.

                  Basically, I plan to start with the current factLat.pl, strip out all
                  references to the GGNFS postprocessing, and replace them with
                  appropriate msieve calls. I also want it to not even try
                  postprocessing until there are enough relations that it has a
                  reasonable chance of succeeding. I plan to do this next month, but if
                  someone else wants to do it now, I certainly have no objections! :-)

                  Greg


                • James Wanless
                  Re-reading my post - it sounds a bit odd :) That thanks is on behalf of the whole community, of course!
                  Message 8 of 27 , Dec 5, 2007
                    Re-reading my post - it sounds a bit odd :)
                    That 'thanks' is on behalf of the whole community, of course!

                    On 5 Dec 2007, at 20:07, James Wanless wrote:

                    Yes, I've been helped by Bob's makems...

                    mind, Greg's offering sounds great! - I'll await eagerly- thanks!
                    J

                    On 5 Dec 2007, at 19:42, gchil0 wrote:

                    --- In ggnfs@yahoogroups. com, "Bob Backstrom" <bobb7772004@ ...> wrote:
                    > > When I get time, I plan to modify factLat.pl to use msieve for
                    > > the postprocessing automatically, but that probably won't
                    > > happen for a month or so.
                    > 
                    > I posted my "makems" script a month ago on the XYYXF Group, so
                    > you don't really have to wait "a month or so" :-) It works now...

                    I want to do more than just convert the GGNFS files to msieve and run
                    it. I want to completely replace factLat.pl, so that starting with
                    either a *.n or *.poly file, the script will find a poly using the
                    GGNFS tools if starting with *.n, grab reasonable parameters, automate
                    the sieving, and do all of the postprocessing with msieve. It should
                    be fire and forget just as factLat.pl is now. 

                    Basically, I plan to start with the current factLat.pl, strip out all
                    references to the GGNFS postprocessing, and replace them with
                    appropriate msieve calls. I also want it to not even try
                    postprocessing until there are enough relations that it has a
                    reasonable chance of succeeding. I plan to do this next month, but if
                    someone else wants to do it now, I certainly have no objections! :-)

                    Greg




                  • Jason Papadopoulos
                    ... Several people have asked about this, so I thought I d throw it out: is it time for a merge between GGNFS and msieve? The latter can replace the majority
                    Message 9 of 27 , Dec 5, 2007
                      Quoting gchil0 <jgchilders@...>:

                      > I want to do more than just convert the GGNFS files to msieve and run
                      > it. I want to completely replace factLat.pl, so that starting with
                      > either a *.n or *.poly file, the script will find a poly using the
                      > GGNFS tools if starting with *.n, grab reasonable parameters, automate
                      > the sieving, and do all of the postprocessing with msieve. It should
                      > be fire and forget just as factLat.pl is now.

                      Several people have asked about this, so I thought I'd throw it out:
                      is it time for a merge between GGNFS and msieve? The latter can replace
                      the majority of the GGNFS source, basically everything except the
                      polynomial selection and the lattice siever. I'm reasonably happy with
                      the state of msieve's NFS postprocessing and have started messing
                      with NFS sieving, so it won't be long before I'll be working side by
                      side with code that is in GGNFS anyway. The library source can go into
                      the GGNFS tarball and get built with the build system too. I'd be happy
                      to help maintain things, and the GGNFS user community is much larger
                      than the msieve community so it's more exposure for my work too :)

                      I'll understand if the proposal is too drastic, msieve has a lot of
                      code that is not NFS postprocessing. But I won't be working on the
                      library forever, and other developers should get a chance to contribute.

                      jasonp

                      ------------------------------------------------------
                      This message was sent using BOO.net's Webmail.
                      http://www.boo.net/
                    • mgrogue@wi.rr.com
                      Sounds like a great idea. If you want any assistance, I would be willing to help, although I would do better with getting ports to work correctly than with
                      Message 10 of 27 , Dec 5, 2007
                        Sounds like a great idea. If you want any assistance, I would be willing to help, although I would do better with getting ports to work correctly than with any significant coding changes.

                        --Mark

                        ---- Jason Papadopoulos <jasonp@...> wrote:
                        > Several people have asked about this, so I thought I'd throw it out:
                        > is it time for a merge between GGNFS and msieve? The latter can replace
                        > the majority of the GGNFS source, basically everything except the
                        > polynomial selection and the lattice siever. I'm reasonably happy with
                        > the state of msieve's NFS postprocessing and have started messing
                        > with NFS sieving, so it won't be long before I'll be working side by
                        > side with code that is in GGNFS anyway. The library source can go into
                        > the GGNFS tarball and get built with the build system too. I'd be happy
                        > to help maintain things, and the GGNFS user community is much larger
                        > than the msieve community so it's more exposure for my work too :)
                        >
                        > I'll understand if the proposal is too drastic, msieve has a lot of
                        > code that is not NFS postprocessing. But I won't be working on the
                        > library forever, and other developers should get a chance to contribute.
                        >
                        > jasonp
                        >
                        > ------------------------------------------------------
                        > This message was sent using BOO.net's Webmail.
                        > http://www.boo.net/
                      • gchil0
                        I m entirely in favor of this, but will license issues be a problem? GGNFS is GPL v2. Also, you could consider it not so much merging with GGNFS, but simply
                        Message 11 of 27 , Dec 5, 2007
                          I'm entirely in favor of this, but will license issues be a problem?
                          GGNFS is GPL v2.

                          Also, you could consider it not so much merging with GGNFS, but simply
                          importing Franke's poly selection and lattice sieve into msieve.
                          These are the only parts of GGNFS that are better than what msieve
                          currently has. (GGNFS's sqrt is faster but doesn't always work, so
                          it's not better.)

                          Greg

                          --- In ggnfs@yahoogroups.com, Jason Papadopoulos <jasonp@...> wrote:
                          >
                          > Quoting gchil0 <jgchilders@...>:
                          >
                          > > I want to do more than just convert the GGNFS files to msieve and run
                          > > it. I want to completely replace factLat.pl, so that starting with
                          > > either a *.n or *.poly file, the script will find a poly using the
                          > > GGNFS tools if starting with *.n, grab reasonable parameters, automate
                          > > the sieving, and do all of the postprocessing with msieve. It should
                          > > be fire and forget just as factLat.pl is now.
                          >
                          > Several people have asked about this, so I thought I'd throw it out:
                          > is it time for a merge between GGNFS and msieve? The latter can replace
                          > the majority of the GGNFS source, basically everything except the
                          > polynomial selection and the lattice siever. I'm reasonably happy with
                          > the state of msieve's NFS postprocessing and have started messing
                          > with NFS sieving, so it won't be long before I'll be working side by
                          > side with code that is in GGNFS anyway. The library source can go into
                          > the GGNFS tarball and get built with the build system too. I'd be happy
                          > to help maintain things, and the GGNFS user community is much larger
                          > than the msieve community so it's more exposure for my work too :)
                          >
                          > I'll understand if the proposal is too drastic, msieve has a lot of
                          > code that is not NFS postprocessing. But I won't be working on the
                          > library forever, and other developers should get a chance to contribute.
                          >
                          > jasonp
                          >
                          > ------------------------------------------------------
                          > This message was sent using BOO.net's Webmail.
                          > http://www.boo.net/
                          >
                        • Jason Papadopoulos
                          ... How the licensing will work depends on the level of integration. The msieve codebase can remain public domain, the rest of GGNFS can remain under GPL, and
                          Message 12 of 27 , Dec 5, 2007
                            Quoting gchil0 <jgchilders@...>:

                            > I'm entirely in favor of this, but will license issues be a problem?
                            > GGNFS is GPL v2.
                            >
                            > Also, you could consider it not so much merging with GGNFS, but simply
                            > importing Franke's poly selection and lattice sieve into msieve.
                            > These are the only parts of GGNFS that are better than what msieve
                            > currently has. (GGNFS's sqrt is faster but doesn't always work, so
                            > it's not better.)

                            How the licensing will work depends on the level of integration. The
                            msieve codebase can remain public domain, the rest of GGNFS can remain
                            under GPL, and as long as msieve can be used apart from GGNFS I don't
                            see a problem. If you want to distribute GGNFS in your own project
                            and include the advanced NFS tools your own code will have to be released
                            under GPL. Making the advanced tools part of msieve would pretty much
                            require relicensing.

                            I feel kind of bad suggesting throwing away 45k lines of code; even
                            discounting the code that was lifted from elsewhere, implementing
                            an entire algebraic square root from scratch using Nguyen's algorithm
                            is an amazing accomplishment. At the same time, I'd like to be able to
                            move GGNFS from alpha to something better.

                            jasonp

                            ------------------------------------------------------
                            This message was sent using BOO.net's Webmail.
                            http://www.boo.net/
                          • Anton Korobeynikov
                            Hello Everyone It was pretty quite here for some time :) ... Just my two cents: we can also think about better make system than current (I can spend some time
                            Message 13 of 27 , Dec 5, 2007
                              Hello Everyone

                              It was pretty quite here for some time :)

                              > At the same time, I'd like to be able to move GGNFS from alpha to
                              > something better.
                              Just my two cents: we can also think about better make system than
                              current (I can spend some time on it). Current one doesn't work fine in
                              some circumstances.

                              Some (huge) time ago Emmanuel Thome sent me one variant which he used
                              for his own project involving GGNFS at some step. I haven't integrated
                              it, because it lacks some important bits (like support for
                              cross-compilers), but I think we can use some really interesting things
                              from there.

                              Any thoughts/objections?

                              --
                              With best regards, Anton Korobeynikov.

                              Faculty of Mathematics & Mechanics, Saint Petersburg State University.
                            • j_m_berg
                              ... Have you managed to integrate things or is this still on the wish-list? -J-
                              Message 14 of 27 , Jan 19, 2008
                                --- In ggnfs@yahoogroups.com, "gchil0" <jgchilders@...> wrote:
                                >
                                > I want to do more than just convert the GGNFS files to msieve and run
                                > it. I want to completely replace factLat.pl, so that starting with
                                > either a *.n or *.poly file, the script will find a poly using the
                                > GGNFS tools if starting with *.n, grab reasonable parameters, automate
                                > the sieving, and do all of the postprocessing with msieve. It should
                                > be fire and forget just as factLat.pl is now.
                                >
                                > Basically, I plan to start with the current factLat.pl, strip out all
                                > references to the GGNFS postprocessing, and replace them with
                                > appropriate msieve calls. I also want it to not even try
                                > postprocessing until there are enough relations that it has a
                                > reasonable chance of succeeding. I plan to do this next month, but if
                                > someone else wants to do it now, I certainly have no objections!


                                Have you managed to integrate things or is this still on the wish-list?

                                -J-
                              • deyringer
                                ... T=9004878440740661095144621156073472000-3415573457537271520591872000X-28504044348594877440X^2 ... run?. ... I don t now what s the reason, but is fails
                                Message 15 of 27 , Jan 19, 2008
                                  --- In ggnfs@yahoogroups.com, "cobete1" <cobete1@...> wrote:
                                  >
                                  > Hi,
                                  > does anybody tried Ggnfs on a powerpc (970) architecture?
                                  > I can only get it working for a while and then segfaults.
                                  > This is the output for tst250:
                                  >
                                  > =>"cat" spairs.add >> spairs.out
                                  > => "../../bin/procrels" -fb tst250.fb -prel rels.bin -newrel spairs.out
                                  >
                                  > __________________________________________________________
                                  > | This is the procrels program for GGNFS. |
                                  > | Version: 0.77.1-20060722-970 |
                                  > | This program is copyright 2004, Chris Monico, and subject|
                                  > | to the terms of the GNU General Public License version 2.|
                                  > |__________________________________________________________|
                                  > done.
                                  > Monic polynomial:
                                  >
                                  T=9004878440740661095144621156073472000-3415573457537271520591872000X-28504044348594877440X^2
                                  > + 3622248X^3 + 1X^4
                                  > Obtained integral basis:
                                  > W =
                                  > 20710785024000 0 0 12426471014400
                                  > 0 287649792000 285323212800 36329886720
                                  > 0 0 2937600 2251368
                                  > 0 0 0 1
                                  > denominator = 20710785024000
                                  > Checking file rels.bin.0 ...
                                  > Largest prel file size is 0 versus max allowed of 128000000.
                                  > Warning: Could not stat processed file rels.bin.0. Is this the first
                                  run?.
                                  > New file is 35.29419MB.
                                  > New file has 403861 relations.
                                  > Building (a,b) hash table...0..makeABList() Failed to open rels.bin.0
                                  > for read!
                                  >
                                  > makeABLookup() : Sorting abList...Done.
                                  > Before processing new relations, there are 0 total.
                                  > hola
                                  > Return value 11. Terminating...
                                  >
                                  > Thanks.
                                  >
                                  I don't now what's the reason, but is fails maybe because PowerPC is a
                                  RISC architecture. Maybe GGNFS uses some code that will only work on
                                  CISC. If you haven't already done it, get the latest SVN version and
                                  compile with make generic. Please tell me which OS you use!

                                  Kind regards
                                • Mark Rodenkirch
                                  It does work on PPC as I have built and run it (besides I wrote the PPC specific asm routines). If you follow the thread you will see that it died after I
                                  Message 16 of 27 , Jan 19, 2008
                                    It does work on PPC as I have built and run it (besides I wrote the PPC specific asm routines).  If you follow the thread you will see that it died after I posed a question that wasn't answered.

                                    BTW, also missing was the ggnfs.log file and the entire output of the factLat.pl script.

                                    --Mark

                                    On Jan 19, 2008, at 11:36 AM, deyringer wrote:

                                    --- In ggnfs@yahoogroups. com, "cobete1" <cobete1@... > wrote:
                                    >
                                    > Hi,
                                    > does anybody tried Ggnfs on a powerpc (970) architecture?
                                    > I can only get it working for a while and then segfaults.
                                    > This is the output for tst250:
                                    > 
                                    > =>"cat" spairs.add >> spairs.out
                                    > => "../../bin/procrels " -fb tst250.fb -prel rels.bin -newrel spairs.out
                                    > 
                                    > ____________ _________ _________ _________ _________ _________ _ 
                                    > | This is the procrels program for GGNFS. |
                                    > | Version: 0.77.1-20060722- 970 |
                                    > | This program is copyright 2004, Chris Monico, and subject|
                                    > | to the terms of the GNU General Public License version 2.|
                                    > |___________ _________ _________ _________ _________ _________ __|
                                    > done.
                                    > Monic polynomial:
                                    >
                                    T=90048784407406610 9514462115607347 2000-34155734575 3727152059187200 0X-2850404434859 4877440X^ 2
                                    > + 3622248X^3 + 1X^4
                                    > Obtained integral basis:
                                    > W = 
                                    > 20710785024000 0 0 12426471014400 
                                    > 0 287649792000 285323212800 36329886720 
                                    > 0 0 2937600 2251368 
                                    > 0 0 0 1 
                                    > denominator = 20710785024000
                                    > Checking file rels.bin.0 ...
                                    > Largest prel file size is 0 versus max allowed of 128000000.
                                    > Warning: Could not stat processed file rels.bin.0. Is this the first
                                    run?.
                                    > New file is 35.29419MB.
                                    > New file has 403861 relations.
                                    > Building (a,b) hash table...0..makeABLi st() Failed to open rels.bin.0
                                    > for read!
                                    > 
                                    > makeABLookup( ) : Sorting abList...Done.
                                    > Before processing new relations, there are 0 total.
                                    > hola
                                    > Return value 11. Terminating. ..
                                    > 
                                    > Thanks.
                                    >
                                    I don't now what's the reason, but is fails maybe because PowerPC is a
                                    RISC architecture. Maybe GGNFS uses some code that will only work on
                                    CISC. If you haven't already done it, get the latest SVN version and
                                    compile with make generic. Please tell me which OS you use!

                                    Kind regards


                                  • Croco Dille
                                    ... From: Mark Rodenkirch To: ggnfs@yahoogroups.com Sent: Saturday, January 19, 2008 7:09:15 PM Subject: Re: [ggnfs] Re: GGNFS on PowePC64
                                    Message 17 of 27 , Feb 8, 2008

                                      ----- Original Message ----
                                      From: Mark Rodenkirch <mgrogue@...>
                                      To: ggnfs@yahoogroups.com
                                      Sent: Saturday, January 19, 2008 7:09:15 PM
                                      Subject: Re: [ggnfs] Re: GGNFS on PowePC64 (970)

                                      It does work on PPC as I have built and run it (besides I wrote the PPC specific asm routines).  If you follow the thread you will see that it died after I posed a question that wasn't answered.


                                      BTW, also missing was the ggnfs.log file and the entire output of the factLat.pl script.






                                      I posted this data in other message: http://tech.groups.yahoo.com/group/ggnfs/message/2138



                                      Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
                                    Your message has been successfully submitted and would be delivered to recipients shortly.