Menu
▾
▴
ggnfs-devel — GGNFS Developers list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(39) |
Sep
(27) |
Oct
(2) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
| 2008 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Anton K. <as...@ma...> - 2008-01-21 00:57:05
|
Hello, Everyone. Looks like, that during SVN migrations hooks were not installed properly. I've added them again and commit notification seems to be working now. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. |
|
From: Brian G. <br...@gl...> - 2008-01-17 10:57:08
|
Anton Korobeynikov wrote:
> Hello, Everyone
>
>> If they are not being maintained, my view is that we should remove them
>> since they will mislead people into thinking that they work when this is
>> not the case.
> I definitely agree. It will be better to remove them, not to leave.
> Maybe, there will be someone, who will be able to maintain at least one
> of vc7/vc8 versions.
Hi Anton,
In fact we probably don't need to maintain the vc8 build projects since
it seems to be very easy to move back from vc9 to vc8.
Simply changing the line:
Version="9.00"
to
Version="8.00"
in a vc9 *.vcproj file makes it into a project file that will work in
vc8 (which simply ignores the vc9 features in the file).
I have done this on quite a few projects and, so far, it has worked
every time.
Brian
|
|
From: Anton K. <as...@ma...> - 2008-01-17 10:45:18
|
Hello, Everyone > If they are not being maintained, my view is that we should remove them > since they will mislead people into thinking that they work when this is > not the case. I definitely agree. It will be better to remove them, not to leave. Maybe, there will be someone, who will be able to maintain at least one of vc7/vc8 versions. -- WBR, Anton Korobeynikov |
|
From: Brian G. <br...@gl...> - 2008-01-17 10:39:08
|
Jason Papadopoulos wrote:
> I think I'm set for now. The pol51opt Murphy rating code still
> uses global variables, but these are fairly well insulated from
> the rest of the codebase. Turning them into another structure
> should be easy, but enough changes have piled up that I wanted
> to commit what I have first.
>
> Brian, sorry for the churn in src/exprimental, I promise this
> will be the last big upheaval.
Hello Jason and Colleagues.
It's no problem Jason since I was expecting some early upheaval until
the code settles down.
For the moment I have added two new VS build projects, pol51m0bx and
pol51optx, for the new code whilst leaving pol51m0b and pol51opt intact
for the old code.
Beyond this, however, there are some decisions that we need to take for
the Visual Studio build projects depending on how many people still want
to use ggnfs with Visual Studio.
Firstly, as I am now using Visual Studio 2008 (VC++ v9), I have added a
vc9 build directory to the build.vc directory. This is the _only_ VC++
build system that I am now maintaining. Hence, unless someone else is
maintaining the vc7 and vc8 build projects, these will now be out of
date and will not fully compile ggnfs. And, of course, they will get
worse with time.
So do we need to maintain the vc7 and vc8 build systems for ggnfs? And,
if we do, who is going to be able to do this?
If they are not being maintained, my view is that we should remove them
since they will mislead people into thinking that they work when this is
not the case.
best regards,
Brian Gladman
|
|
From: Jason P. <ja...@bo...> - 2008-01-17 07:01:45
|
I think I'm set for now. The pol51opt Murphy rating code still uses global variables, but these are fairly well insulated from the rest of the codebase. Turning them into another structure should be easy, but enough changes have piled up that I wanted to commit what I have first. Brian, sorry for the churn in src/exprimental, I promise this will be the last big upheaval. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Jason P. <ja...@bo...> - 2008-01-13 20:06:29
|
Should be complete now. I have another big patchset on the way for the pol5 rewrite too, will probably commit that Monday. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Stanislav V. <st...@ma...> - 2007-12-25 20:58:18
|
Hi Jason,
Usually a new sources branch is being created for this king of stuff.
But, considering quite inactive ggnfs development, it should be safe
to place the modified pol51m0b into the trunk branch. Maybe here:
.\trunk\src\experimental\pol5 ?
Personally, I do not think it would be a much harm to replace the
existing pol51m0b implementation, providing you've tested it carefully.
But, I may turn to be a bad idea until people test new pol51m0b on
different platforms and configurations. And they won't until you
replace the existing implementation.. :)
Stanislav
JP> It was a little dicey at times but I think I have pol51m0b in
JP> better shape now. The source is reformatted and split over
JP> multiple files, dead code is removed, and almost all the global
JP> variables are now packed into local structures that are allocated
JP> and freed (this was very painful). Finally, the main code has
JP> been split off into a library with a very minimal API. If you don't
JP> use the assembly code, it's actually thread-safe :)
JP> Performance is the same, output is identical in all my tests
JP> (these are actually just running the complete binary for a little
JP> while on RSA100-140). I want to commit what I have before continuing
JP> the cleanup and moving on to optimizations, and I don't want to
JP> disturb the current pol5 directory. Where would a good place be to
JP> put the modified code?
JP> jasonp
JP> ------------------------------------------------------
JP> This message was sent using BOO.net's Webmail.
JP> http://www.boo.net/
JP> -------------------------------------------------------------------------
JP> This SF.net email is sponsored by: Microsoft
JP> Defy all challenges. Microsoft(R) Visual Studio 2005.
JP> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
JP> _______________________________________________
JP> Ggnfs-devel mailing list
JP> Ggn...@li...
JP> https://lists.sourceforge.net/lists/listinfo/ggnfs-devel
|
|
From: Jason P. <ja...@bo...> - 2007-12-25 20:43:46
|
It was a little dicey at times but I think I have pol51m0b in better shape now. The source is reformatted and split over multiple files, dead code is removed, and almost all the global variables are now packed into local structures that are allocated and freed (this was very painful). Finally, the main code has been split off into a library with a very minimal API. If you don't use the assembly code, it's actually thread-safe :) Performance is the same, output is identical in all my tests (these are actually just running the complete binary for a little while on RSA100-140). I want to commit what I have before continuing the cleanup and moving on to optimizations, and I don't want to disturb the current pol5 directory. Where would a good place be to put the modified code? jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Anton K. <as...@ma...> - 2007-12-18 18:42:20
|
Hello, Everyone. Subversion migration just ended. Please *dont* use CVS anymore. Let me know if something is wrong. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. |
|
From: Anton K. <as...@ma...> - 2007-12-18 17:59:49
|
Hello, Everyone. > I am in exactly the same situation. I'll try to convince Anton (aSL_) we > have do to this. I've just asked conversion from GGNFS CVS server to Subversion. Please don't commit everything to CVS until it will finish. I'll write a notification e-mail after finish. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. |
|
From: Stanislav V. <st...@ma...> - 2007-12-18 12:51:38
|
Hi Brian, I am in exactly the same situation. I'll try to convince Anton (aSL_) we have do to this. Sten Brian Gladman wrote: > Stanislav Vinokurov wrote: > > >> P.S. By the way, how everybody feel about finally switching the project >> to the SubVersion? CVS is a bit inconvenient. >> > > Hi Sten > > I for one would like to see this happen as soon as possible as I don't > use CVS any longer and cannot hence work with the GGNFS CVS repository. > > Brian Gladman > > . > > |
|
From: Jason P. <ja...@bo...> - 2007-12-17 21:45:46
|
Quoting Stanislav Vinokurov <st...@ma...>: > I remember my first attempt to refactor mpqs.c. There were many claims > it became broken a bit, so I was forced to revert my changes. You > should be very careful while changing lattice siever and run the tests > after every major change to the sources _and_ compare their output > with the etalon, not only check if they factor the input. I agree that the lattice siever is a big job; the polynomial selection is easier, because there's less total code and Kleinjung's paper is available to help make sense of it. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Stanislav V. <st...@ma...> - 2007-12-17 18:51:49
|
Hi Jason,
I remember my first attempt to refactor mpqs.c. There were many claims
it became broken a bit, so I was forced to revert my changes. You
should be very careful while changing lattice siever and run the tests
after every major change to the sources _and_ compare their output
with the etalon, not only check if they factor the input.
P.S. By the way, how everybody feel about finally switching the project
to the SubVersion? CVS is a bit inconvenient.
Sten
JP> If nobody minds, I'm going to start an overhaul of the Kleinjung
JP> polynomial selection tools. They're better than anything else
JP> for selecting NFS polynomials, and they're a natural starting point
JP> for some optimizations I have in mind. But not in their current state!
JP> I've started with pol51m0b. Once this and pol51opt is refactored
JP> (does anyone use pol51m0n?) if I'm feeling adventurous I'll try
JP> doing the same with the lattice siever. But even cleaning up one
JP> file at a time with the poly selection means I'll have my hands full
JP> for a while.
JP> jasonp
JP> ------------------------------------------------------
JP> This message was sent using BOO.net's Webmail.
JP> http://www.boo.net/
JP> -------------------------------------------------------------------------
JP> SF.Net email is sponsored by:
JP> Check out the new SourceForge.net Marketplace.
JP> It's the best place to buy or sell services
JP> for just about anything Open Source.
JP> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
JP> _______________________________________________
JP> Ggnfs-devel mailing list
JP> Ggn...@li...
JP> https://lists.sourceforge.net/lists/listinfo/ggnfs-devel
|
|
From: Jason P. <ja...@bo...> - 2007-12-17 15:08:46
|
If nobody minds, I'm going to start an overhaul of the Kleinjung polynomial selection tools. They're better than anything else for selecting NFS polynomials, and they're a natural starting point for some optimizations I have in mind. But not in their current state! I've started with pol51m0b. Once this and pol51opt is refactored (does anyone use pol51m0n?) if I'm feeling adventurous I'll try doing the same with the lattice siever. But even cleaning up one file at a time with the poly selection means I'll have my hands full for a while. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Jason P. <ja...@bo...> - 2007-12-16 04:22:36
|
As threatened, I've added branch_0/src/msieve, and commited the msieve files (no non-NFS algorithms, no NFS poly selection). Running 'make' can benefit from adding 'ARCH=XXX', just like the regular GGNFS makefile. Please let me know if I've messed up anything or if your system cannot build the msieve binary. Moderator(s): the huge diff emails can be deleted, I don't care to see them :) jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Jason P. <ja...@bo...> - 2007-12-14 17:34:43
|
My current plans involve adding branch_0/src/msieve and then dropping in the entire NFS distribution and its required support code from the msieve library. The demo application will be modified to just take in one number at a time and to require an NFS factor base file. I'm also willing to license the code identically to the other code in GGNFS. Most of these changes are done already. Time permitting, I'll be making the initial commit this weekend. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Anton K. <as...@ma...> - 2007-12-08 23:33:14
|
Hello Brian. > Both GGNFS and MSIEVE adhere to the C90 standard, not the C99 > standard. I really think it's pretty good practise to use C90 with some bits from C99. Imho, stdint.h is pretty useful feature and we should definitely use it (we already have something homegrown like this in GGNFS). We can surely provide necessary bits to support compilers which don't have it. I saw many compilers, which being non-C99, surprisingly have stdint.h PS: Let's move to ggnfs-devel -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. |
|
From: Anton K. <as...@ma...> - 2007-12-08 13:00:03
|
Hello, > This makes sense provided we import a version of stdint.h in order to > maintain the C90 compatibility of the code since a number of compilers > (including Microsoft VC++) don't provide C99 features or headers. Right, but fortunately there is direct alternative for vcpp. I even have already cooked .h file for this. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. |
|
From: Dennis L. <dla...@sf...> - 2007-01-31 03:02:58
|
Hi, Would it be possible to update def-par.txt, or perhaps post an updated version with parameters for larger numbers? I foolishly added the values from: http://tech.groups.yahoo.com/group/ggnfs/message/2003 into my def-par.txt and tried to factor a 132 digit number. I gave up after a month. I now believe that the alim number from the the gnfs,130 line is missing a 0. Thanks, Dennis |
|
From: Jason P. <ja...@bo...> - 2006-07-24 12:59:53
|
Quoting Sten <st...@ma...>: > So, I think we can analyze how sievers factor relations - they > should have more optimal approach - and, maybe, mimic CWI-like > behaviour saving only large factors. Ideas mailed to Anton. jasonp ------------------------- I have a few ideas to increase factoring speed but they're all pretty complicated: - use the heavy-duty ECM implementation. It should be able to split relations into several big pieces very quickly - use some kind of resieving procedure to handle the larger factor base primes. Alternately, you can sort the list so that relations with the same b value are contiguous, then use the sieving root of each factor base prime to implement the divisibility test without multiple-precision arithmetic - (enormous amount of work) Dan Bernstein has studied this problem a lot, and has several papers on his web page (cr.yp.to) that give what are asymptotically the fastest algorithms for solving this problem. Unfortunately they require FFTs and arithmetic on huge operands. I think the best bet for a quick speedup is the sorting idea, but I haven't looked at the patches yet. Note that if you don't know the special-q from the lattice siever, the product of the large primes can be up to 96 bits in size, and using MPQS to finish off that cofactor means that the theoretical upper bound on the relation processing rate is 100-200 relations per second. ---------------------------- ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Sten <st...@ma...> - 2006-07-24 10:49:37
|
The idea behind these latest modifications is to reduce size of the spairs.out files in large scale projects. Say, c155 and higher. I've already implemented and commited changes to the both sievers making them able to produce what I call "short relation format". When siever is invoked with -s command line argument it outputs only a,b values. procrels now recognizes such "short relation" automatically and calls factRel() routine for it instead of completePartialRelFact(). I've tested yesterday "short relations" on snfs_small and found critical performance degradation on procrels step. On my test machine the relation processing speed dropped from 13000 rels/sec to 360 rels/sec. It seems the factRel() -> factor() routine seems to be a bit unoptimal (it tried to factor relations using Trial Division and Pollard Rho). And after aSL! commited his changes to factor(), a call to squfof(), the speed increased to 550 rels/sec. But it still too low.. So, I think we can analyze how sievers factor relations - they should have more optimal approach - and, maybe, mimic CWI-like behaviour saving only large factors. Sten JP> With the recent checkins to enable compressed relation JP> handling, I was wondering... JP> Could the lattice siever be modified to not dump the full JP> multiplicity of each factor to the output? Procrels figures JP> out the multiplicity on its own, and duplicate factors JP> take about 25% of the volume in a relation file. JP> Another idea would mimic what the CWI suite does, and JP> only print factors larger than a specified lower bound. JP> jasonp |
|
From: Jason P. <ja...@bo...> - 2006-07-23 15:00:22
|
With the recent checkins to enable compressed relation handling, I was wondering... Could the lattice siever be modified to not dump the full multiplicity of each factor to the output? Procrels figures out the multiplicity on its own, and duplicate factors take about 25% of the volume in a relation file. Another idea would mimic what the CWI suite does, and only print factors larger than a specified lower bound. jasonp ------------------------------------------------------ This message was sent using BOO.net's Webmail. http://www.boo.net/ |
|
From: Max <re...@un...> - 2006-03-14 06:05:10
|
Geoffrey Reynolds wrote: > I think src/Makefile still needs to be updated to add matsave.o to the > list of objects to be compiled. Fixed in CVS by now. Max |
|
From: Geoffrey R. <g_w...@ya...> - 2006-03-14 02:24:31
|
I think src/Makefile still needs to be updated to add matsave.o to the list of objects to be compiled. Geoff. --- Anton Korobeynikov <as...@ma...> wrote: > Hello, Everyone. > > I've just commited G.W. Reynolds' matrix save routines. I've also > changed them a little bit in order to work under mingw32. > > So. If anyone will be able to test current cvs snapshot - it will be > fine. Especially, the compilation with Visual C++ should be checked. > I'm managing to make snapshot release soon at the end of this week. > > -- > With best regards, > Anton mailto:as...@ma... > > Monday, March 13, 2006 12:55:55 PM > > Faculty of Mathematics & Mechanics, Saint-Petersburg State University > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Ggnfs-devel mailing list > Ggn...@li... > https://lists.sourceforge.net/lists/listinfo/ggnfs-devel > Send instant messages to your online friends http://au.messenger.yahoo.com |
|
From: Anton K. <as...@ma...> - 2006-03-13 10:06:46
|
Hello, Everyone. I've just commited G.W. Reynolds' matrix save routines. I've also changed them a little bit in order to work under mingw32. So. If anyone will be able to test current cvs snapshot - it will be fine. Especially, the compilation with Visual C++ should be checked. I'm managing to make snapshot release soon at the end of this week. -- With best regards, Anton mailto:as...@ma... Monday, March 13, 2006 12:55:55 PM Faculty of Mathematics & Mechanics, Saint-Petersburg State University |
