But have they integrated the Northbridge yet? A traditional two-part chipset does not make for good efficiency.
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!
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.
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.
It's pretty shocking that you can get almost double performance from common libraries by faking having an Intel CPU.
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.
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...
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.
Very honest of you.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?
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.
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.
Very honest of you.
At the same time, do you see some rabid anti AMD posters popping up, or is it my imagination?
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.
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.
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.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.
Probably gone hoarse, especially if they've also been over in the PS4 thread...Amazingly, it seems as if all the AMD naysayers have lost their voices.
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).If your market base is cross-hardware wise - hopefully your smart enough not to compile with ICC.
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.
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.
What tablets ? There aren't any in the market place AFAIK !When you can make bay trail tablets for $200, I think it's unfair to say that Intel didn't change direction.