mersenneforum.org Anyone familiar with GPU Lattice Siever?
 Register FAQ Search Today's Posts Mark Forums Read

 2019-10-30, 16:23 #1 EdH     "Ed Hall" Dec 2009 Adirondack Mtns 338410 Posts Anyone familiar with GPU Lattice Siever? It looks to be a few years old. It compiles fine in Colab, but I can't figure out what it wants for input. The README is just a quick description of what it is and there doesn't appear to be a --help option. I created a poly file, but can't tell if it reads it or wants everything on the command line. I didn't dig deep into the code - wouldn't expect to have to. Any discussion on it anywhere? Thanks. . . https://github.com/pstach/gls
 2019-10-30, 16:39 #2 Dylan14     "Dylan" Mar 2017 3·173 Posts A quick look at the code shows that it has a file called gls_config.c and gls_config.h, which appears to take a poly file and then extract the appropriate parameters. Code:  int polyfile_read(gls_config_t cfg, const char *fname) appears to be the function that does this.
2019-10-30, 17:55   #3
EdH

"Ed Hall"
Dec 2009

23×32×47 Posts

Quote:
 Originally Posted by Dylan14 A quick look at the code shows that it has a file called gls_config.c and gls_config.h, which appears to take a poly file and then extract the appropriate parameters. Code:  int polyfile_read(gls_config_t cfg, const char *fname) appears to be the function that does this.
Thanks. I looked through the code, but can't figure out exactly what it wants:
Code:
both q range and qlist not specified
I've tried several things, but they all return the same.

 2019-10-31, 20:39 #4 EdH     "Ed Hall" Dec 2009 Adirondack Mtns 23×32×47 Posts Well, I'm just not getting anywhere. The help invocation is useless: Code: !../las/las -h (null) I guess if you're not in the know (or well versed in the code), don't expect to use this package. This is as far I've gotten: Code: !../las/las -out Testout -I 11 -q0 2300000 -poly test.poly Configuring OpenCL cofactorization for "OpenCL 1.2 CUDA 10.1.152" - "Tesla K80" fb_fileread:fopen: No such file or directory or: Code: !../las/las -out Testout -I 11 -q0 2300000 -poly test Configuring OpenCL cofactorization for "OpenCL 1.2 CUDA 10.1.152" - "Tesla K80" failed to open polynomial file I can't figure out the secret file it wants. Everything is either invalid or "no such. . ."
 2019-10-31, 20:48 #5 fivemack (loop (#_fork))     Feb 2006 Cambridge, England 2·29·109 Posts The code doesn't seem that unclear. You need two factor-base files, {poly}.fb.0 and {poly}.fb.1, which are binary-format and generated by running the separate makefb executable on the polynomial file with the bounds filled in in the same format that nfs@home uses (lpbr, lpba, alim, rlim) I believe pstach did quite a lot of work with Jason six years ago and then lost interest with nobody else picking it up; I think he gave a presentation at the Nancy conference which must have been in 2009 (it was the one where all the people from INRIA were checking on their laptops the progress of the RSA-768 sieving that they hadn't quite announced they were doing) Last fiddled with by fivemack on 2019-10-31 at 20:50
2019-10-31, 21:12   #6
EdH

"Ed Hall"
Dec 2009

23×32×47 Posts

Quote:
 Originally Posted by fivemack The code doesn't seem that unclear.
Sorry I'm so dense. I was starting to figure out that something generated something, but I hadn't gotten further.
Quote:
 Originally Posted by fivemack You need two factor-base files, {poly}.fb.0 and {poly}.fb.1, which are binary-format and generated by running the separate makefb executable on the polynomial file with the bounds filled in in the same format that nfs@home uses (lpbr, lpba, alim, rlim)
This does help me a bunch. Thanks! I should be able to figure it out from this info. (Famous last words? %^) It would also be helpful if there was at least something like this in the README.
Quote:
 Originally Posted by fivemack I believe pstach did quite a lot of work with Jason six years ago and then lost interest with nobody else picking it up; I think he gave a presentation at the Nancy conference which must have been in 2009 (it was the one where all the people from INRIA were checking on their laptops the progress of the RSA-768 sieving that they hadn't quite announced they were doing)
Bummer about the interest loss. I see papers on GPU Lattice Sieving but no other implementations. Is the efficiency poor compared to CPU sieving?

2019-10-31, 21:36   #7
chalsall
If I May

"Chris Halsall"
Sep 2002

2·4,643 Posts

Quote:
 Originally Posted by EdH I can't figure out the secret file it wants. Everything is either invalid or "no such. . ."
I hope this comes across as helpful; it's intended as much... Run this command (unprivialged is fine), and examine closely the output.

Code:
strace ls 2>&1 | less
"strace" can be *very* handy when reverse engineering, or just finding one's own SPEs. It has helped me a lot over the years.

2019-10-31, 22:23   #8
EdH

"Ed Hall"
Dec 2009

23×32×47 Posts

Quote:
 Originally Posted by chalsall . . . Code: strace ls 2>&1 | less "strace" can be *very* handy when reverse engineering, or just finding one's own SPEs. It has helped me a lot over the years.
Thanks! If I'm reading this correctly:
Code:
Building OpenCL kernels...
fopen: No such file or directory
Code:
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
I'm missing this file. But, this is what I get when I search for it:
Code:
You probably don’t want to “solve” this problem; according to the
Debian glibc manpage for ld.so,

/etc/ld.so.nohwcap When this file is present the dynamic
linker will load the non-optimized version of a library, even if the
CPU supports the optimized version.

It’s not installed by a package, it can be created by the system
administrator to disable loading optimised libraries.
Then again, there are other files that can't be found either.

Time for a break. . .

Thanks for all the help everyone. I'll go back to my room for a while.

2019-10-31, 23:29   #9
chalsall
If I May

"Chris Halsall"
Sep 2002

244616 Posts

Quote:
 Originally Posted by EdH Then again, there are other files that can't be found either.
This then suggests that this file is *not* supposed to be found. That is quite nominal in the SW space... "Does this file exist? Great, use it! No? Well, what about this one..."

Spend some time making friends with strace. It's a bit of a steep learning curve, but its not vertical.

You'll want to generally read the output from the bottom up. Over time you'll learn how to recognize (in the trace) the failed code backing out of the run, and a little further above the point where it decided to give up trying...

2019-11-01, 12:16   #10
EdH

"Ed Hall"
Dec 2009

23×32×47 Posts

Quote:
 Originally Posted by chalsall . . . You'll want to generally read the output from the bottom up. Over time you'll learn how to recognize (in the trace) the failed code backing out of the run, and a little further above the point where it decided to give up trying...

 2019-11-01, 14:46 #11 jasonp Tribal Bullet     Oct 2004 DA116 Posts Tom is correct, Patrick talked about GPU block Wiedemann in late 2008 at the CADO conference. We never discussed his lattice sieve per se, I only discovered the code later.

 Similar Threads Thread Thread Starter Forum Replies Last Post R.D. Silverman Factoring 31 2018-10-08 17:17 chris2be8 Factoring 6 2018-02-06 17:22 pstach Factoring 1 2014-05-23 01:03 fivemack Programming 2 2012-12-16 01:07 Batalov Msieve 54 2010-01-13 19:45

All times are UTC. The time now is 00:13.

Wed Oct 28 00:13:31 UTC 2020 up 47 days, 21:24, 2 users, load averages: 2.28, 2.10, 1.98