Mersenne Digest Sunday, October 21 2001 Volume 01 : Number 894 ---------------------------------------------------------------------- Date: Fri, 19 Oct 2001 15:52:21 +0200 (MET DST) From: Reto Keiser Subject: Mersenne: Problems with Firedeamon and Prime95 Hi all, As the operating system in the computer lab changes from Windows 95 to Windows 2000 professional, we intend to install Prime95 as service using Firedeamon. In an early attempt to set up an example system which can be used as image for all the computers it worked properly. At that time some other things were not all right. Therefore a new image was set up (completely independent from the earlier successful one). Now, when we installed Firedeamon and Prime95, it ran properly, but it crashed while logging out. When Prime95 is not minimized while logging out, we could see, that the output window changed during the last 0.5 seconds and some strange random characters appeared in the last three lines and somewhere above; three characters each line. They looked like '|È|' or similar. After logging in next time, this strange output window appeared again, and Prime95 was kind of idle but with a red icon. At that time all menu items are grayed. After closing Prime95 it started correctly from the last save file. If Prime95 is minimized while logging out, the same happened, but was not possible to reactivate it after at the next login because there was no icon in the tray. Does someone know this problem? It seems that the Prime95's memory is overwritten by the system during the logout process. In some installations, it was also possible, that prime95 only appeared invisible even if the 'interact with desktop' box was checked. It is not possible to bring the output window on the desktop, even by double clicking on the executable icon. In the taskmanager we can see that the program is running, but it cannot be killed. Is there a way to install Prime95 and Firedeamon without having these problems? I hope that a solution can be found soon, as we try to integrate prime95 into the image file from where all the workstations are set up. Thanks, Reto & Werner _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 19 Oct 2001 17:54:27 +0200 From: "Steinar H. Gunderson" Subject: Mersenne: Re: Problems with Firedeamon and Prime95 On Fri, Oct 19, 2001 at 03:52:21PM +0200, Reto Keiser wrote: >Is there a way to install Prime95 and Firedeamon without having these >problems? I hope that a solution can be found soon, as we try to >integrate prime95 into the image file from where all the workstations >are set up. I'm unaware of what Firedaemon really is, but to me, it sounds like some sort of "daemonizing" program, making an ordinary program into a service. In that case, I'd advise you to try the NT service version of Prime95 instead, as it's written natively as a service and thus should work a lot better :-) It's there at the download page together with the ordinary version. /* Steinar */ - -- Homepage: http://www.sesse.net/ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 19 Oct 2001 10:06:55 -0700 From: "John R Pierce" Subject: Re: Mersenne: Re: Problems with Firedeamon and Prime95 > >Is there a way to install Prime95 and Firedeamon without having these > >problems? I hope that a solution can be found soon, as we try to > >integrate prime95 into the image file from where all the workstations > >are set up. > > I'm unaware of what Firedaemon really is, but to me, it sounds like some sort > of "daemonizing" program, making an ordinary program into a service. In that > case, I'd advise you to try the NT service version of Prime95 instead, as > it's written natively as a service and thus should work a lot better :-) neither was I, but here it is, http://www.firedaemon.com/ appears to be a glorified "SRVANY", runs ordinary apps as services. Much better is what Steinar suggests, use the NT Service version of Prime95. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 19 Oct 2001 13:39:05 -0400 From: "Carleton Garrison" Subject: Re: Mersenne: Re: Problems with Firedeamon and Prime95 The NT service version looses a lot of Prime95 interactivity, that's why Firedaemon is preferable. I do know that if it is running invisible and you are unable to interact with it, you can uninstall/remove the Prime95 service from Firedaemon, reboot and get interaction again, from which point you can Prime95 service install again. I don't know, it is hard to tell. I don't think your problems happen when doing it by hand, so something must be wrong with the image? Carleton Garrison, #105 www.teamprimerib.com - ----- Original Message ----- From: "Steinar H. Gunderson" To: Sent: Friday, October 19, 2001 11:54 AM Subject: Mersenne: Re: Problems with Firedeamon and Prime95 > On Fri, Oct 19, 2001 at 03:52:21PM +0200, Reto Keiser wrote: > >Is there a way to install Prime95 and Firedeamon without having these > >problems? I hope that a solution can be found soon, as we try to > >integrate prime95 into the image file from where all the workstations > >are set up. > > I'm unaware of what Firedaemon really is, but to me, it sounds like some sort > of "daemonizing" program, making an ordinary program into a service. In that > case, I'd advise you to try the NT service version of Prime95 instead, as > it's written natively as a service and thus should work a lot better :-) > > It's there at the download page together with the ordinary version. > > /* Steinar */ > -- > Homepage: http://www.sesse.net/ > _________________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 20 Oct 2001 11:02:53 +0200 From: Guillermo Ballester Valor Subject: Mersenne: Glucas v 2.8c released. Hi all, A new Glucas v.2.8c version has been released. You can download the source code or precompiled binaries at sourceforge site: http://sourceforge.net/projects/glucas and, as slow as a snail alternative at my anonymous ftp server: ftp://ftp.oxixares.com/pub/glucas/Glucas-2.8c The main features of this release are in the ChangeLog excerpt : - Most of the FFT code has been written specially for IA64 (anyway standard C code) and the use of Intel compiler has doubled the speed for that platform. Now is the fastest Glucas runner (per clock). The improvement is not only because of a rewritten code, a new preload scheme has been introduced. Basically it loads in a loop cycle what we need in the next one. It is only efficient in processors with lot of registers as Itanium's (128 FP registers). To active this code in IA64 architecture compile with -DY_ITANIUM -Klaus Kastens has improved the timing routines. The elapsed real time now is measured with a millisecond precision. -Klaus also has written a new output format for verbose information. Now there is information about the percentage of processor time spent by Glucas. -Some small changes for other platforms. No significant performance improvements. -Fixed a rare memory bug affecting to huge selftest under OpenBSD (reported by Gregory Matus). Better memory management. -Fixed signal code for FreeBSD/x86 and Mac OS X. This release has been possible because of the help of Klaus Kastens (new developer of Glucas), and the superb team of beta testers (in alphabetical order): Brian J. Beesley, Tom Cage, Ludovic Ferrandis, Gregory Matus and Thomas Perrier. The increase in performance is moderate for most of platforms (0% to %5). For Itanium (the STAR of the release) this version is almost twice faster than 2.8b. Here is the timings for an Itanium @ 800 Mhz (Compaq Blazer Itanium): ***************************************************************************** These are timings from Glucas-2.8c. (sec/iter). Roundoff check on/off. Itanium: Intel C compiler v.5.0 beta COMPILER FLAGS: - -O3 GLUCAS FLAGS: - -DY_AVAL=3 -DY_MEM_THRESHOLD=32768 -DY_BLOCKSIZE=4096 -DY_SHIFT=9 - -DY_TARGET=0 -DY_ITANIUM (1) Blazer Itanium 4 @800 RedHat Linux Kernel 2.4.3 128 K 0.011/0.010 144 K 0.015/0.013 160 K 0.015/0.014 192 K 0.018/0.016 224 K 0.021/0.019 256 K 0.023/0.022 288 K 0.031/0.028 320 K 0.031/0.029 384 K 0.037/0.035 448 K 0.043/0.042 512 K 0.049/0.047 576 K 0.065/0.059 640 K 0.082/0.080 768 K 0.100/0.095 896 K 0.117/0.114 1024 K 0.134/0.130 1152 K 0.166/0.155 1280 K 0.187/0.181 1536 K 0.223/0.215 1792 K 0.260/0.253 2048 K 0.295/0.288 2304 K 0.363/0.341 2560 K 0.378/0.367 3072 K 0.447/0.431 3584 K 0.523/0.508 4096 K 0.588/0.574 ******************************************************** At the server, there is two IA64 prebuild binaries. I would recommend the statically linked one. It is build with an older beta compiler version and is faster (about %5). There is a lot of good and fast binaries build for powerpc family Linux/MacOS/MacOSX/Darwin. It is remarkable the good timings for G4 processors (only 10% slower than prime95/pentiumIII). We still have no made a good timing page, we will send it to E.Mayer and to sourceforge when possible. Have a good weekend. Guillermo. - -- Guillermo Ballester Valor gbv@oxixares.com Granada (Spain) _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 20 Oct 2001 09:44:35 -0500 From: mikus@bga.com (Mikus Grinbergs) Subject: Re: Mersenne: Glucas v 2.8c released. Interesting to compare the performance numbers given for the Itanium running Glucas v2.8c against my Thunderbird running mprime v21.4 : - At the smallest FFT length, the Itanium is WAY faster. this performance difference decreases until - At FFTs 640K-2048K, the Itanium is a little bit faster then the performance difference increases until - At the largest FFT length, the Itanium is noticeably faster Is it memory-bandwidth that lets the Itanium pull ahead at the large FFT lengths ? mikus _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 20 Oct 2001 16:31:33 -0400 From: George Woltman Subject: Re: Mersenne: Glucas v 2.8c released. At 09:44 AM 10/20/2001 -0500, Mikus Grinbergs wrote: > then the performance difference increases until > > - At the largest FFT length, the Itanium is noticeably faster > >Is it memory-bandwidth that lets the Itanium pull ahead at the >large FFT lengths ? Just speculation, it could be the larger Itanium caches or better TLB caches. - -- George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 21 Oct 2001 11:04:38 +0200 From: Guillermo Ballester Valor Subject: Re: Mersenne: Glucas v 2.8c released. Hi, > Interesting to compare the performance numbers given for the Itanium > running Glucas v2.8c against my Thunderbird running mprime v21.4 : > AFAIK, mprime v21.4 now uses prefetch hints to avoid idle cycles waiting for new data. Glucas/Itanium (C-plain code) uses a kind of preload, no prefetch, it loads in a loop-cycle what it will need in the next. This way of preload I think is less efficient than directly prefetch if prefetch hints are well tuned. To say the true, it was the first thing I tried, but I got difficulties: gcc compiler is still no good for inline assembler on Itanium, and Intel compiler simply does not support inline assembler (for IA64). So I had to write the preload scheme I told. But what if FFT data are big enough? prefetch request are some often out of L2 memory and the system have to wait many cycles to get the requested data near the processor. So, if we've not prefetched the data many cycles before we still have to wait some clocks to use. > - At the smallest FFT length, the Itanium is WAY faster. > at short FFT length, both mprime/prefetch and Glucas/preload are efficient. L2 cache are big enough too. Here, Itanium has the advantage of its superb FPU units. It can do any combination of FADD and FMUL up to two ops/clock. On the AMD we can only do an FADD and a FMUL in a clock cycle. It is not permitted two FMUL. > this performance difference decreases until > > - At FFTs 640K-2048K, the Itanium is a little bit faster > Here, perhaps, the mprime/prefetch scheme is better. > then the performance difference increases until > > - At the largest FFT length, the Itanium is noticeably faster > > > Is it memory-bandwidth that lets the Itanium pull ahead at the > large FFT lengths ? Now we should need large L2. Some memory request are to main memory. Here the L2 size and bandwidth are important. And, just a speculation, prefetch hints are less effective. Guillermo - -- Guillermo Ballester Valor gbv@oxixares.com Granada (Spain) _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 21 Oct 2001 11:43:51 +0200 From: Guillermo Ballester Valor Subject: Re: Mersenne: Glucas v 2.8c released. Hi again, I forgot to comment an observation made when writing Glucas for Itanium. IA64 architecture has a very nice feature: predication. In the DWT used in most GIMPS clients, the normalization and carry phase has a relevant cost in terms of performance. There some branches hard to predict and here the predication substitutes this branches with great success. On small FFT length, the relative cost of carry_and_norm are greater than bigger runlengths, and this is an additional point to know why Itanium is so good at short Mersenne exponents, and why this advantage is decreases when FFT runlength increases. Have a nice Sunday. Guillermo. - -- Guillermo Ballester Valor gbv@oxixares.com Granada (Spain) _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 21 Oct 2001 15:16:09 -0000 From: bjb@bbhvig.uklinux.net Subject: Re: Mersenne: Glucas v 2.8c released. On 20 Oct 2001, at 9:44, Mikus Grinbergs wrote: > Interesting to compare the performance numbers given for the Itanium > running Glucas v2.8c against my Thunderbird running mprime v21.4 : > > - At the smallest FFT length, the Itanium is WAY faster. Probably a "large cache" effect. > > this performance difference decreases until > > - At FFTs 640K-2048K, the Itanium is a little bit faster Yes, by 640K FFT run length you need > 2MB cache to run with no significant access to "real" memory. > > then the performance difference increases until > > - At the largest FFT length, the Itanium is noticeably faster > > > Is it memory-bandwidth that lets the Itanium pull ahead at the > large FFT lengths ? > I would suspect that the main cause is that the Thunderbird has a fairly limited TLB - as the amount of memory involved in the workspace increases, the proportion of recursive TLB lookups will increase faster than it does with Itanium and so the memory access will effectively slow down. 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 #894 ******************************