Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AMD Rejects SYSmark Benchmark

CmdrTaco posted more than 3 years ago | from the if-you-can't-win-quit dept.

AMD 118

Deathspawner writes "In an unusual move, Advanced Micro Devices has issued a press release rejecting its endorsement for the industry recognized benchmark SYSmark 2012. Developed by BAPCo and backed by industry heavyweights such as Dell, Intel and Hewlett-Packard, AMD has stated that BAPCo both has tuned SYSmark to create bias in favor of its competitor, and that its benchmarks are not relevant for the audience it targets. Also noted is a complete lack of heterogeneous CPU+GPU testing. Techgage tears apart AMD's claims to see if they are valid, while also evaluating the overall usefulness of SYSmark and the impact it can have on consumers."

Sorry! There are no comments related to the filter you selected.

Not the only ones. (5, Informative)

ustolemyname (1301665) | more than 3 years ago | (#36519950)

Nvidia and Via quit too. [semiaccurate.com]

Re:Not the only ones. (1)

blair1q (305137) | more than 3 years ago | (#36520044)

Um, linking to Charlie Demerjian is like linking to AMD marketing.

Just saying.

Re:Not the only ones. (1)

jcombel (1557059) | more than 3 years ago | (#36520124)

why?

Re:Not the only ones. (1)

bmo (77928) | more than 3 years ago | (#36520190)

1.7 woodscrews.

And the fact that Nvidia got Charlie booted from The Register.

--
BMO

Re:Not the only ones. (1)

Anonymous Coward | more than 3 years ago | (#36520444)

And the fact that Nvidia got Charlie booted from The Register.

The Inquirer you mean?

Re:Not the only ones. (1)

bmo (77928) | more than 3 years ago | (#36520584)

Yeah, that too. :-P

I stand corrected.

--
BMO

Re:Not the only ones. (2)

Groo Wanderer (180806) | more than 3 years ago | (#36521086)

You are wrong about both the site, and how I left.

            -Charlie

Re:Not the only ones. (1)

bmo (77928) | more than 3 years ago | (#36521510)

Corrected twice for one message.

I'm slipping.

I retract everything.

--
BMO

Re:Not the only ones. (0)

Anonymous Coward | more than 3 years ago | (#36522084)

It's almost like a James "Kibo" Parry sighting ... just mention their name or reference a URL pointing to them and they appear like magic after an extended hiatus.

Always cool to see the real people involved in articles respond.

Re:Not the only ones. (1)

ustolemyname (1301665) | more than 3 years ago | (#36521144)

Immaterial, if all I am using the article for is to reference the fact that Nvidia & Via left as well. Unless you have some evidence to the contrary, I don't care what "marketing" department I'm presently using as a source.

I knew that Via & Nvidia left, and Googled the first reference that popped up. So what? You're not questioning my facts, so I don't give a damn.

Re:Not the only ones. (0)

Anonymous Coward | more than 3 years ago | (#36521532)

The only sensible benchmark, is running your target algorithm/application on it. Everything else is bullshit.

(Of course a good platform should come with a compiler [or compiler back-end] that optimizes for it. But I wonder how much AMD/Intel/etc have contributed to e.g. GHC or even grandpa GCC.)

Re:Not the only ones. (1)

kelemvor4 (1980226) | more than 3 years ago | (#36522806)

I can't believe people actually read that guy's drivel.

Re:Not the only ones. (1)

ustolemyname (1301665) | more than 3 years ago | (#36523442)

I will admit that the article's quality can certainly be qualified as "drivel," but as other sources have independently confirmed that Nvidia has left, I don't see why that matters.

Other [anandtech.com] sources [notebookvideoreview.info] of Nvidia quiting.

Re:Not the only ones. (0)

Anonymous Coward | more than 3 years ago | (#36524576)

It's just a pity AMD took ATI instead of Nvidia the combination of AMD & Nvidia would have been bang on never know someone might see sense one day and grab the right choice next time .

link to clean article (2)

cheeks5965 (1682996) | more than 3 years ago | (#36519968)

for your convenience, here you go: http://techgage.com/print/amd_rejects_bapcos_sysmark_2012_-_should_we [techgage.com]

Re:link to clean article (1)

nschubach (922175) | more than 3 years ago | (#36520072)

To be fair, it's only two pages in the non-print version. It's not like some of the horrid 15 page ad farms.

Re:link to clean article (1)

cheeks5965 (1682996) | more than 3 years ago | (#36520138)

just trying to help... there are fewer tracking bugs at least.

Once again... (2)

ThoughtMonster (1602047) | more than 3 years ago | (#36520096)

This would've been avoided if these "industry standard" tools were released as open source. It would be interesting to see if such a development will arise from this dispute.

Re:Once again... (3, Insightful)

h4rr4r (612664) | more than 3 years ago | (#36520192)

There is always the Phoronix test suite. They might be chicken littles, but their test suite is at least open and repeatable.

Re:Once again... (1)

GigaplexNZ (1233886) | more than 3 years ago | (#36522578)

PTS is really only a bootstrapper to launch 3rd party benchmarks and compare the results. If the test it is running just so happens to be SYSmark, an open source bootstrapper won't help us evaluate the fairness of the test itself.

Re:Once again... (3, Interesting)

meerling (1487879) | more than 3 years ago | (#36520420)

Of course, the more the people being tested know about how it's tested, the easier it is for them to cheat.
(Plenty of past history from both Nvidia and ATI doing that with video cards.)

(Note: Always investigate claims of benchmark cheating, sometimes it's a misunderstanding. One example deals with a claim of cheating because an optimization routine found the same process being hit constantly, so it cached it. There were screams of cheating and 'tuning' the driver to trick the benchmark when all it really was is caching doing what it's supposed to. Even though it did give artificially high scores in that one test. Once the issue was known, the benchmarkers changed their program to not do a stupid repetitive test that would just get cached.)

Of course this isn't an issue of cheating, but it sure feels like it. Makes you wonder what AMD is really worried about...

Re:Once again... (5, Informative)

hairyfeet (841228) | more than 3 years ago | (#36520868)

Well if they used the Intel compiler then it is for all intents and purposes useless as Intel has been rigging their compiler with a "Genuine_Intel" flag and if the flag isn't detected dropping all SSE and above optimizations and instead running in slow ass x87 mode. Last I read despite being ordered to change their behavior Intel is STILL putting out compilers with the evil bit on and haven't done anything to alert previous customers of their douchebaggery.

So I wouldn't be so quick to just dismiss out of hand, after all, who would have thought that Intel would rig their own compiler to cheat? I can't even imagine how many programs out there have been compiled using the Intel compilers which makes every single program written using their tool chain rigged against AMD and Via.

Re:Once again... (0)

Anonymous Coward | more than 3 years ago | (#36521184)

This is simply solved. All AMD has to do is create their own compiler.

Re:Once again... (1)

Moridin42 (219670) | more than 3 years ago | (#36521338)

.... and get everybody to compile all their stuff a second time?

Not so simply solved..

Re:Once again... (2)

cynyr (703126) | more than 3 years ago | (#36522288)

you mean like GCC?

AMD has contributed a lot to GCC in the past.

Re:Once again... (0)

Anonymous Coward | more than 3 years ago | (#36521190)

Should be a higher mod levels possible than 5, and you should be there.

Re:Once again... (1)

yuhong (1378501) | more than 3 years ago | (#36522172)

Yea, there was an old Slashdot article about it.

Re:Once again... (2, Informative)

Anonymous Coward | more than 3 years ago | (#36522984)

The most recent versions of Intel's compiler clearly document the evil behavior in the description of the code generation options, so at least it's not hidden any more. You can also mostly disable the evil behavior, if you are willing to sacrifice the runtime code-path selection that allows you to use SSEx on hardware that supports it while retaining compatibility with earlier machines.

Still, any benchmark using Intel's compiler can't be trusted unless it is fully open-source, including the exact compiler flags used.

Hmm (3, Interesting)

Spykk (823586) | more than 3 years ago | (#36520154)

It seems like AMDs biggest complaint is that the benchmark isn't offloading CPU intensive tasks to the GPU. It is pretty hard to take them seriously when they are complaining that the benchmark favors their competition by actually benchmarking the CPU.

Re:Hmm (1)

orient (535927) | more than 3 years ago | (#36520202)

Or AMD is complaining that some applications are using and the GPU and are benchmarked as NOT using the GPU.

Re:Hmm (3, Interesting)

afidel (530433) | more than 3 years ago | (#36520272)

Well, a benchmark with 2012 in the name certainly shouldn't be using two non-GPU accelerated web browsers and Acrobat 9! They really do have a point that currently released software is doing a much better job of using their more well rounded systems then the benchmark is. It's a system benchmark not a CPU benchmark (we have SPEC for that).

A CPU benchmark absolutely should (1)

Sycraft-fu (314770) | more than 3 years ago | (#36520982)

Reason is you are benchmarking, well, the CPU. You don't want the GPU messing with it. While the day may come when CPU and GPU fuse, that day is not now. So seems silly to bench a CPU with things that accelerate using a GPU.

Nothing wrong with benchmarking a GPU, or benchmarking things that use both, but you need to be clear about what you are testing. If the test is CPU, then that is what you want to restrict it to.

Re:A CPU benchmark absolutely should (1)

Joe U (443617) | more than 3 years ago | (#36521112)

While the day may come when CPU and GPU fuse, that day is not now.

They are currently interdependent, design a 6 core system with 8GB RAM, put a Rage 3d card in it, then run something modern, not a game, just a browser or a spreadsheet and tell me if the GPU doesn't improve the system.

Re:A CPU benchmark absolutely should (1)

Khyber (864651) | more than 3 years ago | (#36522340)

Rage3D would make a Windows 7 system nearly unusable, at least for Aero.

Re:A CPU benchmark absolutely should (1)

Lanteran (1883836) | more than 3 years ago | (#36522646)

Forget nearly unusable, I doubt anything that old has drivers for anything newer than 2000, maybe xp. 64-bit? Forget it.

Re:A CPU benchmark absolutely should (1)

Khyber (864651) | more than 3 years ago | (#36522688)

Omega Drivers would likely have something to work, but again, the limitations of the card itself would make the system nearly unusable.

Re:A CPU benchmark absolutely should (1)

Lanteran (1883836) | more than 3 years ago | (#36524200)

I run debian on an old pentium 3 with a rage 128 and gnome is damn near unusable. Windows 7 would be torment.

Re:A CPU benchmark absolutely should (2)

Moridin42 (219670) | more than 3 years ago | (#36521164)

Okay, but SYSmark isn't a CPU benchmark.

From BAPco's SYSmark page:

SYSmark® 2012 is the latest version of the premier performance metric that measures and compares PC performance based on real world applications.

As stated by the GP, there are CPU benchmarks such as SPEC's. But SYSmark isn't one and AMD alleges it isn't designed to benchmark what they say they're benchmarking.

Re:A CPU benchmark absolutely should (1)

ustolemyname (1301665) | more than 3 years ago | (#36521254)

Um... from the GP, "It's a system benchmark not a CPU benchmark"

Re:Hmm (1)

dgatwood (11270) | more than 3 years ago | (#36520324)

No, the complaint is that it is supposed to be a benchmark of overall system performance, and that benchmarking just the GPU does not do this. For example, in running a typical OS, a lot of the screen redrawing performance is dependent on the GPU if the GPU can handle it. If the GPU can't, a lot of that work gets offloaded onto the CPU, and performance suffers. Thus, by benchmarking only the CPU, you cannot get an accurate picture of the real-world performance of the system as a whole, or even of the processing capabilities of the system as a whole.

Re:Hmm (2)

Billly Gates (198444) | more than 3 years ago | (#36520370)

AMD is also betting big on Fusion and hardware accelerated HTML 5 with IE 10/Windows 8. They plan on making x86 tablets in which, some of their CPU's are barely faster than an Intel Atom but have a GPU inside as powerful as an ATI 6xxx HD. These benchmarks will be crap on the Llamo chip, but in real world use with Windows 8 and Flash 10.3 and higher you can run 1080p HD video fluidily without a sweat.

I would be irrated and concerned too if I were AMD, as people would get a false impression on their low end Llamo netbook chipsets as non Windows 8 ready.

Re:Hmm (1)

hedwards (940851) | more than 3 years ago | (#36521114)

I've been using a Llano chip recently, and the performance has been a lot better than I was expecting. Because the APU utilizes a Radeon HD 6310 it's not suitable for recent games, but I've found that games up until the last couple years seem to do just fine on it.

I'll wait to see what the performance is like on Windows 8, but Llano has little trouble with Windows 7, the system remains responsive pretty much whatever I'm doing and I rarely feel like I'm waiting around for things that should be done. There's a bit more lag than my desktop, but that sports an AMD dual core that's quite a bit faster and more power hungy.

Re:Hmm (1)

pla (258480) | more than 3 years ago | (#36522264)

It seems like AMDs biggest complaint is that the benchmark isn't offloading CPU intensive tasks to the GPU. It is pretty hard to take them seriously when they are complaining that the benchmark favors their competition by actually benchmarking the CPU.

Although once I would have agreed that, as a pure CPU benchmark it seems strange to allow offloading work to the GPU, the line has blurred rather a lot in the past year. AMD/ATI has put a ton of work into getting their OpenCL implementation as close to general purpose as most programmers could ask for - SIMD on a truly massive scale. So if the benchmark allows SSE, why shouldn't it allow OpenCL?

And as for the performance thereof... If some of the haters will forgive me for bringing up BitCoins, the performance of the various GPU miners on AMD vs NVidia vs Intel hardware leaves each of those, two orders of magnitude behind the next, in the order I just gave them. OpenCL destroys CUDA, and Intel doesn't even rank.

one thing that always bugs me about most is... (1)

VVelox (819695) | more than 3 years ago | (#36520188)

How they never take the ability to deal with threads into account.

This is one area where things becomes problematic for Intel. This is because of hyperthreading shaes some important resources, such as the SSE related stuff. There for if you are running lots of threads making use of features with these issues, then you will actually run into notably reduced performance as the threads compete for the same resources.

This can also be a increased problem with some optimization options with GCC as it will make heavier use of SSE/etc.

Ummmm... What? (1)

Sycraft-fu (314770) | more than 3 years ago | (#36521292)

Hyperthreading doesn't share some things, it shares everything. It is the ability for a single core to run two threads at the same time in hardware. Intel isn't the only one who does things like that, Sun does, as does IBM (with more than two threads to a core). There are two benefits to this:

1) Less context switching penalty. It actually takes a fair amount of resources for an OS to switch from one thread to another. So run more threads in parallel in hardware, get more performance in heavily multi-threaded stuff. Servers in particular can benefit form this, hence why Sun and IBM do it with more than 2 threads per core.

2) Increased usage of the chips execution units. You discover that in almost all cases with a single thread on a core, come execution units sit unused some of the time. With two threads, the processor can better schedule things in to get all the units used more of the time.

Net effect is better performance for heavily threaded tasks. There is no real downside, other than additional chip complexity. It doesn't slow down or anything.

What you may be confusing is that it doesn't double performance. Going from 4 cores to 4 hyperthreaded cores, which does 8 threads does not double performance. At worst it remains the same, at best you see a low double digit percentage increase.

However it doesn't decrease performance. The only way that would happen is if you made the mistake of thinking a dual core, hyper threaded system was the same as a quad core, non-hyperthreaded system.

Re:Ummmm... What? (1)

NeoMorphy (576507) | more than 3 years ago | (#36521986)

There actually can be a performance hit.

Imagine you have 4 hyperthreaded cores and you have a process that is running 7 CPU intensive threads. Because of processor affinity, 6 threads will share a processor(2 each) and one thread will have an entire processor. If they all have equal work, the one using a processor by itself will complete first, but the other 6 still need to complete for the whole set to be considered complete.

Using mpstat on AIX you can see the effect I am describing.

Also, there is some overhead, this becomes more noticable with CPU intensive processes. But you wouldn't want to use hyperthreading for that. The advantage of hyperthreading is to increase the ability to fully utilize the processors. If a thread stalls(ie:cache miss) then it can switch in the other thread.

AMD a bit lost (1)

metalmaster (1005171) | more than 3 years ago | (#36520196)

I think AMD is a bit lost on this one or atleast they dont understand the point of benchmarking

AMD's largest complaint is that SM2012 doesn't represent the market well enough, employing high-end workloads that the regular consumer doesn't care about

As far as i know benchmarking is about pushing the tech to its limits to see what it can do or at least how it does against a standard heavy load. Your average user whose surfing the web, checking email, playing/streaming media or playing games probably isnt going to stress new hardware all that much. Aside from gaming, hardware from 5 years ago is still up to that task.

I think they are pissy because they dont stand up well to the competition.

Re:AMD a bit lost (1)

Shadow99_1 (86250) | more than 3 years ago | (#36520378)

Well having run the benchmark in question and many others (including open ones) on my newest system build, The current SYSmark scores lower then it should based on other tests which test the same things. So I don't think it's just whining. Something really is going on under the hood with SYSmark, compared to other benchmarking apps that do the same sorts of things. I seem to recall this isn't abnormal either, this has been something seen often in a variety of tools with bias often programmed in treating one cpu/platform specific different than another. It has never been done in AMD's favor though...

Re:AMD a bit lost (4, Insightful)

Anonymous Coward | more than 3 years ago | (#36520628)

A benchmark that doesn't test realistic workloads is of little use for evaluation if a system is fit to purpose.

A benchmark that isn't open about its methodology is at best worthless and at worst directly misleading.

I think they are pissy because they dont stand up well to the competition.

I think the complaints sound quite reasonable on the face of it. If it is true that Nvidia and VIA have also resigned, that just leaves Intel waving their cocks around at any rate.

Re:AMD a bit lost (2)

Moridin42 (219670) | more than 3 years ago | (#36521288)

I'm not sure you understand the point of benchmarking.
You can benchmark a lot of stuff. But its pointless to benchmark HD read/write speeds when what you're interested in is FLOPS. So there are benchmarks which see how many floating point ops your system can do. And there are benchmarks about hard drive performance. But there tends not to be one benchmark to rule them all.

BAPco say that SYSmark is a benchmark for real-world business app performance. But AMD say SYSmark doesn't utilize the GPU in any way.

Given that modern operating systems go to GPUs for rendering, which they're good at, and freeing up CPU time for CPU stuff, SYSmark isn't benchmarking what they claim to be benchmarking.

Which would make SYSmark a pointless benchmark.

Re:AMD a bit lost (1)

garyebickford (222422) | more than 3 years ago | (#36523426)

To get right down to it, the real purpose of all benchmarks is to provide grist for geeks to argue about which toy is better at doing X. So, the more benchmarks the better, ideally each measuring not-quite-the-same-thing and not-quite-the-same-way. That way, everybody can have a favorite, and everyone can win! :)

Re:AMD a bit lost (1)

billcopc (196330) | more than 3 years ago | (#36521934)

I think they are pissy because they dont stand up well to the competition.

Before reading the article, that was my assumption as well, but we are both wrong. IMHO, the complaint is legitimate, as Sysmark's results seem to contradict even basic common-sense metrics like "how long does it take to perform task XYZ". Whatever measurements they use, it seems the weighting has been intentionally skewed to give misleading results. Like the example in TFA, where Sysmark says an old Core-2 QX9770 with DDR2 matches an i7-965 with DDR3, even though simple task-oriented tests prove the i7 stomps the Core 2 with 25% to 38% lead, clock-for-clock.

If the stated purpose of Sysmark is to help identify the relative performance of a whole system, then it fails miserably. It tries to sell itself as a real-world test yet does not reflect real-world results.

Re:AMD a bit lost (1)

Rockoon (1252108) | more than 3 years ago | (#36522850)

I think you are a little lost on this one.

Once upon a time [vanshardware.com] BAPCo didnt even bother pretending that they weren't actually Intel.

These days, BAPCo pretends that they arent Intel. Its still Intel tho.

BAPCo is Intel.

The last time Intel so blatantly rigged the benchmark game was when the Athlon XP's were beating the shit out of the Pentium 4's. AMD has recently made a mockery of Intels Atom solutions, and the one leaked benchmark [phoronix.com] for the Bulldozer design must have Intel more than a little worried about its future bragging rights.. so here we are, with Intel blatantly rigging the benchmark game again.

Expect a new version of ICC shortly.

Intel's compilers (5, Interesting)

KiloByte (825081) | more than 3 years ago | (#36520224)

Quite a bit of Windows software is compiled using Intel's compilers, and they are intentionally made to sabotage performance on AMD chips. When looking at CPUID, instead of checking the features they want, they look for that _and_ the CPU being "GenuineIntel", and if not, the code chooses the worst possible implementation [agner.org] . This includes some major scientific math libraries and a part of popular benchmarks.

Re:Intel's compilers (0)

Anonymous Coward | more than 3 years ago | (#36520314)

That's great! Why doesn't AMD go and write a compiler of thier own and give it away for free?

Re:Intel's compilers (3, Informative)

Rockoon (1252108) | more than 3 years ago | (#36520690)

That's great! Why doesn't AMD go and write a compiler of thier own and give it away for free?

Its called Open64 [amd.com] .

Re:Intel's compilers (0)

Anonymous Coward | more than 3 years ago | (#36521324)

And it sucks when used with Intel CPUs - big surprise there!

Re:Intel's compilers (3, Interesting)

Rockoon (1252108) | more than 3 years ago | (#36522318)

In recent tests [phoronix-test-suite.com] Open64 is better than ICC at producing code that executes on the Pentium Dual Core T2370

In fact, its not just better... its significantly better.

Stop talking out your ass.

Re:Intel's compilers (1)

AmiMoJo (196126) | more than 3 years ago | (#36525540)

That is because the Pentium Dual Core is a low end CPU and Intel optimises for the high end ones where people care about benchmarks.

That is also the reason why performance of code generated with the Intel C++ compiler is poor on other manufacturer's CPUs; They were required to stop looking for the GENUINE_INTEL CPU flag but still optimise based on assumptions about pipelines and available APUs/FPUs on current generation Intel processors. The Pentium Dual Core is based on the older Core 2 architecture and of course AMD CPUs are completely different.

This reminds me of Intel's tactic in the late 90s/early 2ks of pushing up CPU speeds with little regard for actual performance. The Pentium 4 architecture was designed to run at high clock rates rather than to actually perform well, and it speaks volumes that they abandoned it and went back to the P3 design to create the Core architecture. Similarly Intel is now optimising its compiler to produce code that isn't necessarily the fastest but is heavily tied to their CPU designs so that they can claim better performance than AMD. For their part AMD have usually gone for the best technical solution, e.g. when they stopped using clock speeds as a measure of performance and now with their compiler.

Re:Intel's compilers (1)

Foredecker (161844) | more than 3 years ago | (#36520362)

Quite a bit of Windows software is compiled using Intel's compilers...

Dear KiloByte, You clearly just made that up. That is a patently untrue statment. Both Windows and Office are bult with the Microsoft Compiler.

Don't make stuff up.

-Foredecker

Re:Intel's compilers (0)

Anonymous Coward | more than 3 years ago | (#36520590)

I would love to compile my open source windows binaries with intel's compiler, however it is unclear how I am supposed to get it for free, and old versions i have found for free fail to compile my programs.

Re:Intel's compilers (1)

tyrione (134248) | more than 3 years ago | (#36520830)

I would love to compile my open source windows binaries with intel's compiler, however it is unclear how I am supposed to get it for free, and old versions i have found for free fail to compile my programs.

Then compile against LLVM/Clang Trunk. The LLVM 3.0 release is nearing and is has come a long way in a short period of time.

Re:Intel's compilers (1)

suutar (1860506) | more than 3 years ago | (#36520754)

I think he meant "Windows software" in the sense of "software compiled to run on Windows"; a lot of folks use Intel's compilers for that.

Re:Intel's compilers (0)

Anonymous Coward | more than 3 years ago | (#36520822)

I'm going to bet they use Visual Studio instead.

Re:Intel's compilers (0)

Anonymous Coward | more than 3 years ago | (#36522112)

...which can be configured to use ICC.

Re:Intel's compilers (1)

arose (644256) | more than 3 years ago | (#36520952)

Dear Foredecker. Windows isn't "Windows software" and Office is not "quite a bit". Learn to read. -AC

Re:Intel's compilers (0)

Anonymous Coward | more than 3 years ago | (#36521094)

Although I don't know whether or not those claims are true, gp specifically said that quite a bit of Windows software is compiled using the Intel compilers. I don't think Windows or Office were mentioned by name.

Re:Intel's compilers (1)

Myria (562655) | more than 3 years ago | (#36521714)

Quite a bit of Windows software is compiled using Intel's compilers...

Dear KiloByte,

You clearly just made that up. That is a patently untrue statment. Both Windows and Office are bult with the Microsoft Compiler.

Wow, I would've expected better from a low 6-digit UID. Maybe, perhaps, by "Windows software" KiloByte meant programs made to run on Windows, not necessarily Windows itself? There exist companies making Windows software that were built with Intel C++.

Re:Intel's compilers (1)

DGolden (17848) | more than 3 years ago | (#36523212)

Wow, I would've expected better from a low 6-digit UID.

Yeah, I don't think it works that way. Plenty of people with low UIDs are complete assholes.

Re:Intel's compilers (0)

Anonymous Coward | more than 3 years ago | (#36525670)

So can you name any significant software made using the Intel compiler? We've got an entire company worth of software that definitely doesn't use it. How about a few pieces that definitely do?

Re:Intel's compilers (1)

Khyber (864651) | more than 3 years ago | (#36522378)

"Both Windows and Office are bult with the Microsoft Compiler. '

Guess what the MS Compiler was made from?

Duh.

Re:Intel's compilers (1)

Foredecker (161844) | more than 3 years ago | (#36522774)

Dude, that's just idiotic. Just stop making stuff up.

Maybe AMD should get off their butts (1)

Sycraft-fu (314770) | more than 3 years ago | (#36520892)

...and make a compiler.

The reason Intel's compiler gets used so much is because it consistently generates the fastest code, period, when run on Intel processors (which are by far the majority). You see compiler shootouts and among others it goes back and forth what is faster at what, then at the top is the ICC, it just kills all the others.

Well, maybe AMD should do something about that. Maybe they should make their own, competing, compiler. Make it generate optimized code for ALL chips. Hell give it away for free (the ICC is not cheap).

Companies would have incentive to use it. Free, generates highly optimized code for all CPUs (even if its Intel code wasn't quite as good as the ICC), talk about a win.

However as it stands, AMD has nothing. So people can use VC++ or GCC or the like, which do an ok job, or they can use the ICC (which plugs right in to VS) and get the fastest code for Intel CPUs, including extremely good auto parallelization.

No surprise the ICC gets a lot of use.

Re:Maybe AMD should get off their butts (4, Informative)

Ogi_UnixNut (916982) | more than 3 years ago | (#36521016)

Um, they do have their own compiler: http://developer.amd.com/tools/open64/Pages/default.aspx [amd.com]

Seems to be both free to download, and comes with source code so you can go over it if you wish.

Re:Maybe AMD should get off their butts (1)

Sycraft-fu (314770) | more than 3 years ago | (#36521060)

Didn't know they'd done that. Well then I guess the question now is how it performs. If it gives results similar to the ICC then they just need to market the thing and start convincing companies to use it.

Re:Maybe AMD should get off their butts (1)

postbigbang (761081) | more than 3 years ago | (#36521932)

Well, if you test it with BAPco's SysMark, not so well.

Re:Maybe AMD should get off their butts (1)

arnott (789715) | more than 3 years ago | (#36521018)

Someone above has already posted this : AMD64 [amd.com]

Re:Maybe AMD should get off their butts (0)

Anonymous Coward | more than 3 years ago | (#36521130)

actually thats not true. the GCC compiler in almost all of code compiled except for certain specialty items like encryption whoops the Intel compiler hands down when it comes to benchmarks and speed.

Re:Maybe AMD should get off their butts (1)

hedwards (940851) | more than 3 years ago | (#36521186)

You can get away with that sort of behavior when you're a bit player in the market, but when you've got most of the supply locked up, I don't think there's anyway in which it isn't an antitrust violation to do so. Developers are mostly going to use the one that produces the fastest code on Intel processors because it's the larger part of the market. The odds are good as well that the machines they're using use Intel processors as well.

Re:Maybe AMD should get off their butts (5, Informative)

compro01 (777531) | more than 3 years ago | (#36521314)

...and make a compiler.

They did. It's even GPL licensed.

http://developer.amd.com/tools/open64/Pages/default.aspx [amd.com]

Re:Maybe AMD should get off their butts (0)

Anonymous Coward | more than 3 years ago | (#36523650)

Last time I checked, Open64 was Linux only. I would use their compiler if it was mult-platform like Intel's.

Re:Maybe AMD should get off their butts (1)

johncadengo (940343) | more than 3 years ago | (#36524810)

Did you notice that this compiler is linux only?

The reason why Intel compiled programs are so prevalent is because of Windows.

Re:Intel's compilers (0)

Anonymous Coward | more than 3 years ago | (#36521366)

That's good to know. Thanks for the link.

Re:Intel's compilers (1)

hitmark (640295) | more than 3 years ago | (#36524866)

Reminds me of a claim that the MS ACPI test suit is subtly different form the Intel one, so if one use the MS suit one get a ACPI setup that may not play nice with the ACPI spec.

AMD quit because it was losing. (2)

blair1q (305137) | more than 3 years ago | (#36520228)

AMD has chosen an architectural roadmap that makes the GPU and CPU part of the same APU. SYSmark does not measure 3-D graphics performance. At all. So while AMD is pursuing a path that will give its APUs greater overall performance than the CPUs they contain, they are actually hamstringing themselves in the CPU-only testing arena, because the CPU portion of thier APUs will seem relatively lower in performance at the same price point.

AMD's proper course of action should have been to promote an APU-specific benchmark. Instead, it tried to change SYSmark to do something it doesn't do.

It was denied the right to twist the benchmark in its favor. Rather than coming up with the obvious solution of spinning off a new benchmark consortium to develop an APU-specific test, it started crying and ran to its room shouting, "I hate you! I hate you! I hate you!"

AMD is, really, behind a major 8-ball right here. It has, again, put all of its eggs into a rather hopeful basket, and come up with fewer than expected. At least this time, unlike with the Barcelona [xtremesystems.org] debacle, it isn't doing it while roller-skating blindfolded through a car-wash. That time it cost them their fabs. [eweek.com] They don't have much left to sell.

It's little wonder that it's not having an easy time of finding a new CEO [eetimes.com] .

Re:AMD quit because it was losing. (1)

Fujisawa Sensei (207127) | more than 3 years ago | (#36520436)

Looks like the rare talent that demands so much money, isn't needed at all.

Re:AMD quit because it was losing. (1)

tyrione (134248) | more than 3 years ago | (#36520852)

Sorry, but AMD is hard at work with LLVM/Clang support and OpenCL support into LLVM to make third parties applications leverage the most out of their solutions. It's a wise move.

Re:AMD quit because it was losing. (2)

hedwards (940851) | more than 3 years ago | (#36521202)

So then the answer is to stop innovating unless everybody else is doing the same thing?

I recently bought a laptop with a Llano chip in it, and I love it, the battery life is great, and the performance in terms of things that people normally do is great as well. This isn't about sour grapes, this is about a benchmark that's lost its way and isn't of particular use. If it's focusing so heavily in the way that it is, I'm not sure how I'd use the scores to figure out what processor to get.

Re:AMD quit because it was losing. (0)

Anonymous Coward | more than 3 years ago | (#36522412)

The problem is that SYSmark claims to be a full-system benchmark, not a CPU benchmark. Ignoring GPU performance in a day and age where the OS's interface, web browsers, document readers, image manipulation programs, video encoders/decoders, office suites, and so on all take advantage of the GPU is absurd. Would you trust SYSmark at all as a system benchmark if it ignored (for instance) hard drive performance? Intel is pushing very hard against the adoption of GPU benchmarking into SYSmark because its own graphics offerings are horrid and they do not want to rely on a discrete GPU from nVidia (or worse, AMD) to maintain their apparent performance leadership.

Re:AMD quit because it was losing. (0)

Anonymous Coward | more than 3 years ago | (#36522748)

Make their own benchmark? Some of the charts and Powerpoint displays they were taking around to shops to pimp the new APUs showed that Intel's CPUs tore them apart at the lower price points on everything but HD video playback. If they couldn't tweak their ad copy properly, we can't expect them to tweak an app.

Re:AMD quit because it was losing. (1)

arkhan_jg (618674) | more than 3 years ago | (#36524516)

Sysmark is supposed to measure overall systems performance, not just be a CPU benchmark.

"SYSmark® 2012 is the latest version of the premier performance metric that measures and compares PC performance based on real world applications."

Real world software uses the GPU; Aero, flash, Chrome, IE, Firefox, photoshop, just off the top of my head. Intel is moving into the combined CPU/GPU market too, though in a slightly different way, with sandy bridge. GPU acceleration of applications is here to stay, and ever more important to the overall performance benchmark of a system. Using old versions of software that don't test that at all makes sysmark a BAD TEST of real world performance, and AMD have been complaining for some time that disproportionate weight is given to the OCR and compression sections for overall score.

Nvidia and VIA have dropped their endorsement too, so sysmark is an intel only party now. Not exactly great for what is supposedly a neutral party system test.

I predict... (0)

Spad (470073) | more than 3 years ago | (#36520380)

Fanboy fight!

Will it be AMD, the plucky underdog who always does what's best by the consumer vs Intel, the evil conglomerate who will stop at nothing to screw you over for profit?

Or will it be Intel, who are trying their best in the face of constant criticism simply for being number one vs AMD, who are just bitter about the fact that they've been playing catch-up ever since the Core2s were released?

Let's watch!

Re:I predict... (2)

hedwards (940851) | more than 3 years ago | (#36521242)

Intel, you mean the same Intel that got caught paying integrators not to use AMD chips?

It's a pretty gross mis-characterization to suggest that criticism of the size of Intel is based upon size rather than how they got to be so big.

Re:I predict... (1)

Bill_the_Engineer (772575) | more than 3 years ago | (#36523468)

I think it's more of:

Intel, the evil conglomerate who will stop at nothing to screw you over for profit vs AMD, who are just bitter about the fact that they've been playing catch-up ever since the Core2s were released.

Well, they are both right and they are wrong (1)

Anonymous Coward | more than 3 years ago | (#36520592)

AMD is certainly correct in that most benchmarks these days are optimized for Intel cpus. That has been known for years. However, they are also wrong because Intel's SandyBridge architecture blows away AMD's phenom II architecture by 30% or better while also using considerably less power, in tests with the more cpu-neutral GCC.

As far as I can tell it basically comes down to main memory management. The Phenom II architecture can run a system call a lot faster than an Intel I7, but the moment data has to be pulled from main memory the whole thing comes grinding to a stop and Intel beats the crap out of AMD. SandyBridge also has much better bulk memory access for data sets exceeding available caches (I7 against Phenom II again, with the same DDR3 memory speeds).

Intel is able to charge a significant premium for their I7, $100 or more, verses AMD's high-end Phenom II's, and the difference pays for itself in power savings (for a server installation) in less than 2 years so it's a real problem for AMD. In previous years upgrading an AMD system was a lot cheaper due to its better socket compatibility but that isn't going to be the case for AMD's next generation. There are very few AM3+ mobos available at the moment and those that are available are wired for compatibility, meaning they can't make full use of the AM3 cpus that will be coming down the line. So at the moment there's no reason to stick with AMD.

In anycase, a lot of these benchmarks are basically designed to break AMD's cache architecture and yet still work within Intel's, which makes the numbers look even worse. But despite this AMD doesn't really have a leg to stand on right now. They had an executive shakeup and the executives who wanted AMD to compete on the high-end lost. That possibly spells the end for AMD's competitiveness because their lead in the integrated GPU arena is not all that large. Just today Intel introduced a 50-core (mini intel cpus basically) coprocessor to compete against nvidia's gpu architecture, and other things too. Intel can catch up without much effort in my view.

-Matt

AMD vs Intel (0)

Anonymous Coward | more than 3 years ago | (#36520944)

We all know that benchmarks are designed to sell certain products based on who pays the benchmark company more. In the defense of AMD, the chips seem to be a more perfected design than intel. For instance my i7 notebook core utilization would be all over the place with certain cores utilizing more processor load than others while my AMD quad core notebook is even across the board at all times.

Re:AMD vs Intel (1)

Ferzerp (83619) | more than 3 years ago | (#36521358)

Let me guess, your AMD notebook is even at 100% to all cores? ;)

But, see, (2)

Dremth (1440207) | more than 3 years ago | (#36522676)

I don't care about SYSmark telling me whether any given Intel CPU is better than any given AMD CPU or vice versa. What I really care about is finding out if the newly released Intel/AMD [insert arbitrary name here] CPU/GPU is truly better than the old Intel/AMD [insert arbitrary name here] CPU/GPU. By the time I get to the point of looking into concrete numbers from benchmarks, I've already decided whether I'm going to get an AMD or an Intel processor. The real problem that I have with all this benchmarking crap is why these manufacturers don't just provide us with coherent naming schemes for their CPU's (and GPU's too) so we as customers can fully understand the product they're trying to sell us.

Intel is embracing LLVM for SPMD (1)

tyrione (134248) | more than 3 years ago | (#36523830)

http://ispc.github.com/ [github.com]

ispc is a new compiler for "single program, multiple data" (SPMD) programs. Under the SPMD model, the programmer writes a program that mostly appears to be a regular serial program, though the execution model is actually that a number of program instances execute in parallel on the hardware. (See a more detailed example that illustrates this concept.) ispc compiles a C-based SPMD programming language to run on the SIMD units of CPUs; it frequently provides a a 3x or more speedup on CPUs with 4-wide SSE units, without any of the difficulty of writing intrinsics code.

There were a few principles and goals behind the design of ispc:

  • To build a small C-like language that would deliver excellent performance to performance-oriented programmers who want to run SPMD programs on the CPU.
  • To privide a thin abstraction layer between the programmer and the hardware—in particular, to have an execution and data model where the programmer can cleanly reason about the mapping of their source program to compiled assembly language and the underlying hardware.
  • To make it possible to harness the computational power of the SIMD vector units without the extremely low-programmer-productivity activity of directly writing intrinsics.
  • To explore opportunities from close coupling between C/C++ application code and SPMD ispc code running on the same processor—to have lightweight funcion calls betwen the two languages, to share data directly via pointers without copying or reformating, and so forth.

ispc is an open source compiler with a BSD license. It uses the remarkable LLVM Compiler Infrastructure for back-end code generation and optimization and is hosted on github. It supports Windows, Mac, and Linux, with both x86 and x86-64 targets. It currently supports the SSE2 and SSE4 instruction sets, though support for AVX should be available soon.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?