We can have a look at Linux GCC compiled Benchmark results for Phenom II X3 vs I5 Vs I7 for reference :Quote:
Originally Posted by RPGWiZaRD
http://www.phoronix.com/scan.php?pag...ield_add&num=2 :shocked:
Printable View
We can have a look at Linux GCC compiled Benchmark results for Phenom II X3 vs I5 Vs I7 for reference :Quote:
Originally Posted by RPGWiZaRD
http://www.phoronix.com/scan.php?pag...ield_add&num=2 :shocked:
What I'd prefer seeing is different windows apps compiled both with MS and Intel compiler and then check results both with say an i7 vs Phenom II X4. If there's huge gains for the Intel CPU when compiled an app with Intel's compiler under this circumstance, then we have a problem which cannot always only be blamed on Intel either, but also the software developer. I don't think it's always fair to say this only Intel's fault, could be just the software developer just likes one CPU more and decides to use all possible SSE optimizations from Intel part and nevermind about the AMD CPUs instruction set. I know this from experience since I've been beta tester for an open source PS2 emulator project called PCSX2 and they were always making sure only use instructions that both CPUs can handle to avoid having issues when for example Intel having a clear advantage. They were also looking into trying Intel's compiler at one point but it never went off.
Well here's one for starters. There's many more where that came from. Now what?Quote:
Originally Posted by RPGWiZaRD
http://arstechnica.com/hardware/revi...o-review.ars/6
Lol ,I with my limited knowledge don't know of any available applicaion for end users and not software programmers that runs or is can be compiled using different compilers at any given time .. If you know of one please share .. :)Quote:
Originally Posted by RPGWiZaRD
There's gotta be some open source projects, maybe emulators. PCSX2 for example is only tested and fixed to ensure it works both with GCC and MS compiler.
It's all a matter of perspective, buddy. If you consider the baseline as intel using the optimized code path, than it is nerfing AMD. If you consider the baseline as intel not using the optimized code path for AMD, then it is boosting itself. Either way ...Quote:
Originally Posted by alfaunits
Yea now I see, I wasn't aware of Intel's compiler taking different codepaths depending if it reads "AuthenticAMD" or "GenuineIntel" so different SSE instructions are utilized depending on which it reads etc. OK, there's no question if this is the case that it's very dirty business practice. At least I see it as "on purpose" crippling AMD's performance as they are not making it perform optimally for AMD's CPUs even if it was easily possible to fully make use of all instructions the AMD CPUs supports. If this what's being complained about I fully agree. Luckily majority of software relies on MS' compiler.Quote:
Originally Posted by flippin_waffles
Probably sooner or later this matter will get more attention, I doubt Intel will be able to get by with this forever.
It would be better to have a method to change the vendor ID of the processor and test the various compilers with different values.Quote:
Originally Posted by RPGWiZaRD
If the CPU can tell the dispatcher what optimizations it can perform then there should never be a difference in optimization paths based on vendor ID.
(BTW: The burden of testing each cpu doesn't fall onto Intel so that particular attempt at justification of this action is not valid.)
Just as a discussion topic, what do you think about the games with Intel advertisement during intro "performs best on..." Intel compiler or not? :)
Whats the point of x86 standard if it uses different codepaths for different CPUs? Shouldnt the technology for running code be the same (if CPUs support the same instructionsets), and if not then whats the point of x86 at all?
This remind me of building a house. You can either just write the cheques for the builder to buy materials from their own warehouse, or you can take a van and drive few miles to get them 30% cheaper. Its still the same stuff...just cheaper. Ofcourse youll p*ss off the builder, but in the end its your house/wallet.
Emulators (GCC, MSVC), ffdshow (MSVC, ICC)...Quote:
Originally Posted by Blaber
Say AMD implements something differently than Intel (they do, I'm sure), so the optimizations for Intel processors might (I've got no idea how the optimizations are actually made, but in my mind the best optimizations would be to hand off to a specified point which might not exist in the AMD system exactly as it does in Intel's) actually make performance worse on AMD systems than having no optimizations. You can't really expect them to tear into testing their competitors products to make sure they work properly in every case.
AMD's a big company, they could make their own compiler and send programmers to developers to help add features (like nvidia does for TWIMTBP); in the long run they've done more harm to themselves than Intel has.
AMD big? LOL. Look at AMD turnover vs. Intel turnover.
So, your right at one level, it is AMD's responsibility to make sure those who purchase their products have the tools they need to use them in an optimal fashion. As others have pointed out though, you have to pick your battles. Between the cost of development and getting people to switch compilers, it becomes an intractable problem in the end. With the increasing use of linux and GCC in the business world, part of the problem is already solved at an enterprise level (HPC is a little different, but even then the programmers there don't fall for the usual games).The fine line in all of this is finding which differences are due to implementation (ie optimization), and which are due to intentional performance decrease. You can argue it both ways to some extent, but if you are refusing to use the same code path for another processor and specifically looking for it's cpuid, then that does get a little fishy. That being said, Intel's compiler does work better than AMD's at providing more optimal code for many applications, with a few instances in which AMD's can make a dramatic improvement. Like anything else, you have to take things on balance and choose the right tools for the job.Quote:
Originally Posted by ecidious
I don't see the issue here, I really don't. My view:
- Is anyone at all surprised that an Intel compiler would work better on Intel processors? Intel never claimed it offered equal performance on all processors, they didn't say it wouldn't, but that's really not their job.
- Intel is not actually crippling the performance of other processors. There is a huge difference between not providing optimizations and crippling performance.
- As a subset to the above point, Intel is also specifically not crippling AMD processors; their compiler treats all non-Intel processors this way. This is an extremely fair practice as, realistically, a lot of x86 processors exist. Because this is a critical tool Intel must test any optimizations they allow on all processor architectures they say it will work on; and how is that their responsibility? And before you say "but there is just AMD and Via!" realize that this means a test for each core variation from every x86 processor either of them (or anyone else) has ever released.
- Alternatives (and better ones at that) do exist and are freely available and have been for years and years now. There is no reason to use an Intel compiler unless you are developing for an Intel-only platform.
Oh look, it's this thread again...
Wonder why we need every month a new thread for the same topic....
and the best thing, when you set the right flags (manually), icc even provides good performance on amd cpus.Quote:
Originally Posted by Serra
I say it's a problem when it gets to the point where they've spent effort developing this special case where it hurts performance IF it would perform better if they were to have done nothing to begin with. At that point it gets pretty hard to defend as anything other than:
1) Purposeful crippling
or
2) Embarrassingly extreme incompetence
#1 would be in Intel's best interest. #2 doesn't fit their profile.
What is with the rabid AMD fanboi'ism on these forums?
#1 Intel doesn't owe AMD anything in their compilers.
#2 Intel doesn't own the only compiler.
#3 Any good software developer will not stop optimizations at the compiler level. They bring in byte code programmers fluent in assembly to tweak things beyond what is normally possible for a compiler to do.
This AMD is the wounded kitten being picked on by the Intel pitbull mentality on these forums is so annoying already.
By the way, I've found that gcc-compiled binaries optimized for AMD Family 10 run faster on Intel Xeon 53xx than gcc binaries optimized for Intel Core2. Just because you optimize specifically *for* one architecture doesn't mean it will automatically pessimize for everything else, nor should it.
i think the problem is a simple conflict of interest. its like building a car engine and then build the dyno that tests the engine horsepower. if anything i hope they are forced to break off that part of their company into a new one that has to support any client which pays them. so sure intel can pay them to make theirs work, but then amd should have equal opportunity. intel knew making a good compiler had a pretty decent chance of improve the competitions cpus aswell. as it currently stands, this seems like intel trying to stay as a monopoly.
The normal method for the CPU dispatcher is to do the following:Quote:
Originally Posted by Particle
1. Ask the CPU what optimization it can use.
2. Use it.
Intel is either asking if it is an Intel chip first before following this normal programming convention OR they add a step where they ignore the answer to the first question if it is not an Intel chip.
Either way it would take somebody that is pretty naive or extremely biased to not understand that either of those actions is purposeful.
Especially if Intel has been told about this issue and they have not fixed this obvious bug. (ie. Something that bypasses normal conventions is a bug. Or it is intentional and purposeful; and therefore unethical... take your pick.)
I'm not sure what is worse... rabid AMD fanboi'ism or blatant blindness by other people that are pretending to be impartial. (AMD fanboys do not pretend to be unbiased/impartial.)Quote:
Originally Posted by Dalten
Intel is not following standard programming rules and guidelines. They need to fix their obvious bug. (And should have done so years ago when it was discovered.)
Friend, you shock and suprise me when you say this information presented by the prof. on the practices of Intel are hard to believe.Quote:
Originally Posted by zalbard
In my experience, this is standard operating practice(sop).
Mind clarifying on why you feel the decades long monopolistic practices of Intel is hard to believe?
Edit. I am not saying AMD is an ideal corporation either; that is just it : a corporations' business is to stay in business by making money. You do not stay in business long facing excellent competition. Lying, cheating, stealing, bribery, sabotage, internal politics/pressure... this is standard operating practice whether it be government, religion, fox news, cnn, the view, resteraunts&hotels, local city muncipals, et al. Earth. Welcome to it.
You don't appear to have actually taken the time to become familiar with the workings of the compiler. This came up a year or two ago with a very detailed article explaining exactly what it's doing. It's not a matter of simply picking and choosing which instruction sets are present and using them. I'm a programmer by profession. I understand the necessities of doing what you're talking about and don't feel like it's a conspiracy. To see conspiracy there would of course be idiotic. The Intel compiler will instead do stuff like use x87 instead of SSE when it's an AMD chip even if SSE is supported. It's obviously not a good choice for performance reasons and there's no need to do it for the sake of compatibility. It's something that should be changed.Quote:
Originally Posted by keithlm
Ah, but the normal method for creating a CPU dispatcher is to:Quote:
Originally Posted by keithlm
1. Write the software
2. Test it against all CPU's it will be used on and debug it as necessary
Do you see the issue here? Intels compiler must be extremely rigorously tested, it's not simply "Do you have SSE2? Great, we'll use it.". Intel has a HUGE steak in their compiler working on all CPUs, even if the performance is less than it could be on some of them. Could you imagine being a software company that used it only to find out that due to bug CSC2932812 in stepping 3 second-gen Athlons it did not interwork properly and you lost major accounts as a result of your software crashing on all servers that make use of that hardware? You'd never use an Intel compiler again, and you might even be iffy on using any Intel software at all. Yet that kind of things certainly could happen.
I mean seriously. The guys who work on gcc certainly test their compiler on a variety of processors for this very reason, and they will tweak the program based on the feedback they find. Intel has no reason to do this, nor is it reasonable to expect them to.
Intel compilers are the fastest ones afaik, even for AMD, so if it's THAT obvious, why aren't lots of people using different compliers?Quote:
Originally Posted by BatteryOperated
Maybe it has something to do with deep optimisations for Intel chips and not taking just as much time optimising for AMD? Since no compilers are better...
I'd like to see the proof, as some kind of source code, disassembled or whatever.
This is what I am talking about and it might be the case.Quote:
In other words, they claim that they are optimizing for specific processor models rather than for specific instruction sets.