AMD presents "The Bulldozer Blog"

[flippin_waffles]

I know he's under NDA. I just want a release date. Surely by now AMD must know what their schedule is! I'm not mad at JF as a person, I've never met the man; but I am upset with the company he works for. I've said in a few other posts, just throw us a bone, even a small one.

Well if its a release date you're after, you might as well give up right now. There is no chance of that happening, period. And since this is about server products, you're barking up the wrong tree anyway. It wouldn't do you any good to know Bulldozer release dates for Orochi products anyway.
I'm sure if you harassed, I forget who?, I'm sure you'd get the same response. Other than the ever popular, "as soon as we get the screwdrivers and pliers out to 'fine tune' this sucker. Its no good the way it is", that seems to be the standard response from the blue team

[richierich]

freeloader, does Intel have a representative that leaks any information?

We are all dying to see performance #s and whatnot, but we have to be patient.

[terrace215]

Other than the ever popular, "as soon as we get the screwdrivers and pliers out to 'fine tune' this sucker. Its no good the way it is", that seems to be the standard response from the blue team

Surely it isn't that difficult to understand the increased complexity of having a second processor on die, constantly regulating which features of the larger processor are active, allocating power and frequency among these features, etc? And that this complexity results in a greater percentage of performance being determined by the "program" this second processor follows?

[-Boris-]

If he can't share any information that customers are asking for, then why bother posting anything at all?

They have already released information on bulldozer, not all there is, but as much as they feel they can share at the moment. JF-AMD is here to clear things up, if you haven't noticed people seem to be incapable of reading the information and reading it right, so he is in fact needed.

It could hurt business to create a hype or releasing performance numbers. So for now they are only releasing basic architecture information.

[informal]

I bet JF still gets questions about the 9th core in Bulldozer in his mails.He is needed on this forum,just like Francois is.

[flippin_waffles]

Surely it isn't that difficult to understand the increased complexity of having a second processor on die, constantly regulating which features of the larger processor are active, allocating power and frequency among these features, etc? And that this complexity results in a greater percentage of performance being determined by the "program" this second processor follows?

Nope not hard to understand at all. On the other hand, its just as likely that the performance isn't what they expected and are now turning the screws to see if they can muster up some performance gains, now that compiler tricks and benchmarketing are being scrutinized by the FTC, and about every other watchdog on the face of the planet. . Welcome to the world of competition intel! I know its been a couple decades for ya lol

[Calmatory]

now that compiler tricks and benchmarketing are being scrutinized by the FTC

Nope. FTC hasn't changed a thing, Intel will continue to play with the tricks on their compiler. The rules have been changed a bit, they just play with the new rules and the same garbage continues.

But once again open source software saves us(non-windows users at least) all.

[Chumbucket843]

Nope not hard to understand at all. On the other hand, its just as likely that the performance isn't what they expected and are now turning the screws to see if they can muster up some performance gains, now that compiler tricks and benchmarketing are being scrutinized by the FTC, and about every other watchdog on the face of the planet. . Welcome to the world of competition intel! I know its been a couple decades for ya lol

you really are making a mountain out of a molehill with intel's compiler. you havent even used binaries compiled with it either.

intel doesnt cheat to beat amd. they just do it. you can look at anything from industry standard benchmarks to WCG/BOINC projects.

[nn_step]

you really are making a mountain out of a molehill with intel's compiler. you havent even used binaries compiled with it either.

intel doesnt cheat to beat amd. they just do it. you can look at anything from industry standard benchmarks to WCG/BOINC projects.

cheat certainly isn't a term I'd use for Intel's compiler; lazy and anti-optimizing however seems to be a far better description.

It generates x87 instructions in long mode for crying out loud. Only 2 types of people make that sort of mistake; idiots and used car salesmen.

[Chumbucket843]

i'm with you on that. x87 is truly an abomination of an instruction set, especially when there is an alternative that is supported on the same processor.

using icc for a benchmark i would consider cheating. other than that it's fair game.

[blindbox]

freeloader, does Intel have a representative that leaks any information?

We are all dying to see performance #s and whatnot, but we have to be patient.

He's neither buying from Intel then

[freeloader]

He's neither buying from Intel then

VIA it is then

[tifosi]

you really are making a mountain out of a molehill with intel's compiler. you havent even used binaries compiled with it either.

intel doesnt cheat to beat amd. they just do it. you can look at anything from industry standard benchmarks to WCG/BOINC projects.

If you refer to gaining more than 40% in performance when you rename merely a cpu vendor id... well, then yes, people are indeed making mountain out of a molehill...

http://www.osnews.com/story/22683/In...from_Compiler_

[nn_step]

If you refer to gaining more than 40% in performance when you rename merely a cpu vendor id... well, then yes, people are indeed making mountain out of a molehill...

http://www.osnews.com/story/22683/In...from_Compiler_

actually if you look closer to Intel's implementation, you quickly realize that they assume any non-Intel processor must be a 80486SL, even when generating 64bit code. [Using only 8 of the 16 in Long mode]
Not to mention, skipping several common optimizations [that all other compilers do for all processor anyways]

[terrace215]

On the other hand, its just as likely that the performance isn't what they expected and are now turning the screws to see if they can muster up some performance gains

The comments (scattered about this forum) from the few folks that have samples and/or information suggest... otherwise.

[savantu]

If you refer to gaining more than 40% in performance when you rename merely a cpu vendor id... well, then yes, people are indeed making mountain out of a molehill...

http://www.osnews.com/story/22683/In...from_Compiler_

Intel is under no obligation whatsoever to support AMD, much less produce optimal code for it. That takes effort and intimate knowledge about the caveats and errata on AMD cpus. AMD isn't willing to share that, nor support financially the development.

If you don't like Intel's compiler ( which has something like 4% market share ) , you're free to use from a plethora of others : MS, Pathscale, GCC, Sun Studio,etc.
The whole compiler thing is BS stemming from the socio-political views of those in power, liberal neo-socialists ) both US/EU, who have grand ideas of benevolence from the strong to the weak and if they don't do it willfully they will be forced. Horse manure.

[nn_step]

Intel is under no obligation whatsoever to support AMD, much less produce optimal code for it. That takes effort and intimate knowledge about the caveats and errata on AMD cpus. AMD isn't willing to share that, nor support financially the development.

If you don't like Intel's compiler ( which has something like 4% market share ) , you're free to use from a plethora of others : MS, Pathscale, GCC, Sun Studio,etc.
The whole compiler thing is BS stemming from the socio-political views of those in power, liberal neo-socialists ) both US/EU, who have grand ideas of benevolence from the strong to the weak and if they don't do it willfully they will be forced. Horse manure.

Umm no, producing optimal code rarely requires knowledge of the errata of CPUs. [If you have errata in relation to such common cases, why even bother selling the chip?]

High level optimizations make several orders of magnitude performance difference regardless of the underlying architecture.

Now yes it is easy to say Vector optimizations are implementation specific; however Vendor ID doesn't matter remotely as much as instructions supported. Hence just throw a CPUID opcode and check the feature flags and optimize all hardware implementations that utilize those given instructions. [Swings in instruction latency aren't as important in OoO hardware, so why optimize for it???]

As for why the Intel compiler is only 4% of the of the market; that is because it has a tendency to suffer from Splot [edge cases that cause compilers to hang indefinitely or crash] even on some trivial code.

[tifosi]

Intel is under no obligation whatsoever to support AMD, much less produce optimal code for it. That takes effort and intimate knowledge about the caveats and errata on AMD cpus. AMD isn't willing to share that, nor support financially the development.

If you don't like Intel's compiler ( which has something like 4% market share ) , you're free to use from a plethora of others : MS, Pathscale, GCC, Sun Studio,etc.
The whole compiler thing is BS stemming from the socio-political views of those in power, liberal neo-socialists ) both US/EU, who have grand ideas of benevolence from the strong to the weak and if they don't do it willfully they will be forced. Horse manure.

I agree one hundred percent with the fact that Intel is under no obligation to support AMD or any other chip manufacturer for that matter. Given that i was planning to start something myself, i understand completely that it would suck balls for Intel to have to support AMD...

Now, please give a few minutes to read something rather important. Optimization is not the same as executing/ running the code at all. Optimization is when you tailor a certain code to work more efficiently on a given piece of hardware/ equipment. FTC has noted certain descrepancies in the compilers from Intel in that they do not run the (instruction sets) code at all on anything else than "Genuine Intel". Now this is what put Intel in soup. What Intel was doing was not using instruction sets such as SSE2, SSE 3 (and now AVX in their latest beta compilers) and blah blah supported by VIA and AMD processors... the compilers simply ran the code as if there was no support at all.

To put it simply, the current scenario is:

If Genuine Intel"{
AVX{}
}
else{}...

What is present in Intel's settlement with AMD is, "Intel would have to remove any piece of code which artificially limits performance of AMD processors"... So now the piece of code in question should ideally look like...

If AVX{
If Intel{}
else{}
}

This is not optimizing for AMD is this? This is for simply detecting support of an instruction set and execute the same, with optimized path for "Genuine Intel" processors. However, they are rather sneaky with the same dodgy behaviour persisting, which is evident what with their new beta compilers which dropped in soon after they reached the settlement with AMD.

I believe from your demeanour that you believe people at Intel to be more evolved (and hence intelligent?) than any other on this planet... Given that they're all so superlative, do you think they were a bunch of idiots to agree to such a thing?

Now FTC in their settlement with Intel have asked Intel to notify that their compilers do not run certain codes/ instruction sets (in other words are broken :P) on any other procesor than Intel's own. Which is fair... FTC didn't ask them to optimize code... only advised that they better run it, or, notify people who use it that it is broken

If you follow soccer/ football, FTC has caught Intel committing a foul, as Intel went diving and asking for a penalty. This time, they've been warned, shown a yellow card, if you like. The next time, it will be a red card. This is only fair...

Oh, yeah... just so you know... i'm typing all this using a "Genuine Intel" system

[Sn0wm@n]

LOL intel's compiler tricks proves that intel can only win if they cheat .... go go go amd let the bulldozer wipe the floor

Intel is under no obligation whatsoever to support AMD, much less produce optimal code for it. That takes effort and intimate knowledge about the caveats and errata on AMD cpus. AMD isn't willing to share that, nor support financially the development.

If you don't like Intel's compiler ( which has something like 4% market share ) , you're free to use from a plethora of others : MS, Pathscale, GCC, Sun Studio,etc.
The whole compiler thing is BS stemming from the socio-political views of those in power, liberal neo-socialists ) both US/EU, who have grand ideas of benevolence from the strong to the weak and if they don't do it willfully they will be forced. Horse manure.

if intel promotes a compiler that works on other cpu then yes they are forced to make it behave the same on other platform .... you dont know nothing concerning the legality of this so stop talking out of your ass

[savantu]

I agree one hundred percent with the fact that Intel is under no obligation to support AMD or any other chip manufacturer for that matter. Given that i was planning to start something myself, i understand completely that it would suck balls for Intel to have to support AMD...

Now, please give a few minutes to read something rather important. Optimization is not the same as executing/ running the code at all. Optimization is when you tailor a certain code to work more efficiently on a given piece of hardware/ equipment. FTC has noted certain descrepancies in the compilers from Intel in that they do not run the (instruction sets) code at all on anything else than "Genuine Intel". Now this is what put Intel in soup. What Intel was doing was not using instruction sets such as SSE2, SSE 3 (and now AVX in their latest beta compilers) and blah blah supported by VIA and AMD processors... the compilers simply ran the code as if there was no support at all.

To put it simply, the current scenario is:

If Genuine Intel"{
AVX{}
}
else{}...

What is present in Intel's settlement with AMD is, "Intel would have to remove any piece of code which artificially limits performance of AMD processors"... So now the piece of code in question should ideally look like...

If AVX{
If Intel{}
else{}
}

This is not optimizing for AMD is this? This is for simply detecting support of an instruction set and execute the same, with optimized path for "Genuine Intel" processors. However, they are rather sneaky with the same dodgy behaviour persisting, which is evident what with their new beta compilers which dropped in soon after they reached the settlement with AMD.

As you know very well, compilers work by the switches you enable. Intel's compiler work perfectly well for AMD witht he right switches given that AMD themselves uploaded benchmark scores using Intel's compilers. Interesting behaviour towards a "cheating" compiler.

Intel's compiler does not bother to check for support. It uses the familly code bits, e.g it optimizes for Core, Northwood, PPro,Prescott,etc. The code it creates takes into account all the peculiarities for the given uarch.

I believe from your demeanour that you believe people at Intel to be more evolved (and hence intelligent?) than any other on this planet... Given that they're all so superlative, do you think they were a bunch of idiots to agree to such a thing?

I fail to see how this nonsense can be extracted from my "demeanour" and what's the point you're trying to make.
If you believe politics do not interfere with regulators, you need to get out of the house more. I suppose you don't see any connection between AMD/GF building a FAB in NY and the Cuomo case ?

Now FTC in their settlement with Intel have asked Intel to notify that their compilers do not run certain codes/ instruction sets (in other words are broken :P) on any other procesor than Intel's own. Which is fair... FTC didn't ask them to optimize code... only advised that they better run it, or, notify people who use it that it is broken

Who is dumb enough to buy Intel's compilers when targeting the broadest base possible ? You use MS or GCC.

[tifosi]

Intel's compiler work perfectly well for AMD witht he right switches...

Works... and works perfectly well are two different things...
Read:
http://www.osnews.com/story/22683/In...from_Compiler_
and,
http://arstechnica.com/hardware/revi...o-review.ars/6

The same code on the same processor with a differnt vendor id, ran 10% less efficiently

Intel's compiler does not bother to check for support. It uses the familly code bits, e.g it optimizes for Core, Northwood, PPro,Prescott,etc. The code it creates takes into account all the peculiarities for the given uarch.
.

What any compiler ideally should do especially when it comes to instruction sets is check for support... otherwise, what is the point of having a standard, if no one is to follow it. What you're talking about is code optimization...

I fail to see how this nonsense can be extracted from my "demeanour" and what's the point you're trying to make.
If you believe politics do not interfere with regulators, you need to get out of the house more. I suppose you don't see any connection between AMD/GF building a FAB in NY and the Cuomo case ?

I'm sorry about the earlier remark , this one specifically... but you do see pun was intended... nothing personal. Then again, i meant to imply that if Intel knew they did no wrong, why'd they agree to such terms with AMD?

Who is dumb enough to buy Intel's compilers when targeting the broadest base possible ? You use MS or GCC.

Apparently a lot of people who make benchmarking tools, whom we rely upon :P

[savantu]

Works... and works perfectly well are two different things...
Read:
http://www.osnews.com/story/22683/In...from_Compiler_
and,
http://arstechnica.com/hardware/revi...o-review.ars/6

The same code on the same processor with a differnt vendor id, ran 10% less efficiently



What any compiler ideally should do especially when it comes to instruction sets is check for support... otherwise, what is the point of having a standard, if no one is to follow it. What you're talking about is code optimization...



I'm sorry about the earlier remark , this one specifically... but you do see pun was intended... nothing personal. Then again, i meant to imply that if Intel knew they did no wrong, why'd they agree to such terms with AMD?



Apparently a lot of people who make benchmarking tools, whom we rely upon :P

I'd like to direct you to another discussion which was highly entertaining both from a comic and a content perspective. Too bad I don't have links to all the excellent discussions held at Aces and Realworldtech about this. You had people with real knowledge discussing the issues at a totally different level than enthusiasts. ( ok, not all the posts were at that level )

http://aceshardware.freeforums.org/c...iler-t428.html

There are several gems in that thread :

One day, Cadence decided that those Synopsys heathens and their treacherous users shouldn't be able to flip between a Synopsys tool for netlist compilation, and a Cadence tool for place & route.

"Why are people using dc_shell for compiling their netlists?," cried Fister. "We have RTL Compiler! We should optimize our P&R tool for our RTL compiler!" Of course, RTL Compiler was already optimized as much as Cadence software engineers could ever optimize anything. A sly executive inquired, "can't we just make Encounter slow down for non-RTL Compiler inputs?"

The new product was released. Suddenly, P&R jobs for netlists produced by Design Compiler were running 10% slower, and producing layouts which were 5% larger, and 10% slower. Internal benchmarks began to report that RTL Compiler was superior to Design Compiler, and Cadence began to sell more licenses than ever before. Fister smirked with glee, "the money doesn't even matter; our biggest competitor is being completely undermined."

The users, curious engineers, were suspicious. The masses of Deepchip.com pooled their collective resources together to investigate what was going on. It was soon discovered that Cadence's P&R tool was performing selective optimizations depending on the source of the netlist.

"How dare Cadence do this!," cried an engineer.

A calm reply from a Cadence spokesperson was heard: "it is quite simple after all. If Encounter doesn't meet your requirements feel free to use something else."

and levicki nails it :

Excuse me, how has this discussion gone from Agner's speculation about flaw in Intel's compiler (which is bogus because CPUID is also tested in much the same way in legacy BIOS code) into this pointless discussion whether should ICC have separate AMD code path or not?!?

I say it shouldn't support AMD at all. Let AMD write their own compiler.

I deal with code optimization since Pentium MMX and if I recall correctly until very recently AMD didn't invest into popularization of code optimization a single cent. They couldn't teach anyone even if they wanted to, because their developer website is a mess -- it took me one hour to find a document which describes proper AMD CPU detection.

They always had their brute force approach as in "why waste time optimizing code when you can buy a faster CPU".

That was when they had faster CPUs. Now that they don't have faster CPUs they have started preaching about code optimization, hypocrits.
.................
Are "works fine" and "works optimally" synonyms for you?

AMD CPUs need separate code path.

Just of the top of my head:

1. AMD themselves said in their optimization manual for AMD64 that their CPUs prefer interleaved reads and writes while Intel prefers batched reads and writes. There are probably a lot more differences especially in instruction scheduling.

2. There are some old AMD CPUs with family and model < 6 which report SSE and SSE2 capability incorrectly.

3. AMD supports SSE3 but not MONITOR/MWAIT, if you allow it to execute the same SSE3 code path it will crash.

You can always patch the check and risk it. If you don't like it, don't use it. Period.

It is far more entertaining when people bring actual facts and do not follow the herd instinct. Facts have a nasty way of enabling the mute button in the most vocal but shallow participants.

[Calmatory]

Who is dumb enough to buy Intel's compilers when targeting the broadest base possible ? You use MS or GCC.

Many people are. Many people who are writing time-critical software use Intel's compilers, mainly the C++ compiler for Windows-

So many, many people use it regardless of the unbiased nature(Possibly not knowing about it even).

Intel's compilers are superior at speed compared to MS and MinGW(GCC compiler ported to Windows, not up to date) on Windows. In other platforms(Mainly linux) gcc(C compiler) is faster than Intel C compiler and g++(c++ compiler) is about just as fast as Intel's C++ compiler.

[Calmatory]

It is far more entertaining when people bring actual facts and do not follow the herd instinct. Facts have a nasty way of enabling the mute button in the most vocal but shallow participants.

1. CPU architectures behave differently. Doesn't matter if you compare AMD archtitecture to Intel architecture, or future Intel to older Intel etc. They have differences which require different kinds of optimizations.

2. Never heard of this, and it seems Google hasn't heard of it either. I'd bet a bunch they were ES parts.

3. MWAIT and MONITOR are Hyper Threading specific instructions, they are of no use for AMD.

So yeah. Great.

[Hornet331]

So why again do we have to discuss ICC as totaly unrelated matter to the topic?