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)
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/
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
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"
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.
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.
> 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.
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.
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?
"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.
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."
Okay, mod me up as "insightful."
Got Rhinos?
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...
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,"
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!
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
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
~LoudMusic
No sig for you. YOU GET NO SIG!
Uninnovate - Only the finest in engineering.
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