"I doubt that they were a part of that firefight. However, when I did come up on the scene, there was an RPG as well as AK-47s there. … You just don’t walk around with an RPG in Iraq, especially three blocks away from a firefight. …"
"And where the soldier said [in the video], “Well, you shouldn’t take your kids to battle.” Well in all actuality, we brought the battle to your kids. There’s no front lines here. This is urban combat and we’re taking the war to children and women and innocents."
and "I don’t think that [the] big picture is whether or not [the Iraqis who were killed] had weapons. I think that the bigger picture is what are we doing there? We’ve been there for so long now and it seems like nothing is being accomplished whatsoever, except for we’re making more people hate us."
I admire this guy. He seems to take responsibility vs ducking it or explaining it away.
This is about the specifics of what happened here. It's about whether or not Americans in Iraq are living up to a high enough standard of ethical warfare in their day-to-day.
These conversations decay into "big picture" when people get tired. It's not the point though. The point of rules of war, engagement or otherwise is 'while there is war..'
Bottom line: it's a business decision. Code generated by the Intel compiler "works" on AMD chips, although it may not be optimal. For Intel to support the optimal codepaths on AMD chips would require a substantial amount of research. I don't think they're intentionally crippling AMD chips; just declining to invest the effort to support them optimally.
Nope. Checking the vendor string to determine capabilities when the CPUID instruction already has flags for different capabilities is unjustifiable. When a CPU claims SSE2 support, the compiler should enable SSE2, regardless of the vendor string. If AMD's implementation of SSE2 is buggy, that's their problem, and Intel should have no trouble making it into a PR win.
This is really no better than printer manufacturers putting chips into their cartridges so that they can use the DMCA to prevent third parties from refilling or making compatible cartridges.
if( CPUIDbits & SSE1_CAPABLE ) {enable SSE1}
if( CPUIDbits & SSE2_CAPABLE ) {enable SSE2}
if( CPU is Athlon 64 ) {disable some SSE2 functions}
if( CPU is Pentium-M ) {disable all SSE2 functions}
[etc]
Intel's way of doing it:
if( CPU is Pentium 3 ) {enable SSE1}
if( CPU is Pentium 4 ) {enable SSE1/SSE2}
if( CPU is Core 2 ) {enable SSE1/SSE2/SSE3/SSSE3}
[etc]
Practically all sane applications do things the first way; a couple do things the second way. Anyone doing things the third way is just asking for trouble both in terms of future compatibility and resilience to unexpected situations. For example, some VMs disable certain instruction sets, which would result in SIGILLs when using the last method.
If you read the article, it looks like Intel's CPU-type dispatcher actually does it the second way (sorta; it appears to only check Intel CPU family IDs), but at the bottom of that list there's a big "if(CPU string is not "GenuineIntel") { disable everything and use crappy fallback code path }".
In addition to just the question of what path is optimal, they'd have to keep track of all the bugs in AMD's, Cyrix's, Transmeta's, and other implementations which aren't the same as the bugs on Intel x86 chips. Falling back to a subset of the architecture that is more likely to produce the right behavior is the sane thing to do.
Have you actually looked at the details of the AMD errata? I scanned through quite a few, and none of them looked at all relevant to whether a compiler should enable certain SIMD extensions. Also, for the bugs that do need workarounds, the fix is typically in the BIOS or kernel, not the compiler.
Regardless of whatever bugs may or may not exist in AMD's chips, it is anti-competitive for Intel's compiler to refuse to enable SSEx extensions on AMD processors that claim compatibility, when the user has requested SSEx instructions to be used, unless Intel has specific knowledge that AMD has never produced a sufficiently bug-free implementation of SSEx.
I was an AMD intern responsible for writing the software that tests for those bugs (these are my views and not those of AMD).
You're entirely on the mark--the bugs are generally not SSE-related, and are typically worked around at the BIOS level. In addition, these bugs aren't "bugs" in the software sense, but more in the engineering sense; running some specific set of 10 million instructions on 3% of the chips while holding at exactly 28 deg C flips a byte in the L2 cache or something. Not something that's easily reproducible.
OP is also right insofar as there would probably be a few gotchas with weird software that would make some engineer somewhere scratch his head because his for loop returns too quickly every third Monday. That doesn't mean that it's fair for Intel to disable SSEx, but it is probably an accurate observation--AMD and Intel have different bugs.
Clearly the cost of checking that AMD's errata is accurate is greater than the cost of having icc produce suboptimal code for AMD processors.
The results of incorrect code generation on any given platform would more likely be people ceasing to use Intel's compiler, and that's not something they want to deal with, I'm sure. As to it being anti-competitive, there's nothing stopping AMD from making their own compiler that produces more optimal code and trusts everyone's processors to work as advertised. If it produced better results, people would likely use it.
As to it being anti-competitive, there's nothing stopping AMD from making their own compiler that produces more optimal code and trusts everyone's processors to work as advertised.
Sure there is: time and money. Huge companies that are near-monopolies have enormous reservoirs of both in comparison to the competition.
What Intel is accused of doing is considered anti-competitive because they are not actually improving their product. Instead, they are using their stronger market position to degrade the value of another company's product. This harms the overall market, and particularly the consumers. Hence, it's illegal.
The objection in the article is not what the compiler does, but how it's advertised. If it was claimed to be an optimizing compiler "for Intel CPUs only", then there would be no problem.
(Of course, if they did that, would people use it?)
"I doubt that they were a part of that firefight. However, when I did come up on the scene, there was an RPG as well as AK-47s there. … You just don’t walk around with an RPG in Iraq, especially three blocks away from a firefight. …"