Re: Mersenne: Primenet software under Win95 and OS/2
Hi, At 02:52 PM 10/29/98 CST, Richard G. Larson wrote: >install the mersenne stuff in one directory on a drive shared by OS/2 >and Win95 with them sharing the Pxxx, Qxxx etc files >When I tried it, Win95 >picked up the computation that OS/2 was doing when I booted it, but when I went >back to OS/2, the partial computations were lost. The results.txt file is: Win95 is running version 17 which can read a version 16 save file. Unfortunately, version 16 OS/2 cannot read the version 17 save file. If you'd like, I can email a version 16 win95 program to you. Regards, George
Re: Mersenne: Re: Is 128 bit instruction code needed ?
On Thu, 29 Oct 1998 15:58:29 +0100 (MET) Bojan Antonovic wrote: > Realy ? But with 64 bit or 128 bit adressing space you can address > every atom on the earth ... Once I mad a calculation about it, but I > think that 256 bit can address 1/8 of the universe. I seem to recall (vaguely!) that there's about 10^68 or 10^70 atoms in the universe? If 10^70 is the case, that's around 2^231. 2^256 is around 10^77... Simon.
Mersenne: Prime95 version 17.1
Hi all, Prime95 version 17.1 is now available. As usual, go to http://www.mersenne.org/freesoft.htm to download it. The whatsnew.txt file is included below. The first new features is the ability to use ECM factoring on numbers of the form 2^N+1. See http://www.mersenne.org/ecm.htm for exponents that need work (be sure to download lowp.txt). Of special interest are three Fermat numbers: F14 = 2^16384+1 has no known factors, and F12 and F13 are the smallest Fermat numbers that are not completely factored. The 2^N+1 factorer is not quite as fast the 2^N-1 factorer and only supports power-of-two FFT run lengths. The second new feature is the ability to run prime95 with different options at different times of the day (such as a priority above a screen saver at night). You can also have prime95 sleep during some hours of the day. Barring any bug reports, ports to other platforms will occur next week. Happy hunting, George 1) The -T command line switch has been deleted. 2) You can now fine tune your control of the program by adding Time= lines to your prime.ini file - see the readme.txt file. 3) ECM factoring for 2^N+1 is now available. 4) By default, ECM factoring stops if a factor is found for exponents above 5825 and continues (if the cofactor is composite) for exponents below 5825. You can override this behavior by setting ContinueECM=0 or 1 in prime.ini.
Mersenne: Primenet software under Win95 and OS/2
I've been running Mersenne computations on various machines for a longish time. This summer I switched from the manual method to the Primenet server. All under OS/2. I'm currently using: Thu 10-29-1998 13:32 [D:\MERSENNE]primeos2 -v Mersenne Prime Test Program, Version 16.3.2 OS/2 - EMX version 3.1 Just recently I decided (in order to have a compuational environment on my machine that is the same as my students at UIC are using) to install Boot Manager with OS/2 Warp 4 and Windows 95 on one of my machines. I had the bright idea: install the mersenne stuff in one directory on a drive shared by OS/2 and Win95 (taking advantage of the differently named executables: PRIMEOS2.EXE and PRIME95.EXE) and autostart the appropriate one from each operating system, with them sharing the Pxxx, Qxxx etc files When I tried it, Win95 picked up the computation that OS/2 was doing when I booted it, but when I went back to OS/2, the partial computations were lost. The results.txt file is: [Thu Oct 22 10:35:42 1998] Self-test 320 passed! [Thu Oct 29 12:37:02 1998] Error reading intermediate file: p6258701 Renaming intermediate file q6258701 to p6258701. Error reading intermediate file: p6258701 (Being a strong believer in Murphy's Law, I had made a backup of the directory before I tried this, so all was not lost.) The FAQ says that the Windows and linux versions are compatible, and I understood that the OS/2 version a re-compilation of the linux version. (I'm using the version Thu 10-29-1998 14:47 [D:\MERSENNE]primeos2 -v Mersenne Prime Test Program, Version 16.3.2 OS/2 - EMX version 3.1 of the OS/2 version; I don't have the exact version of the Windows version (it's too much trouble to re-boot Windowss at the moment) but it was downloaded on10/14/98) Suggestions? - Richard G. Larson, Professor, Dept of Math., Stat., and Comp. Sci. U. of Ill. at Chicago, 851 S. Morgan St, M/C 249, Chicago IL 60607-7045 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (312) 996-8616 email: [EMAIL PROTECTED]homepage: http://www.uic.edu/~rgl/ PGP key fingerprint: FA 6A 8D 21 41 0D 33 E9 E4 5F 46 83 50 C1 34 09
Re: Mersenne: AMD K7 will
At 03:38 PM 10/29/98 +0100, Bojan Antonovic wrote: >> Why do you believe there will be no 128bit processors? Isn't "more data >> at a time" always better? > >No. Except you know what you want to do with it. More data isn't always better, but there are cases where it helps. To take an example that is familiar to us, if you double the data width you make testing Mersenne numbers more than twice as fast. +--+ | Jud McCranie [EMAIL PROTECTED] or @camcat.com | | | | Where a calculator on the ENIAC is equipped with 19,000 | | vacuum tubes and weighs 30 tons, computers in the future | | may have only 1,000 vacuum tubes and perhaps only weigh | | 1.5 tons.-- Popular Mechanics, March 1949. | +--+
Re: Mersenne: Error: Illegal Sumout
On Wed, 28 Oct 1998 16:59:47 -0500, George Woltman wrote: >> I think my Prime95 broke! I am on iteneration 479162/5518463 and get a >>continuous stream of "ERROR: ILLEGAL SUMOUT" messages which are constantly >This is probably an interaction with some new piece of software. >I know that the OS should protect you from such interactions, but >this problem is quite common. >The good news is that these errors do not seem to affect prime95's >accuracy (unlike other error messages). A recent double-check had >3 SUMOUT errors, but the residues matched anyway. Speaking of error messages.. I have a PII-266 working on a 6 million number at the moment which is (almost) constantly spitting out ERROR: SUM(INPUTS) != SUM(OUTPUTS) errors and the occasional ERROR: ROUND OFF thrown in for fun.. I've had problems with the computer before (the motherboard almost literally fried itself overheating and was replaced - note that it isn't overclocked in any way), and I'm getting the (new) board replaced by the local manufacturer on monday. The question is whether I should just throw out the computations that have already been done, or continue when the new board arrives? -- Sincerely, | Don't waste your computer's idle time! Philip Heede | = = = = = = = = = = = = = =| http://www.distributed.net/ WWW: http://pah.person.dk | http://www.mersenne.org/ Email: [EMAIL PROTECTED] | http://www.thoic.com/keyblitz/ Regional representative for www.Distributed.Net in Denmark PGP Public RSA Fingerprint: 5DB0 21A6 A606 D9BC BD71 59CA 82B4 0C6E PGP Public DSS Fingerprint: FDA0 A1FD D025 EF15 1041 894F 4109 0B57 CDAA ACC3 ... If there is no God, who pops up the next Kleenex in the box? ** Tag(s) inserted by Bandit Tagger98 - http://www.gbar.dtu.dk/~c918704
Re: Mersenne: Error: Illegal Sumout
>>>[...] "ERROR: ILLEGAL SUMOUT" [...] Any suggestions? >> >>It happened to me. Turned out to be bad tag RAM. > >Luke, could you explain what "tag RAM" is please? > >Help in identifying same would be nice too, if possible. its the part of the cache that holds the address bits. On pentium pro and pentium-II systems, its in the CPU module. On *some* plain pentium chipsets, its 1 or two discrete static ram (SRAM) chips, but on other P5 chipsets, its integrated into the memory controller chip. -jrp
Mersenne: Re: Is 128 bit instruction code needed ?
> So far, the drive towards more bits in the instruction code is by the need > to address more data rather than the needs to compute longer integer or > higher numeric precision. And this is usually driven by 2 factors : The > computer > RAM size and the biggest Database size required commercially . Realy ? But with 64 bit or 128 bit adressing space you can address every atom on the earth ... Once I mad a calculation about it, but I think that 256 bit can address 1/8 of the universe. 1 mol protons = 1g = 6*10^23 protons 10^3 mol p. = 1kg =6*10^23 protoons earth: 5*10^24 kg = 3*10^48 protons = 2^150 bit (+- 5 bit, approx). = 2^73 g -> enough to adress ... Bojan
Re: Mersenne: Error: Illegal Sumout
Brian J Beesley writes: >I think maybe that means that either you have a hardware IRQ >conflict between your Midi device and the system board, or that >'Crescendo' is clobbering the interrupt vector being used to control >the floating-point unit. It ONLY happens during Crescendo. This happens on ANY win95/win98 system but not on NT. Crescendo is streaming midi from the net and using its own midi playback algorithms (software synthesis). Its not a IRQ conflict. >Does the same thing happen if you play a Midi file using something >else? yup. >If so, then look for a hardware conflict. If not, I'd reccomend >disabling Crescendo. Of *COURSE* I disabled it. Crescendo is from http://www.liveupdate.com >As for IE, I prefer Netscape Communicator anyway ;-) This thing crashes when installed as a nutscrape plugin too. Its just a bigger pain to install... (IE will ask if you want it and autoinstall it, while with netscape, you have to manually download, save, and execute the installer).
Re: Mersenne: AMD K7 will "smoke" Intel FPU?
> Date: Mon, 26 Oct 1998 16:26:54 -0500 (EST) > From: "Brian U. Peltzer" <[EMAIL PROTECTED]> > To: Bojan Antonovic <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED] > Subject: Re: Mersenne: AMD K7 will "smoke" Intel FPU? > MIME-Version: 1.0 > > On Thu, 22 Oct 1998, Bojan Antonovic wrote: > > > > > c:=a+b > > RISC: add a,b,c > > CISC: mov a,c (1) > > add b,c (2) > > > > When (2) depends on (1), there is no possibility for parallelization. Good, you > > can argue that instructions on 3 operators are better than the one on 2 > > instructions. > > > > Bojan > > > > > > (1) U. I hate to be picky, but that code is not the same... >add b,c; move a,b (just thought is was funny nobody >mentioned it) Why ? But it depends on declaration of the execution order (left to right). > (2) Sure, you loose the parallelism between the two instructions, > but aren't you forgetting basic pipelining? Simple wrap arounds will make > that execute in one more cycle than the RISC equivalent. Big deal. Before doing a branch, the precosser executes the command written after the branch. So it compensates. > You > are also not taking into account that some cisc based routines will take a > shorter time than some RISC. No. Speedup is made by loosing some space on the DIE to reach the goal, so this is independent of the architecture (if you mean that). > instruction level, you are comparing apples and oranges. I don't even > think there IS a level ground to actually compare them on. Why that ? If two things should do the same, why shouldn`t be there a comparison ? Bojan
Re: Mersenne: Error: Illegal Sumout
Hi, At 04:44 PM 10/29/98 +0100, Philip Heede wrote: >Speaking of error messages.. >I have a PII-266 working on a 6 million number at the moment which is >(almost) constantly spitting out ERROR: SUM(INPUTS) != SUM(OUTPUTS) errors >and the occasional ERROR: ROUND OFF thrown in for fun.. These are the kind of errors that indicate serious hardware problems. It could be CPU overheating, flaky RAM, or something else. The bad news is these errors may well corrupt results. In the recent 535 double-check results, 3 had these errors - only one of the three matched the previous residue. Sorry, George
Re: Mersenne: AMD K7 will
> On Mon, 26 Oct 1998, Bojan Antonovic wrote: > > [...schnipp...] > > > > My conjuncture is: there is no need for 128 bit instruction code, so 64 bit > > inst. code will be the final one. FPU register will stay to use 64 bit, and > > for the other one I can`t say nothing. The main part of speeding up > > processors will be done be using multiple processors. > > Why do you believe there will be no 128bit processors? Isn't "more data > at a time" always better? No. Except you know what you want to do with it. > I agree with you that advances in multiprocessing are needed and will be > beneficial, but in the race for a better desktop machine, SMP does little > to help. > > Without more info on the technical reasons behind your conjecture, I am > willing to bet that at least one of the non-intel chip manufacturers > announces a 128bit chip, if only to gain some attention. There has been already some developting of 256 bit instruction code machines. But for an usual user there is no use in more instructions. And as long for an usual user there is no use, such special chips will not be produced. Bojan
Re: Mersenne: Error: Illegal Sumout
>>[...] "ERROR: ILLEGAL SUMOUT" [...] Any suggestions? > >It happened to me. Turned out to be bad tag RAM. it happens to me each and every time a piece of web-ware called 'Crescendo' fires itself up under IE and plays a MIDI stream. -jrp
Re: Mersenne: Error: Illegal Sumout
At 05:09 PM 10/28/98 -0800, Luke Welsh wrote: >>[...] "ERROR: ILLEGAL SUMOUT" [...] Any suggestions? > >It happened to me. Turned out to be bad tag RAM. Luke, could you explain what "tag RAM" is please? Help in identifying same would be nice too, if possible. Bruce Metcalf mailto:[EMAIL PROTECTED] http://www.magicnet.net/~bmetcalf/
