Mersenne Digest Sunday, November 4 2001 Volume 01 : Number 900 ---------------------------------------------------------------------- Date: Fri, 2 Nov 2001 12:19:59 -0800 From: "Stephan T. Lavavej" Subject: Mersenne: SMT I was wondering, Will Prime95 be optimized to take advantage of simultanous multithreading processors? Perhaps some part of the FFT computation can be done with multiple threads, so a SMT processor could devote more power to one while the other is waiting on memory or something. I don't know the details of FFTs; if they're a completely serial process I may sound really silly. SMT will provide a performance boost to Prime95 anyways, as other system activity will impact idle threads less, of course. - -- Stephan T. Lavavej _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 03 Nov 2001 09:04:50 +0000 From: Gareth Randall Subject: Mersenne: mprime for Solaris x86 ? Dear All, I have to do some work with Solaris 8 on x86 (i.e. Intel processors), and was wondering if anyone felt inclined to port mprime to this OS. Now I know that most ports actually take a long time and are not worth it unless there's a significant target user base, but I'm not suggesting the typical "Can I have this graphics-intensive Direct-X Windows game on my Mac running Linux?" :-) Mprime is simply a command-line program that does file I/O, outgoing network connections ... and that's about it in terms of interacting with the OS. All this is standard POSIX stuff which might even compile without change (he says). Consequently the only questionable part is whether the assembly code is sufficiently OS independent. Would anyone be interested in giving this a try? Yours, ======= Gareth Randall ======= _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 3 Nov 2001 01:49:27 -0800 From: "John R Pierce" Subject: Re: Mersenne: mprime for Solaris x86 ? > I have to do some work with Solaris 8 on x86 (i.e. Intel > processors), and was wondering if anyone felt inclined to > port mprime to this OS. I'm quite inclined to suspect that mprime would just compile right over for Solaris. I don't know how the assembly is handled (is it intel syntax, or at&t, and is it seperate ASM files or is it embedded inline in .c ? So the biggest problem might be finding the right compilers to get it to compile. once its compiling, all the IO and stuff is standard posix unix, it should play on solaris just fine. I believe the gnu c compiler (egcs/gcc) is available for solaris/x86. - -jrp _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 3 Nov 2001 11:23:48 +0100 From: Lars Lindley Subject: Re: Mersenne: mprime for Solaris x86 ? > So the biggest problem might be finding the right compilers to get > it to compile.  once its compiling, all the IO and stuff is > standard posix unix, it should play on solaris just fine.   I > believe the gnu c compiler (egcs/gcc) is available for > solaris/x86. Every Linux app is suppposed to be runnable on solaris 8. At least via an application called Lxrun. There's a whole bunch of opensource apps (Like gcc) available on www.sunfreeware.com. Lxrun can be found there too. Tell us how it works. Happy hunting! /Lars _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 03 Nov 2001 05:32:56 -0500 From: Michael Vang Subject: Re: Mersenne: mprime for Solaris x86 ? I have gcc and 10 days left on the newest Forte demo... If someone needs access to this box to compile mprime (or anything else...) I can arrange access to it... I assume (Here we go...) that it is possible to compile target executables for x86 Solaris on my SPARC Solaris box... See http://www,teamprimerib.com/freeshell.html for more info... Xyzzy [81/116.886/102/9.339/791.50] http://www.teamprimerib.com/ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 03 Nov 2001 11:53:43 -0500 From: George Woltman Subject: Re: Mersenne: mprime for Solaris x86 ? Hi, At 01:49 AM 11/3/2001 -0800, John R Pierce wrote: >I'm quite inclined to suspect that mprime would just compile right over for >Solaris. I don't know how the assembly is handled (is it intel syntax, or >at&t, and is it seperate ASM files or is it embedded inline in .c ? > >So the biggest problem might be finding the right compilers to get it to >compile. once its compiling, all the IO and stuff is standard posix unix, >it should play on solaris just fine. Just grab the source at http://www.mersenne.org/source.htm and see if it compiles and links. You will not compile the ASM stuff - both ELF and COFF style object files are provided for the ASM code. If it works, then you'll have to operate in manual mode. The "security codes" are not provided in the sources. Thus, the server won't talk to your client. Good luck, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 3 Nov 2001 19:18:22 +0100 From: =?utf-8?Q?Torben_Schl=C3=BCntz?= Subject: SV: Mersenne: Strange factor arrived though not calculating it > It seems like I have had credit for one factor that I never did: > > M16871993 with factor: 2224518820603490479 > > I am the owner of this exponent as it is assigned to me. Yes! > > But I didn't work on it. If you're running v20 then P-1 will be done early - the current test will break off at the next multiple of 65536 iterations whilst the P-1 is run. :-) Thank you, Brian; but look at exponent: M16871993, these aren't handed out for LL test yet (as for as I know), this one is a trial factoring. Now maybe you think I don't control what is going on, but I think otherwise. To convince you that I know everything cooking I show you this script I can run anytime: Z:\primenet\expl>echo off MULTEM~1\RESULTS.TXT Iteration 810000 / 13124623 TERMIN~1\RESU0001.TXT Iteration 8070000 / 11944657 TERMIN~1\RESULTS.TXT Iteration 1850000 / 11511061 TORBEN~1\RESULTS.TXT Iteration 10540000 / 12510737 APOLD\RESULTS.TXT Iteration 10400000 / 11167979 - ----------------------------Factoring:---------------------------------- - - HHV012\RESULTS.TXT Factoring M18056699 to 2^65 is 7.69% complete. HHV003\RESULTS.TXT Factoring M17954653 to 2^65 is 16.38% complete. JANSTA\RESULTS.TXT Factoring M17883379 to 2^65 is 20.01% complete. HHV005\RESULTS.TXT Factoring M17790013 to 2^65 is 37.69% complete. HHV014\RESULTS.TXT Factoring M16645553 to 2^65 is 39.02% complete. LAGER2\RESULTS.TXT Factoring M16538857 to 2^65 is 48.15% complete. HHV007\RESULTS.TXT Factoring M18079057 to 2^65 is 42.39% complete. HHV001\RESULTS.TXT Factoring M17556293 to 2^65 is 54.26% complete. HHV011\RESULTS.TXT Factoring M17863829 to 2^65 is 51.76% complete. ZENTRA01\RESULTS.TXT Factoring M17694427 to 2^65 is 76.71% complete. ZENTRA01\RESULTS.TXT Factoring M17694427 to 2^65 is 77.65% complete. INTEGR~1\RESULTS.TXT Factoring M17785673 to 2^65 is 78.66% complete. HHV002\RESULTS.TXT Factoring M18054301 to 2^65 is 89.72% complete. HHV016\RESULTS.TXT Factoring M18012121 to 2^65 is 86.38% complete. HELLY\RESULTS.TXT Factoring M17021969 to 2^65 is 93.43% complete. HHV009\RESULTS.TXT Factoring M17950103 to 2^65 is 97.19% complete. - ----------------------------66------------------------------------------ - - HHV006\RESULTS.TXT Factoring M17960981 to 2^66 is 0.47% complete. --- HHV015\RESULTS.TXT Factoring M17889829 to 2^66 is 14.30% complete. --- HHV008\RESULTS.TXT Factoring M17950123 to 2^66 is 21.52% complete. --- --- --- --- --- HHV004\RESULTS.TXT Factoring M17919931 to 2^66 is 78.03% complete. --- --- - --------------------logs-or-results-if-any:----------------------------- - - HHV013\RESULTS.TXT UID: tsc/hhv013, M17927929 no factor to 2^66, WW1: AC1D7755 HHV013\PRIME.LOG UID: tsc/hhv013, M17927929 no factor to 2^66, WW1: AC1D7755 Factors done: RESULTS.ALL 808 lines match Things done this month: RESULTS.ALL 5 lines match And here follows the directory listing for the machine in question: Directory of Z:\primenet\expl\helly2 29-08-1999 11:01 28.672 Rpcnet.dll 29-08-1999 11:01 61.440 Httpnet.dll 25-04-2000 14:33 1.212.928 phelly2.exe 27-09-2001 15:15 529 PRIME.INI 24-10-2001 23:04 . 24-10-2001 23:04 .. 24-10-2001 23:11 182 worktodo.ini 24-10-2001 23:12 633 prime.log 24-10-2001 23:12 256 LOCAL.INI 25-10-2001 00:03 79 results.txt 25-10-2001 00:04 32 pG481447 9 File(s) 1.304.751 bytes 2 Dir(s) 1.836.318.720 bytes free This directory sorted by date, shows that the last date I did anything on this was 25-10-2001. Here is the entry from the individual primenet report: 16871993 61 F 2224518820603490479 28-Oct-01 17:17 helly Notice the date, 28 oct. Finally the contents of the worktodo.ini from the same library: Factor=16481447,58 Factor=16481557,58 Factor=16833517,59 Factor=16871993,59 Factor=16871999,59 Factor=16872017,59 Factor=16872049,59 Factor=17432083,59 Factor=17432117,59 Please notice, that the exponent in question is located at position 4. So all the 3 tests before the 4.th should have been done. They haven't, it now looks like this at 03/11-01: 16481447 F 58 1 53.1 -6.6 53.4 24-Oct-01 21:10 11-Sep-01 09:51 helly 400 v19/v20 16481557 F 58 53.1 -3.6 56.4 24-Oct-01 21:10 11-Sep-01 09:51 helly 400 v19/v20 16871999 F 59 1 111.1 -1.8 58.2 28-Oct-01 17:17 15-Jul-01 10:40 helly 400 v19/v20 16872017 F 59 111.1 1.2 61.2 28-Oct-01 17:17 15-Jul-01 10:40 helly 400 v19/v20 16872049 F 59 111.1 4.2 64.2 28-Oct-01 17:17 15-Jul-01 10:40 helly 400 v19/v20 Kind of spooky to, that the progress coloumn has 2 numbers with a 1. I'm working at the first one, the worktodo.ini is right about that. Who's working on 16871999? Happy hunting Torben Schlüntz, tsc _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 04 Nov 2001 01:19:33 +0100 From: Henk Stokhorst Subject: Mersenne: some stats on primenet L.S., I took the file cleared.txt which lists all results that have been checked in since the last database master sync. A quickly written program produced the following stats: 94.810 exponents checked in, of which 13.124 are factors and 81.686 are LL tests. There are 8.588 different useraccounts listed, with a total of 22.448 different computerID's If a computerID is defined to be active only on the day it checked in the exponent if it checked in only one result, or on all the days between the first and the last exponent checked in if it checked in more than one result, than the maximum amount of accounts that were active on the same day is 3.273. This number is lower than the real amount of processors that work simultaneous on primenet assigned exponents. But it is an indication how much air is in the number of processors active listed on the primenet statuspage due to pc's that never finish an assigned exponent. YotN, Henk Stokhorst. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 03 Nov 2001 21:01:35 -0500 From: George Woltman Subject: Re: Mersenne: SMT Hi, At 12:19 PM 11/2/2001 -0800, Stephan T. Lavavej wrote: >Will Prime95 be optimized to take advantage of >simultanous multithreading processors? Perhaps >some part of the FFT computation can be done >with multiple threads, so a SMT processor could >devote more power to one while the other is >waiting on memory or something. A good theoretical question! The details on Intel's SMT implementation are not out yet, but the information we have now suggests that SMT could be a big winner for modern CPUs. SMT will be implemented in some versions of the P4 soon. SMT for those that don't know makes one P4 CPU look like 2 CPUs to the operating system. Each "virtual CPU" has its own set of registers and each runs a different program (actually a different "thread"). The real CPU can now execute instructions from either virtual CPU. Why is this good? Well, the P4 CPU is often stalled waiting for a instruction dependencies or memory accesses or whatever. With SMT the CPU now has more instructions to choose from in scheduling to keep the functional units busy. Better yet, it is guaranteed that there are no dependencies on instructions from different virtual CPUs. Intel states they are seeing up to 30% improvements in CPU throughput. Can prime95 take advantage of SMT? I'm skeptical. If the FFT is broken up to run in two threads, I'm afraid L2 cache pollution will negate any advantage of SMT. Of course, I'm just guessing - to test this theory out we should compare our throughput running 1 vs. 2 copies of prime95 on an SMT machine. - -- George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 03 Nov 2001 21:40:31 -0500 From: Kel Utendorf Subject: Re: Mersenne: SMT At 21:01 11/03/2001 -0500, George Woltman wrote: >Can prime95 take advantage of SMT? I'm skeptical. If the FFT is broken >up to run in two threads, I'm afraid L2 cache pollution will negate any >advantage of SMT. Of course, I'm just guessing - to test this theory out we >should compare our throughput running 1 vs. 2 copies of prime95 on an >SMT machine. Could things be setup so that factoring and LL-testing went on "simultaneously?" This would speed up the overall amount of work being done. Kel _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 03 Nov 2001 19:21:27 -0800 From: Luke Welsh Subject: Mersenne: List's Signup Page and a Request Hello everybody-- After all these years, they killed off a very fine ISP, SCruzNet.Com. Sorta like losing an old pal, right JP? And Best.com got gobbled up by Verio, which was bought by a Japanese Telco, I think. On the plus side, my best-hosted business domain, ndatech, got its disk quota upped to 100 MB, so I haphazardly move the Signup Page here: http://www.ndatech.com/mersenne/signup.htm I think this will be for the long term. I have also moved some very old digests here: http://www.ndatech.com/mersenne/archives/digest/ These need to be brought up-to-date. If you have some old digests, please see http://www.ndatech.com/mersenne/archives/digest/$readme.txt for the file-naming convention. I think you guys can figure it our from there. To minimize duplication of effore, send me an email stating which date ranges you'll handle. Then put the ZIPs somewhere on the wwweb for me to transfer to the above URL. And while you're at it, can anybody hack into www.ndatech.com? The main page is really nothing (plus a dead link or two). But there's some other stuff there, supposedly hidden. Run a whois to verify that ndatech is mine. Thanks-- - --Luke _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 04 Nov 2001 07:18:04 +0000 From: Gareth Randall Subject: Re: Mersenne: SMT George Woltman wrote: > SMT for those that don't know makes one P4 CPU look like 2 CPUs > to the operating system. Each "virtual CPU" has its own set of registers > and each runs a different program (actually a different "thread"). The real > CPU can now execute instructions from either virtual CPU. SMT on Intel? I didn't know about that. If SMT is implemented like the planned Alpha EV8 implementation, then it will be up to the OS to schedule multiple tasks for the processor. Consequently unless the OS had special interfaces to allow one program to consume several SMT slots, the program would either be restricted to running as normal, or have to try running as several processes, or would have to replicate the necessary OS kernel functionality itself (difficult, and not portable). I think the odds are that prime95 / mprime would not be able to gain much unless either the OS makes special arrangements for single compute-intensive programs, which seems unlikely since SMT is intended for CPUs running multiple processes, or the OS is open source and can be patched at kernel level, which excludes windows. Some SMT news that I know of: Alpha EV8 will have SMT with 4 simultaneous execution paths. Alpha recently got canned by compaq, so the above may never happen. Yours, ======= Gareth Randall ======= _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 4 Nov 2001 13:59:17 +0100 From: "Dieter Schmitt" Subject: Re: Mersenne: SMT Gareth Randell wrote: > Some SMT news that I know of: > Alpha EV8 will have SMT with 4 simultaneous execution paths. > Alpha recently got canned by compaq, so the above may never happen. ..... and Intel bought Alpha from Compaq recently. Yours, Dieter Schmitt _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 04 Nov 2001 09:38:00 -0500 From: Nathan Russell Subject: Re: SV: Mersenne: number of processors participating On Tue, 30 Oct 2001 21:33:59 -0500, Rick Pali wrote: >Aaron Blosser wrote: > >>Good old sysinternals... they have the neatest tools. > >Damn straight! I've been using (and loving) PageDefrag since I stumbled on >that site. A few other gems have since made their way onto my system... > >Rick. See also HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ClearPageFileAtShutdown This setting was put in place by a 'twink' program I tried a month or two back, and has been working great for me (marginally more secure too). Nathan _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: 4 Nov 2001 11:40:26 -0500 From: "Robert Deininger" Subject: Re: Mersenne: SMT On Sun, Nov 4, 2001 7:59 AM, Dieter Schmitt wrote: >Gareth Randell wrote: > >> Some SMT news that I know of: >> Alpha EV8 will have SMT with 4 simultaneous execution paths. >> Alpha recently got canned by compaq, so the above may never happen. > >..... and Intel bought Alpha from Compaq recently. More precisely, Intel bought non-exclusive rights to all the alpha technology, as well as the right to hire a lot of the Compaq Alpha people. The EV8 designers are going/have gone to Intel. Compaq is still developing the Alpha EV7 family. In a few years, the EV7 people may migrate to Intel also. At this point, Compaq still owns all the Alpha intellectual property, and could continue EV8 development if they wanted to (though they would have to start over with new people). Intel could complete the Alpha EV8 and ship it as an Intel-branded chip if they wanted to. Or (far more likely) they will incorporate what features they can in their current CPU families, mainly Itanium. Many of Compaq's compiler people will be migrating to Intel also. - --------------------------- Robert Deininger rdeininger@mindspring.com _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 04 Nov 2001 18:36:44 +0000 From: Gareth Randall Subject: Re: Mersenne: mprime for Solaris x86 ? George Woltman wrote: > Just grab the source at http://www.mersenne.org/source.htm and see if it > compiles and links. You will not compile the ASM stuff - both ELF and COFF > style object files are provided for the ASM code. Er, my Solaris x86 machine just expired (suspect failed PSU), so maybe someone else can try this! :-( - -- ======= Gareth Randall ======= _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 4 Nov 2001 21:35:47 -0000 From: bjb@bbhvig.uklinux.net Subject: Re: Mersenne: SMT On 3 Nov 2001, at 21:40, Kel Utendorf wrote: > At 21:01 11/03/2001 -0500, George Woltman wrote: > >Can prime95 take advantage of SMT? I'm skeptical. If the FFT is > broken >up to run in two threads, I'm afraid L2 cache pollution will > negate any >advantage of SMT. Of course, I'm just guessing - to test > this theory out we >should compare our throughput running 1 vs. 2 > copies of prime95 on an >SMT machine. I'm not sure I fully understand the way in which a SMT processor would utilise cache. But I can't see how the problem could be worse than running two copies of a program on a SMP system. This seems to work fairly well in both Windows and linux regimes (attatching a thread to a processor and therefore its associated cache, rigidly in the case of Windows, loosely but intelligently in the case of linux). If an SMT processor has a unified cache, cache pollution should surely be not too much of a problem? Running one copy & thereby getting benefit of the full cache size would run that one copy faster, (just as happens with SMP systems where memory bandwidth can be crucial) but the total throughput with two copies running would surely be greater. Especially on a busy system, where two threads get twice as many timeslices as one! If there is some way in which the FFT could be broken down into roughly equal sized chunks, it _might_ be worth synchronizing two streams so that e.g. transform in on one thread was always in parallel with transform out on the other, and vice versa. Obviously you'd need to be running on two different exponents but using the same FFT length to gain from this technique. Whether this would be any better than running unsynchronized would probably require experimentation. > > Could things be setup so that factoring and LL-testing went on > "simultaneously?" This would speed up the overall amount of work > being done. Because trial factoring, or P-1/ECM on _small_ exponents, have a very low memory bus loading, running a LL test and factoring in parallel on a dual-processor SMP system makes a lot of sense. I suspect the same situation would apply in an SMT environment. The "problem" of mass deployment (almost everyone in this position, instead of only a few of us) is that there is a great deal of LL testing effort required in comparison to trial factoring, so running two LL tests in parallel but inefficiently would bring us to "milestones" faster than the efficient LL/trial factoring split. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ End of Mersenne Digest V1 #900 ******************************