Ok, but modern Intel and AMD CPUs both support SSE3.Quote:
Originally Posted by Hornet331
Printable View
Ok, but modern Intel and AMD CPUs both support SSE3.Quote:
Originally Posted by Hornet331
You are twisting things...Quote:
Originally Posted by Solus Corvus
The AMD crowd would complain that the ICC compiled code doesn't always run the fastest code path on an AMD system (because sometimes it would be slower due to different uarch. tweaks) - LIKE THEY DO NOW. They'd just have different words saying it.
Did you see how many people in this thread think the right thing was done? Most. - the few irrational repetitions.Quote:
Of course there will always be irrational people that will complain about anything. But that's not a reason to not do the right thing.
I would be happy if they simply ran the same codepath. Of course intel would be faster with that code because it would be intel optimized but it would be a level playing field.Quote:
Originally Posted by alfaunits
Nice appeal to popularity. What I see is people rationalizing why an optimizing compiler should output unoptimized code for 1/4 of the customer base.Quote:
Did you see how many people in this thread think the right thing was done? Most. - the few irrational repetitions.
You would be fine.Quote:
Originally Posted by Solus Corvus
I wouldn't care less, because I would (and actually did) test my code to see the performance (were it smaller on AMD than with MSVC code I would have provided 2 executables).
But most would complain again.
ok heres another question.
ignoring what Intel does. who here things its ok if a major benchmark company were to use a brand specific code?
like what we saw with PCmark?
but if lets say all FutureMark products used it, and we saw computer stores showing the PCs scores using a program that was inflated for one brand from the start?
is that fair practice?
and im not a very knowledgeable programmer, so how hard would it be for futuremark to know that what they were using was hindering AMD on purpose?
and is it possible for futuremark to have different code compiled for when a AMD and Intel chip is detected?
and would it be an ok solution for Intel if they were to offer a non AMD compatible version, so developers know they should not be using their software in non intel machines?
That's a nice gesture to provide multiple binaries. Are you going to do the same thing with an AMD compiler if they ever bring it to windows?Quote:
Originally Posted by alfaunits
I'd prefer that AMD and Intel focused on contributing to the MS and GCC compilers then creating their own. In linux at least people can recompile with the compiler that works best with their system. But under windows people will be left wondering if their software is compiled with the "other brand's" compiler. And most windows developers don't supply multiple binaries, much less tell you how it was compiled.
It's possible, though much easier to provide separate binaries.Quote:
Originally Posted by Manicdan
If I need to provide 2 binaries to give the best performance I will.Quote:
Originally Posted by Solus Corvus
I currently provide not 2, but 38 different compiled binaries of the same base code to customers.
No they won't that's why this is not an issue.. ICC does not cripple the code to perform slower than GCC/MSVC code on AMD system!!!Quote:
But under windows people will be left wondering if their software is compiled with the "other brand's" compiler.
And we proved it did hinder? No, we still disagree on that.Quote:
Originally Posted by Manicdan
We agree AMD could be doing better - we don't agree Intel should be helping, in any way.
Yes. (it can be a single executable)Quote:
and is it possible for futuremark to have different code compiled for when a AMD and Intel chip is detected?
You're mixing compatible and not-AMD-optimized?Quote:
and would it be an ok solution for Intel if they were to offer a non AMD compatible version, so developers know they should not be using their software in non intel machines?
If Intel did that, then AMD fanboys would again complain why Intel doesn't make code that runs on AMD systems. We're in a loop here ;)
great job of taking a "what if" question and turning into a biased trollQuote:
Originally Posted by alfaunits
you seem to have a decent background in this, so thanks for being so kind and answering the questions.
first, i do agree with you that Intel should not be helping AMD, so im wondering how this affects programmers if Intel completely ignored other chips. and second, let AMD fall on their faces if they dont provide any developer tools. what do you care about the AMD fanboys? let them complain all they want, its not like there blaming you, are they
That's good. However, most developers don't.Quote:
Originally Posted by alfaunits
It will be an issue if AMD brings its compiler to windows.Quote:
No they won't that's why this is not an issue.. ICC does not cripple the code to perform slower than GCC/MSVC code on AMD system!!!
OK let me answer it technically then only:Quote:
Originally Posted by Manicdan
If you mean separate binaries to get the best performance from each platform then yes.Quote:
ignoring what Intel does. who here things its ok if a major benchmark company were to use a brand specific code?
If you mean a single code that runs faster on either platform than any other code then yes.
Yep. We should sue PCMark for not optimizing their app the best for each architecture.Quote:
like what we saw with PCmark?
I am serious - this is what I think (not that I care what a benchmark-only app does)
It's not - but Intel is not at fault here unless they paid FM to do it.Quote:
but if lets say all FutureMark products used it, and we saw computer stores showing the PCs scores using a program that was inflated for one brand from the start?
is that fair practice?
FM is at fault for not testing.
IF it were hindering AMD on purpose, they would know it - otherwise it means they did not test on an AMD machine.Quote:
and im not a very knowledgeable programmer, so how hard would it be for futuremark to know that what they were using was hindering AMD on purpose?
And it was easy for them to know that ICC can compile better code for AMD than the default one.
Do you mean would it make sense for Intel to provide a compiler that just works on Intel processors? Yes. Considering you would not buy such a thing (since you already needed MSVC) unless you needed real performance gains.Quote:
and would it be an ok solution for Intel if they were to offer a non AMD compatible version, so developers know they should not be using their software in non intel machines?
(i.e. you would buy it if you do a lot of math - not if you do a lot of file copying in your app)
Considering ICC provides better performance on AMD CPUs than MSVC, that would not be needed but.. to answer what-if:Quote:
first, i do agree with you that Intel should not be helping AMD, so im wondering how this affects programmers if Intel completely ignored other chips
I think people would still buy it - I would. I want the added performance benefit on Intel CPUs at least for my customers.
It would be a hassle to compile 2 applications - but I would actually save time not having to test on an AMD machine.
Believe it or not, I am quite calm with this subject.. usually I am very tempered, but don't write it always. This one.. I am writing in a "You guys complain too much; it leaves me puzzled" fashion ;)Quote:
and second, let AMD fall on their faces if they dont provide any developer tools. what do you care about the AMD fanboys? let them complain all they want, its not like there blaming you, are they
Moved this from news.
Something more important than what even a majority of people might believe in an internet forum would be what Intel themselves believe.Quote:
Originally Posted by alfaunits
Let's review the Intel IPP documentation at: http://software.intel.com/en-us/arti...amd-processor/
(I snipped the 64 bit selections out of the above to make it terse. The 64 bit should default to the lowest 64-bit selection. Which it correctly does. Only the 32-bit default selection is bugged.)Quote:
32bit Processor Codes
* px - C-optimized for all IA-32 processors
* w7 - Optimized for Pentium 4 processors
* t7 - Optimized for Pentium 4 processors with Streaming SIMD Extensions 3 (SSE3)
* v8 - New Optimizations for 32-bit applications on IntelŽ CoreTM 2 and IntelŽ XeonŽ 5100 Processors
* p8 - New Optimizations for 32-bit applications on 45nm IntelŽ CoreTM2 Duo (Penryn) family processors and IntelŽ CoreTM i7 processors
For example, If 32bit processor,
the "v8" library will be used for IntelŽ CoreTM 2 Duo CPU, T7300 @ 2.0GHzp, which support MMX, SSE,SSE2,SSE3,SSSE3, EM64T
For AMD processor AMD Athlon64TM 6400+, it supports MMX, SSE, SSE2, SSE3. so the "t7" code will be used on the machine.
That documentation along with the OP's reply from Intel make this a black and white case of a bug.
What people are saying in this thread is that they want that bug to be fixed and for this tool to work the way that Intel has documented that it should work. i.e., AMD chips should now be using the documented "t7" selection. Instead they currently fall back to the slowest "px" extension by default.
You seem to be arguing that people want one of the selections with higher optimizations than what is currently supported by the AMD processor.
As you can see in the link from Intel they can't really run the exact same codepath... But it would be good to see the AMD chip use the appropriate code path that Intel has documented; i.e. SSE3. The Intel chips themselves would still run at one or two steps higher in the selected optimizations shown, but at least the AMD chips would not be using the slowest code. Now IF the AMD chips did support all the extensions of one of the higher selections shown then it would be appropriate for Intel to use that higher selection. (I'm sure some Intel proponents would disagree.)Quote:
Originally Posted by Solus Corvus
Do they provide applications that are heavy on the math or similar that needs CPU optimizations? Then they will or they suck.Quote:
Originally Posted by Solus Corvus
I.e. a Total Commander type app doesn't require any hard optimizations. At least none that the compiler can provide.
Most games don't need optimizations for the CPU, but for the GPU.
If your app is CPU intensive you will provide separate binaries if needed. It's a little work to set up, but it's not harder to test, or maintain.
I think that would force programmers even more to test different builds on different machines.Quote:
It will be an issue if AMD brings its compiler to windows.
If that's what happens, it's a bug, plain and simple. I doubt anyone is arguing that.
I think we are arguing as you said:
I hope that's what people are arguing about, otherwise we wasted a whole lot of time on nothing :DQuote:
You seem to be arguing that people want one of the selections with higher optimizations than what is currently supported by the AMD processor
Quote:
Originally Posted by keithlm
I guess our experiences are different here. In most cases where I need to do heavy number crunching the source code is available. I suppose it would be crappy for a closed-source developer to not optimize for their end user's hardware - but I don't really know how prevalent that is.Quote:
Originally Posted by alfaunits
Personally I am moving away from compiled code where possible anyway. I used to write in nothing but x86 assembly. But I dropped that for interpreted code with small hand optimized sections. The number crunching can be done in a small compiled dll if the interpreter isn't fast enough. It's fairly simple to optimize that section of code for different archs and then simply drop it in.
Perhaps. But only for the programmers that actually care about what they are creating and aren't hounded by unreasonable deadlines and stupid management.Quote:
I think that would force programmers even more to test different builds on different machines.
The default behavior should be to run the highest supported codepath. Of course there area always going to be instructions that one vendor supports that the other doesn't - and they should be used when possible. That's the point of optimization. But doing full optimization for one processor and defaulting to the most archaic version for another is unacceptable - the default should be the greatest common codeset supported by both.Quote:
Originally Posted by keithlm
I didn't see any posts in this thread with anybody arguing that Intel should do anything other than support the highest level of extensions that any particular chip supports.Quote:
Originally Posted by alfaunits
EDIT: Perhaps it got confusing to some people if different wordings were used. In other words you can say: "Intel must use the highest level of optimization possible" or "Intel must optimize it the best that they can" and actually mean the same thing as the line above.
Exactly. Code splitting and modularization of code as much as possible is where the industry is heading in quite a fast pace nowadays.Quote:
Originally Posted by Solus Corvus
Hence the testing required would be even smaller.
Software whose performance is critical is always accompanied with a big testing team.Quote:
Perhaps. But only for the programmers that actually care about what they are creating and aren't hounded by unreasonable deadlines and stupid management.
let's agree to disagree here and leave the rest to lawyers? We won't agree with you, you won't with us. Deal or no deal?;)Quote:
The default behavior should be to run the highest supported codepath. Of course there area always going to be instructions that one vendor supports that the other doesn't - and they should be used when possible. That's the point of optimization. But doing full optimization for one processor and defaulting to the most archaic version for another is unacceptable - the default should be the greatest common codeset supported by both.
@keithlm, I actually misread your post. I think people are arguing whether Intel should use highest supported/optimized code path for AMD or the default and not about the bug.
Even so I think most companies would prefer to simply use it as a chance to get away with a smaller testing budget rather then as a chance to optimize for more hardware. The potential is there though. I'd love to see this taken all the way down to the basic consumer level. Imagine a game that's optimized for both Nvidia AND ATI, that would give the fanboys one less talking point.Quote:
Originally Posted by alfaunits
I can see we aren't going to agree on the topic. Though I don't really trust lawyers to make the right choice in a technical matter. I think they will ultimately make Intel change the default behavior and fix the long-standing bug. But I'd prefer if Intel chose to do it on their own because it's the technically superior choice, not because they are forced to.Quote:
let's agree to disagree here and leave the rest to lawyers? We won't agree with you, you won't with us. Deal or no deal?;)
Bug - ICC code crashing on AMD machines. That was a bug in v7.1. Now we're at v11 - do you really think the bug is still there?
I'm referring to the bug described in the OP article if it is indeed true:
Quote:
When I started testing Intel's compiler several years ago, I soon found out that it had a biased CPU dispatcher. Back in January 2007 I complained to Intel about the unfair CPU dispatcher. I had a long correspondence with Intel engineers about the issue, where they kept denying the problem and I kept providing more evidence. They said that:
Sounds nice, but the truth is that the CPU dispatcher didn't support SSE or SSE2 or any higher SSE in AMD processors and still doesn't today (Intel compiler version 11.1.054). I have later found out that others have made similar complaints to Intel and got similarly useless answers (link link).Quote:
The CPU dispatch, coupled with optimizations, is designed to optimize performance across Intel and AMD processors to give the best results. This is clearly our goal and with one exception we believe we are there now. The one exception is that our 9.x compilers do not support SSE3 on AMD processors because of the timing of the release of AMD processors vs. our compiler (our compiler was developed before AMD supported SSE3). The future 10.x compilers, which enter beta this quarter and release around the middle of the year, will address this now that weve had time to tune and adjust to the new AMD processors.
I get the feeling he used the text from someone else's bug report from v7.1 days and just changed the version.
Would be strange that something like this is not fixed. If true, however, not good for/from Intel.
Why do you get that impression? He's associated with the Copenhagen University college of engineering. He has published online many resources for optimization in assembly, C++, etc. In fact, if you read to the end of the article, he claims to have code and instructions to patch the cpu dispatcher for correct operation. That doesn't exactly sound like someone who would need to copy someone's work.Quote:
Originally Posted by alfaunits
It would be strange. Though you'd have to admit, it would be a rather self-serving mistake.Quote:
Would be strange that something like this is not fixed. If true, however, not good for/from Intel.
I'd prefer not to take Mr Fog at his word. I'd like to test this myself but I don't really have the motivation and I haven't had access to an AMD machine for years.
I didn't say he COPIED someone's work, but he DID use the SAME words his links used just changed the version number of the compiler.Quote:
Originally Posted by Solus Corvus
The problem is not whether he copied someone's text - I think he mistakenly put the wrong compiler version in his text.
And had they been doing it for all this time (5+ years since ICC 7.1), enough customers would have dropped using them, don't you think? Not to even mention someone would have sued them by now for monetary compensation.Quote:
It would be strange. Though you'd have to admit, it would be a rather self-serving mistake.
Did more checks. There is a check for GenuineIntel - I didn't look where it is and what id does after it though.Quote:
I'd prefer not to take Mr Fog at his word. I'd like to test this myself but I don't really have the motivation and I haven't had access to an AMD machine for years.
intel being forced to give technology/rights to amd again :shakes:
intel has always been the far superior company and will continue to do so for a long time to come
These words from the OP article make most sense:
"In other words, they claim that they are optimizing for specific processor models rather than for specific instruction sets. If true, this gives Intel an argument for not supporting AMD processors properly."
Not good wording, but somewhat what I wanted to say. Now, unless some words from ICC manual say otherwise, there's no legal stand to ask Intel to change the current behavior.