George wrote:
One correction to my previous post. I said that the latency to
access the L1 data cache was 2 clocks. This is correct for integer
instructions only. For floating point and SSE2 instructions the latency
is 6 clocks! Interestingly, the L2 cache latency is 7 clocks for
For those interested, I have a machine capable of running the simulator if
you need something tested or measured. Contact me by personal email.
-Original Message-
From: Henk Stokhorst [SMTP:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 1:22 PM
To: [EMAIL PROTECTED]
Subject:
Hello, all.
I'm curious if anyone has any preliminary performance figures for Athlon
processors on the new crop of DDR MBs. If noone has any data, I guess I'll
have to go out and buy one. :)
Cheers,
David
_
Unsubscribe
All benchmarks say is that "It's good for *this* application". I've heard
that it speeds up mersenne calculations on some MBs. Now, that's nice, but
if it doesn't speed it up enough vs its cost. That's the question.
I'm just going to hold my breath for DDR-SDRAM. Cheaper, faster, better
I only DC with my Alphas--heck, I only have *two* machines (out of 8) doing
first time LL. :) Don't get me wrong, I'd like to find a new mersenne
prime, but I feel the DCs are underrated in importance. And since this
project is 'vote with your CPU', I am. :)
Thanks for the suggestion. Ernst
If we only had some great P-1 code for the Alpha... Ernst? :)
-Original Message-
From: Stefan Struiker [SMTP:[EMAIL PROTECTED]]
Sent: Friday, June 09, 2000 1:43 PM
To: Willmore, David (VS Central)
Cc: 'Nathan Russell'; [EMAIL PROTECTED]
Subject: Re: Mersenne: What's
Yeah, the manual pages are apparently offline. Will they be back online
soon? I have a machine about to 'go dry' (500MHZ Alpha EV6).
Help.
-Original Message-
From: Barry Stokes [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, June 06, 2000 4:03 PM
To: [EMAIL PROTECTED]
Subject:
Brian J. Beesley wrote:
A more general more secure method of preventing the type of problem
exposed by this incident would be to have the server enforce a quota
for the maximum number of assignments issued to any user/computer id
combo in a particular time interval e.g. 20 per
From: Willmore, David [mailto:[EMAIL PROTECTED]]
value of 90 days. For some reason, I'm not allowed to get more than
about
a
month of factoring work. It's starting to cut into my efficiency. Is
there
a way around this?
Paul Leyland wrote:
Try joining the people
There's previously been several posts discussing the performance penalty
one suffers when running multiple LL tests on a multiprocessor system
with a single shared system bus. It would be interesting to see whether
this
penalty could be alleviated in a reasonably cost-effective fashion
And dont the K6-III and Athlon support an L3 design, using slower memory
of
course, but dedicated to each CPU so eliminating bus contention? Of
course,
the K6-III doesn't do SMP, but the Athlon supports it, doesn't it? Are
there any SMP motherboards out there yet for the Athlon?
The
No, no, no, you guys have it all wrong, you take a pencil and a big sheet of
paper and write:
(brute force spoiler)
power 1 3-1 -2
9-3-6
-3 1 2
-6 2 4
power2 9 -6 -11 4 4
Is it 584, and if so, what's so intuitive? :)
-Original Message-
From: Steinar H. Gunderson [SMTP:[EMAIL PROTECTED]]
Sent: Saturday, November 20, 1999 6:32 AM
To: [EMAIL PROTECTED]
Subject: Mersenne: Re: Quiet list?
On Fri, Nov 19, 1999 at 08:27:12PM -0800, Spike Jones
One more idea--virus scanners.
_
Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
On Mon, Sep 20, 1999 at 05:45:17PM -0500, Willmore, David wrote:
Since it's a cache reading problem there's no real way to 'flush' it.
Normally, that means to write back dirty data to whatever backing store
exists, not 'invalidate everything'. Even if you did, it would't solve
the
problem
Random chance. I wouldn't count on it.
-Original Message-
From: Steinar H. Gunderson [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, September 21, 1999 4:12 PM
To: [EMAIL PROTECTED]
Subject: Mersenne: Re: Re: Timing(?) errors
On Tue, Sep 21, 1999 at 02:03:54PM -0500, Willmore
From: Brian J. Beesley [SMTP:[EMAIL PROTECTED]]
This is _still_ remarkable, since the "consumer" Athlons starting to
trickle onto the market have 64-bit 100 MHz FSB and 512KB L2 cache,
like PII / PIII / Xeon, but run their L2 cache at only 1/3 clock
speed (c.f. full clock speed for Xeon
IA64 is really VLIW (very long instruction word), which is quite different
than traditional sequential RISC. It requires the compiler to do a LOT of
massively parallel pipeline scheduling to achieve optimal results. HP has
a
leg up on this compiler technology as IA64 is based on their
From: Simon Burge [SMTP:[EMAIL PROTECTED]]
From what I understand of Merced, compiler technology is going to be the
problem. It's probably not unreasonable to expect large performance
increases as the intelligence of compilers (especially the "free"
compilers like gcc and egcs) catches up
We ran the DC for M38 on a DS20/500. Using Ernst's code we were getting .18
s/i, but I don't remember the FFT size. I want to say 384K? Ernst?
Cheers,
David
_
Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
All,
There are several things in a computer which will have their operational
parameters vary with CPU activity. The most likely ones are: audio
subsystem receiving noise coupled either directly (magnetically) into its
signal lines or via its power feed; or the load on the power regulation unit
For a few years. Most PII class MBs have them and some late Socket7 ones
do, too. They're not standard as far as how they interface both at the
hardware and software levels. You need MB specific drivers. Linux has a
project called lm_sensors (named after one of the early chips used to
perform
1) see my other email. Yes, they did.
2) Yes, it was Compaq. Intel bought foundry technology that is used on the
StrongARM as well as the StrongARM archetecture itself.
Cheers,
David
--
From: Joth Tupper[SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, June 09, 1999 1:13
23 matches
Mail list logo
