anand's jaguar article

[Idontcare]

MS Excel is not compiled with ICC. Gaussian is not compiled with ICC. In fact, almost no real software is compiled with it. ICC is mostly used in several useless synthetic benchmarks.

That makes it is even less of an issue then for people who test with their apps of interest and make data-driven purchasing decisions.

People who don't value their money more than their time such that they won't take the time to determine the best value for their money are always going to get exactly what they deserve, and that is true regardless the product involved (be it CPUs, cars, 401k retirement choices, their home, choice of higher education, career path, etc).

Telling me that ICC is a red herring because benchmarks are a red herring makes it even less relevant to me. It is just arguing for the sake of arguing at that point.

 

[Headfoot]

Isn't talk of FLOPS a lot more relevant than talk of CUs with regard to performance across architectures?

Yes. But these are the same architecture. Every product here is based off of the same revision of GCN (according to current information). Thus GFLOPS is worse than just comparing execution units.

 

[Cerb]

Yes, and I am not alone.

Yes, you are.
http://www.maxonshop.com/us/ps/CINEMA 4D CINEMA 4D Studio/1/s1/C100-CAT201

Cinebench isn't just random. It's been latched on to, but it's made as a measure of performance for content creation applications, which are very much real software.

ICC, MS VCC, GCC, and LLVM, are all used for real software. ICC and GCC tend to offer the best performance for data crunching, LLVM is the awkward teenager of the bunch, doing things its elders can't understand, and MS' compiler is typically very good at pointer-chasing work, like DB and GUI apps, and good at optimizing well across many CPUs.

Most software is not compiled with ICC, and a lot of ICC hype is just hype, but it is a good compiler, and if it can offer better performance, it will get used, not merely for benchmark applications, but real ones, too.

MS Excel is not compiled with ICC.

Well, duh. I'm sure MS has more than a few licenses for it, but are you willing to be the guy that tells his boss some other compiler might be faster? No. You will be the guy that gets in touch with the assembly wizard to bypass your compiler's weaknesses, so that it is fast with your company's compiler.

However, only MS' own products are subject to that. Intel's licenses are cheap enough as to be a drop in the bucket, if you're already shelling out for the luxo Visual Studio licenses (which, you will be, because they're cheaper than having your guys try to do it some other way). Everyone else chooses what is best. Usually, it doesn't matter, sometimes MS' or GCC are faster (GCC if on *n*x), and sometimes ICC is faster. For content creation, ICC will usually be the faster one.

 

[Headfoot]

The next gen consoles are so weak that we need more powerful and expensive hardware to be able to play them!

The reason is the same reason that iOS>Android development. Console>PC development.
Always will be like this.
Even Flash>HTML5.

Yes, Android, PC and HTML5 are awesome and cool and whatever. But iOS, Console and Flash will always be "better". (Unless Adobe keep being jerks...)

Oddly enough, that's what Microsoft wants to do but "people" don't like that. Lmao!

Which is also what Steam wants to do! And people want it! rofl...nothing makes sense, its the same reason!

Closed, manageable systems/targets will win. Always. They offer the better experience. (iOS, Flash, Consoles. All primerally closed in one way or another, yet, ubiquitious!)

That's why most "real" PC games now are on VM's... .Net, Mono/Unity, Flash, Java, etc. And published directly to an App Store of sort, which are mostly closed.

("Real" in the context of games developed for the PC first.)

The more you treat the PC like a Console the more you "Win". That's what Steam has been doing on PC. Which is what MS wants to do on Windows!

PC Gamers usually have a hard time believing this.

Point is, closed systems have always won and will always win. Because, world peace will never be achieved unless world peace is compromised.

Lol seriously? Most "real" PC games wouldn't touch a managed language with a ten-foot pole unless they are indie and so small that they must use something along those lines for pure time-to-market reasons.

UDK, Unreal Engine: written in C++ targeting OpenGL (open language/API) and DirectX (closed language/API)
Source (HL2, etc): C++ targeting OpenGL (open) and DirectX
Unity supports DirectX, OpenGL and is written in.... you guessed it, C and C++.
Every single iOS game: either Quartz (2D only) or OpenGL ES (open API)
Every single Android game: Canvas/Drawables (2D only) or OpenGL ES (open API)

C++ is an ISO standardized language: it is not proprietary. Seeing a pattern here? Or are you going to argue that the above platforms aren't valid examples somehow?
In short, you are completely wrong

 

[MightyMalus]

Lol seriously? Most "real" PC games wouldn't touch a managed language with a ten-foot pole unless they are indie and so small that they must use something along those lines for pure time-to-market reasons.

UDK, Unreal Engine: written in C++ targeting OpenGL (open language/API) and DirectX (closed language/API)

Source (HL2, etc): C++ targeting OpenGL (open) and DirectX Unity supports DirectX, OpenGL and is written in.... you guessed it, C and C++.

Every single iOS game: either Quartz (2D only) or OpenGL ES (open API)
Every single Android game: Canvas/Drawables (2D only) or OpenGL ES (open API)
C++ is an ISO standardized language: it is not proprietary.
Seeing a pattern here? Or are you going to argue that the above platforms aren't valid examples somehow? In short, you are completely wrong

I'm not wrong. I gave the meaning of "real" in my context, in my post.

I find it interesting that you used two engines to define the majority of PC games.
Intense graphical twitch games? Yes, C++ most of the time.
(And even if they use OpenGL, they end up being on Windows only!)

Unity is written in, but does not deploys to...C++. It deploys to a VM.
iOS has Flash and Mono support and soon Java. They will be used, they are used.
Android has a Java like managed language, also supports Flash and everything else.


Most games aren't written straight to metal. Only a few and they end up limiting themselves to one OS anyways, which goes towards my point to. Everything else is written to a target or VM.

Truly open systems do not work well. Probably because of ambition and limits.
Just how non managed languages are used, for very ambitious projects that want to push the limits.


In essence its hard to go for direct hardware/non closed standard, simply because there is too much variety. Android hardware, usually aim at a specific OS versions. Computer Hardware, probably Windows. Web, Flash since it will run pretty much the same in every browser.

C++ is used, but mostly on consoles and some PC games. But overall, writing a game in Flash/Java/C# won't stop you from making a couple billions$$$. Most games are written in everything else than C++, most games aren't "AAA".

 

[NTMBK]

You will be the guy that gets in touch with the assembly wizard to bypass your compiler's weaknesses, so that it is fast with your company's compiler.

Actually, MSVC doesn't support inline assembly when targeting x64 - its one of its major weaknesses.

 

[Idontcare]

Actually, MSVC doesn't support inline assembly when targeting x64 - its one of its major weaknesses.

True for the publicly available retail releases, but I'm betting the internal guys have access to all kinds of beta goodies that aren't available to the outsiders for risk-control reasons.

 

[MisterMac]

I'm not wrong. I gave the meaning of "real" in my context, in my post.

I find it interesting that you used two engines to define the majority of PC games.
Intense graphical twitch games? Yes, C++ most of the time.
(And even if they use OpenGL, they end up being on Windows only!)

Unity is written in, but does not deploys to...C++. It deploys to a VM.
iOS has Flash and Mono support and soon Java. They will be used, they are used.
Android has a Java like managed language, also supports Flash and everything else.


Most games aren't written straight to metal. Only a few and they end up limiting themselves to one OS anyways, which goes towards my point to. Everything else is written to a target or VM.

Truly open systems do not work well. Probably because of ambition and limits.
Just how non managed languages are used, for very ambitious projects that want to push the limits.


In essence its hard to go for direct hardware/non closed standard, simply because there is too much variety. Android hardware, usually aim at a specific OS versions. Computer Hardware, probably Windows. Web, Flash since it will run pretty much the same in every browser.

C++ is used, but mostly on consoles and some PC games. But overall, writing a game in Flash/Java/C# won't stop you from making a couple billions$$$. Most games are written in everything else than C++, most games aren't "AAA".

What exactly is your point?

I lost it.


Nothing of what you say makes sense.

I get the sense your saying closed is better - but then you argue open bloated easier to learn bloated languages with overhead is best?

what?

 

[Olikan]

mmm... there seems to still have some room for improvements for jaguar... without adding more decoders or exec units....

bottlenecks that i have gartned....
high branch penality of 14 cicles
L1i is only 2-way associative
L2 cache have a big latency
add operations have an insane latency of 5

overall, nice little chip

 

[galego]

Yes, you are.
http://www.maxonshop.com/us/ps/CINEMA 4D CINEMA 4D Studio/1/s1/C100-CAT201

Cinebench isn't just random. It's been latched on to, but it's made as a measure of performance for content creation applications, which are very much real software.

ICC, MS VCC, GCC, and LLVM, are all used for real software. ICC and GCC tend to offer the best performance for data crunching, LLVM is the awkward teenager of the bunch, doing things its elders can't understand, and MS' compiler is typically very good at pointer-chasing work, like DB and GUI apps, and good at optimizing well across many CPUs.

Most software is not compiled with ICC, and a lot of ICC hype is just hype, but it is a good compiler, and if it can offer better performance, it will get used, not merely for benchmark applications, but real ones, too.

Rather than contradicting you are confirming what I said: most real world software does not use ICC. This ICC is very popular in useless synthetic benchmarks that use the cripple_AMD function.

Regarding Cinema 4D only two points:

• It is difficult to believe that Cinema 4D was the relevant application used in computers based in jaguar cores @ 1.5 GHz.
• And so far as I know Cinema 4D it almost not used in the film industry.

 

[joshhedge]

Rather than contradicting you are confirming what I said: most real world software does not use ICC. This ICC is very popular in useless synthetic benchmarks that use the cripple_AMD function.

Regarding Cinema 4D only two points:

• It is difficult to believe that Cinema 4D was the relevant application used in computers based in jaguar cores @ 1.5 GHz.
• And so far as I know Cinema 4D it almost not used in the film industry.

As per a lawsuit in 2009, settling in November of that year, Intel has been forced to remove any AMD inhibiting code. Your claims are unsubstantiated.

Source: http://www.agner.org/optimize/blog/read.php?i=49#49

 

[Abwx]

As per a lawsuit in 2009, settling in November of that year, Intel has been forced to remove any AMD inhibiting code. Your claims are unsubstantiated.

Source: http://www.agner.org/optimize/blog/read.php?i=49#49

You , are wrong..
All they did was to put a disclaimer...

From the very same site :

Author: Agner Date: 2012-05-17 13:40 Guest wrote:

does anyone have any news on whether Intel has any intention of removing the performance throttle against AMD?​

It's not getting better. The latest version of Intel's SVML (small vector math library) has some functions that can only be called from processors with AVX because the input parameter is an AVX vector (YMM register). There is no logical reason why these functions should have a CPU dispatcher, yet they have two different code paths for the same instruction set: An optimized version for Intel processors with AVX and an inferior version for other brands of CPU with AVX.

 

[joshhedge]

You , are wrong..
All they did was to put a disclaimer...

From the very same site :

Well I've got another source here: http://www.osnews.com/story/22683/I...quot_Cripple_AMD_quot_Function_from_Compiler_

I don't know enough to comment further, but there has been a settled lawsuit against Intel for this matter which should have either resolved or helped improve the situation.

 

[NTMBK]

Rather than contradicting you are confirming what I said: most real world software does not use ICC. This ICC is very popular in useless synthetic benchmarks that use the cripple_AMD function.

Trust me, there is plenty of real world software which uses the ICC.

 

[Idontcare]

Well I've got another source here: http://www.osnews.com/story/22683/I...quot_Cripple_AMD_quot_Function_from_Compiler_

I don't know enough to comment further, but there has been a settled lawsuit against Intel for this matter which should have either resolved or helped improve the situation.

The comment quoted by Abwx is over a year old.

I suspect if it were still a legitimate complaint and not simply more mountains being made of molehills then I'd expect AMD to already be dragging Intel back to court.

 

[wlee15]

mmm... there seems to still have some room for improvements for jaguar... without adding more decoders or exec units....

bottlenecks that i have gartned....
high branch penality of 14 cicles
L1i is only 2-way associative
L2 cache have a big latency
add operations have an insane latency of 5

overall, nice little chip

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.

 

[galego]

As per a lawsuit in 2009, settling in November of that year, Intel has been forced to remove any AMD inhibiting code. Your claims are unsubstantiated.

Source: http://www.agner.org/optimize/blog/read.php?i=49#49

Nope. Abwk is right. The Intel compiler continues cheating. The FTC settlement included a disclosure provision where Intel must:

...publish clearly that its compiler discriminates against non-Intel processors (such as AMD's designs), not fully utilizing their features and producing inferior code.

In compliance with this rule, Intel added an "optimization notice" to its compiler descriptions:

Intel® compilers, associated libraries and associated development tools may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include Intel® Streaming SIMD Extensions 2 (Intel® SSE2), Intel® Streaming SIMD Extensions 3 (Intel® SSE3), and Supplemental Streaming SIMD Extensions 3 (Intel® SSSE3) instruction sets and other optimizations.

I will wait to see some realistic benchmarks (lacking the Cripple_AMD function evidently) and will run my own benchmarks as well, but it looks as AMD has clear winner here.

 

[Cerb]

Rather than contradicting you are confirming what I said: most real world software does not use ICC. This ICC is very popular in useless synthetic benchmarks that use the cripple_AMD function.

Aside from the cripple AMD function having been legislated out, no, it confirms nothing. You just want to believe that there is an invisible force trying to put down AMD. That, "cripple_AMD," functionality is long gone. If you look, you will find that the performance of other programs doing similar work has similar performance. Change over to Adobe Premier, FI, and you'll find similar results.

ICC is not uncommon for content creation and HPC. That software is, "real world." There's no conspiracy, HPC and such are just really easy to benchmark. Compile with GCC, and you'll get similar results. In fact, here you go.

 

[galego]

Aside from the cripple AMD function having been legislated out, no, it confirms nothing. You just want to believe that there is an invisible force trying to put down AMD. That, "cripple_AMD," functionality is long gone. If you look, you will find that the performance of other programs doing similar work has similar performance. Change over to Adobe Premier, FI, and you'll find similar results.

ICC is not uncommon for content creation and HPC. That software is, "real world." There's no conspiracy, HPC and such are just really easy to benchmark. Compile with GCC, and you'll get similar results. In fact, here you go.

My main point what that most software is not compiled with ICC. You wrote: "Most software is not compiled with ICC". It looks like there is some agreement rather than disagreement.

The cripple_AMD functionality remains here in ICC. If you read above posts, Intel merely added a disclaimer for legal issues. Benchmarks using ICC continue cheating the results.

Your link to phoronix confirms again what I am saying. They use openbenchmarks (the code cannot cheat) and, as is well-known, AMD performs much better here when compared to Intel. E.g. they have a comparative FX-8350 vs i7-3770k where the FX is on the same performance envelope, beating the i7 in several benchmarks (the FX is up to a 42% faster than the i7 in one of the benchmarks). This is possible because GCC does not cheat.

I am anxiously waiting for openbenchmarks on jaguar based chips!

 

[mrmt]

Aside from the cripple AMD function having been legislated out, no, it confirms nothing. You just want to believe that there is an invisible force trying to put down AMD. That, "cripple_AMD," functionality is long gone. If you look, you will find that the performance of other programs doing similar work has similar performance. Change over to Adobe Premier, FI, and you'll find similar results.

There was no "cripple AMD function". What exists is a check for the ID of the processor. If the check gets an Intel ID, it runs the optimum code for that given series of processor. If it gets anything else, it runs a less optimized code path. The catch here is that the ICC is optimized for specific models, not for specific ISA features.

 

[galego]

There is a cripple_AMD function, if the CPU dispatcher detects a genuineIntel string then apply the optimizations compatible with the processor model and series, if it is not a genuineIntel then run the slowest possible code even if the processor is compatible with the fast code. There was a delicious testing with PCMark and VIA processors. The VIA processor allows changing the CPUID. When the benchmark detected a VIA processor it gave the slowest possible score, when the reviewer changed the CPUID to genuineIntel, the benchmark gave a 40% more score. The chip was the same in both cases. The VIA was a faster chip than the Intel when the benchmark was not cheating.

 

[galego]

dup post

 

[MisterMac]

There is a cripple_AMD function, if the CPU dispatcher detects a genuineIntel string then apply the optimizations compatible with the processor model and series, if it is not a genuineIntel then run the slowest possible code even if the processor is compatible with the fast code. There was a delicious testing with PCMark and VIA processors. The VIA processor allows changing the CPUID. When the benchmark detected a VIA processor it gave the slowest possible score, when the reviewer changed the CPUID to genuineIntel, the benchmark gave a 40% more score. The chip was the same in both cases. The VIA was a faster chip than the Intel when the benchmark was not cheating.

...and where is this delicious testing?

Also - i know your a unrationale crazy fanboi - but having a enhance_intel option and a normal_routine option does not mean normal is cripple AMD.
But your too daft and way off the mark to realize that right?

If it's they're own compiler - it's NATURAL they optimize for their closed hardware.
This is pretty much your whole console code to the metal argument all over again.

Except your on the wrong side now diffyboy.

 

[NTMBK]

...and where is this delicious testing?

Look up Agner Fog's blog- what Galego says is actually entirely true. (And Agner Fog is well known in C++ circles as a reputable and very knowledgeable man- his optimization manuals are required reading. So it's not just some random on the internet.)

 

[Vesku]

What Intel did with their compiler:

If CPU identifies as Intel compile the code to target best extensions supported

Else

compile the code for x87 or similar bare minimum

Which isn't the behavior you'd expect from most compilers, you'd expect them to utilize whichever extensions are supported by the system regardless of vendor.

Kind of hard to dispute this when they settled with the FTC over it, so now they have to publicly disclose that exact behavior:

"disclose to software developers that Intel computer compilers discriminate between Intel chips and non-Intel chips, and that they may not register all the features of non-Intel chips. Intel also will have to reimburse all software vendors who want to recompile their software using a non-Intel compiler." - http://ftc.gov/opa/2010/08/intel.shtm

Which is another reason why actual tests of the applications you use are important, as has been said.

 

[NTMBK]

Dug up that Agner Fog blog post:

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

It's pretty shocking that you can get almost double performance from common libraries by faking having an Intel CPU.

EDIT: And some follow up: http://www.agner.org/optimize/blog/read.php?i=126