- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
링크가 복사됨
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
The documentation is supposed to answer these, so maybe it could use improvement. First off, there is no HT, in the Intel sense,on AMD, in spite of what ZDnet said this week about how AMD had to invent hyperthreading before they could bring Opteron to market. I never heard of anyone disabling hypertransport on AMD. Maybe that's why marketeers from either company don't like it used as an abbreviation. Sorry I don't feel like looking to see if this site has a trademarker or auto-disclaimer, sorely wanted as it may be here.
/O3 doesn't have any architecture dependence
/QaxN and /QaxB are intended to support all compatible processors, but make a separate code path including SSE/SSE2 only for processors recognized as Intel with support for SSE/SSE2. So, the code path taken on AMD is not usually as well optimized as the one for the specific target. /QaxB will not generate separate code paths as often as /QaxN.
/Qipo isn't really architecture dependent, although it could do some optimizations which have more value on Intel than AMD.
/G7 probably has no effect on ifort 8. On earlier compilers, which supported P-III more directly, /G7 would avoid scheduling code in a way which was better for P-III than for P4. Some of what /G7 did was good for AMD, some not.
Scalar replacement is a good optimization for any architecture. I haven't seen it used much explicitly. It is likely to have more effect on Netburst processors.
/Qunroll also is rarely used by itself.Intel compilers normally make good choices of unrolling for optimization by default, unlike gcc/g77 which doesn't unroll without you asking. If you know that your loops aren't long enough for unrolling to be useful, you can use /Qunroll to turn off unrolling. Not architecture dependent.
/Qparallel wouldn't help you on a single CPU AMD, where it might help somewhat on a single Hyperthreaded Intel CPU. If it does anything, it could be more helpful on a dual AMD.
The same comments apply to /Qopenmp, except then the parallelization is controlled directly by the OpenMP directives in the source code. Without the directives, /Qopenmp has no effect except to link with threaded libraries, in case your code, or some you link in, such as MKL, will be using them.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
rajesh
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
any comments on comparisions posted at Boston Univ (link below)? They don't say anything on what type of processors they used....
http://scv.bu.edu/SCV/Archive/linux-cluster/compiler-performance.html
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
