anand's jaguar article

[NTMBK]

Take it easy, new 28nm TSMC native and monolithic VIA QuadCore CN-R processor with refresh VIA Isaiah x86-64 microarchitecture with hundreds of changes e.g. 2MB L3 cache and SIMD up to AVX2 will be (I presume) better performance as Jaguar or Silvermount. And of course: Power, not performance, is the key!

But have they integrated the Northbridge yet? A traditional two-part chipset does not make for good efficiency.

 

[crashtech]

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

Finally there is evidence of some real meat to the contentions being made. A function check would obviously be superior to a CPUID check; the only reason to rely on a CPUID check is to exclude competitor's processors from optimized code paths. Thanks, NTMBK, for the links. Maybe I've been living under a rock, but this (relatively old) news is a revelation to me. I heard about it a long time ago, but assumed it had been taken care of long before now.

 

[CTho9305]

Finally there is evidence of some real meat to the contentions being made. A function check would obviously be superior to a CPUID check; the only reason to rely on a CPUID check is to exclude competitor's processors from optimized code paths. Thanks, NTMBK, for the links. Maybe I've been living under a rock, but this (relatively old) news is a revelation to me. I heard about it a long time ago, but assumed it had been taken care of long before now.

It's (very) old news, but there's a vocal set of fanboys/apologists who seem to always claim Intel didn't do it (or stopped doing it long before they did), and it can be hard to figure out which posters are credible unless you've taken the time to find the original sources for information yourself. It's nice when someone posts a good link!

 

[maddie]

Amazingly, it seems as if all the AMD naysayers have lost their voices.

 

[2is]

You are using GFLOPS because you think it supports your position. We aren't using it because we know the difference between theoretical numbers and real life performance.

I'm not sure if you're aware, but you're arguing with a guy who thinks it takes 3 Titans to match the performance of an APU.

 

[mrmt]

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

To optimize for your own processor isn't the same of cripple the performance of your competitor's processors. This is the legal leg that saved Intel in the FTC settlement. Also, the code path isn't always the slower one, but one inferior to Intel's processors.

 

[Exophase]

I'm not aware that the dispatching changes anything other than what instruction set is being targeted. And at least it has enough sense not to use x87 code in 64-bit. For processors that don't have AVX/AVX2 the difference between SSE2 and SSE4.x is usually not that big for compiled code.

As far as ICC generated code goes, this only applies if you even use the dispatch option to begin with (instead of specifying the architecture manually). Since GCC doesn't even have a runtime dispatch option (as far as I could find) you'd just be stuck with a fixed architecture there anyway. So I don't understand why "use GCC" is a better alternative than "fix the arch on ICC." That also means that it's not enough to see if a program is compiled with ICC, it has to be compiled with auto-dispatch to potentially be using inferior code paths on non-Intel processors.

Frankly I'm not really sure why runtime dispatching is even desirable. I'd rather have separate compiled executables that are chosen at install time, like how Android does it. It shouldn't be hard at all to roll that into an installer for a Windows app.

The libraries are a different story. It looks like the big offender is Intel's MKL. Not sure how much uses that outside of HPC code and Matlab or similar.

 

[Idontcare]

It's (very) old news, but there's a vocal set of fanboys/apologists who seem to always claim Intel didn't do it (or stopped doing it long before they did), and it can be hard to figure out which posters are credible unless you've taken the time to find the original sources for information yourself. It's nice when someone posts a good link!

Amazingly, it seems as if all the AMD naysayers have lost their voices.

I may fall into that category but its not without reason.

I spent years (not exaggerating on the timeline there) trying to get the source code of my application of interest (Gaussian98) to run optimally in Linux with my Portland Group compilers (using the BLAS libraries of course)...and I was only "just" able to get it to the point where the performance justified the effort provided I valued my personal time and effort at pennies on the hour.

Move along by a few years and now I see things from the other side of the cost-angle. It isn't that I don't want to care; rather, I can't possibly justify caring what AMD could deliver in a perfect world. I have to take the world as it exists and attempt to maximize my own personal gain from it.

And that means taking an Intel processor and running with it because the apps, ethical or not, are compiled and optimized such that they do deliver the best performance/dollar with an Intel processor once TCO is fully accounted for.

That isn't my fault, that is reality. I can either embrace it and move on or I can fight the current and do something that is less than fully cost-justified.

Where do the dollars go in that situation?

 

[crashtech]

The problem with that line of thinking is it tacitly accepts injustice. What you do for money need not be exactly the same as what you advocate for here on the forum, and if the two happen to be different, it need not signify hypocrisy, either. What we want and what we get are often at least slightly different...

 

[Idontcare]

The problem with that line of thinking is it tacitly accepts injustice. What you do for money need not be exactly the same as what you advocate for here on the forum, and if the two happen to be different, it need not signify hypocrisy, either. What we want and what we get are often at least slightly different...

I like to think that I do what you suggest, walk a fine line in two different capacities, as well as simultaneously strive to do something better than simply converting energy into entropy during my brief existence in this realm.

I fear thermo is going to win out on this one though

Most days I feel like I've done little more than that of a gas expanding into a vacuum. No PV work there, just lots of entropy being created.

With Intel CPUs you just never know how many baby seals were clubbed in the process of making the CPU in question.

With AMD you know exactly how many, and it is non-zero, but they seem to be on some perpetual "woe-is-me" train and that gets old when it is a girlfriend who is at least putting out on a regular basis...however when it is a business who can do no better than resort to those tactics it just seems tired and sad.

Like Berlusconi chasing after 19 year olds like he is still 25 himself. Its not working, give it up.

 

[crashtech]

That's true, yet I am rather shocked to enter back into the enthusiast realm some decade after first hearing of the Intel compiler stuff, and finding it still has not been rectified. I can't yet decide if it is due to Intel's nefariousness or AMD's ineptitude.

 

[Chiropteran]

It isn't that I don't want to care; rather, I can't possibly justify caring what AMD could deliver in a perfect world. I have to take the world as it exists and attempt to maximize my own personal gain from it.
...
That isn't my fault, that is reality. I can either embrace it and move on or I can fight the current and do something that is less than fully cost-justified.

This is a fine point of view. The issue I take is when this point of view is taken at the expense of making AMD look bad while in another review the opposing view is taken to make AMD look bad in that particular case. Consistency is the only way to be fair.

Specifically, I'm referring to the practice of running gaming benchmarks at artificially low resolutions to maximize the performance differences between CPU, when a test at realistic parameters would show that there is virtually no real-world difference at all, given that the game becomes GPU limited when played a real resolution values.

Either A: consider all CPU based on real world usability, and stop the useless terrible benchmarks like high-end game run at 1366X768 res.


Or B: consider all CPU tested in artificial "CPU comparison" mode, without limiting results based on software optimizations or video card limits.

This mix and match crap is biased.

 

[maddie]

I may fall into that category but its not without reason.

I spent years (not exaggerating on the timeline there) trying to get the source code of my application of interest (Gaussian98) to run optimally in Linux with my Portland Group compilers (using the BLAS libraries of course)...and I was only "just" able to get it to the point where the performance justified the effort provided I valued my personal time and effort at pennies on the hour.

Move along by a few years and now I see things from the other side of the cost-angle. It isn't that I don't want to care; rather, I can't possibly justify caring what AMD could deliver in a perfect world. I have to take the world as it exists and attempt to maximize my own personal gain from it.

And that means taking an Intel processor and running with it because the apps, ethical or not, are compiled and optimized such that they do deliver the best performance/dollar with an Intel processor once TCO is fully accounted for.

That isn't my fault, that is reality. I can either embrace it and move on or I can fight the current and do something that is less than fully cost-justified.

Where do the dollars go in that situation?

Very honest of you.

At the same time, do you see some rabid anti AMD posters popping up, or is it my imagination?

 

[CTho9305]

I like to think that I do what you suggest, walk a fine line in two different capacities, as well as simultaneously strive to do something better than simply converting energy into entropy during my brief existence in this realm.

I fear thermo is going to win out on this one though

Most days I feel like I've done little more than that of a gas expanding into a vacuum. No PV work there, just lots of entropy being created.

With Intel CPUs you just never know how many baby seals were clubbed in the process of making the CPU in question.

With AMD you know exactly how many, and it is non-zero, but they seem to be on some perpetual "woe-is-me" train and that gets old when it is a girlfriend who is at least putting out on a regular basis...however when it is a business who can do no better than resort to those tactics it just seems tired and sad.

The AMD "fair and open competition" stuff always seemed really whiny to me, but this is a situation where the gripes are completely legitimate. AMD didn't communicate that very well. It does get annoying, but it's a case of: kid A breaks the rules, kid B complains to teacher, teacher ignores it, kid A continues breaking the rules, kid B continues complaining, and everyone calls out kid B for whining.

 

[beginner99]

Agreed, it's painfully obvious, silvermont didn't even had a review and he praised it like it was the best low-power CPU ever that no one can match. He does not even try to hide his preference.

Jaguar isn't exactly that amazing. It's just a low-performance SOC for cheap laptops and x86 tablets. It's not a very interesting sector and at least on the laptop segment, Celerons and Pentiums offer better performance, especially single-threaded which matters most anyway for people buying $300-$400 laptops.

Silvermont (or baytrail-m) will be competing with temash and in low-power segment ARM chips. it's not really directly competing with the reviewed kabini apu and is a completely new uArch (after 5 years of almost no changes) and not just a "tock" like kabini. That makes it more interesting. And one could also assume Anand might know more that he isn't allowed to write about directly, like it's performance/watt. But knowing that would obviously make you enthusiastic about the product.

 

[frozentundra123456]

Very honest of you.

At the same time, do you see some rabid anti AMD posters popping up, or is it my imagination?

I see a lot more rabid pro-AMD posters now that you mention it.

I am not speaking of the compiler issue, but in general terms.

 

[frozentundra123456]

This is a fine point of view. The issue I take is when this point of view is taken at the expense of making AMD look bad while in another review the opposing view is taken to make AMD look bad in that particular case. Consistency is the only way to be fair.

Specifically, I'm referring to the practice of running gaming benchmarks at artificially low resolutions to maximize the performance differences between CPU, when a test at realistic parameters would show that there is virtually no real-world difference at all, given that the game becomes GPU limited when played a real resolution values.

Either A: consider all CPU based on real world usability, and stop the useless terrible benchmarks like high-end game run at 1366X768 res.


Or B: consider all CPU tested in artificial "CPU comparison" mode, without limiting results based on software optimizations or video card limits.

This mix and match crap is biased.

I dont really see how running gaming benchmarks at low resolutions relates to unethical behavior. You are projecting motives onto the testers which they may or may not actually have. As I posted earlier, low resolution benchmarks have their place. It would be nice to see a wide variety of resolutions and image quality settings tested, I agree, but it is hardly fair to accuse a test site of being anti-AMD just because they only show low resolution benchmarks. It is a generally accepted method to use to see differences in CPU performance. You can dispute its validity if you like, but I hardly think test sites do it "to make AMD look bad".

 

[ShintaiDK]

That's true, yet I am rather shocked to enter back into the enthusiast realm some decade after first hearing of the Intel compiler stuff, and finding it still has not been rectified. I can't yet decide if it is due to Intel's nefariousness or AMD's ineptitude.

Still? Are you talking about the test with software anno 2005?

So what about the other compilers?

 

[Cerb]

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.

That is the "Cripple AMD" function. Everyone accepts that VIA is plain slower, so AMD is the only one they'd worry about. If the processor supported the same features, it would still get the unoptimized code paths, if multiple dispatch is allowed.

Beaten with the links. That's what exploring an aquifer-infested embark point (shallow metals, deep metals, flux, clay, shallow soil, dense plats and trees, calm, and cold...but there's an aquifer taking up much of the middle), and then save-scumming to be able to get aquifer-centric workshop positioning, for the sake of symmetrical fortress design, instead of hopping over to AT forums, will get you .

AFAIK, if you specify the target, it will not check, today, and can still be much faster at vector math than MS--yes, even with an AMD CPU ("can still be," because not everything is crunching on big loops, which are its forte).

Amazingly, it seems as if all the AMD naysayers have lost their voices.

Probably gone hoarse, especially if they've also been over in the PS4 thread...

 

[MisterMac]

@NBTMK
I just don't get how the hell you can argue it's a cripple amd function.

I'm suprised it's that large a deficit actually - but it's not a bloody cripple AMD function.


And the usual AMD fanbois arguments are straws at best.


Intel is not pushing ICC as a de-facto IDE solution or compiler.
Therefor market sentiment should regulate this problem by itself.

A software company would never make the release binaries in ICC - if they want to reach all, done.

You could argue that intel has been withholding this bit which is un-ethical as hell - and i assume they got told that during the FTC issues.

I somehow don't expect VS to compile optimally to windows vs unix either.
(Even tho that's a vague comparison).



Come on - is that best argument you have as a fan?
"ICC is only good Intel! - that's cheating!".

If your market base is cross-hardware wise - hopefully your smart enough not to compile with ICC.

 

[Cerb]

If your market base is cross-hardware wise - hopefully your smart enough not to compile with ICC.

Depends on performance. ICC-created SSE2 code could very well rock, with any x86-64 CPU, FI, offering no downside except license costs (small) and porting the project (which you'd have to do just to try it out, anyway).

A great deal of compiler optimizations are about putting more on the stack, flattening loops, deciding between alignment and cache footprint (data), greedy loops v. cache footprint (instructions), when to inline (is it better to make it bigger but not call, or make it smaller with calls stalling loops?), and so on.

Hopefully, you'd be smart enough to buy a few performance testing boxes powered by current-gen AMD CPUs, and see what performance is actually like, rather than making it a political decision.

 

[mrmt]

That is the "Cripple AMD" function. Everyone accepts that VIA is plain slower, so AMD is the only one they'd worry about. If the processor supported the same features, it would still get the unoptimized code paths, if multiple dispatch is allowed.

I can understand AMD whining, as I can understand the complaining from developers that want the fastest code running in every x86 processor out there, and I can see the deleterious effects on the market if ICC were to become a de facto standard compiler to the most popular programs.

Still, I tend to side with Intel on this one.

The ICC is just one more advantage that Intel has on the market, like the bigger R&D engine, like the better process, like the clout on the OEMs... Intel puts money and resources there, I can understand the moral (and legal) case for the ICC to yield better results with Intel processors.

I guess this is one of the cases in which what is good for the company isn't necessarily good for the consumers.

 

[krumme]

I can understand AMD whining, as I can understand the complaining from developers that want the fastest code running in every x86 processor out there, and I can see the deleterious effects on the market if ICC were to become a de facto standard compiler to the most popular programs.

Still, I tend to side with Intel on this one.

The ICC is just one more advantage that Intel has on the market, like the bigger R&D engine, like the better process, like the clout on the OEMs... Intel puts money and resources there, I can understand the moral (and legal) case for the ICC to yield better results with Intel processors.

I guess this is one of the cases in which what is good for the company isn't necessarily good for the consumers.

I dont think it really matter what Intel or AMD thinks about it or the morality in it. Its what happens in a natural monopoly market.

Its an government issue the same way as fx. MS and explorer. And in this case, it would be the same if MS made sure, firefox whatever, didnt run so fast using their OS as platform for that or used another form, to exclude competition. Its seen all over the question is, what is the effect in general. The precedence as i know is, that you really have to be a bad ass, ugly mother f....r just to draw any attention here, because interferrence in the market is best avoided for good reasons.

Looked in hindsight what Intel did and do here, is just plain stupid. The wider effect is the erroding of the pc market, the emergence of ARM. Using similar monopolistic tactics, Intel is now in a position where they are not perfectly sure if they can maintain their cost structure, because the world is simply moving away from their platform. Its what is reflected in the shareprice. Otellini used the monopolistic tactics to gain momentum under the P4 era and squeeze AMD, the wider effect is showing now.

The compiler issue was perhaps relevant 5 or 10 years ago, today its just Intel trying to compete with AMD. They just cant change direction. Perhaps Otellini can say ARM and Apple 20 times in an interview, and only one time AMD, but at the same time what happening on the floor is more of the same procedure.

 

[mrmt]

The compiler issue was perhaps relevant 5 or 10 years ago, today its just Intel trying to compete with AMD. They just cant change direction. Perhaps Otellini can say ARM and Apple 20 times in an interview, and only one time AMD, but at the same time what happening on the floor is more of the same procedure.

When you can make bay trail tablets for $200, I think it's unfair to say that Intel didn't change direction.

 

[R0H1T]

When you can make bay trail tablets for $200, I think it's unfair to say that Intel didn't change direction.

What tablets ? There aren't any in the market place AFAIK !