Slashdot Mirror
AMD Athlon Multi-Processor Under Linux
An Anonymous Coward writes: "Just saw this review at GamePC. It's a pretty extensive review of AMD's entry into the multiprocessor arena, full of exciting benchmarking results. The
full text is here."
← Back to Stories (view on slashdot.org)
Actually, your comparison is utterly ridiculous, unless you were compiling an x86 kernel on your Mac with a cross-compiler.
Different GCC back ends (and the different default compiler options for the PPC kernel build vs the x86 one) make your numbers 100% useless for any kind of comparison.
When Q3 was released the P4 wasn't even available.
Well, I've got some happy news for you, twice sound sources giving of the same amount of noise very close to each other do not double the amount of sound, it only gives you 3dBa increase.
Anyway, palomino is supposed to produce less heat than older athlons, so here goes another happy surprise, you can get little less noisy fans!
On the kernel compilation tests he says "we can definitely see where AMD's superior FPU and number crunching come into play". This doesn't make sense to me. GCC is probably not doing any FP calculations at all while compiling the kernel!!! GCC is a well known, hard to optimize *integer* workload, not floating point (FPU and the usual instruction type for number crunching)
FYI, NetBSD boots and runs on dual-CPU Athlons. You just have to build your system via the (expirimental) nathanw_sa CVS branch. Here's a dmesg posted to the NetBSD tech-smp mailing list:
0 000.html
http://mail-index.netbsd.org/tech-smp/2001/06/05/
AMD have had MP technology in their processors for a long, long time, including the K6. It's just no-one built motherboards for it. The Athlon series has been the first time they'rve had the strength to do their own motherboards, too.
the K6 family never supported the OpenPIC standard. The K5 family DID, however (granted no chipsets were ever developed for OpenPIC). It is widely assumed that the K6 also had OpenPIC built-in, but that is untrue. They did not support any type of SMP operation, even "in theory."
As for scientific applications, you need load balancing regardless of whether the processors running the threads are in one box or in several. This is usually handled transparently by the OS, the compliler, the communications library, or a combination of the above (usually all of the above).
In my experience with high precision RF simulations on massive SGI multiprocessor machines, the OS (IRIX), the compiler (MipsPRO), and the communications package (OpenMP) do very little for you automatically. In order to achieve decent scalability you need to take your computing needs into consideration when you develop the architecture behind your simulation. If you, as the developer, don't distribute your calculations as evenly as possible, your simulation is going to run very, very poorly. It will become more noticible how poorly your simulation runs as you throw more processors at the problem.
If you are dealing with simulations requiring high levels of internal messaging, you definitely gain from a multiprocessor machine. Bus throughput is much higher than network throughput, especially because data must be specially packaged before it is sent across the network. Again, you must design your simulation architecture specifically for this application. Frequently used data should be close to the process that needs it. If the data resides on only one processor (or machine in a cluster, as the case may be), you will deal with a high cost in accessing that data from any processor or machine to which the data is not local.
If you are dealing with a simulation that has high internal messaging and relatively little computational work, you are actually better off using fewer processors/machines. Of course the optimal amount depends on the application, so your milage may vary. And, of course, none of this means squat if you don't plan for spreading the work and localizing messaging and hope everything will be taken care of automatically.
something clever
You're the 3rd post after the FreeBSD post, I think you're losing your touch. I remember the days when the the *BSD is dieing trolls were all appearing instantly in relation to any BSD post. Things just arne't what they used to be. For all intents and purposes the *BSD Troll is dead.
One processor could be running civclient while the other is running civserver. :-)
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
You are absolutely correct about how the MySQL "benchmarks" work. MySQL's crufty benchmarks are a Perl script that simulates one user doing a whole lot of goofy things like dropping tables and dropping and creating connections. Quite frankly I can't think of a single benchmark that would be less useful for benchmarking a SMP system. I was actually surprised when the folks making up the benchmarks didn't simply add up the respective bogomips scores from each processor and call it a day.
I generally don't criticize benchmarking tests like these because I don't consider myself knowledgeable enough, but even I know that running one instance of the MySQL benchmark is not a good SMP test.
The ppc backend is more computationally expensive than the x86 backend, in my experience. gcc runs fast on athlons because the x86 codegen doesn't take as much time as ppc codegen. (I'm 90% sure about this, since I didn't check it carefully or anything, and it was a while ago. I used gcc 2.94 when I tried a bit of stuff.)
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
If you used Compaq/Digital's optimizing C compiler, you obviously found that the compile took a long time, because the compiler spends a long time scheduling the instructions for the Alpha's pipeline and exact insn execution capability. I read somewhere that the compiler actually simulates an Alpha running the code to see what it can do to make faster code. No wonder it takes a long time, and no wonder the code it generates is so good.
Compilation speed is nice, esp. when developing software, but you can usually get that by turning optimization off. When you're compiling something that will eventually use more CPU cycles than it took to compile, it's ok if the compile takes a long time, as long as the compiler does something useful with that time!
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
Since Athlons use the Alpha bus, does the recent purchase of the Alpha line of processors by Intel affect AMD at all? (ie. Intel now owns the Athlon core)
Just wondering if anyone knew.
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
this sig limit is too small to put anything good h
Clock speeds on two different processors mean
different things, so I would say yes it's fair
since what they're comparing is top end
vs. top end, not efficiency per MHz.
Mac users used to play this silly game all the
time: PPC is faster per MHz! Yeah sure, but
if you can't buy them at the same higher
speeds as Intel CPUs then it doesn't really
matter. In fact, that efficiency may be why
they can't manufacture faster clocked processors.
-Kevin
I agree that the limitation with MySQL is probably with I/O, but to answer your query, MySQL is multithreaded, but I've had to really pound on it in order to need more than one CPU on a four headed Sun box.
-"Zow"
if you think that buying a dual whatever board is going to be more cost effective than a Abit BP6 with a couple of cheap celerons, you are nuts.
At least that is my opinion.
In my experience with high precision RF simulations on massive SGI multiprocessor machines, the OS (IRIX), the compiler (MipsPRO), and the communications package (OpenMP) do very little for you automatically. In order to achieve decent scalability you need to take your computing needs into consideration when you develop the architecture behind your simulation. If you, as the developer, don't distribute your calculations as evenly as possible, your simulation is going to run very, very poorly.
What the original poster was referring to, if I understand correctly, was distribution of processes or (in his case) web page requests across hardware nodes. This is handled by the OS and/or libraries in the setups that I've seen (admittedly few).
I definitely agree that the task has to be properly parallelized in the first place, but that wasn't what I was responding to.
Regarding the internal bus in a SMP system being faster than the communications network in a cluster, that's what I'd thought too. Then my prof got me to run subsets of the SKaMPI and NPB 2.3 benchmark suites on our cluster (MPI libraries on top of SCore running on a bunch of dual-processor Linux boxes). Running on 2nx1 nodes was faster than running on nx2 nodes for almost all of the tests. Caveat: this was for small n, and I can't guarantee that it wasn't just due to lousy process distribution or lousy SMP communication routines in the libraries.
YMMV.
For anything with a high communications load, SMP almost certainly wins, but for moderate communications loads, my experiences have made me leery of it.
Has anyone done a cost-efficiency comparison of dual-cpu performance vs. a simple cpu when considering the costs involved (special SMP boards, etc.) In otherwords is it more economical to buy two web servers or one smp server with tons of ram? Do certain applications (cpu intensive obviously) save money with SMP systems verus others that depend on IO throughput, etc and what applications are those?
Any task that is easily parallelized and has low internal communications requirements would run more effectively on multiple servers than on one SMP behemoth. Web serving has zero internal communications requirement, and so falls into this category. Things like ray-tracing have low communications requirements when partitioned properly, which is why you use clusters as render farms instead of massively parallel Big Iron.
SMP has overhead from coherence operations, and more complex and expensive chipsets.
SMP benefits tasks that lend themselves to shared-memory implementations. It's a lot easier to toss ownership of memory pages back and forth inside an SMP machine than it would be to send modified pages back and forth across a network. I don't have examples of this kind of task offhand, but I'm sure they exist.
All of this is for CPU-bound tasks. For I/O bound tasks, you're still better off splitting it up into multiple machines if it's easily parallelized, but again I don't have good examples to illustrate with off the top of my head.
For more information, pick up a couple of good books on parallel computer architecture and parallel programming. Your local university's bookstore will stock these.
Any task that is easily parallelized and has low internal communications requirements would run more effectively on multiple servers than on one SMP behemoth.
:). In the second case, you're looking at one of a handful of disk nodes within a much larger system (in all likelihood). For non-disk nodes, you wouldn't need PCI-64. For clusters that distributed disks over many nodes, your I/O bandwidth needs would be adequately served by PCI-32, and PCI-64 again becomes unnecessary.
:). You've made me think about the problem in more detail.
I have several problems with this generalization. First, parallelizing over multiple servers always adds overhead (in both $$$ and performance) of its own. How are you going to spread a load over multiple web servers? You need a load balancer, either the dedicated (pricey) hardware kind or a standard server converted over to load balancing service (which doesn't get you the greatest speed or scalability in the world). Even in a scientific application that you spread over several boxes, you need some kind of load balancer or traffic cop to get an equitable distribution of work.
You make a valid point, in that load-balancing is an issue. However, I'm assuming that in the case of a web server, if you have enough traffic to need more than one server, you have enough money to buy a hardware load-balancer to spread out requests (and a hardware firewall, if management has any sense).
As for scientific applications, you need load balancing regardless of whether the processors running the threads are in one box or in several. This is usually handled transparently by the OS, the compliler, the communications library, or a combination of the above (usually all of the above). This is standard for any high-performance computing project, and so doesn't add to your maintenance overhead. It also doesn't contribute substantially to the processor workload, so I don't see it as much of a concern for scientific workloads.
Second, let's not forget that two-way (and even four-way, if you were in the Xeon market to begin with) boxes have gotten much cheaper in the past year or two. Most of the important server availability features, like hot swap drives, hot swap power supplies, ECC RAM, 64 bit PCI, etc., are almost impossible to find on 1-way systems these days.
The last time I checked, n-way systems for n > 2 were still far more expensive than n one-way systems, but I haven't checked within the past couple of months. This might have changed, but I doubt it.
N = 2 was marginal, if I remember correctly.
ECC RAM support is available on several single-CPU motherboards; check your favourite vendor's site for a list of options (admittedly pricier than most of the boards, but not horribly so).
I'm assuming that hot swap power supplies aren't relevant. Your load-balancing hardware or (for a cluster) software will be able to detect malfunctioning nodes; this is essential for any cluster of significant size. A supply failing would be no different from any other component failing from a maintenance point of view (bad node is cut out of the loop by the load balancer, the hardware person gets paged, the node is swapped out and the old node serviced or gutted for parts).
PCI-64 support is a good point. If you have to support PCI-64, then it probably makes sense to build your cluster out of dual-CPU nodes, because the incremental cost of getting a dual-CPU motherboard will be low. Quad-CPU and higher will probably be less economical (quad cost diamonds the last time I checked). You'd only need PCI-64, though, if you either had a very large communications requirement (multiple very fast network cards per node), or if you were mounting a large RAID on the node (many controllers, many strings). In the first case, I can weasel out by claiming that you're outside of my stated problem domain (low communications bandwidth)
It's nice to get an interesting response, though
Yup! it actually is quite good.
2 PIII 866 processors - $129.00 ea
1 ASUS mobo to support above - $129.00
result? Un-fricking-believeable.....
Really, The motherboard in it's self is massively faster than the regular ASUS mobo. Dont know why but I get a major speed difference that I can actually feel.
Now activate the 2nd processor... Woah!
Frames render almost 2 times faster with povray and BMRT is even faster.
And this is with el-cheapo 866 processors. The mobo says it will handle 1.2Ghz.
I havent had this much of a speed-up cince I went from 486 to pentium.. it's about time htat feeling of "WOW" came back to computing.
Now, if you are a regular user, it's probably a waste... but the fact that I can actually preview my video clips within 2 hours is awesome! (Now if someone would only port poser to linux I'd be really happy!)
Do not look at laser with remaining good eye.
It's been less than two years since the Athlon has been released. How impatient are you?
I have two Athlon heaters in mine, which is very unpleasant in July. Trade ya?
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Or am I the only one still old enough to remember that?
damn, slashdot readership must be young. even my 12 year old brother knows that.
anyone want to mirror the article? My employer's proxy has blocked the site because of the word "game" in the URL. Yes, they are that lame.
> There were a few AMD CPUs that *should* have been recalled.
IIRC the original runs of the K6, or maybe the K6-2, had a bad problem, and though there wasn't a recall, they would give you an exchange for it if you asked.
There may have been others, though I don't recall hearing about them. Intel, on the other hand...
> You'd better stick to the price argument.
Not at all, though the price would be argument enough by itself.
--
Sheesh, evil *and* a jerk. -- Jade
> As much as the Athlon people tout their shit as superior, and it took them HOW long to do SMP ?
What's the ratio of AMD processor recalls : Intel processor recalls ?
--
Sheesh, evil *and* a jerk. -- Jade
How the fuck is that flamebait?
I write a blog now, you should be afraid.
Highlights of the dmesg for those who like that sort of thing:
Whohoo!
Dave
I write a blog now, you should be afraid.
I have several problems with this generalization. First, parallelizing over multiple servers always adds overhead (in both $$$ and performance) of its own. How are you going to spread a load over multiple web servers? You need a load balancer, either the dedicated (pricey) hardware kind or a standard server converted over to load balancing service (which doesn't get you the greatest speed or scalability in the world). Even in a scientific application that you spread over several boxes, you need some kind of load balancer or traffic cop to get an equitable distribution of work.
Second, let's not forget that two-way (and even four-way, if you were in the Xeon market to begin with) boxes have gotten much cheaper in the past year or two. Most of the important server availability features, like hot swap drives, hot swap power supplies, ECC RAM, 64 bit PCI, etc., are almost impossible to find on 1-way systems these days.
Finally, there's a huge difference between up-front cost and maintenance costs, with the maintenance usually being more expensive. If you double the amount of rack space you need, double the amount of power you need, and put in the effort to keep both systems perfectly in sync, you'll quickly find that you've blown away that little savings you got at the cash register.
But, on the other hand, I agree with that this business of benchmarking web servers with like 8 and 12 CPUs (where things really get into a different pricing league) is a bit silly.
yes, I know that there are very significnt variations which make this an unscientific number.
... so I expect my build shouldn't be unusually fast.
However, the kernel I built was a fairly well-provisioned one with plenty of drivers (USB, networking), filesystems,
My experience is that the other stuff one builds often has a relatively minor effect on the total time, so the number is probably not a crazy comparison.
Not knowing these benchmarks were available, I just spent today compiling 2.4.6-smp for my Dual 500 MHz G4 PowerMac. My complete kernel rebuild time, using 4 jobs, was 3min,10sec, putting it ahead of the Dual-PIII/1GHz but behind the Dual Athlon/1.2GHz. I was very pleased with this speed.
It seems pretty strange to me that the reviewer decided to run their benchmarks on a 2.4.2 kernel. AFAIK there's been quite a few patches going into the kernel since dual Athlon hardware actually became avaliable to improve stability/performance. Surely a more recent kernel would've been a better choice?
Ah. Thanks. That kind of explains the lack of improvement in the benchmark then for dual CPUs. All it means is that the perl script ran on one CPU and MySQL on the other.
Fear: When you see B8 00 4C CD 21 and know what it means
Quote about freezes: "which could have been caused by either 1) nVidia driver problem (which still has a few known SMP bugs still in the latest version) or 2) the AMD 760MP chipset."
Or a whole slew of other things like cooling, SMP problems in the IDE driver for the 760, plain bad luck that you got the 760MP both times etc. etc. Without actually nailing this down as to what specifically causes the problem you can only make VERY vague guesses about what the problem is.
Quote from compiling the kernel: "Here, we can definitely see where AMD's superior FPU and number crunching power come into play."
When did gcc actually use ANY floating point code. Does this guy actually understand what he's benchmarking? All sorts of effects can slow down a compile, from memory bandwidth to I/O bandwidth as well as CPU speed. It was nice to see the Athlon beat the P4, but what CPU was gcc optimised for when IT was compiled (just curious)?
Quote from MySQL bench: "A real surprise occurred when the single processors faced off. The Athlon not only soundly beat the P3, but actually also managed to beat the dual Athlon by a little over a minute. This does seem a bit odd because going from a single P3 system to a dual P3 system decreased the time buy a good 10 minues. This could be another example of the maturity of Intel's SMP solution versus AMD's."
It is more likely that the issue is somewhere in the I/O bandwidth chain. SQL tests tend to stress I/O bandwidth more than anything else - I'd be looking at the drivers before claiming that there are issues with the 760MP. Is MySQL multithreaded anyway so it can take advantage of dual CPUs? Most of the tests seem to show that only the OS is getting any advantage from the dual CPUs.
Quote from Blender: "It is surprising to note, however, that the Athlon, despite running 500 MHz slower than the P4, still managed to render blacksmith.blend at least a tenth of a second faster."
No, it's not surprising. Even Intel says that x86 floating point code is slow on the P4. If Blender was rewritten to use SSE-2 instructions rather than x86 FPU instructions then I'd almost guarantee a 50% improvement in P4 scores. I'm not defending the P4 here - just saying that the P4 giving cruddy results is not surprising.
Kudos to the author for the journalistic integrity to correct his error about NT and SMP. Anyone can be wrong - few journalists ever admit it.
Anyway - those are my thoughts. Debate them as you will.
Fear: When you see B8 00 4C CD 21 and know what it means
Every so often a process dies horribly, and camps on one of your processors chewing up cycles like there's no tomorrow. Depending on what sort of development you do this may be a rare experience or a common one. And on a single processor machine, sorting it out can be painful, because everything is responding like thick treacle.
On a dual processor machine, everything still works just fine, and you go in, identify the messed up process, and kill it.
When I'm working I normally have
all going at the same time. My twin processor PII/300 definitely feels a lot more responsive under this sort of load than the Athlon 500 on the next desk. Mind you, the Athlon box was a lot cheaper!
I'm old enough to remember when discussions on Slashdot were well informed.
You need a load balancer, either the dedicated (pricey) hardware kind or a standard server converted over to load balancing service (which doesn't get you the greatest speed or scalability in the world).
No you don't, you need BIND (which is free) and multiple A records (which require a clueful network admin, but are otherwise free). We get within 0.2% of perfect load balance with this method on our server farm.
Cisco LocalDirector is for people with two-tier Windows NT setups who don't know any better.
from the reviews i've seen so far, battery life isn't that swuperior to x86 machines....
given a reasonable amount of RAM, i find 'make -jN' fastest, where 'N' = number of CPUs +1
is it right to compare several systems of *COMLETELY* differing speeds???
perhaps a single/pair of 1.4GHz athlons against a single/pair of 1.4GHz intel chips maybe with a few thousand dollars' worth of xeon thrown in for a reasonable high-end comparason?
what use is a SMP box for gaming when there are no SMP games? i know, i know, Quake3Arena runs SMP, but only under WinNT/2K, iirc.
am i off the mark? are there any games that can/will take advantage of SMP linux?
So what you're saying is that no one should buy a P4? I say I must agree. The brilliance of the Athlon arch is that it runs legacy compiled code faster than Intel processors. To get the architectural speed improvements of the P4, you have to recompile your source code. Are you going to recompile every bit of software you run? So the conclusion is that no one should buy a P4 unless they have an entire distribution compiled for it. The Q3 tests came out smelling like a rose on the P4 because they have a lot of SSE code in them so they will run well on P3s, and at 1.7GHz, there is no way the P4 would get beat by the Athlon running their own instructions at 500MHz faster clock rate.
"Since all of the hardware and software, save the motherboards and processors, were the same on each of our systems, it should be safe to conclude that the differences in performance are primarily CPU related."
Well, I saw two different harddrives on the list, one was 15000 RPM and the other was 10000 RPM, that could have an effect on performance.
MySQL spawns another child process for each connection to the database. If you use one mysql_connect() in your code, then you'll be communicating with only one mysqld.
--
--
E2 IN2 IE?
1. The BH6 was a uniprocessor motherboard, and I oughtta know, since I had one and used for Celeron overclocking until it died a few weeks ago. The CPU (Cel. 366A) lives on in a different BX board. The BP6 was the Abit board that could do dual PPGA Celerons, but it can't handle more than one FC-PGA processor of any kind.
2. There was never a PII 600. PII's maxed out at 450, then Intel moved over to the Katmai P3's, which were PII's in every respect, discounting the SSE extensions. Katmai effectively ran up to 550, although there were a handful of 600's, which were really just overclocked 550's that Intel shoved out the door as a preemptive strike against the Athlon. AMD countered with a 650 at launch time, and thus began The Chip Wars...
Don't get me wrong -- I have a dual P3-800 system and I love it. It's good at the kind of stuff that I like to do at my workstation. Beside it, I have a 1GHz Athlon, which is good in its own right for playing games (and running that icky Win98), and beside that is the old Celeron I mentioned, to serve them both with files, DNS, and all that other crap.
--
--
E2 IN2 IE?
make your numbers 100% useless for any kind of comparison
Well, it does tell us how long it takes him to build a "standard" kernal on a PPC machine vs. on an Intel machine. So it's a TINY bit useful (most benchmarks are 97% useless, while this is 99%).
Especially with software that you have source for (and that has a gazillion compilation options) almost ALL benchmarks have very little relation to the real world use of a machine. It is entirely likely that with just a compile or config option or two you could DOUBLE (or more) the speed of an app like MySQL or GCC. And these options usually have different results for different platforms / processors / configurations / test scripts, so you have to decide if you want to use the same set of options for both (more "scientific"), or use whichever works best on each setup (more "real world").
and what applications are those? I'm really interested in knowing with better evidence than "well, I think..."
Unfortunately, "I think" you'll just get vague estimates because your question is not sufficiently specific to provide the kind of answer that you demand.
That is, exactly what application will you run and under exactly what kinds of circumstances?
The hardware performance depends on so many variables (CPU speed, cache hits, main memory size, main memory BW and main memory latency, network card, disk controller, disks) that different applications will be limited by different parts of the hardware.
Worse, the same application could be limited by different parts of the hardware depending on the tasks demanded of it.
As a friend of mine used to say to difficult questions like this
"Provided by the management for your protection."
Yawn. I've got *plenty* of Karma to burn.
Got Rhinos?
I agree! It actually was pretty funny. Mod it up!
Got Rhinos?
Okay, mod me up as "insightful."
Got Rhinos?
- CPU load balancing: If you're using many servers instead of
one, you need to make sure that your load is spread evenly across the
systems. For some applications, load imbalance can significantly
reduce efficiency. An SMP can dynamically balance between many tasks,
efficiently utilizing the processors.
- Sharing other resources: SMPs allow the jobs to dynamically share
other (non-processor) resources such as RAM, swap, disk I/O bandwidth, etc.
For example, a web server can share a large file cache between all the
server processes, making efficient use of the DRAM.
One of my favorite uses of smaller SMPs is parallel compilation via make -j. You can launch 2n jobs on n processors and get good speedup. This does not work as well on a cluster setup. You can do it, it is just a bit of a pain.Of course this all depends on the cost premium of an SMP over uniprocessors. This is more of the market effect of economies of scalar rather than a fundamental issue with SMPs. If everyone bought SMPs, they would have at worst a small cost premium. SMPs could even be _cheaper_ (per processor) since you can share the DRAM, case, power supply, keyboard, video card, and maybe even monitor (unless you run headless servers).
http://www.amdmb.com/lkc/
Test Results in Minutes
Abit VP6 dual CPU Pentium III 1GHz machine.
J2 5.55
J3 7.15
J4 7.2667
J5 7.45
J6 7.45
Asus A7V single CPU Athlon 750MHz
J1 10.26
J2 10.93
J3 13.61
J4 13.71
J5 14.3
J6 13.88
I don't know about anyone else, but I'm planning to hold off on buying new hardware til the Athlon 4 desktop version hits the market. How many of these new Athlon-MP mobo's are gonna be compatible with it? I've seen way too often a new CPU will come out and nothing will support it for a month after that.
I am !amused.
i posted the following to comp.os.linux.hardware a few weeks back. the numbers are lower, reasons being: beta tyan board, mem speed is only 119mhz for some reason(not 133), producing 1071 mhz cpu speed. the demo for q3, which is older than that used in this test.
enjoy the following hardware is identical under both conditions. visiontek geforce3 the quake3 free demo was used. for your enlightenment, i will post my Quake3 demo benchmarks under linux on the following boards. the first is the Tyan S5250, an 840 board, with dual p3-1ghz, and 1gig rambus ram. 2.4.5 kernel, XFree86-4.1.0, nvidia binary drivers 1.0-1251. agpgart was not used, as it was slower than nvidia's nvagp support using agp4x, probably because the 840 isn't that well supported under agpgart. using hi-quality settings under q3 and doing demo001, i got 119fps. on a Tyan S2462, a 760mp dual athlon board with dual 1066mhz chips(are 1.33ghz chips, but posted at 1066 for some reason), with 256 meg ddr sdram running at 266. same 2.4.5 kernel, XFree86-4.1.0, nvidia binary drivers 1.2-1251. once again agpgart was not used, as it complained that it was an unsupported chipset. doing agp_try_unsupported=1(or whatever it was, can't remember, but it was the right thing), didn't work either. using nvagp listed it as generic amd chip with support for agp4x. i edited the nv-registry.c(or whiver one it was) to include sba support, which only took on this chipset. using hi-quality settings and doing demo001, i got 133 fps. both these seemed low to me. possible reasons are poor support in nvagp for 840 (a server chipset, not exactly a gaming platform) and the 760mp, which is really new. also, the older version of q3 which is in the demo probably doesn't have as good support for dual cpu's. also, agpgart has no support for the 760mp, so i couldn't even test it. nevertheless, the clear winner is the 760mp system. it was only 6% faster in cpu speed, less ram, slower memory, and it is 12% faster in q3. not too shabby.
--
Patrick Paul
Microway.com
patrick@no_microway_spam.com
Do you see the sig? Do you have it in your sights? Why yes, Miss Moneypenny...
The main point of Crusoe is that it isn't a hardware only solution and is nothing you can bash it for.
SSE is for floating point numbercrunching. Neither a compiler or a database uses floating point mainly, but it did well in the Q3 bench which is both floating point and SSE optimized.
Yeah 4 way was definately around back in the ppro day. But i still haven't seen that dual p4 machine make it's appearance yet either.
I've seen benchmarks of the T-bird chips done in the tyan board with the 760mp. As far as I've ever read they are pin compatible. I think this is a case of "it will work but we don't support it". There are also some huge benifits of the MP chips vs the t-bird chips when it comes to multiprocessing because of the cache improvements in the MP chips.
"You can now flame me, I am full of love,"
Err, now. That is if you count Beowulf cluster in a rack, 64 way a simp at $70720
Medway Dual Athlon Cluster
I would love to see some stats that are more realistic of a server envirnment. I don't know about mySql, but I know postgres spawns more than one thread for addition queries when needed. Looks to me from the numbers that mySql is only doing one thing at a time for the bechmark.
I know my dual PIII 700 kicks ass when two big queries are going on at once, as long as they are indexed well. I have a hard time believing a single processor would still beat the dual in any useful DB test. (How many DB's really only perform one query at a time?) Two mySql benhmarks run at the same time, and then 4, would be much more interesting to me.
Correct me if I'm wrong about how the mySql benchmark works.
-Pete
Soccer Goal Plans
The reason the kernel compile didn't gain from > 2 CPUs is that the disk become a bottleneck. The proper way to compile a kernel on a multicpu machine:
1) change the makefile to run gcc with '-pipe'. Read the man page to see why.
2) set MAKE=make -jN, where n=num of CPUs
3) either put the source in a ramdisk or run it on a fast striped raid system.
4) run make -jN (yes, both the environ and the arg)
TaDa! Much faster!
I'll explain :
Imagine that you go for the cheaper ones at half the speed of the fastest one. Your performance will be 25%-40% slower than the fastest single cpu box, and still more expensive because you had to pay extra for the motherboard.
Strangely enough, this is true for intel CPUs and not for AMD CPUs. AMDs slower CPUs are far more cheaper and may turn more profitable.
But for Intel, the only CPU with which your SMP can compete is a not yet existing one (because availability wins from price) which would theoritically be 1.7 times faster than your cpu speed on your smp.
It's strange but it's true.
Buy AMD.
So... it's more convenient IMO to have dual/quadruple system than N single-CPU system.
Most important, though, is what everyone and their donkey has said; it all depends on what you plan to do with your system.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
Crusoe was meant for people like me who consider getting basic work done adequately a higher priority than blowing the doors off the guy down the street or rendering so sharp you can see Lara Croft's pantyline and erect nipples.
It's a good chip for what it does (and I had this idea the other day that I'd love to see it do a PDP-11 just so I could run the copy of Unix V6 I downloaded a year or so ago). But it just doesn't fit into this company.
/Brian
As much as the Athlon people tout their shit as superior, and it took them HOW long to do SMP ?
Just because SMP hasn't been a business priority for AMD doesn't meen that they didn't have the technical competance to do so years ago, nor does it have any relevance to the quality of their chips.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Because TransMeta doesn't make processors to compete on speed, rather battery life and portability.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
As others here mentioned, the choice between SMP and multiple boxes depends a lot on your current bottlenecks and the amount of communication between tasks.
For instance, if your web server is memory speed or I/O bound, and updates are managed by a central authority (like an SQL server), go for a pair of servers. That doubles your system bus and disk subsystem capacity over a single SMP system.
On the other hand, if your server is CPU bound and/or requires fast communication between tasks (like updates to on-disk data), go for the SMP. Sure, the board is more expensive, but you only need one (same goes for drives, cases, network cards, etc).
Web servers generally fall into the I/O bound category, so two servers is probably your better bet unless you handle quite a bit of dynamic content.
~LoudMusic
No sig for you. YOU GET NO SIG!
Uninnovate - Only the finest in engineering.
-- .sig are belong to us!
All your
A feeling of having made the same mistake before: Deja Foobar
The Athlon MP is actually the same core (palamino) as the upcoming Athlon 4, the only difference is that the athlon MP has been 'certified' by AMD to run in SMP configurations. There is no change in the socket or connections, all AMD socket A processors are compatible with the AMD 760(MP) based boards and will be compatible with the Athlon 4.
WikiAfterDark.com It's a sex wiki, go now!
As much as the Athlon people tout their shit as superior, and it took them HOW long to do SMP ?
Well, don't forget that before the Athlon less than two years ago, AMD was always playing catch-up with Intel; Intel was always the performance leader. Now that AMD has arguably grabbed the performance crown, it makes sense for them to put in the support for SMP.
--
Convictions are more dangerous enemies of truth than lies.
Convictions are more dangerous enemies of truth than lies.
- Nietzsche
Go buy a Silverado and improve your Quality-of-Sleep.
-- Cure for Cancer instead of SETI! (only w32 yet - mail and beg)
AARRG.. Two noisy athlon coolers in my bedroom (or just room, actually), damn them for making such relative cheap speedy-musthave(though noisy)-stuff..
I think maybe my current fan is getting to my head, better go to bed.. But only to look forward to total insomnia iguess..
thanks dude
In the early SMP Unix days (mid 1980s) when parallel make became available, a single CPU would benefit from parallel compiles. The single CPU was usually 60% idle during a single compile. The rest of the time was spent waiting for disk. Thus, I was surprised that the single CPUs didn't gain from multiple processes, and duals didn't gain from more than two. This benchmark is clearly CPU bound, not disk bound. In particular, faster disks won't change anything. It may be that slower disks won't change anything either.
That could be because of:
gcc -pipe
RAM disk
read ahead/write behind in the filesystem
massive kernel buffering, and taking the second test time.
It seems likely that "make -jN" is what was used to achive multiple processes. It seems unlikely that a RAM disk was used.
-- Stephen.
I am curious why TransMeta is absent from the review and is often excluded from benchmarking tests. While Linus may be all that is in common between TransMeta and Linux, it seems TransMeta could offer many new features and advantages over other cpus. Any thoughts on the reasons for this?
"There ought to be limits to freedom"
Look at the site, it's GamePC - we're not talking about an article targetted towards corporate IT managers for their server farms here. Personally, if Athlon MP systems were cheap enough, I'd buy a dual Athlon system for the significant performance gains and the cool SMP factor.
there are probably a few reasons why AMD doesn't support Tbirds for SMP use. 1. Heat, they run much much hotter than the MP or Athlon 4 chips do. Heat = unstable, not good the server market. 2. Chip safety features, including the new built in temp monitor so the chip won't overheat and burn itself out if something fails.
Anyone know if the 760MP chipset will support older AMD Socket A CPU's like the thunderbirds or durons? I've only seen support for the Athlon MP CPUs.