mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > Factoring

Reply
 
Thread Tools
Old 2010-11-30, 13:58   #34
jasonp
Tribal Bullet
 
jasonp's Avatar
 
Oct 2004

32×5×79 Posts
Default

The 64-bit windows binary would require converting all the 64-bit asm that makes the linux binary so fast, and right now only Brian Gladman has the expertise to do that. You may get it to compile on windows, but it won't have all that asm.
jasonp is offline   Reply With Quote
Old 2010-11-30, 18:12   #35
Andi47
 
Andi47's Avatar
 
Oct 2004
Austria

2×17×73 Posts
Default

Quote:
Originally Posted by Batalov View Post
Just to clarify: "mpqs failed" or "mpqs on a prime square" are not critical errors per se: MPQS implementation in the siever is expected only to work to certain limits (which we are pushing more and more) and occasionally fail to factor (but not crash). We of course don't want the siever to hang or crash. If removing the block that starts with mpz_sqrtrem call clears the crash on Windows, then there are some mpz_sqrtrem side-effects that I cannot account for. If the recompiled binary will still crash, then there may be some damage done in mpqs routine after it fails. The three debug cases should be sufficient to examine that.

Yes, the sub-topic of crashes could be moved to the
Tweaking and compiling the Kleinjung siever and tracked there.
Is it possible that the occasional crashes of the 11e and 12e sievers under windows (I have posted a few of them into the "running GGNFS" thread, IIRC) have the same cause? (one example is this posting, there should be more in this thread)

edit: another crash at q=43274929

Last fiddled with by Andi47 on 2010-11-30 at 18:50
Andi47 is offline   Reply With Quote
Old 2010-11-30, 19:59   #36
jrk
 
jrk's Avatar
 
May 2008

109510 Posts
Default

Quote:
Originally Posted by Batalov View Post
Just to clarify: "mpqs failed" or "mpqs on a prime square" are not critical errors per se: MPQS implementation in the siever is expected only to work to certain limits (which we are pushing more and more) and occasionally fail to factor (but not crash). We of course don't want the siever to hang or crash. If removing the block that starts with mpz_sqrtrem call clears the crash on Windows, then there are some mpz_sqrtrem side-effects that I cannot account for. If the recompiled binary will still crash, then there may be some damage done in mpqs routine after it fails. The three debug cases should be sufficient to examine that.

Yes, the sub-topic of crashes could be moved to the
Tweaking and compiling the Kleinjung siever and tracked there.
If the "mpqs failed" type of errors is what's causing the crashes on Windows, in the meantime (until the real problem gets fixed in code), the mpqs errors could be reduced by using the more conventional 2LP parameters*.

*OTTOMH, though I don't guarantee these:
Code:
alim: 300000000
rlim: 300000000
lpba: 32
lpbr: 31
mfba: 64
mfbr: 62
alambda: 2.6
rlambda: 2.6
jrk is offline   Reply With Quote
Old 2010-12-02, 11:12   #37
ET_
Banned
 
ET_'s Avatar
 
"Luigi"
Aug 2002
Team Italia

3·1,619 Posts
Default

Quote:
Originally Posted by Andi47 View Post
what is the name of your outputfile? add -o <name of your outputfile> to the command line.
It worked smoothly, thank you Andi.

Luigi
ET_ is offline   Reply With Quote
Old 2010-12-06, 19:41   #38
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

22·3·311 Posts
Default

I see you're requesting .gz files. Is that a general request that the relations be zipped, or can you only deal with gzip specifically? bzip2 produces files about 10-15% smaller than tar -z does.
bsquared is offline   Reply With Quote
Old 2010-12-06, 20:18   #39
Andi47
 
Andi47's Avatar
 
Oct 2004
Austria

1001101100102 Posts
Default

Quote:
Originally Posted by bsquared View Post
I see you're requesting .gz files. Is that a general request that the relations be zipped, or can you only deal with gzip specifically? bzip2 produces files about 10-15% smaller than tar -z does.
I guess bzip2 should be OK - at least fivemack never complained when I uploaded bzip2'd relations in his previous projects
Andi47 is offline   Reply With Quote
Old 2010-12-06, 20:36   #40
Batalov
 
Batalov's Avatar
 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

2×11×457 Posts
Default

Though in an ideal world (all files being error-free) one could simply concat all gz files and get one nice test.dat.gz file, it will fail as soon as the first transfer error in any of the files. In Tom's shoes, I'd gzip -tv and bzip2 -tv all incoming files anyway, so with this in mind the format wouldn't matter as much to me as the file transfer time. But this is for Tom to decide.
Batalov is offline   Reply With Quote
Old 2010-12-07, 01:02   #41
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

2·7·461 Posts
Default

I don't mind what format you use; I keep the relations in gzip rather than bzip form on disc because I find it takes a lot longer to bunzip than to gunzip if I want to do a quick filtering test, but if you upload bz2 then I'll convert them to gzip.
fivemack is offline   Reply With Quote
Old 2010-12-07, 02:25   #42
Batalov
 
Batalov's Avatar
 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

235068 Posts
Thumbs up (...wearing a bioinformatic hat...)

For the same reason all fancy 7z methods, albeit packing better and better, are failing the same use case: they are slower and yet slower -- and more and more memory-consuming. There's no free lunch anywhere, including packing - it is a clear tradeoff.


Interestingly, if you allow a small tangent: B-W transform recently provided a huge boost to the bioinformatical problem of mapping of billions of short substrings on a larger string with a few errors (a.k.a. genome mapping). There are a dozen programs for this job -- all written within the last two years (because of the new generation of sequencers) and all using BWT, for a representative example see BWA. But this uses the indexing property of B-W with the Ferragina-Manzini clever algorithm.

I mean, why is this even interesting? It just goes to show that some algorithms lie dormant for decades because their use is unclear (Wheeler found the transformation in 1983 but it was only in the 90s that Burrows convinced him that it was useful, and they published it; later the .bz2 emerged, and now... (25 years after!) it became used exponentially more.)

Last fiddled with by Batalov on 2010-12-07 at 02:33
Batalov is offline   Reply With Quote
Old 2010-12-15, 20:19   #43
Andi47
 
Andi47's Avatar
 
Oct 2004
Austria

2·17·73 Posts
Default

this one got the 16e siever stuck into an endless loop:

gnfs-lasieve4I16e -v -M 1 -a 2_956+.poly -o 2_956+_43.44d07.out -f 43953600 -c 46400
Warning: lowering FB_bound to 43953599.
FBsize 2658728+0 (deg 5), 8444395+0 (deg 1)
<looping "forever", without any message like "total yield: xy..." - I stopped it and restarted with -f 43953680, this seems to work now>
Andi47 is offline   Reply With Quote
Old 2010-12-19, 11:25   #44
Andi47
 
Andi47's Avatar
 
Oct 2004
Austria

248210 Posts
Default

Quote:
Originally Posted by Andi47 View Post
reserving 43M-44M
done, 3014307 relations. http://www.sendspace.com/file/8kdmun

Quote:
Originally Posted by Andi47 View Post
Edit: another reproducible crash at q=43515611. Is there a binary for windows 64-bit available, which is newer than svn-374?
I had to restart 51 times due to crashes (lost quite some time, i.e. when I came to the PC and found the error messages on the screen and the threads sitting idle since hours).

After looking into the windows task manager, I noticed that I in fact use a 32-bit binary (svn-374, newest available on Jeff's homepage, hence I never managed to compile the binaries from source). Is there any newer windows binary available? (*hoping for bugfixes*)
Andi47 is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
The "Hello - I am... - Nice to meet you" thread.... Prime Monster Lounge 29 2023-01-02 21:46
Nice progress! schickel FactorDB 29 2012-07-18 17:03
Nice pic Dubslow Forum Feedback 0 2012-05-02 02:13
Very nice strategical puzzle Raman Puzzles 2 2009-11-01 10:23
Nice link... Xyzzy Lounge 4 2003-06-28 13:37

All times are UTC. The time now is 01:41.


Thu Feb 2 01:41:00 UTC 2023 up 167 days, 23:09, 1 user, load averages: 0.90, 1.02, 1.06

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔