anand's jaguar article

[NTMBK]

@NBTMK
I just don't get how the hell you can argue it's a cripple amd function.

I'm suprised it's that large a deficit actually - but it's not a bloody cripple AMD function.


And the usual AMD fanbois arguments are straws at best.

The thing is, if it was intended to be a feature to extract maximum performance out as opposed to lock out their competitors then they would have implemented it differently. The CPUID instruction emits a bitmask which very clearly lists each individual capability of the processor- whether it has SSE4, whether it has SSE3, etc etc. This is the most straightforward and reliably portable way of determining what code will run on that processor, and as such the most straightforward way to implement the logic for a dispatcher. The same logic would determine what codepath to execute for AMD, Intel or VIA chips- and this is very simple logic, the kind of thing I could write in an afternoon.

Instead, Intel implemented a solution based upon the name of the chip. This not only prevents optimal performance on competitor's chips, but it also limits performance on future chips which did not exist when the binary was compiled. A binary compiled in 2004 will not know what is the optimal code path for Haswell, for instance.

Take a look at the "Common math programs are affected" section on the Agner Fog blog. When the Via Nano fakes being a Pentium 4, the same Mathcad job runs more than twice as fast as it does when pretending to be a "Intel nonexisting fam. 7". It's pretty obvious that there is no good technical reason to go with this solution, other than to shaft their competitors.

Also, I really don't appreciate you calling me a fanboy.

Intel is not pushing ICC as a de-facto IDE solution or compiler.
Therefor market sentiment should regulate this problem by itself.

Intel Parallel Studio is heavily marketed as deeply integrated into Visual Studio, and works very well in that respect. You get a whole suite of (very useful) Intel tools linked into your IDE.

A software company would never make the release binaries in ICC - if they want to reach all, done.

Trust me, software companies make the release binaries with the ICC.

I somehow don't expect VS to compile optimally to windows vs unix either.
(Even tho that's a vague comparison).

Microsoft's compiler doesn't support Unix at all, so I'm not really sure what you're saying. :S

Come on - is that best argument you have as a fan?
"ICC is only good Intel! - that's cheating!".

If your market base is cross-hardware wise - hopefully your smart enough not to compile with ICC.

Now that the issue has been raised publicly and most people are aware of it? Sure, they probably won't. But what if your company uses Intel workstations for development? You're rushing towards a deadline, looking for any way to hit a critical performance requirement, and suddenly "hey look, if I rebuild it with the Intel compiler I get an extra 15%!" You try it out on a few other Intel machines, it looks good, you ship it. Yes, you should really be benchmarking across all sorts of different architectures and manufacturers, but do you really think everyone is that stringent, especially when there is a deadline coming up?

 

[NTMBK]

Still? Are you talking about the test with software anno 2005?

So what about the other compilers?

Take a look at http://www.agner.org/optimize/blog/read.php?i=126#127 - the same dispatch mechanism exists in the Intel Compiler 12.

I am not familiar with SpecInt's codebase, but it is possible that it uses handwritten intrinsics/ASM - this would not be affected by the dispatch mechanism, as that only affects the autovectorized code generated by the compiler

 

[NTMBK]

VIA Nano X2 (2C -2T) / VIA QuadCore (4C -4T) vs. Intel Atom D525 (2C -4T) on the SPECfp2000 /GNU (GCC) Compiler/ and SPECint2000 /Intel (ICC) Compiler/

source: http://www.via.com.tw/en/products/processors/nanoX2/whitepaper.jsp
source: http://www.via.com.tw/en/downloads/whitepapers/processors/NanoX2_whitepaper_201107.pdf

That's using two different processors, so its not really relevant I'm afraid. The more interesting situation is using the CPUID faking mechanism of the Via chips to pretend to be Intel chips with the same instruction set support, and seeing the effect that has on ICC generated code.

 

[Olikan]

Pretty sure that Jaguar's scalar and packed ADD are single cycle while floating points one are 3 cycles which I believe is identical to Bobcat.

yes, it's 3 cycles... typo
still, kinda bad

 

[wlee15]

yes, it's 3 cycles... typo
still, kinda bad

That's actually quite good for x86 processors. In comparison Bulldozer takes 5-6 cycles while previous AMD architectures took 4 cycles, and it matches the Intel cpus (except for P4 and current gen Atom which are much slower). I think the only x86 processor that have a lower latency are the Via ones.

 

[CTho9305]

yes, it's 3 cycles... typo
still, kinda bad

Compared to what? As far as I can tell, it (ADDPS?) is also 3 cycles on recent Intel designs, or 4 cycles on AMD's family 10h and 12h and 6 cycles on AMD's more recent "high-performance" designs. Intel's cores clock higher, but as far as I can tell, you could fit three 28nm Jaguar cores on one Intel 22nm Ivy Bridge core, so unless you live and die by nanoseconds per sequential scalar add (isn't most float code usually latency-tolerant anyway?), Jaguar seems like a pretty reasonable way to do single-precision FP adds.

I can understand AMD whining, as I can understand the complaining from developers that want the fastest code running in every x86 processor out there, and I can see the deleterious effects on the market if ICC were to become a de facto standard compiler to the most popular programs.

Still, I tend to side with Intel on this one.

The ICC is just one more advantage that Intel has on the market, like the bigger R&D engine, like the better process, like the clout on the OEMs... Intel puts money and resources there, I can understand the moral (and legal) case for the ICC to yield better results with Intel processors.

I guess this is one of the cases in which what is good for the company isn't necessarily good for the consumers.

It just seems shady to me when Intel suggests using feature flags to select code paths, but in their own compiler they go out of their way to add an extra check.

 

[galego]

I can understand AMD whining, as I can understand the complaining from developers that want the fastest code running in every x86 processor out there, and I can see the deleterious effects on the market if ICC were to become a de facto standard compiler to the most popular programs.

Still, I tend to side with Intel on this one.

The ICC is just one more advantage that Intel has on the market, like the bigger R&D engine, like the better process, like the clout on the OEMs... Intel puts money and resources there, I can understand the moral (and legal) case for the ICC to yield better results with Intel processors.

I guess this is one of the cases in which what is good for the company isn't necessarily good for the consumers.

Nobody worried about Intel having one advantage with ICC deliberately crippling AMD chips, but about Intel hiding this fact to programmers, OEMs, consumers... and denying it latter (when some scholars began to denounce ICC) until the FTC research and final settlement obligated Intel to put the disclaimer.

When I see CB and similar benchmarks of jaguar I know that AMD has a clear winner here because the benchmark is cheating.

Seeing other benchmarks I got that jaguar has the same ST performance than sandy @ same clock.

Some people here continue missing the main point about ICC and Intel lies. Therefore I have emphasized in bold-italic font the two important words.

 

[mrmt]

It just seems shady to me when Intel suggests using feature flags to select code paths, but in their own compiler they go out of their way to add an extra check.

It is shady, but that's to be expected, no? I wouldn't expect a so-called MS Office for Linux to perform better than MS Office for Windows as I wouldn't trust a MSVC Linux benchmark (if that was possible). In the same way, if you are aiming for a neutral benchmark, you should not use a vendor compiler to compile your benchmark software. If you are compiling your software with an Intel compiler, you shouldn't expect your code to run in AMD or VIA processors with the same speed.

Me, as a consumer or a developer, I would prefer to have the best compiler available for free and without any compatibility hassle, but Intel is no "open sauce" foundation, it exists for the sake of money, and ICC only exists for the sake of improving Intel CPU performance in order to allow Intel to make more money.

I think it would be wishful thinking to expect Intel to spend millions of dollars and HH in improving the compiler and then expecting AMD or VIA to eat a free lunch here. Intel is forcing these two companies to cough up some cash to invest in compiler resources (AMD is developing some libraries) and to give an edge for their processors. I simply cannot fathom the other possibility, Intel investing millions in a compiler that *also* improved the performance of AMD processors. How can you justify that to your shareholders?

 

[crashtech]

To produce a compiler that deliberately fails to expose functionality of certain CPUs is expected? Maybe if it was advertised as such.

 

[Atreidin]

What about Intel customers who bought their compilers but use them with AMD hardware? Maybe they are a researcher who got some grant money and heard that Intel's compiler is great so they paid for it, and they bought/inherited an AMD cluster. They are still Intel customers and they are get screwed with an inferior, crippled product.

 

[mrmt]

What about Intel customers who bought their compilers but use them with AMD hardware? Maybe they are a researcher who got some grant money and heard that Intel's compiler is great so they paid for it, and they bought/inherited an AMD cluster. They are still Intel customers and they are get screwed with an inferior, crippled product.

I wouldn't use an Intel compiler with an AMD processor. If I were so keen on using ICC, I would also use an Intel processor. If I were keen on using an AMD processor, I would use anything but ICC.

 

[Idontcare]

What about Intel customers who bought their compilers but use them with AMD hardware? Maybe they are a researcher who got some grant money and heard that Intel's compiler is great so they paid for it, and they bought/inherited an AMD cluster. They are still Intel customers and they are get screwed with an inferior, crippled product.

People getting screwed over for buying something that in the end turned out to be an unwise decision is as old as commerce itself.

That is why due diligence is required, unless one wishes to be a fool and be quickly parted from their money.

Ask around and see how many AM3 mobo owners were pleased to find out they weren't going to be able to put bulldozer or piledriver in their mobo...the game you are fretting over is not a novel invention of Intel.

 

[RoarTiger]

That is why due diligence is required, unless one wishes to be a fool and be quickly parted from their money.

How exactly do you propose people exercise this due diligence when the information is not made available to them? The compiler issue was known for some time yet was rarely mentioned except much later when it was a legal issue. Then it was generally only covered as a settlement issue without technical discussion. Even today, years later there has been no real follow up technical reporting on the issue to be found on popular tech sites like Anand. How exactly are consumers supposed to reliably find this information when it is only covered on wordpress blog type sites at best and major sites ignore it.

This is not just a compiler issue or even a computing issue. It is unreasonable to expect manufacturers to disclose unflattering information about hardware and other limtiations of their products since it would negatively impact sales. When the supposed news organizations fail to cover said information for fear of losing advertising revenue or other relations, exactly what is the consumer supposed to do? As consumers we need news sites to actually report the information that the manufacturers are unwilling to publicize and when this clearly doesnt happen as in the case of Intel's compiler, it is hard to use due diligence as any argument at all.

 

[Phynaz]

What about Intel customers who bought their compilers but use them with AMD hardware? Maybe they are a researcher who got some grant money and heard that Intel's compiler is great so they paid for it, and they bought/inherited an AMD cluster. They are still Intel customers and they are get screwed with an inferior, crippled product.

Except the Intel compiler still produces the best code you can get for AMD CPU's.

 

[mrmt]

How exactly do you propose people exercise this due diligence when the information is not made available to them?

The information *is* available. This is exactly the crux of the FTC settlement regarding ICC. In the settlement Intel must put a big disclaimer in their compilers that if you use it with a non-Intel processor, you won't get all the compiler can do for you.

Most people think that Intel *has* to allow AMD and VIA to get their free lunch. You can see clearly this in Agner's text here:

http://www.agner.org/optimize/blog/read.php?i=25

Where he argues that the future x86 standards should be decided by an inter-company commitee, much like in the Linux world. x86 isn't open sauce, x86 is a proprietary standard, much like Power or DEC are/were. I don't think Intel ought to do give AMD or VIA a free lunch, and I don't think it should.

Also I don't think that Intel - or any other organization for that matter - will always be fair with their customer or their competitors or at least deserves the supposition it will. If you have this expectation, think again, you'll get screwed rather sooner than later.

 

[RoarTiger]

The information *is* available. This is exactly the crux of the FTC settlement regarding ICC. In the settlement Intel must put a big disclaimer in their compilers that if you use it with a non-Intel processor, you won't get all the compiler can do for you.

Available and readily available are wildly different. Agner is not exactly a popular hub for internet tech news like Anand. As for the settlement, Intel has to disclose to users of their compiler, not the general public. I think the rest of your post agrees with my assertion that the manufacturers are not going to disclose this themselves and we need better reporting for consumers and not just isolated websites like Agner with limited page hits. How many times have you ever seen a notation after a benchmark saying that software favors one processor manufacturer over another. I have seen those types of comments in GPU articles regarding specific games but rarely about the CPU sythetics unless it is just single versus multi comments. Where is the asterisk or footnotes on Anand CPU bench for example? Did I miss the informative sticky thread in the CPU forum? Wouldnt that be helpful consumer information on such a popular resource?

 

[Khato]

Since many are enjoying beating up on Intel's compiler for only enabling features that it can guarantee proper functionality for... where exactly is AMD's compiler?

Is Intel playing a somewhat annoying game here? Sure. Do I blame them for it? Not really. They make no claim of optimization for non-Intel processors... and as such it makes no sense to buy AMD platforms in order to validate that optimized code performs as expected on them. Yes, technically it should produce exactly the same result as on the Intel platform, but if it doesn't then does anyone doubt that the lawyers could find a way to hold Intel liable? (Why go after AMD when Intel's the one with money?)

 

[crashtech]

The rationalization of unethical behavior never ceases to unnerve me. It is clear that Intel can and does do what they do with their compiler, but to defend it seems so odd, perhaps it is just to be the devil's advocate?

 

[Khato]

perhaps it is just to be the devil's advocate?

I certainly do enjoy taking that role when I see the same arguments ad naseum. How many times has this discussion regarding ICC come up? Yet it just keeps coming back, even though the FTC is apparently fine with the current state of it.

 

[mrmt]

Available and readily available are wildly different. Agner is not exactly a popular hub for internet tech news like Anand. As for the settlement, Intel has to disclose to users of their compiler, not the general public.

That's to be expected, no? This is a non-issue if you don't use the ICC, and use the ICC to compile your software is just one more business decisions. What if it is worth to my public to please 80%+ of the market while giving the other 20%- worse performance (but still better than the other compilers)?

How many times have you ever seen a notation after a benchmark saying that software favors one processor manufacturer over another. I have seen those types of comments in GPU articles regarding specific games but rarely about the CPU sythetics unless it is just single versus multi comments. Where is the asterisk or footnotes on Anand CPU bench for example? Did I miss the informative sticky thread in the CPU forum? Wouldnt that be helpful consumer information on such a popular resource?

What benchmarks softwares are compiled with ICC?

 

[RoarTiger]

What benchmarks softwares are compiled with ICC?

Cinebench and Passmark for starters. Again this is another place where the information is not readily available and I as the user am expected to visit every benchmark software homepage for documentation which may or may not be present when the professional review sites who should be aware of this information could disclose it for me.

 

[Exophase]

Take a look at http://www.agner.org/optimize/blog/read.php?i=126#127 - the same dispatch mechanism exists in the Intel Compiler 12.

I am not familiar with SpecInt's codebase, but it is possible that it uses handwritten intrinsics/ASM - this would not be affected by the dispatch mechanism, as that only affects the autovectorized code generated by the compiler

SPECInt doesn't use intrinsics or ASM. The simpler explanation is that it's compiled with a fixed arch target instead of the dispatcher. In fact, I know for sure that Intel's submitted SPEC scores, both for Intel and AMD processors, are compiled this way. So the so-called "cripple AMD" functionality wouldn't apply to compiler generated code here.

The dispatch issue is entirely instruction set oriented. There are no separate code paths for different Intel uarchs, just instruction sets. The problem isn't that there are code paths optimized for Intel processors, but there are code paths using instruction sets that are available on non-Intel processors but aren't getting selected on these processors. And that's because the heuristics seem to use CPUID vendor ID + processor info instead of CPUID feature bits, despite the latter being there for exactly that reason. So they identify instruction set capability based on CPU uarch instead of what instruction sets the CPU identifies as. This also means Intel has been careful in choosing new processor info numbers to make sure new CPUs will still get the same dispatch, and IIRC this has led to some weird numbers.

There could be some argument that just because an instruction set is there doesn't mean it's the fastest code path - like how AVX might not be the fastest on Bulldozer, but I doubt that's motivating Intel's selection. The fair way to do things would be to use the vendor ID + processor info for Intel processors if that makes more sense for them, then fall back on the feature bits for non-Intel processors.

The funny thing is that some Intel libraries actually do use fair heuristics, so it's not as if they haven't put that work in. They could pretty easily extend this to all of their code. I'd love to know what internal politics would cause this to happen differently on a project by project basis.

I have a hard time buying the claim that Intel is avoiding liability for testing the compiler output on non-Intel processors. When has a compiler ever been deemed liable for compatibility issues? Maybe if Intel relied on something that was undefined by the architecture (and perhaps that they knew other implementers weren't following) there'd be an argument, but I doubt they'd do this because there's precious little in the ISA extensions that has interesting undefined behavior. That and it's risky to them in case their implementation changes later - these things tend to be undefined for a reason. Otherwise, if we're talking relying on defined behavior then it's on AMD or whoever else has a cross-license x86 agreement to get their implementation right before they complain.

 

[Vesku]

The foundations of the capitalist economic system have concepts like regulating monopolies, punishing price fixing, and similar for a reason. It's not meant to be anarchy. Yes they did A and did B, doesn't mean the consumer should just shrug and bear it. I certainly didn't like the RAM price fixing during the DDR era. If regulators were completely impotent and consumers completely blase would we have had the opportunity to pick up 2x4GB DDR3 kits for $40 recently?

There were people denying Intel was rigging ICC for quite some time despite solid evidence, pretty sure at least some of those people didn't have direct financial interest in Intel. It's an odd world out there.

Now after having said all that, people still have to deal with the environment they are in rather than the one they would like and so anyone seriously investing in hardware should be looking for ways to test out what it will do for them before they exchange currency for it. Your favorite review site not have the info you need: send an email or comment requesting they test it, or ask on forums for input from people who have the equipment, or even join (visit) a local user group.

 

[blastingcap]

with something like SC2, you mean something which is written with very poor threading/load balancing in mind i assume?

Why would a developer studio who develop software for xbox/ps4 and maybe pc write a game so it uses 1/8th of the available power?

It's hard to utilize multiple cores. Programming for 1-2 threads isn't as hard as programming for more. In some cases, it may be impossible to evenly or even quasi-evenly spread the work around to eight cores.

That doesn't excuse companies like CA from trying harder, though, as Shogun 2 was apparently more or less single threaded which is just ridiculous.

 

[galego]

Available and readily available are wildly different. Agner is not exactly a popular hub for internet tech news like Anand. As for the settlement, Intel has to disclose to users of their compiler, not the general public. I think the rest of your post agrees with my assertion that the manufacturers are not going to disclose this themselves and we need better reporting for consumers and not just isolated websites like Agner with limited page hits. How many times have you ever seen a notation after a benchmark saying that software favors one processor manufacturer over another. I have seen those types of comments in GPU articles regarding specific games but rarely about the CPU sythetics unless it is just single versus multi comments. Where is the asterisk or footnotes on Anand CPU bench for example? Did I miss the informative sticky thread in the CPU forum? Wouldnt that be helpful consumer information on such a popular resource?

When someone offers me some AMD vs Intel comparison based in biased synthetic benchmarks such as Sysmark, Cinebench, Passmark... I just say "No thanks", because I know the issue, but average Joe would benefit from your idea of a footnote disclaimer: "Sysmark and other benchmarks used in this review are biased pro Intel and don't represent real world performance".