Slashdot Mirror
AMD Gains In the TOP500 List
MojoKid writes "AMD recently announced its share of the TOP500 supercomputer list has grown 15 percent in the past six months. The company credits industry trends, upgrade paths, and competitive pricing for the increase. Of the 68 Opteron-based systems on the list, more than half of them use the Opteron 6100 series processors. The inflection point was marked by AMD's launch of their Magny-Cours architecture more than a year ago and includes the twelve-core Opteron 6180 SE at 2.5GHz at one end and two low-power parts at the other. Magny-Cours adoption is important. Companies typically don't upgrade HPC clusters with new CPUs, but AMD is billing their next-gen Interlagos architecture as a drop-in option for Magny-Cours. As such, it'll offer up to 2x the cores as well as equal-to or faster clock speeds."
Why is it newsworthy when one company goes up or down a random list?
I guess if you are a stockholder, but other than that I can't see caring.
funny, whats more news worthy is that a SPARC chip reached the top. That hasn't happened in like a decade has it? (i haven't checked it in a while)
That's hardly a "random list". And this is a site about technology. Do you think it would be irrelevant for a site about gaming consoles to mention that the Kinect increased the Xbox's share of exercise games (or whatever) ?
Supercomputing designs are a rather good real-world benchmark of CPUs, because they take into account cost, density, ease of deployment, etc..
More interesting than the share of the top 500 list, though, is the fact that AMD holds the #3 spot, ahead of Intel (whose first system comes in at #4) and both are behind a GPU-based system (using Nvidia Tesla chips, at #2). This is probably a good indicator of things to come, and explains why AMD is betting so heavily on integrating the GPU into its overall system architecture, and why Intel has finally started serious work on GPUs.
#1, by the way, is held by a SPARC system.
It's not standard SPARC. The VIIIfx's commercial-workload performance would probably be pretty bad - the cores themselves are more or less identical to the existing VII cores, which have less than impressive performance. The VIIIfx derives its HPC performance, which is admittedly good, from some extensions (called HPC-ACE) that are not part of the normal SPARC instruction set. In a lot of ways, the VIIIfx is closer to a vector processor than a conventional SPARC chip. This isn't inherently a bad thing, but it is certainly not a general-purpose processor.
The top500 site has its own take on highlights:
http://www.top500.org/lists/2011/06/press-release
- The two Chinese systems at No. 2 and No. 4 and the Japanese Tsubame 2.0 system at No. 5 are all using NVIDIA GPUs to accelerate computation, and a total of 19 systems on the list are using GPU technology.
- China keeps increasing its number of systems and is now up to 62, making it clearly the No. 2 country as a user of HPC, ahead of Germany, UK, Japan and France.
- Intel continues to provide the processors for the largest share (77.4 percent) of TOP500 systems. Intel’s Westmere processors increased their presence in the list strongly with 169 systems, compared with 56 in the last list.
- Quad-core processors are used in 46.2 percent of the systems, while already 42.4 percent of the systems use processors with six or more cores.
- Cray defended the No. 2 spot in market share by total against Fujitsu, but IBM stays well ahead of either. Cray’s XT system series remains very popular for big research customers, with three systems in the TOP 10 (one new and two previously listed).
In my opinion, the newest & most important trend in high performance computing is the advent of accelerators like GPUs.
The supercomputer I use daily is one of these new AMD based ones in the TOP500. It is a sweet machine. My software (custom engineering simulation written in C++) scales perfectly on it all the way out to over 10,000 cores.
The memory architecture is really excellent as well. With our old Intel based cluster we wouldn't load up every core on the node because of memory contention. But hyper-transport with NUMA completely negates the need to do that. We routinely fully load the nodes on the new machine without any trouble at all.
If AMD keeps it up they are going to find a lot of business in the high-end computing segment.
I think Intel, with its Larrabee thingy (now Knights Ferry?) will come to dominate the lists even more, in the short term. But honestly, who wants it?
People (like, 99% of people) want a reasonable CPU, and maybe a GPU for games. Most researchers want fast cores (parallel problems are hard), or vector processing (Matlab, Scipy, Mathematica etc take the pain out of distributing the workload), or distributed systems; in that order.
So normal people will want Fusion for its cheap GPU, and researchers will want it because it's actually easier to program.
AMD might have a bright medium-term future.
But when are those 28nm CPUs coming out?
Mostly for your ATI video cards. The heat output of your 6000 series is incredible. Love the industrial fan though.
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
No, AMD does not write a C++ compiler. In anyu case, that's irrelevant, unless you think software developers should start distributing two versions of every executable.
And it's a well documented fact that Intel's compiler checks for "GenuineIntel" in the CPU ID string and executes different (generally less efficient) code if it gets "AuthenticAMD" instead. Intel itself has never denied it, and says it's because "they can't keep track of what instructions other manufacturers support" (it's not as if they copied their 64-bit extensions from AMD or anything *cough*).
http://patch-authenticamd.googlecode.com/hg/web/index.html?r=1.0
http://www.agner.org/optimize/blog/read.php?i=49
http://www.theinquirer.net/inquirer/news/1567108/intel-compiler-cripples-code-amd-via-chips
etc...
So why should intel have to write optimizations into their compiler for a competitor? The article basically says if it finds a non intel chip then all optimizations are turned off. Can this feature not be overidden? Sounds overblown if you ask me.
Only the State obtains its revenue by coercion. - Murray Rothbard
"Any proof of these claims of compiler tampering?"
This is a well known issue with the intel compiler which has been fixed since. The story is told on wikipedia in the criticism section of http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler
The problem is so well known, that people wrote software to patch the code produced by the intel compiler to make it work properly on AMD processors such as http://code.google.com/p/patch-authenticamd/
"So why would you be using an intel compiler on AMD cpus?"
One of the interest in using the x86 instruction set is to be binary compatible so that you can use the code generated by any compiler. The intel compiler is a very good compiler, why not use it ? VIA also produces x86 processors you can use the binaries generated by the intel compiler on it. These technologies are designed to be compatible.
"Does AMD not write one?"
AMD contributes to http://en.wikipedia.org/wiki/Open64 and to GCC.
"Your third paragraph reads like an advertisement,"
I agree on that one.
It's not that Intel had work to do to support non-Intel chips. They did extra work to make all code produced by the Intel compiler slower that necessary on non-Intel chips. Thats' not just binaries delivered by Intel, but also a lot of code from 3rd parties.
Is we need to look at finding a new benchmark perhaps for supercomputer. Maybe two or three different kinds, depending on the kinds of thing you want.
The reason is that while GPUs are great, they are limited. We don't use them for everything for good reason. So if you have the kind of problem GPUs are good at, and linpack happens to be one of them these days, then wonderful. They are a great way to go in terms of performance/dollar and performance/watt. However if you don't, then they are not useful and you need to use CPUs.
Thus there are reasons to have the "slower" CPU based supercomputers because for some things, they are not slower at all.
For example one problem linpack has is it doesn't test interconnect speed very well. You can break the problem down in to small pieces and run it on the nodes quite well. Now that's wonderful, but not all problems are like that. Some do heavy cross node memory access and linpack doesn't show that.
That is an area GPUs fall down in. For example a Tesla M2090 has 177GB/sec of memory bandwidth to its onboard 6GB of RAM. Nice. However it only has 8GB/sec of bandwidth back to any system memory since it is on a PCIe 2.1 16x slot and that is all the bandwidth that has. Well that means things slow down a TON if you have to go off of the included RAM, never mind to RAM in another system.
So for some things, and linpack is one, that you can divide down and not have a ton of access between nodes, then wonderful, the GPUs are good. But we should have a benchmark that tests other situations too. Part of the reason why someone may buy a supercomputer instead of just a cluster is the need for high interconnect speed.
Would you have preferred it if I had wrote "Yo Dawg, I be hooking up video and that shit be fat yo! teh pic be all big and shit, and it be fatter than a ho's ass dawg!" is that more preferable? How else are you gonna write that you get great video performance and the ability to transcode without actually saying that?
So excuse me for actually writing down what I have experienced installing and building AMD systems. Perhaps a video of never gonna give you up or a pic of a distended anus would be more to your liking?
Now back to the topic, I have found since switching that the typical 10% performance gain of Intel usually comes at a 300% markup when you figure in the price of the boards, and most people will never be able to notice the difference. I bet if I built identical quads, one Intel and one AMD, and had you do your average everyday tasks you frankly wouldn't be able to tell the difference. Well not until you got the bill that is.
And frankly anyone that supports the free market would have to be nuts to buy Intel ATM, because their behavior frankly should have had their ass dragged into court for antitrust years ago. Bribery? Rigging software? Oh and BTW Intel still rigs their compiler the ONLY difference since the settlement is they document it in the fine print and give you the "choice" of taking a dump over ALL of the software you compile by forcing it all to run in X87 mode, or only have it take a shit on AMD and Via chips. Wow, what a choice!
When you add to this their current campaign to slowly kill Nvidia, whose chipset division they have already strangled, then how anyone here can say that MSFT deserved to be busted but Intel not I will simply not understand. So if you don't want to reward bribery, unfair market manipulation, and outright douchebaggery, try to buy AMD next time okay? And this is from someone that for nearly 15 years was strictly an Intel man, but I can't reward douchebaggery with a clear conscience.
And as for proof, since teh Google must not work where you are here you Go and you should read the first one especially, since it is a post from right here on /. where a programmer documents the behavior and what happened when he ran programs compiled with an Intel compiler on AMD. Now since most programs on Windows (including most benchmarking suites) and compiled for Windows with the Intel compiler than the results of ALL those programs must now be looked upon as suspect. It is no different than the classic "Quack.exe" where if it detects A you get one result and B gets you another, even though the chips in question have identical abilities to run SSE code. And this programmer had noticed the problem back in 2004 so for at LEAST 7 years they have been rigging.
ACs don't waste your time replying, your posts are never seen by me.
some proof:
http://www.agner.org/optimize/blog/read.php?i=49
My biggiest issue is I am VERY VERY impatient when it comes to computers and I can't find anything from AMD that even comes CLOSE to my current i7 2600K @ 5Ghz. Not even a mb/cpu(s)/memory costing 3 times as much can touch this thing in most everyday things I do such as read/program/play games/photoshop/repeat. I finally, a few weeks ago, broke down and gave them another chance and built "my" 1st amd rig in like I said about 4 or so years and whilst it's fine for the money [it's a Phenom II X4 955 Black, water cooled, overclocked to 4.2Ghz with 4 gigs DDR3 @ 1333]. it's still much slower than the i5 I built around the same time [i5 750 @ 3.4Ghz, and 12 gigs DDR3 @1328 air cooled] and both cost about the same in parts, yet the i5 SMOKES the 955 even at 800Mhz less per core. So dollar for dollar you're still "faster" with intel and I Like fast. I pay well for fast. IF Amd was faster I'd be using them right now but they don't have ANYTHING to offer me except the HD 6990 I have in here but that's still ATI in my minds eye.
AMD will need to pull a major magic rabbit out thier hats on this upcoming bulldozer [which does seem to have intel worried as they are delaying the x78 chipset and subsiquent LGA2011 cpu's and boards until AMD reviels thier hand]. Smart on thier part I guess, sucks on mine cause I couldn't wait and went with the flakey p67 but hey in a couple of months I'll have a fairly cheap motherboard/cpu combo for sale :)
i just don't see it.
This Top500 comes in handy after these:
http://www.brightsideofnews.com/news/2011/6/24/amd-insiders-speak-out-bapco-exit-is-an-excuse-for-poor-bulldozer-performance.aspx
Following our coverage on AMD's exit from BAPCo and blog post made by Nigel Dessau, we got a surprising call from the person at the heart of AMD which we had to check out. After the end of an eye opening conversation, we started calling our sources in order to confirm if the claims made by an obviously disappointed engineer hold any substance. We talked to our usual sources inside the company, as well as with a number of sources at their key partners and customers. The odd part was that all of our contacts said the same thing - the story checks out. Thus, we bring you the modestly edited version of our conversation, filed with comments.
AMD's BAPCo Exit is a Smokescreen
First and foremost, we started the discussion over the blog Nigel Dessau, AMD's Senior Vice President and Chief Marketing Officer wrote, stating clear reasons why AMD decided to leave the BAPCo and why AMD considers SYSmark 2012 an invalid benchmark.
"When I read Nigel's blog and saw the press release from BAPCo it made me sick because our CMO talks about transparency and honesty and it's all smoke and mirrors. At the end of the day, we actively had internal teams and external organizations hired to promote/discredit SYSmark. Not because it was inaccurate, but because it is accurate. Back in the original Athlon 64 and Opteron days, when we were winning in SYSmark we were heavily promoting it in the public sector, who in turn used it as a benchmark on which they based many of their purchases on. It was us who actually got BAPCo and SYSmark inside several government tenders to win orders measured in tens of thousands of systems. SYSmark was used to show how our K8 processors were beating Intel's NetBurst."
http://www.zdnet.com/blog/computers/why-did-amd-quit-bapco-board-poor-bulldozer-performance-on-sysmark-2012-or-intel-bias/6230
The latest dust-up in the AMD-versus-Intel never-ending conflict concerns BAPCo, a consortium of tech companies that releases a set of benchmarks, including, most importantly, SYSmark. This week, AMD quit the BAPCo board, and speculation over why has run rampant ever since.
Officially, AMD claims that the latest version of SYSmark, the just-released SYSmark 2012, fails to keep up with current computing trends and ignores the increasing role the GPU plays in computing tasks. Since AMD is trying to differentiate itself from Intel by boosting the GPU in its new chip designs, SYSmark’s reliance on just the CPU, in AMD’s opinion, doesn’t reflect everyday computing performance.
That’s the official word. But conspiracy theorists think there’s more to the story than just that. Most sensationally, Bright Side of News has run a piece with startling claims from “unnamed sources,” most notably that AMD decided to pull out of BAPCo because its forthcoming Bulldozer chips delivered underwhelming performance on SYSmark 2012, and that the company has spent resources toward surreptitiously undermining BAPCo through negative PR campaigns. According to the piece, AMD’s paranoia about SYSmark is related to the benchmark’s role in securing government contracts and the chip company’s fear that it won’t win new contracts with poor SYSmark 2012 results.
Coincidence?
No, AMD does not make a C++ compiler.
what about Open64?
Open64 is not developed by AMD. They ship a few Open64-derived products, but they aren't the main developers.
I am TheRaven on Soylent News
Intel's excuse is valid. AMD has been fairly good (although not perfect) at only setting CPUID feature flags when they have a 100% compatible implementation of an extension. Other x86 manufacturers have been very bad. Worse, some (e.g. IDT's WinChip) have advertised some features and then implemented them with trap-and-emulate code in a driver. They did this for some uncommon operations, to make code that used them occasionally run, rather than exiting with an error, that meant that a compiler that used those instructions in an optimisation would make code that ran much slower. Intel's compiler does not assume that non-Intel chips that advertise a feature actually support it, because the team would get into a lot more trouble if their code broke on other manufacturers' chips than if it just ran a bit slower.
I am TheRaven on Soylent News
I forgot to say - even if the non-Intel chip has a 100% compatible implementation of the feature, that does not mean that it will have the same performance characteristics. This is true even among Intel chips. Some SSE-based optimisations can give you a 2-4x speedup on Core chips, but give a slowdown on Atom chips (early ones, at least, not sure about the latest one). Doing the same optimisations for an AMD or Via chips may make things faster, or they may make things slower. Without extensive testing, Intel's compiler team doesn't know which, and doesn't bother spending money on testing their competitors' hardware to find out.
I am TheRaven on Soylent News
So why should intel have to write optimizations into their compiler for a competitor?
They don't. The issue isn't "optimizations" as one usually thinks of it, tweaking a piece of code with compiler tricks to make it run faster.
The issue is using entirely different code paths that use x86 extensions like the SSE family of instructions. These instructions, in addition to being SIMD for when the same operation is being performed on multiple pieces of data, are essentially a replacement for the old x87 floating point co-processor instructions. x87, which is old and stupid, and a right bitch for both programmers and hardware designers.
There is no processor which supports SSE where that codepath would not be faster than x87. Intel doesn't have to optimize the SSE code for AMD, and nobody is asking them to -- AMD optimizes their implementation to be fast with the code Intel (and other compilers) produce.
The problem comes when the code Intel produces specifically ignores their own spec on how to detect if these instructions are supported, and instead checks for a "GenuineIntel" vendor string, and resorts to the x87 codepath for anything else. Even though AMD chips support both the SSE instruction set and the specification for detecting it.
So that's the problem. Intel is deliberately de-optimizing competitor's parts.
Can the feature be overridden? Yeah. If you know about it, you can hack the binary to remove the check, or you could use a microcode patch to make an AMD chip return an Intel vendor string. The former is illegal if you are an end-user of a non-Free program, and the latter is illegal if you're AMD.
Is it overblown? Maybe. It's a direct and flagrant instance of Intel taking action not to boost themselves, but to harm a competitor. It costs AMD quite a bit of performance in a variety of common and popular programs, as would be expected, and which can be shown by disabling the "feature".
Personally I think that when the solution is so simple and logical -- Intel honors their own damn spec and the CPUID bits for SSE and other instruction sets -- not doing it represents just maliciousness on Intel's part, and so the level of reaction is warranted.
The enemies of Democracy are
Except that ISN'T what they are doing. If you bothered to read the post this all started back when the first P4s came out, aka little space heaters big pile o' suck. if you'll notice it also crippled performance on the P3 which was currently kicking the dog snot out of Netburst (and eventually came back under the Core moniker) so what we have is a simple "If chip equals what we want to promote then code=fast" and "If ship equals one we want to bomb then code' shit".
If they simply wanted to be safe then the safest thing to do would be to do nothing at all. After all if someone complains that just helps them sell chips, right? They could say "Sorry, please use genuine Intel next time" and that would be that. But no, that would let people know they are being fucked. Otherwise how do you explain disabling SSE support on the P3, which had an Intel designed SSE path? Can't be worries about compatibility, after all Intel designed the thing!
No if you read the results in the first link sadly there is only ONE conclusion, and that was Intel is using their position as leader in the market to hamstring any chips they did not want to promote. The P3 really is the smoking gun here, as at the time the benchmarks were showing the P3 on average 20% faster than the Netburst while using 40%+ less power. But guess what happened after the Intel compiler rigging? Why Netburst was suddenly 22% faster than the P3! Isn't that amazing? Oh and while there may be other compilers on Linux, on Windows it is Intel or MSFT. Kinda sad when MSFT is the fairer choice huh?
The simple fact is we aren't talking about some esoteric feature that may or may not be supported, we are talking about basic SSE which is a published standard and has been supported by ALL chip manufacturers since before the Intel compilers were rigged. No this is no different than if MSFT had OEMs rig the BIOS of laptops to do a check for "Genuine Windows" and have it run like shit if the flag wasn't tested. This check does NOTHING but look at CPUID, that's it. No checking of MXX, or SSE, or any other flag. It just looks for a P4 or above flag and if it isn't found drops the entire stack into slow ass x87 mode, which frankly has been depreciated since the Pentium 1 and is used by NOBODY else. If you read the first link the programmer points out they even used a poorly documented crap memory move just to ensure that it would REALLY slow it down.
This isn't "playing it safe" this is classic Sherman Antitrust behavior that sadly Intel WILL get away with, because our government was sold to the corps years ago. Hell if the MSFT case happened today they wouldn't even have had a trial, hell they would have probably gotten a tax break for doing it!
ACs don't waste your time replying, your posts are never seen by me.