Subject: Re: CCL:Short Budget

From: "art'" <[email-masked]>
Date: Wed, 14 Mar 2001 22:22:37 +0100

Hi,

The bottleneck, usually, is the M/B bus, RAM and L2 Cache.  If to choose the best and the
most expensive CPU with highest core performance, what is the overall performance when
M/B and RAM are far behind with speed and performance ? Athlon has better choice choosing
M/B and Cache. So DDRAM, which performs two r or wr functions per clock, could serve well
increasing the total performance too.

Maybe I am wrong somethere, but let me know ;)

Good day
A.Ziemys

> I don't think DDR memory is much faster than PC133 SDRAM. You can find the comparison
> data on the homepage of www.amd.com. CPU is always the most important for
> calculations.
>
> >
> > DDR memory shoud be very quick as  r/wr functions are performed in another way from
> > SDRAM's. The 1.2 GHz Athlon is about $ 280 and mauch cheaper than PIII or P4 ....
> > and Athlons usually have higher performance about 20 %. Espetially in floating
> > point intensive calculations.
> >
>
> I agree Athlon is faster and cheaper than PIII but there isn't dual processor
> supported motherboard available now. Maybe two months later, this type of motherboard
> is available commercially. Double speed is always better than 20% faster.

---

From: Eugene Leitl <[email-masked]>
Date: Thu, 15 Mar 2001 12:05:30 +0100 (MET)

> The bottleneck, usually, is the M/B bus, RAM and L2 Cache.  If to choose the best and the

The bottleneck is specific to the problem. Some codes run entirely within
L2 (or even L1) cache, some thrash cache, so bandwith to memory becomes
relevant, some stream a lot to nonvolatile storage or across network
(where latency or bandwidth may be the bottleneck). The only meaningful
benchmark is your application.

---

From: "Phillip D. Matz" <[email-masked]>
Date: Thu, 15 Mar 2001 10:32:12 -0800

Hi Eugene,

> benchmark is your application.

Not to start a flamer here or anything, but this thread has a very specific
application in mind - Gaussian98.  All of this discussion (at least what
I've seen thus far) is all related to the hardware factors that affect G98
computation efficiency.  So your post is correct in that it doesn't say
anything that is incorrect, but at the same time give us credit for knowing
what the topic is for what we are still talking about.

Respectfully,

Phillip Matz

----- Original Message -----
From: "Eugene Leitl" <[email-masked]>
To: "art'" <[email-masked]>
Cc: "Yubo Fan" <[email-masked]>; "Familia Esguerra Neira"
<[email-masked]>; <[email-masked]>
Sent: Thursday, March 15, 2001 3:05 AM
Subject: CCL:Short Budget

> -= This is automatically added to each message by mailing script =-
> [email-masked] -- To Everybody  | [email-masked] -- To
Admins
> [email-masked] -- HELP CHEMISTRY or HELP SEARCH
> [email-masked] -- archive search    |    Gopher: gopher.ccl.net
70
> Ftp: ftp.ccl.net  |  WWW: http://www.ccl.net/chemistry/   | Jan:
[email-masked]

---

From: Yubo Fan <[email-masked]>
Date: Thu, 15 Mar 2001 20:26:14 +0000

Hi,

I really agree with Phillip. PC is a very good choice to do QM computations.
But there are still some problems when you run jobs on Linux and PC. Sometimes,
the system will jammed or respond very very slowly if you run some large DFT
jobs (> 1000 basis functions) for a long time.

Anyway, UNIX workstations can finish some jobs more efficiently than PCs.
I love PCs because it's far cheaper and the speed of running DFT calculations
is good.

Yubo

> > > increasing the total performance too.

I think CPU is the most important, memory and bus clock are second. Right?
There is a balance between them.

--
============================================================
Yubo Fan                   Email: [email-masked]
Department of Chemistry    Tel:   1-979-845-7222
Texas A&M University
College Station, TX 77843
============================================================

---

From: [email-masked]
Date: Thu, 15 Mar 2001 22:55:51 +0100

> application in mind - Gaussian98.  All of this discussion (at least what

Oh, we're still talking about Gaussian98? Sorry, I thought the thread 
sidetracked. Of course in this case the problem is not underdefined.

> what the topic is for what we are still talking about.

Athlons seem to not be able to make much use from DDR SDRAM's higher 
bandwidth, but Gaussian98 might be different in this case. It will be 
interesting to compare it with Gaussian98 benchmarks on dual-Athlong DDR 
systems (a well-known Beowulfer is currently running a few benchmarks, 
hopefully it will include Gaussian98).

---

From: "Phillip D. Matz" <[email-masked]>
Date: Thu, 15 Mar 2001 14:41:49 -0800

> bandwidth, but Gaussian98 might be different in this case. It will be

Yeah, I'm really curious how well G98 takes advantage of the extra bandwidth
of DDR SDRAM.  My own tests regarding the Athlon with PC100 and PC133 (CAS2
and 3) indicated that G98 was indifferent to the CAS latency but really
benefited by the increase in effective bandwidth in going from PC100 to
PC133 (ie by changing the memory FSB asynchronously with the KT133 chipset).

> systems (a well-known Beowulfer is currently running a few benchmarks,
I doubt Dr. Brown will be benchmarking G98 on the dual-athlon rig but it
would be nice (I don't think he has a license but I may be wrong here).  Of
course I should be asking him rather than lamenting about it here on the CCL
I suppose.  At any rate it would be nice to have some numbers on a P4 system
with the dual-channel rambus just to see if the extra bandwidth really
boosts the effective IPC for G98 code (although I doubt it will lower the
price/performance enough to justify the cost) simply as a matter of
curiosity.

----- Original Message -----
From: <[email-masked]>
To: "Phillip D. Matz" <[email-masked]>
Cc: "art'" <[email-masked]>; "Yubo Fan"
<[email-masked]>; "Familia Esguerra Neira"
<[email-masked]>; <[email-masked]>
Sent: Thursday, March 15, 2001 1:55 PM
Subject: Re: CCL:Short Budget