Mersenne Digest Wednesday, October 17 2001 Volume 01 : Number 893 ---------------------------------------------------------------------- Date: Sun, 14 Oct 2001 19:57:36 -0400 From: George Woltman Subject: Re: Mersenne: AthlonXP Hi, At 11:41 AM 10/14/2001 +0000, bjb@bbhvig.uklinux.net wrote: > > According to latest benchmarks (http://www.mersenne.org/bench.htm), > > AthlonXP seems to be slower than the Thunderbird. Does anybody have a > > technical explanation ? The technical explanation is that I only have one XP benchmark. I'm sure that as I get more benchmarks a better tuned system will report better timings. >The Athlon XP lies about its speed. Remember the old Cyrix trick? >Well AMD have gone for the same - pick a benchmark that suits >you, then claim your chip is "1800+" if it runs _that_ benchmark a >wee bit faster than the opposition's chip running at 1800 MHz. I'll try to post the real processor speed on my page, though it will be a bit of a pain keeping it all straight. I understand why AMD did this, at least they have been relatively honest (that is, conservative) in choosing their "equivalent P4 cpu speed" number. >That seems to have been the case for some months now; it's >SSE2 which makes the difference. A P4 running Prime95 is well >over twice as fast as a T'bird running at the same clock speed. The P4 has two advantages. One is memory bandwidth. The other is SSE2. Interestingly, the theoretical floating point throughput of the P4 is identical to the Athlon (one multiply and one add per clock) and the Athlon even has lower latencies. So why is SSE2 an advantage? I theorize that their are 3 reasons. 1) It relieves the register pressure. With SSE2 there are 16 floating point values in registers instead of 8. Obviously it is much easier to schedule operations that are not dependent on previous operations with twice as many data values. 2) The directly addressable registers are easier for the chip to keep track of than the standard x86 FPU register stack. I'm guessing there is some limit as to how much internal register renaming can hide this problem in the Athlon. 3) Once an SSE2 instruction is ready, it starts two different FPU operations on two consecutive clock cycles. In other words, the CPU only needs to find a new instruction to execute every other clock cycle to keep the FPU units busy. This is of course heavily related to reason #1. When AMD finally implements SSE2 it should be a screamer. The lower latencies could be a big plus. Regards, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 14 Oct 2001 19:16:40 -0700 From: Matthew Ashton Subject: Re: Mersenne: AthlonXP - --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 07:30:24AM +0200, Jean-Yves Canart wrote: > Hello All > > According to latest benchmarks (http://www.mersenne.org/bench.htm), > AthlonXP seems to be slower than the Thunderbird. Does anybody have a > technical explanation ? > Hi, The benchmark run was mine, and I was a little disapointed as well. The system is a dual Athlon 1700XP (1460Mhz). My only guess is that the dual cpu overhead is causeing the slightly slower times. I confess, I origionaly ran the tests while I had other things open (a little sloppy, sorry), but the results are not much different. Best time for 256K FFT length: 27.979 ms. Best time for 320K FFT length: 35.807 ms. Best time for 384K FFT length: 45.213 ms. Best time for 448K FFT length: 51.970 ms. Best time for 512K FFT length: 56.785 ms. Best time for 640K FFT length: 73.057 ms. Best time for 768K FFT length: 89.294 ms. Best time for 892K FFT length: 104.374 ms. Best time for 1024K FFT length: 119.304 ms. Best time for 1280K FFT length: 157.683 ms. Best time for 1536K FFT length: 190.200 ms. Best time for 1792K FFT length: 231.537 ms. For the curious, the system is based on the Tyan Tiger MP, and was running Linux 2.4.10-ac12 with 1GB of 266Mhz DDR Ram.=20 - -- Matthew Ashton mashton@bagofholding.com Sweet Links http://www.pez.ca/ =09 - --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE7ykcI7z3L+guva8IRAhqlAJ4li+TjwpC0HovTdHlkGg9Ck4+d4gCfT0mz LuACj8ICIik5s8EezF6g/vs= =DYZt - -----END PGP SIGNATURE----- - --1yeeQ81UyVL57Vl7-- _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 14 Oct 2001 23:53:32 -0400 From: George Woltman Subject: Re: Mersenne: AthlonXP Hi, At 07:16 PM 10/14/2001 -0700, Matthew Ashton wrote: >The benchmark run was mine, and I was a little disapointed as well. >The system is a dual Athlon 1700XP (1460Mhz). >For the curious, the system is based on the Tyan Tiger MP, and was >running Linux 2.4.10-ac12 with 1GB of 266Mhz DDR Ram. I have three Athlon 1400 reports. Two are slower than your 1460MHz AthlonXP. The faster system was described this way by its owner: 1.4 GHz Athlon (No O/C) 133DDR (512MB, rated CL=2.5 running at 2) Abit KG7-Lite Motherboard Regards, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 15 Oct 2001 09:20:54 -0700 From: Barry Hansen Subject: Mersenne: Prime95 version number in reports First let me say "thanks!" for providing the big speed-up for P4 machines. I've got one P4 box and it's humming along at an astonishing rate, so I just started it on a ten-million digit test. This will be fun! And since my ten-year old is the main user (and a math whiz), he feels proud to contribute to research. Don't worry, he does understand about the probability of very unlikely events. Now for my problem... I have a dozen or so machines scattered among friends that are participating in this prime search. I want to upgrade them all to v21.4, but I can't tell who's got what. My individual status report says they are all "v19/v20". Would it be possible for someone to enhance the individual report (http://mersenne.org/ips/accounts.html) to contain the full version number? Thanks, it would really help my maintenance work! Barry Hansen Team "barryh" _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 15 Oct 2001 19:35:36 -0000 From: bjb@bbhvig.uklinux.net Subject: Re: Mersenne: AthlonXP On 14 Oct 2001, at 13:40, Francois Gouget wrote: > Nope. It is still 0.18 microns (see Anandtech). If you have a > source > claiming otherwise I would like to see it. They plan to switch to 0.13 > early next year. Then, they should be able to increase the frequency > big time. Oops, I got that wrong. Sorry. Comes of trusting a failing memory :( > > > > which means keeping it cool should be a bit easier. > > They say it runs 20% cooler. It would probably run much cooler if > they had switched to 0.13 microns. The reason they provide for the > lower power consumption, is small architectural optimizations. But > what I find most interesting is its low power consumption when idle. > They introduced it for the laptop market but AFAIK it is also present > in the regular desktop processor. 20% cooler = 60K? There should be frost on the heatsink ... Do you mean 20% less power consumption? That seems reasonable. Denser circuits allow lower voltages which does result in a lot less power consumption per element. But there's less area for the waste heat to get out, so the cooling problem doesn't neccessarily go away... > This poses a kind of dilemna since the energy used to run prime-net > is no longer energy that would have been wasted otherwise. So you have > to make a choice between preserving the environment and running > prime-net (to some extent). This is the case with most if not all of the mainstream PC CPUs made in the last couple of years. If you don't use the floating point unit the FPU turns itself off, there is a large drop in current draw and the CPU cools down. Alternatively, with many "micro" desktop & laptops, you need to turn on an extra fan if you run programs which exercise the FPU (as Prime95/mprime undoubtedly does). The CPU current consumption of a 1.2GHz T'bird will drop by ~30W when the FPU is inactive. However, given that the power drawn by the system as a whole is likely to be >150W (_much_ more if you have a large CRT monitor), the power saving by the system as a whole is not likely to be hugely significant. > > [...] > > Note particularly that e.g. 256 MB can be made up of one bank of 256 > > MBit, two banks of 128 MBit or four banks of 64 MBit RAM chips; > > expect a performance difference of 5% - 7% between these > > configurations even if the chip access speeds & timings are > > identical. More banks are faster. > > Hmmm, you need to distinguish motherboards that merely have > multiple > memory slots, from motherboards that have more than one data path to > the memory. The only motherboards that I know of that can do the > latter are some RDRAM based motherboards and the Nvidia nForce. > In all other cases (the more common one?) putting multiple DIMMs > should not affect performance one way or another. No, this is the construction of individual DIMMs, not occupancy of DIMM slots, though populating two DIMM sockets with _identical_ single-bank DIMMs can get you the same performance boost. VIA Apollo Pro chipsets can definitely take advantage of multibank DIMMs; the BIOS provided with some mobos (particularly Abit) allows you to tune the chip banking manually. I found on my Abit KT7A, with two identical double-bank SDRAM DIMMs installed, setting quadruple banking improved the speed of mprime by 7% compared with the default setting. > > Yes, AMD better implement SSE2 in their processors soon. Why? Might there not be a better way? The point is that a PII-350 has more than enough power to do what most business users need, whilst tackling the problem of updating complex displays very rapidly (for games) is better handled in dedicated hardware in the graphics adapter. What I would like to see in a CPU is a means where you could upload your own microcode, enabling design of specific instruction sets to handle particular problems very efficiently. For numerical work, the capability to handle _very_ long integers directly would be extremely useful. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 15 Oct 2001 19:35:36 -0000 From: bjb@bbhvig.uklinux.net Subject: Re: Mersenne: AthlonXP On 14 Oct 2001, at 19:57, George Woltman wrote: > The P4 has two advantages. One is memory bandwidth. The other > is SSE2. If memory bandwidth was a primary reason then the P4 would run the standard "P6" (Pentium Pro) code efficiently. If you remember the postings when the P4 was originally released, this was definitely not the case. > > When AMD finally implements SSE2 it should be a screamer. The lower > latencies could be a big plus. Assuming, of course, that the complications involved in implementing SSE2 don't clobber the performance (in terms of increased latency). Which is what seemed to happen with the P4. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 15 Oct 2001 14:24:03 -0700 From: Matthew Ashton Subject: Re: Mersenne: AthlonXP - --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 11:53:32PM -0400, George Woltman wrote: > I have three Athlon 1400 reports. Two are slower than your 1460MHz=20 > AthlonXP. > The faster system was described this way by its owner: >=20 > 1.4 GHz Athlon (No O/C) > 133DDR (512MB, rated CL=3D2.5 running at 2) > Abit KG7-Lite Motherboard >=20 Well, After hunting around the net, the problem does indeed seem to be the AMD760MP chipset. The VIA chipsets (like the ones used in the Abit KG7-Lite) are generaly faster. Unfortunatly, the AMD760MP is the only available dual athlon chipset (for now). The 760MPX is stated to be released soon and should address some of the latency problems. The BIOS on the TigerMP is also a let down. My previous system was a Abit BP6 (dual celeron) and it had all sorts of options for ram timing, bus speed increments of 1Mhz, voltage tweaks, everything required for tuning. The TigerMP has nothing. The rumours that the AthlonXP chips don't operate in SMP mode are false (with the TigerMP anyways). The XP's are all Palomino cores just like the Athlon MP's. It seems like just another silly marketing trick by AMD. That all said, this computer is crazy fast. - --=20 Matthew Ashton mashton@bagofholding.com Sweet Links http://www.pez.ca/ - --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE7y1Pz7z3L+guva8IRAjz8AJwPWn5tytZh7BZEs8BuZ79jVIhrLgCfVplT UFefs75yxkNdDsr6QlR1pcY= =UFRR - -----END PGP SIGNATURE----- - --UlVJffcvxoiEqYs2-- _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 15 Oct 2001 23:33:56 +0200 From: "Steinar H. Gunderson" Subject: Mersenne: Re: AthlonXP On Mon, Oct 15, 2001 at 07:35:36PM -0000, bjb@bbhvig.uklinux.net wrote: >What I would like to see in a CPU is a means where you could >upload your own microcode, enabling design of specific instruction >sets to handle particular problems very efficiently. What about (in an ideal world) just programming microcode directly, without having to make an extra instruction set on top of that? Suddenly, you would have both instant access to all the "ports" (or whatever the CPU makers call their execution units these days), a lot of registers, etc.. In addition, the problem with only a single decoder etc. on P4 would effectively go away entirely. The only problem I could see would be a lot more code having to go over the bus (and occupy more space in the instruction cache), especially as some people have pointed out that the microcode might very well be some form of VLIW :-) At least for us Linux users, having to recompile everything wouldn't be _that_ big of a problem -- source for about everything you'd need would be readily available (except that mprime would have to be ported, of course ;-) )... /* 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: Mon, 15 Oct 2001 14:59:01 -0700 From: "Aaron Blosser" Subject: Re: Mersenne: Re: AthlonXP Well, I suppose RISC is about as close as you can get to that. Microcode, for reasons best known to someone familiar with CPU design, is not something you can just reprogram on the fly... But RISC instructions are made to map to microcode (or *is* the microcode), allowing a programmer to fine tune the higher level instructions in whatever way they see fit. All the other fancy schmancy CPU stuff just keeps the instruction pipelines churning along at top efficiency. That's the long and short of it. Now, if all programmers were as concerned about optimizing code as George is, we could run Windows XP on a 286 system if you really wanted... optimized code can do wonders on even the slowest systems. :) Aaron - ----- Original Message ----- From: "Steinar H. Gunderson" To: Sent: Monday, October 15, 2001 2:33 PM Subject: Mersenne: Re: AthlonXP > On Mon, Oct 15, 2001 at 07:35:36PM -0000, bjb@bbhvig.uklinux.net wrote: > >What I would like to see in a CPU is a means where you could > >upload your own microcode, enabling design of specific instruction > >sets to handle particular problems very efficiently. > > What about (in an ideal world) just programming microcode directly, without > having to make an extra instruction set on top of that? Suddenly, you would > have both instant access to all the "ports" (or whatever the CPU makers call > their execution units these days), a lot of registers, etc.. In addition, the > problem with only a single decoder etc. on P4 would effectively go away > entirely. > > The only problem I could see would be a lot more code having to go over the > bus (and occupy more space in the instruction cache), especially as some > people have pointed out that the microcode might very well be some form of > VLIW :-) At least for us Linux users, having to recompile everything wouldn't > be _that_ big of a problem -- source for about everything you'd need would be > readily available (except that mprime would have to be ported, of course ;-) > )... _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 15 Oct 2001 15:32:28 -0700 From: "John R Pierce" Subject: Re: Mersenne: AthlonXP There's something a bit screwy about the way your messages are encapsulated here, when I recieve them the message body is appearing as an .txt attachment. I haven't seen that happen from anyone elses mail (and I get a lot of email from numerous lists). MIME formatted mail is generally bad on majordomo email lists anyways, as it looks like heck on the digest version. - ----- Original Message ----- Date: Mon, 15 Oct 2001 14:24:03 -0700 From: Matthew Ashton To: George Woltman Cc: mersenne@base.com Subject: Re: Mersenne: AthlonXP Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20011014235144.03306c60@pop-server.cfl.rr.com> User-Agent: Mutt/1.3.22i Precedence: bulk Status: - --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 11:53:32PM -0400, George Woltman wrote: > I have three Athlon 1400 reports. Two are slower than your 1460MHz=20 > AthlonXP. > The faster system was described this way by its owner: >=20 > 1.4 GHz Athlon (No O/C) > 133DDR (512MB, rated CL=3D2.5 running at 2) > Abit KG7-Lite Motherboard >=20 Well, After hunting around the net, the problem does indeed seem to be the AMD760MP chipset. The VIA chipsets (like the ones used in the Abit KG7-Lite) are generaly faster. Unfortunatly, the AMD760MP is the only available dual athlon chipset (for now). The 760MPX is stated to be released soon and should address some of the latency problems. The BIOS on the TigerMP is also a let down. My previous system was a Abit BP6 (dual celeron) and it had all sorts of options for ram timing, bus speed increments of 1Mhz, voltage tweaks, everything required for tuning. The TigerMP has nothing. The rumours that the AthlonXP chips don't operate in SMP mode are false (with the TigerMP anyways). The XP's are all Palomino cores just like the Athlon MP's. It seems like just another silly marketing trick by AMD. That all said, this computer is crazy fast. - --=20 Matthew Ashton mashton@bagofholding.com Sweet Links http://www.pez.ca/ - --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE7y1Pz7z3L+guva8IRAjz8AJwPWn5tytZh7BZEs8BuZ79jVIhrLgCfVplT UFefs75yxkNdDsr6QlR1pcY= =UFRR - -----END PGP SIGNATURE----- - --UlVJffcvxoiEqYs2-- _________________________________________________________________________ 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: Mon, 15 Oct 2001 15:36:39 -0700 From: Matthew Ashton Subject: Re: Mersenne: AthlonXP On Mon, Oct 15, 2001 at 03:32:28PM -0700, John R Pierce wrote: > There's something a bit screwy about the way your messages are encapsulated > here, when I recieve them the message body is appearing as an .txt > attachment. I haven't seen that happen from anyone elses mail (and I get a > lot of email from numerous lists). MIME formatted mail is generally bad on > majordomo email lists anyways, as it looks like heck on the digest version. > I've heard that before, and always from Outlook users. It seems to be a bit of a bug in how outlook interprets the pgp signature. (Is this any better?) - -- Matthew Ashton mashton@bagofholding.com Sweet Links http://www.pez.ca/ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 15 Oct 2001 18:41:51 -0700 (PDT) From: Francois Gouget Subject: Re: Mersenne: AthlonXP On Mon, 15 Oct 2001 bjb@bbhvig.uklinux.net wrote: > On 14 Oct 2001, at 13:40, Francois Gouget wrote: [...] > 20% cooler = 60K? There should be frost on the heatsink ... > > Do you mean 20% less power consumption? That seems reasonable. Good point, I mixed up. and it's definitely not the same :-) > Denser circuits allow lower voltages which does result in a lot less > power consumption per element. But there's less area for the > waste heat to get out, so the cooling problem doesn't neccessarily > go away... Still usually when the process shrinks and the frequency stays the the chip runs cooler too. I believe this is the case of the new Tualatin P3. > > This poses a kind of dilemna since the energy used to run prime-net > > is no longer energy that would have been wasted otherwise. So you have > > to make a choice between preserving the environment and running > > prime-net (to some extent). > > This is the case with most if not all of the mainstream PC CPUs > made in the last couple of years. If you don't use the floating point > unit the FPU turns itself off, there is a large drop in current draw > and the CPU cools down. Alternatively, with many "micro" desktop > & laptops, you need to turn on an extra fan if you run programs > which exercise the FPU (as Prime95/mprime undoubtedly does). > > The CPU current consumption of a 1.2GHz T'bird will drop by > ~30W when the FPU is inactive. However, given that the power > drawn by the system as a whole is likely to be >150W (_much_ > more if you have a large CRT monitor), the power saving by the > system as a whole is not likely to be hugely significant. True. It's just even more pronounced with processors like the K6 and the new Athlons: I believe they adjust the processor frequency dynamically, kind of like the Transmeta ones. So it's the power economies are realized on the whole processor, not just a specific unit. It's also why I don't run prime-net on my laptop (a P3-600): I like to keep it quiet which means getting it idle so that the CPU fan is stopped. [...] > > > Note particularly that e.g. 256 MB can be made up of one bank of 256 > > > MBit, two banks of 128 MBit or four banks of 64 MBit RAM chips; > > > expect a performance difference of 5% - 7% between these > > > configurations even if the chip access speeds & timings are > > > identical. More banks are faster. > > > > Hmmm, you need to distinguish motherboards that merely have > > multiple > > memory slots, from motherboards that have more than one data path to > > the memory. The only motherboards that I know of that can do the > > latter are some RDRAM based motherboards and the Nvidia nForce. > > In all other cases (the more common one?) putting multiple DIMMs > > should not affect performance one way or another. > > No, this is the construction of individual DIMMs, not occupancy of > DIMM slots, though populating two DIMM sockets with _identical_ > single-bank DIMMs can get you the same performance boost. Ah, I understand what you meant now. I thought all DIMMs were multi-banked (potentially even holding all banks in just one chip?). > > Yes, AMD better implement SSE2 in their processors soon. > > Why? Might there not be a better way? SSE2 seems to be a good extension to the x86 instruction set. It looks like it does wonders for prime-net anyway. And since I expect most applications to target SSE2 rather than 3DNow... As for whether it's really useful in everyday life it's another matter. But for applications that do lots of floating point operations it seems worth it. - -- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 16 Oct 2001 09:29:54 +0200 From: "Steinar H. Gunderson" Subject: Mersenne: Message display problems [OT] (was: Re: AthlonXP) On Mon, Oct 15, 2001 at 03:36:39PM -0700, Matthew Ashton wrote: >I've heard that before, and always from Outlook users. It seems to be a >bit of a bug in how outlook interprets the pgp signature. > >(Is this any better?) If there's still a problem, try set charset="iso-8859-1" in your .muttrc file. It has fixed some similar (although not PGP-related) problems for me. /* 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: Tue, 16 Oct 2001 08:45:37 -0700 From: "Paul Leyland" Subject: RE: Mersenne: Re: AthlonXP > Well, I suppose RISC is about as close as you can get to > that. Microcode, for reasons best known to someone > familiar with CPU design, is not something > you can just reprogram on the fly... I beg to differ. As someone who has written megabytes of microcode, including an entire IEEE floating point instruction set, a C machine, a LispKit machine and a large chunk of a graph reduction machine in AMD 2900 series bit-slice ucode (that dates me!) I can state authoritatively that updating ucode on the fly is not necessarily hard. Just because modern cpus don't provide run-time loadable ucode (if anyone knows of present day examples, please let me know) doesn't mean that it's impossible. Indeed, the IA-64 architecture comes damned close to being a ucodable machine, as the assembly language is very low level in many respects. The main reason, IMO, why runtime loadable ucode isn't more widely available is that there is no perceived large market for it. We sold our machines primarily to labs who were researching machine architectures. Some years before that, DEC sold PDP-11/60 boxes with writable control store for organizations that needed fast and custom data capture. The nuclear and particle physics communities loved them. > of it. Now, if all programmers were as concerned about > optimizing code as George is, we > could run Windows XP on a 286 system if you really wanted... > optimized code can do wonders on even the slowest systems. :) Actually, a 286 would have big problems running WinXP, not least because its lack of support for demand paged virtual memory and inadequate kernel/user separation. That's why Linux requires at least a 386. Paul _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 16 Oct 2001 09:46:06 -0700 From: "Aaron Blosser" Subject: Re: Mersenne: Re: AthlonXP First, the point about XP running on a 286 if it were optimized... I was being facetious. Didn't think people would take me literally. That being said, I'll modify that and say it could run on a *386*. :) Maybe we're not understanding what is meant by "microcode"... The only CPU I've designed was a 4-bit system that didn't use microcode to get it's work done (it was for a class), so I can't claim direct experience, but I at least thought I knew what the word microcode implied... a level of abstraction, if you will, between the opcodes and the actual hardware... a reduced instruction set sitting there that could take some of those complex codes and break it down into the fundamental instructions. Anyway, that's why I said that a RISC processor has more flexibility in that regard, because you have a near 1-1 corellation with the opcodes and what the CPU is directly capable of, and any higher level things you want to do are up to the programmer. So, that was my understanding, at least, but if I'm wrong then I suppose it'd be good to be educated. :) Aaron - ----- Original Message ----- From: "Paul Leyland" To: "Aaron Blosser" ; "Mersenne@Base. Com" Sent: Tuesday, October 16, 2001 8:45 AM Subject: RE: Mersenne: Re: AthlonXP > Well, I suppose RISC is about as close as you can get to > that. Microcode, for reasons best known to someone > familiar with CPU design, is not something > you can just reprogram on the fly... I beg to differ. As someone who has written megabytes of microcode, including an entire IEEE floating point instruction set, a C machine, a LispKit machine and a large chunk of a graph reduction machine in AMD 2900 series bit-slice ucode (that dates me!) I can state authoritatively that updating ucode on the fly is not necessarily hard. Just because modern cpus don't provide run-time loadable ucode (if anyone knows of present day examples, please let me know) doesn't mean that it's impossible. Indeed, the IA-64 architecture comes damned close to being a ucodable machine, as the assembly language is very low level in many respects. The main reason, IMO, why runtime loadable ucode isn't more widely available is that there is no perceived large market for it. We sold our machines primarily to labs who were researching machine architectures. Some years before that, DEC sold PDP-11/60 boxes with writable control store for organizations that needed fast and custom data capture. The nuclear and particle physics communities loved them. > of it. Now, if all programmers were as concerned about > optimizing code as George is, we > could run Windows XP on a 286 system if you really wanted... > optimized code can do wonders on even the slowest systems. :) Actually, a 286 would have big problems running WinXP, not least because its lack of support for demand paged virtual memory and inadequate kernel/user separation. That's why Linux requires at least a 386. Paul _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 16 Oct 2001 10:15:14 -0700 From: "John R Pierce" Subject: Re: Mersenne: Re: AthlonXP > Maybe we're not understanding what is meant by "microcode"... The only CPU I've designed was a 4-bit system that didn't use microcode to get it's work done (it was for a class), so I can't claim direct experience, but I at least thought I knew what the word microcode implied... a level of abstraction, if you will, between the opcodes and the actual hardware... a reduced instruction set sitting there that could take some of those complex codes and break it down into the fundamental instructions. Modern processor architectures are more about datapaths than microcode. The microcode they DO use is far more obtuse than the old 2900 style bitslice architectures (which, IIRC, ran at maybe 4-10Mhz peak, and took 4-8 microcycles for a single CISC type 'instruction', I wrote tons of that stuff too) in fact, the pentiums since P2 at least have a sort of microcode, this is used to break the more complex instructions down into 'microops' which are all executed at the various stages of the execution pipeline. Simple instructions remain a single cycle per stage. This 'microcode' can be field updated by intel via BIOS upgrades, they do this primarily to fix bugs in particular versions. Most of the fixes run considerably slower than the original target instruction. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 16 Oct 2001 11:04:38 +0200 From: Lem Subject: Re: Mersenne: AthlonXP On Sun, 14 Oct 2001 19:57:36 -0400, in Mersenne_mailing_list you wrote: >I understand why AMD did this, at >least they have been relatively honest (that is, conservative) in choosing >their "equivalent P4 cpu speed" number. Hi! Just to say that the number is _not_ a 'Pentium4 rating', but a 'T-bird Rating'. It may sound strange, but it's true. Past rumors about it are now confirmed by AMD web pages. :) - -- Bye. Lem - ---------------------------------- 'CLOCK is what you make of it' _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 16 Oct 2001 20:20:59 +0200 From: Guillermo Ballester Valor Subject: Mersenne: Mersenne list problems? Hi, I've been trying to contact to Mersenne list to change my subscription since a week ago. There is no way to contact to www.scruznet.com host. Is there any problem?. Must we update the links?. Thanks. 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: Tue, 16 Oct 2001 13:26:11 -0500 From: Shane & Amy Sanford Subject: Mersenne: Question Whats up with this exponent I checked out yesterday, the factor bits = 0 on my individual account report page & in my work to do file. 6810631 D* 0 DoubleCheck=6810631,0,0 Thx Shane _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 16 Oct 2001 12:12:21 -0700 From: "John R Pierce" Subject: Re: Mersenne: Mersenne list problems? > I've been trying to contact to Mersenne list to change my subscription since > a week ago. There is no way to contact to www.scruznet.com host. Is there any > problem?. Must we update the links?. yeah, scruz-net is gone. try sending a message with the word 'h e l p' to majordomo@base.com (no spaces, subject is ignored) _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 17 Oct 2001 06:12:03 -0700 From: "Paul Leyland" Subject: RE: Mersenne: Re: AthlonXP > Maybe we're not understanding what is meant by "microcode"... > The only CPU I've designed was a 4-bit system that didn't use > microcode to get it's work done (it was for a class), so I > can't claim direct experience, but I at least thought I knew > what the word microcode implied... a level of abstraction, if > you will, between the opcodes and the actual hardware... a > reduced instruction set sitting there that could take some of > those complex codes and break it down into the fundamental > instructions. That's close to my understanding of microcode but, remember, I last did serious microcoding on hardware that was state of the art 20 years ago. Intermediate level of abstration, yes, as far as it goes, but that description hides a lot of detail which I regard as essential. IMO, microcode has to be able to control functional elements at a very low level indeed. The ALU is controllable independently of the sequencer; the various data paths within the cpu are selectable and controllable individually --- you may be able control the DRAM refresh mechanism on a cycle-by cycle basis, for instance, or determine programmatically whether a given datum is cached or not. Each of these physical units or datapaths would be allocated a separate bit field in the microinstruction. The machine I programmed even had the instruction timing controllable by a 2-bit field in the microinstruction. Some logic elements or data sources were faster than others, so some microinstructions could be executed in less time than others, depending on what resources they required. The basic clock ticked at 40MHz and the 2-bit field selected 5, 6, 7 or 8 ticks for the microinstruction before the next one was executed. Although we had a program to calculate how long an instruction ought to take, we some times dynamically changed the number of ticks on an instruction by instruction basis while the machine was running. Made for some interesting benchmark results... On a traditional microcoded machine, the microcode is an interpreter for the instruction set. To some extent that is still true today: simple instructions are executed directly; complex ones are interpreted. The PDP-8 was an interesting hybrid. Six of its eight instruction types were directly executed. The other two (special ALU ops and I/O) were microcode in their own right. Not interpreted by microcode, but microcode with specific bits to control the functional units directly. An oversimplification, true, but a useful one, is that machine code controls a cpu; microcode controls the components within a cpu. Far from an ideal definition, but the best I can come up with for a one-liner. Paul _________________________________________________________________________ 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 #893 ******************************