Intel Compiler Degrades Performance for Non-Intel CPUs

how am i just hearing about this? this is old news, but worth a read if you don't know what i'm talking about.

why so late? why haven't others written about this?

i haven't searched thoroughly, but, reportedly, intel's ties (big advertiser) with tech blogs and publications has kept this from seeing as much exposure as it deserves.

intel does what?

i'll horribly summarize: intel makes some of the best and most widely used compiler and libraries that exist. they are used in tons of compiled installers. the catch: they unfairly optimize for genuine intel products.

they finally have a notice on their website, but it isn't incredibly obvious and isn't the fix the settlement after the court case with AMD demanded.

but they are intel!

the obvious issue is that processor shouldn't matter -- instruction set should:

if (this.processor supports SSE){use sse code} else {use non sse methods}

instead, the code looks like this:

if(this.processor is genuine intel){use best instruction set method} else {use the least optimized code}

in 2012, they did comply with some court order and offer refunds to those interested (misinformed purchasers who expected an impartial compiler/libraries). not enough.

still, this would be acceptable if the product was billed as an intel exclusive or they were making use of things competitors couldn't offer. it isn't (in this case).

Agner (see source link), who has done MUCH research on the topic, claims that we need to get glibc (a rival compiler) and it's libraries properly optimized. Since that is above my head, I thought getting this dirty practice exposed a few people at a time (the extent of my reach) would have to be my contribution.

*chuckles* ...and...you are surprised?

back when AMD took the performance crown (what, 10 years ago?), no. i've been an AMD supporter for a while since they price their products competitively. but since Intel has been the obvious performance leader for a while now...at least in per-clock work and power efficiency, i thought they'd let their products based on superior manufacturing process speak for their-selves. no, gotta pull (or, not rectify) some underhanded stuff like this? and here i was pulling for them to be competitive with ARM.

source

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

Steam OS and AMD's Mantle API: Almost star-crossed

I feel like this should have been written elsewhere by someone more knowledgeable than myself, but it hasn't.

And if ya don't know, now ya know

Steam OS is Valve's GNU/Linux-based OS which is supposed to be optimized for games and will likely offer/feature the "Big Picture" experience which has gotten some attention recently. Presumably, OpenGL-based engines/games will play with ease on the system, but engines/games which lean on Direct3D (Microsoft's heavily used graphics API) games will almost certainly not be available. The idea is that, since GNU/Linux has the potential to be very lean, or resource-lite, performance gains could be realized while gaming as the underlying system (as compared to Windows 8/7/Vista) would need far less resources and, arguably, be more stable.

Mantle is AMD's recently released API that seems to be in direct competition with Direct3D and OpenGL. It bears some resemblances (in performance vs peers) to a long defunct API called Glide. A new API wouldn't normally be very noteworthy or welcome if performance was supposed to only be similar to existing APIs. However, Mantle claims advantages of "9 times more draw calls per second than comparable APIs" and is said to enable "Console-like" hardware access. Don't let that scare off you PC gamers. Console-like just means lower-level access (more efficient use of hardware), not last-gen/outdated performance on release. Oh, analogy time:

• [Programmer] It's like having something coded in C instead of Java. Sure, Java may be easier and more portable, but C gets far more work done per CPU cycle. (Mantle API is C and OpenGL/Direct3D are Java in this very rough analogy)
• [Communication] I tell my kid to tell my wife that I'm sorry I crashed her car instead of telling her myself. (Mantle API is me telling her, OpenGL/Direct3D is me telling my kid to tell her -- slower and less effective assuming he tells her at all. my apologies for this analogy)

The problems

For now, Mantle only works with CGN (newer) AMD Graphics Cards. This makes sense as you can't very well back-port a low level API you've just created, realistically. Notably absent from this list is newer Nvidia cards.

Mantle is a recently developed API about which AMD has made statements implying a "open nature." Currently, it isn't known if Nvidia could eventually allow Mantle API hardware access. Unless that occurs, Mantle can only EVER be a parallel/alternative API, as opposed to the exclusive API of choice by a Game/Engine/Developer for PC since Nvidia has such high market share.

Steam OS and the pending Steam Box machines seem to be Intel/Nvidia based. Valve has said the AMD hardware will certainly be supported, but since Nvidia was pretty heavily involved in Steam OS, it may have notable advantages.

Interesting note

Both the XBox One (xbone, xb1) and PS4 are built custom developed AMD APUs (CPU and GPU in one), which feature CGN technology (potentially Mantle API compatible). It seems that neither Sony nor Microsoft plan on allowing Mantle-developed games on their machines. This is notable because, IF Mantle API worked on "Next Gen" consoles and it was used by game developers, "porting" from Console to Mantle-capable PCs (or PC to console) would be drastically less work and much faster and more seamless.

So, what you're saying is...if your lips left you...

My Wife, and 8th Grade ELA Teacher, would probably tell me I need a "Call to action" statement if this were a persuasive essay. It isn't, but one or both of the following really should be done:

1. AMD needs to release drivers or lend support or whatever is necessary to enable Mantle to work with Steam OS once it comes out. While there don't seem to be any numbers that show expected performance gains of OpenGL games on Windows 8 vs Steam OS, the intention is that it will run faster. If nothing else, Linux is more malware resistant (possibly due, in part, to security by obscurity) and resource-lite, so OS resource utilization should be minimal. With wider GNU/Linux usage, AMD may be encouraged to beef up driver support. Next, they(/we?) need to get Nvidia on board. Obviously, they are rivals, but share the common goal of preserving interest in PC gaming. If Mantle has half the performance impact is seems capable of, it'll be a HUGE deal, and Nvidia will want to jump on board or (a horrible alternative) develop their own API.
2. [more of a footnote, really] Console makers should lean on Mantle API. It'll make porting between XB1, PS4, and PC much more straightforward and, unless the performance is worse than the custom APIs used by each, shouldn't hurt anything. The exception would be Windows OS sales since many gamers claim that playing is the only thing that keeps them on Windows. Likewise, if everyone else worked well with Mantle, Nvidia would be encouraged to adopt support to stay relevant.

Sources

My sources are a few articles I've read about each (Toms Hardware, probably), a few wikipedia articles I used for general summary information, and the Steam OS website.

Read More

I have come across these resources that may be of interest.

• http://www.extremetech.com/gaming/168671-xbox-one-will-not-support-amds-mantle-and-ps4-is-also-unlikely-is-mantle-doa
• http://www.anandtech.com/show/7371/understanding-amds-mantle-a-lowlevel-graphics-api-for-gcn