OPTIMIZER WANTED FOR A SIX CORE AMD PROCESSOR

If the application compiled by Intel's compiler this old article can explain backlog AMD
http://www.agner.org/optimize/blog/read.php?i=49

Naughty Intel? Hardly. This Agner guy asserts :

Where's he been? Or these clue-less developers and programmers for that matter. I have a rather earlier version of the Intel C++ compiler from when they first started doing this, previous millennium, which ( like now ) has phrases like "for the full range of Intel® processor-based platforms" all over the blurb. You'd have to open the packet with a blindfold on and throw out the all the documents inside before you took it off to miss the 'for Intel products' lean on the product. I suppose he is expecting Intel to validate and accommodate behaviours on hardware they don't design? I suspect if they had they'd still be in court - the complaint would morph to track that. Maybe AMD should reverse engineer the compiler/libraries to source code and put out their own version ..... whoops they've already done that .... using an Intel Fortran compiler no less. AMD are simply paying the price for being derivative and not imaginative. Do AMD stockholders believe this type of behaviour will preserve company worth until 2015? 2020?

This smacks of yacht clubs and the America's Cup. If you can't win out on the waves, do it in court instead.

Cheers, Mike.

The way intel implemented their checks made it clear that the objective was not to guard against 3rd party processors claiming capabilities they didn't have but to nerf AMD performance.

Had their intent been what you describe the implementation would have been something like this:

if (CPU.IsIntel() && CPU.ClaimsSSESupport())
  GenerateSSECode();
else GenerateX87Code();

What Intel actually wrote (and could be trivially confirmed by changing the string checked in CPU.IsAMD()) was something like this:

if (CPU.IsAmd())
  GenerateX87Code();
else if (CPU.ClaimsSSESupport())
  GenerateSSECode();
else Generate X87Code();

The IsAMD function was implemented similar to this:

bool IsAMD()
{
   return CPU.VendorName == "AuthenticAMD";
}

Editing the string in the executable to eg "AuthenticAMC" would result in the compiler trusting the CPU's claim of SSE support.

tl;dr: any cpu by an unknown manufacturer was assumed to be giving correct information about if it supported SSE which would leave them wide open for lawyer trolling if some random vendors CPU didn't do what it claimed it could. AMD cpu's were explicitly not checked for SSE support. Besides AMD and Via there's at least one other company that sells x86 CPUs. Even more so than VIA there was no need for an explicit nerf because the company targeted low power/low performance embedded systems; an area that Intel's only recently expressed any interest in.

You're right, and I get that point. What I clearly don't get is an economy/legal system which requires one company to give any friendly consideration or 'intent' to shareholders of another company. Thus I don't follow the purpose of a commercial context/environment with such a high legislative risk in this aspect. But it's neither my shares nor my country .....

Anyhows : the best C++ compiler I've found for language correctness, learning and features is Greg Comeau's. He converts source to an intermediate code and then invokes a chosen C backend/port ( of which there is a decent spread to choose from ) where further optimisation ( if any ) is done.

Cheers, Mike.

What can I say? That sometimes a distant opinion is useful .... :-)

Cheers, Mike.