Page 2 of 3 FirstFirst 123 LastLast
Results 41 to 80 of 116

Thread: Sieve Coordination Thread [old]

  1. #41
    I love 67607
    Join Date
    Dec 2002
    Location
    Istanbul
    Posts
    752
    RangerX,

    (Louie and Paul: Sorry if I am wrong in any of the comments below.)

    You can submit as frequent as you like. There is no problem in submitting the numbers more than once. The server understands it. Simply copy all of the factors in the window of the client (or from the SoBSieve.dat file, but be careful to exclude pmin and pmax rows in that case) and paste to the submission window, and press the submit button.

    Important: Do not forget to log in before you submit. Otherwise the database will not know it's you submitting (it will record the numbers anyway, but "you" will not get credit for it in the future. This might be an important problem if you care a lot for stats).

    If you feel unsecure at the beginning, simply copy the contents of the folder to another folder before you reboot your computer. (I evern paste my factors to an excel file )

    I accidentially (!) checked the "Create new SoB.dat file" option and closed the program in the previous version, which resulted in loss of my factors (discussed above). I think there is no such risk if you did/will not check it, or better than that are using version 1.07.

    On releasing 140-150 range, I think you should wait for "a day or two" before doing that. I am not really sure you are significantly slower. We'll see how fast everybody is doing by that time as everybody shares their progress.

    By the way, the highest p range that any of us reserved is still just 260 billion. So, it is too early to feel uncomfortable.

    Of course, it is still important that you commit your computer time 7/24 (or close to that) to meet the deadline.

    Q: What is your processor?

    Regards,

    Nuri
    Last edited by Nuri; 01-20-2003 at 07:09 PM.

  2. #42
    My processor is a 1 gHz Athlon Thunderbird (the ones with the 512k cache I think). I'll go ahead and temporarily kill the sb program after it's done with the current data set to speed up the sieve (should be about a ratio of 2x faster since currently they're both taking up about the same processor percentage).

    EDIT: I haven't checked the "create new .dat file", but before I upgrade to 1.07 I'll make sure to copy all the factors into a text file and write down the sieve's p progress so that I don't waste any time.

  3. #43
    Senior Member dmbrubac's Avatar
    Join Date
    Dec 2002
    Location
    Ontario Canada
    Posts
    112
    I've been running for about 28 hours now and my calculations are that my 10 billion (I have 215-225) will take 33 days. If this is too long, let me know. Maybe somebody wants 5 billion.

    It's running on a 1.1 G P3, but only getting 50% CPU. I could shut down the other process, but I would rather not.

    Let me know

    Dave

  4. #44
    I love 67607
    Join Date
    Dec 2002
    Location
    Istanbul
    Posts
    752
    Let me give my status report as well.

    I took 100-125.

    Currently I am running 100-120 at home and is at 100.65. Found 218 factors so far.

    I am also running 120-125 range at work and is at 120.x. Found a couple of factors there too.

  5. #45
    Junior Member
    Join Date
    Nov 2002
    Location
    Saline, MI
    Posts
    9
    My check-in. Working on 50-75 billion. currently at 51.3 billion. 845 factors found thus far. A very rough estimate has me finishing in about 20 days.

  6. #46
    Looking good.

    I'm at 6.6 billion now.

    Here is data of what has been submitted so far

    u-id # of factors submitted
    ------ ---------
    NULL 12
    1 73958
    105 4
    212 182
    365 1034
    366 4
    1418 114
    1577 241
    1608 27
    1761 800
    1831 4

    If you're curious what your userid is, get it from your personal stats page URL.

    i.e. when you lookup my stats, the url is

    http://www.seventeenorbust.com/stats...mhtml?userID=1

    because my userid is 1.

    As you can see, I've submitted a few factors . The low range is pretty rich in factors.

    Also, it looks like someone submitted 12 factors w/o being logged in. Oh well. It's not a huge deal.

    Also, don't think that I'm expecting you to submit factors all the time. I'm just showing you what's been done so far.

    Keep up the good work everyone.

    -Louie

  7. #47
    I love 67607
    Join Date
    Dec 2002
    Location
    Istanbul
    Posts
    752
    Originally posted by jjjjL

    Also, it looks like someone submitted 12 factors w/o being logged in. Oh well. It's not a huge deal.
    I suspect it might be me.

    In fact, since we're not to many people here, and it's known who is working at what range, it should be very easy to understand simply by looking at the p values of the factors.

  8. #48
    I've found 64 so far but haven't submitted yet. And I just rolled over to 130.3, and it's been at least 24 hours since I started. Probably more, but, sticking with liberal estimates, I'm looking to finish in about... ewww... this is nasty... 66.667 days... Yea that should cut down a lot when I stop sb.exe but I may still have to release 5 billion just to make the month deadline.

    EDIT: It's too bad I can't get my video card working on one of these problems... I think it's processor can match my main one as far as math speed goes... Yea I know it's sad.

  9. #49
    I wasn't sure where everyone was at so I took 300 to 301 billion. I just wanted to try out the program and based on other peoples times I don't want to take a bigger chunk.

  10. #50
    So far:

    0 - 25G Louie
    25 - 50 ceselb
    50 - 75 kmd
    75 - 100 cjohnsto
    100 - 125 Nuri
    125 - 130 McBryce
    130 - 150 RangerX
    150 - 155 nuutti
    155 - 175 MikeH
    175 - 200 paul.jobling
    200 - 210 dudlio
    210 - 215 smh
    215 - 225 dmbrubac
    225 - 250 EggmanEEA
    250 - 255 frmky
    255 - 260 Alien88

    300-301 Paperboy

  11. #51

    Re: Alpha=3.2 looks good.

    Originally posted by paul.jobling
    Hi guys,

    I'll take 155 billion to 175 billion. That should take this XP 2100+ about 20 days, with alpha set to 3.2.

    NOTE Using the default value of alpha (0.5) is not recommended - my rate was ~7000 p/sec at that; with alpha set to 3.2 the rate is ~11200 p/sec.

    Regards,

    Paul.

    Can anyone else supply p rates for various machines.
    I've just tried the following on a Duron 900 using WiNE on Linux, with alpha=3:
    p=4.500-4.501G 2500p/s
    p=50.000-50.001G 2300p/s

    This looks too slow by a factor of 2 or so.
    Is anyone else using WiNE on Linux, or using a Duron of similar speed?

    Phil

  12. #52
    Moderator ceselb's Avatar
    Join Date
    Jun 2002
    Location
    Linkoping, Sweden
    Posts
    224
    My rates (at alpha=3.2):
    PIV 1.5Ghz P=26.34G Rate: 6733 p/sec
    PII 350Mhz P=40.16G Rate: 2362 p/sec

    Ranges done 25-26.34G and 40-40.16G.
    Projected time left to run: 32.5 days at full speed.
    1885 factors submittted (I'm id 365 if anyone wonders).
    Last edited by ceselb; 01-21-2003 at 11:59 AM.

  13. #53

    Re: Re: Alpha=3.2 looks good.

    Originally posted by FatPhil
    Can anyone else supply p rates for various machines.
    I've just tried the following on a Duron 900 using WiNE on Linux, with alpha=3:
    p=4.500-4.501G 2500p/s
    p=50.000-50.001G 2300p/s

    This looks too slow by a factor of 2 or so.
    Is anyone else using WiNE on Linux, or using a Duron of similar speed?
    Yes, that definitely sounds too slow. My Athon XP 1800+ (1.533 GHz) clocks in at 11855p/s at p=251G and alpha=3.

    Greg

  14. #54

    Re: Re: Re: Alpha=3.2 looks good.

    Originally posted by frmky
    Yes, that definitely sounds too slow. My Athon XP 1800+ (1.533 GHz) clocks in at 11855p/s at p=251G and alpha=3.

    Greg
    OK, perhaps Paul's program is I/O bound, and that the XPs have larger and/or faster caches than the Durons, and that I'm getting completely constipated.
    I just tried on a Duron1300 running NT, and it wasn't much faster. :-( .

    I've written my own sieve, you see, and I'm trying to compare speeds. On my machines, my own sieve is ~4 times faster than Paul's. However, it appears that Paul's is running at about 1/3rd speed on my machines compared with how it should run (weird, I've not had problems with NewPGen in the past).

    I'll be giving windows (DOS box) and Linux binaries to Louie later this afternoon, and it would be nice if a couple of people could do a speed comparison.

    If there are people out there with workstations (non-x86) then I can probably build binaries for those as well, as it's all C, no assembly language.

    Ooh - final test complete, everything works (4.2* faster) - I'll ship it to Louie right now!

    Phil

  15. #55
    Senior Member
    Join Date
    Apr 2002
    Location
    Near Frankfurt, Germany
    Posts
    106
    Indeed it would really be nice to have a Linux client. I'm also interested in testing this and may compile it with a given makefile under SuSE Linux 8.1.

    Just send me the file or post a download link.

  16. #56
    Originally posted by Pascal
    Indeed it would really be nice to have a Linux client. I'm also interested in testing this and may compile it with a given makefile under SuSE Linux 8.1.

    Just send me the file or post a download link.

    http://fatphil.org/maths/sierpinski/index.html

    Windows and Linux binaries. Tested under NT, WiNE emulation, and Debian Linux, in the obvious ways.

    Pascal - do you mind being the first guinea pig?
    (It's basically only been tested by me on 'toy' ranges. The last one was to mimic a slice from Paul's 155-175G, and for that my Duron 900 was clocking 9900p/s under linux, obviously. Note - I've not worked out what the dimension parameter should be yet, I just use the default (~1.3) and it works fine.)

    Phil

  17. #57
    Hi,

    i will take 260 to 275.

    Lars

  18. #58
    Moderator ceselb's Avatar
    Join Date
    Jun 2002
    Location
    Linkoping, Sweden
    Posts
    224
    Wow, NbeGon seems to be quite nice.
    According to my calculations I jumped from ~6800 to 9400 p/sec (PIV 1.5).

  19. #59
    Some timings on my P4@2,4GHz for SoBSieve 1.07

    Alpha - rate
    2 - 15.6K
    2.5 - 15.6K
    2.7 - 15.7K
    2.8 - 15.75K
    2.9 - 15.75K
    3.0 - 15.7K
    3.1 - 13.7K
    3.2 - 12.8K

    NbeGone64 and SoBsieve have about an equal speed when using default Alpha. When i use -d=2 or higher, SoB sieve is about 20% faster!

  20. #60
    Originally posted by FatPhil
    http://fatphil.org/maths/sierpinski/index.html

    Windows and Linux binaries. Tested under NT, WiNE emulation, and Debian Linux, in the obvious ways.


    Phil

    Phil, could I get a compile done for UltraSparcII?

    I have 2 4cpu smp boxes that can't run anything SoB otherwise. I have no clue if your code sets affinity in SMP mode, I guess I can figure that out if need be.

    Thanks

  21. #61
    Originally posted by smh
    Some timings on my P4@2,4GHz for SoBSieve 1.07

    NbeGone64 and SoBsieve have about an equal speed when using default Alpha. When i use -d=2 or higher, SoB sieve is about 20% faster!

    I tested at d=1.0 (the lowest it can go), 1.3, and 1.6.
    1.0 and 1.6 were about the same speed, and 1.3 was a bit faster, so I'm guessing that on my architecture (Duron) 1.3 (the default) is pretty much optimal.

    I have no idea where the optimal point is for PIIs, PIIIs or P4s, however, as my hash and cache behaviour are unrelated to Paul's, there will probably be no correlation at all. It's obvious mine favours different architectures from Paul's. This is good, as it means that we both fill in each other's weak spots, and noone's left with a slow sieve. I hope.

    Phil

  22. #62
    Originally posted by Cowering
    Phil, could I get a compile done for UltraSparcII?

    I have 2 4cpu smp boxes that can't run anything SoB otherwise. I have no clue if your code sets affinity in SMP mode, I guess I can figure that out if need be.

    Thanks
    Can you (even briefly) get me a login account on the usparcs? I can SSH authenticate.
    I've never tried to build my maths libraries on a usparc, so this could be an intersting experiment. The thing's more than a little chaotic, and requires deep magic to build (it's a drag, but is not impossible, hard coded paths and crap like that).
    I'll try to sneak into the local university tomorrow, and see if I can get access to a machine myself.

    Regarding affinity - I wouldn't know how to set it!

    Phil

  23. #63
    Originally posted by FatPhil
    Can you (even briefly) get me a login account on the usparcs? I can SSH authenticate.
    I've never tried to build my maths libraries on a usparc, so this could be an intersting experiment. The thing's more than a little chaotic, and requires deep magic to build (it's a drag, but is not impossible, hard coded paths and crap like that).
    I'll try to sneak into the local university tomorrow, and see if I can get access to a machine myself.

    Regarding affinity - I wouldn't know how to set it!

    Phil
    I will try, but these machines are behind the firewall from hell, and do nothing internet related all day, they are internal servers only. Might not even have telnet/sshd installed.. but i'll do my best

  24. #64
    Senior Member
    Join Date
    Jan 2003
    Location
    UK
    Posts
    479
    Posted by ceselb
    According to my calculations I jumped from ~6800 to 9400 p/sec (PIV 1.5).
    I too have just done a few quick tests with NbeGon64 v0.06sob

    P4-1.7
    SoBSieve ~7Kp/s
    NbeGon64 ~11Kp/s

    AMD XP 2100+
    SoBSieve ~12Kp/s
    NbeGon64 ~27Kp/s

    These were using Paul's suggested alpha=3.2, and Phil's alpha left as defaut.

    Paul, it looks like you have some competition!

    Phil, NbeGon64 (as well as being faster) solves my problem (1) (other thread). Any chance you could give an option to pick up where you left off? Currently, unless I do some pre-processing to get the last p value, every time I start NbeGon64 I'll do the same range over and over again.

    Thanks,
    Mike.

  25. #65
    Originally posted by MikeH
    Phil, NbeGon64 (as well as being faster) solves my problem (1) (other thread). Any chance you could give an option to pick up where you left off? Currently, unless I do some pre-processing to get the last p value, every time I start NbeGon64 I'll do the same range over and over again.

    Thanks,
    Mike. [/B]

    The quickest hack would be to drop a shell file with the command line you'd use to resume it; every half hour perhaps? In the windows version it would be a batch file, of course.
    A ^C handler would be nice - I can do that for us Loonies, but don't know if windoze supports signals the same way.

    It's late. I'll attack it with a fresh mind tomorrow.

    Phil

  26. #66
    Has your sieve been tested for accuracy Phil? I just want to know because I could run it for a little bit from the beginning of my range and see if it pops up the same things the sobsieve did. IE, I'm perfectly willing to run a test for ya I would offer to help with/make a shell program for continuing number ranges and non-such but I've got my plate full with school work right now, so sorry But perhaps it would be easier to simply modify SoBsieve's algorithm to yours and leave it's shell intact (as much as possible, anyway)?
    Last edited by RangerX; 01-21-2003 at 07:45 PM.

  27. #67
    PS. I tested the program on my comp, it does run much much faster than SoBSieve, so I would be really happy to see it's speed somehow meshed with the current SoBSieve. It finished 1/5 of what my computer has done so far in like at least 1/24th the time (adjusting for the fact that it took all my system resources instead of the half SoBSieve is getting). Mostly the only thing I have a problem with is that I use my computer a lot for various things, and 1) XP lags running DOS (or mine does anyway; I'm convinced it's possessed by a demon though) and 2) The new program doesn't have any way to set it to use only idle resources. Not criticizing or anything; God knows it's better than anything I could throw together!! Just suggesting a solution. So yea I'll just shut up now

    PSS. I checked the output with the one SoBSieve spat out and it's exactly the same (as I expected, but I figured a little extra checking never hurt).

  28. #68
    to set the process priority, go to task manager and right click on the process then set the priority to what you want. by default it'll run at normal priority.

  29. #69
    I compared the speed of the 2 sieves on three Athlons and the timings surprised me:

    Athlon XP 1800+ (1.533 GHz), Windows XP
    SOBSieve 11890 p/s (alpha=3)
    NbeGon64 24485 p/s (d=1) 2x faster

    Athlon TBird 1.266 GHz, Windows 2000
    SOBSieve 8600 p/s (alpha=3)
    NbeGon64 20780 p/s (d=1) 2.4x faster

    Athlon (K7-5 Argon) 750MHz, Windows 98
    SOBSieve 3075 p/s (alpha=3)
    NbeGon64 9805 p/s (d=1) 3.2x faster

    Looks like I'll be switching software. Anyone wanna wrap a GUI around NbeGon64? :-)

    Greg

  30. #70
    Originally posted by RangerX
    2) The new program doesn't have any way to set it to use only idle resources.
    ...
    PSS. I checked the output with the one SoBSieve spat out and it's exactly the same (as I expected, but I figured a little extra checking never hurt).

    Doesn't XP have Task Manager to set priorities?
    It's a single process single thread, just set it to idle.

    I don't generally like the idea of processes setting their own priorities, that's the user's job. I know that different times I run the same program I'll want it to run at a different priority. i.e. priority is not a function of the executable, but of the task at hand. However, I'm used to the fine control that nice/renice give one in Unix.

    Thanks for redoing your range. I did have 2 known small SoBSieve outputs to test against, but more tests is better.

    Phil

  31. #71

    NbeGon for Sparc/Alpha/BSD

    I've had a productive morning building NbeGon for the some new OSes and Architectures. Currently available are the following:

    Linux/x86
    Windows/x86
    FreeBSD/x86
    OpenBSD/x86
    SunOS/Sparc
    Linux/Alpha

    http://fatphil.org/maths/sierpinski/

    I've only tested the new non-86 non-Linux ones on the old 150-150.01G range that I tested others with, and it comes up with identical everything, so I think they're as trustworthy as the Linux/Windows ones.

    It's the plain 0.06sob version, I've not added any features.
    Any system with gcc should take 2 minutes for a new port, so just drop me a note if you want me to look at a new platform.
    Long live portable C!

    Phil

  32. #72
    Just tested NbeGon64 on a PIII 450, and it's IIRC about 80% faster compared to SoBsieve

  33. #73
    Hehe... Yea it does someone else posted about that already. I forgot all about that!! Figures; for once Windows offers something that might be useful to the power-users and I forget all about it. *sigh*

    And testing the range is no problem. I figured since I wanted to test it's comparitive speed, I may as well go high enough to check some of the factors too. I also forgot to mention that my test was with your default alpha (1.3, right?), which isn't even the best for my range and system.

    After SB is done with this current test (6 blocks left) I'm gunna kill both the SoB programs and start running the NbeGon64. I should be all set to finish in a month then.

    I have a quick question though... My computer has the bad tendency to freeze every once in a while, in which case I have absolutely no way to close stuff so I can safely save data. Does the NbeGon64 program output the factors into the file as it goes? If so then I don't have to worry about anything because I could just use the last p value outputted to the file to start over again. And does it overwrite the file when you start if over or append to it?

  34. #74
    Originally posted by RangerX
    I have a quick question though... My computer has the bad tendency to freeze every once in a while, in which case I have absolutely no way to close stuff so I can safely save data. Does the NbeGon64 program output the factors into the file as it goes? If so then I don't have to worry about anything because I could just use the last p value outputted to the file to start over again. And does it overwrite the file when you start if over or append to it?
    I fflush() my write to the factors file, so it's "out of my hands". The kernel is permitted to delay writes if it so desires. For these sparse ranges, I could open and close the factors file each time, but I don't hink there's any need for that at the moment.

    Regarding resuming, I've also today added a self-resuming batch file setup. Basically I write a batch file with the correct command line every 10 minutes, so to restart just run that. Quite how Windows copes with writes to batch files that are being executed, I don't know. Please report back if there are problems. I intend to get most of the versions rebuilt by tomorrow, and they'll have the version number 0.07sob. I'll send a message to the forum when they're ready.

    I also added a counter of the number of primes removed, which I think makes the otherwise boring progress markers more interesting.

    Phil

  35. #75
    Senior Member
    Join Date
    Jan 2003
    Location
    UK
    Posts
    479
    Original post by FatPhil
    The quickest hack would be to drop a shell file with the command line you'd use to resume it; every half hour perhaps? In the windows version it would be a batch file, of course.
    My prime (no pun intended) interest right now is Windows.

    What you sugget would be good. I was thinking along the lines of saving pmin and pmax values to a file every (say) 15 minutes. Then in the client give a command line option to specify pmin and pmax from a specified file.

    With this type of set-up I could install NBeGon64 as a service under FireDaemon. It would also give me the advantage that I can monitor the progress remotely just by looking at the save file.

    Thanks for your help Phil.
    Last edited by MikeH; 01-22-2003 at 01:16 PM.

  36. #76
    Senior Member
    Join Date
    Jan 2003
    Location
    UK
    Posts
    479
    Phil,

    We crossed posts. You're already ahead of me.

  37. #77
    Senior Member
    Join Date
    Jan 2003
    Location
    UK
    Posts
    479
    Phil,

    Just to check the .bat save file will work as a service, I just tried the following line in a .bat file

    nbegon64 -p170886000000-175000000000 -ssob.dat

    Launching the .bat file with FireDaemon is a breeze. I look forward to tomorrow's version.

  38. #78
    Senior Member dmbrubac's Avatar
    Join Date
    Dec 2002
    Location
    Ontario Canada
    Posts
    112

    Holy Cow!

    I just switched over to NBeGon and it is a LOT faster on my P3. My earlier estimate of 33 days for 10 billion should tighten up. After I've run it for a day I will let you know my rate.

    I agree with other posters though, put the NBeGon math inside the SBSeive interface.

    Nice work though, to both Phil and Paul.

  39. #79
    Sieve it, baby!
    Join Date
    Nov 2002
    Location
    Potsdam, Germany
    Posts
    959
    I just tried out NbeGon before getting myself a claim to dig for composites.

    My question:
    Are those outputs completely normal?

    # 0.7 p=275000000543 hash overflows: 0|0|0|0|0|0
    max num factors=1 at p=275000005999
    # 8.7 p=275000066059 hash overflows: 6|0|0|0|0|0
    ! Info: required 2 rehashes for prime 275000120971
    # 18.1 p=275000131613 hash overflows: 12|1|0|0|0|0

    Overflow always sounds like "error" for me...

  40. #80
    Moderator ceselb's Avatar
    Join Date
    Jun 2002
    Location
    Linkoping, Sweden
    Posts
    224
    Below quoted from a mail from Phil (Bold is me).

    Is the proportions of "hash overflows: 9388|154|1|1|0|0" in any way
    related to dimension (and performance)?


    Yes. The more 'big steps' in the DLOG, the more likely my hash table is to
    overflow. If the big step stage is faster then I want to make it as large as
    possible. However, if I overflow the hash table I need to that prime again
    with fewer big steps. Therefore an overflowed prime costs at least one and a
    half times a normal prime, time-wise. So the balance is makign the first
    attempt small enough such that it's as fast as possible, but large enough
    that it doesn't overflow too often. Overflowing 1 in 1000 primes is nothing.
    Multiple overflows chose progressivly fatter rectangles with fewer big
    steps, and incur a further cost.

    The balance is such a compromise that the dependency of speed on the
    dimension parameter is reduced. If you chose a parameter too small, then you
    get faster DLOGs, but you overflow more often, so you have to redo more often.
    Likewise the other way. So it's pretty flat performance-wise on the whole.

    Does the "max num factors=2 at p=" lines mean anything important, or
    should I just ignore them?


    Ignore that. I should remove that printf, it was useful when debugging at
    very small, but is irrelevant now.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •