Fortran - Re: Intel Fortran Compiler

Author

Re: Intel Fortran Compiler

Tim Prince

2004-03-27, 12:16 am

"Dr Chaos" <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message
news:slrnc5htib.6a7.mbkennelSPAMBEGONE@lyapunov.ucsd.edu...
> On Wed, 17 Mar 2004 15:42:54 -0500, Steve Lionel <Steve.Lionel@intel.com>
wrote:
Whether[color=darkred]
implementation is.[color=darkred]
>
> And what is the purpose of the CPUID check?

Subroutines compiled with options like -axP will test a flag set by the main
program, to determine whether the processor was recognized as a processor
which supports (in this case) SSE3 instructions. On this basis the SSE3 or
non-SSE code path is taken.

I haven't had much luck attempting to run P4 SSE2 code on an Opteron. There
appear to be a number of undocumented differences between the variety of
SSE2 supported by Opteron and that supported by Intel CPUs. I doubt that
the Intel compiler goes out of its way to exploit the differences (except
where a certain choice of instructions is expected to optimize for Xeon); if
it did, I would expect the success rate to be closer to 0. I suspect that
it's more difficult for Intel compiler folks to find out about these than
for other compiler vendors, but I think various groups are trying to find a
subsets of SSE instructions which will work on current models of various
brands. It's easy enough to select different options for the main program
and the important subroutines, such that the CPU brand will not be checked
and there is no protection against running into these failures.

Among the reasons for the original use of CPUID check is that there was no
documented way to distinguish Athlons which had the SSE hardware capability
flag on but SSE disabled in BIOS from those which could actually run SSE
code. Also, there have always been differences among models in the numerics
of the instructions which don't satisfy IEEE-754 (e.g. rcpps). It's
probably too difficult for anyone to reverse engineer these sufficiently to
get identical results to some other CPU; if AMD can't make their models
consistent, there's not even a single target to match.

My opinions are personal, probably wrong, yet subject to change.....

Dr Chaos

2004-03-27, 12:17 am

On Thu, 18 Mar 2004 05:23:27 GMT, Tim Prince <tprince@computer.org> wrote:
>
> "Dr Chaos" <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message
> news:slrnc5htib.6a7.mbkennelSPAMBEGONE@lyapunov.ucsd.edu...
> wrote:
> Whether
> implementation is.
>
> Subroutines compiled with options like -axP will test a flag set by the main
> program, to determine whether the processor was recognized as a processor
> which supports (in this case) SSE3 instructions. On this basis the SSE3 or
> non-SSE code path is taken.

OK, that's not what I mean. I think testing for CPU features is fine;
but Steve Lionel said that now Intel compilers specific test for
the manufacturer, and only use the more advanced instructions on
"GenuineIntel" squawking CPUs, regardless of the actual hardware
capability.

> I haven't had much luck attempting to run P4 SSE2 code on an Opteron.

what was the compiler, or was it assembly?

> There
> appear to be a number of undocumented differences between the variety of
> SSE2 supported by Opteron and that supported by Intel CPUs. I doubt that
> the Intel compiler goes out of its way to exploit the differences (except
> where a certain choice of instructions is expected to optimize for Xeon); if
> it did, I would expect the success rate to be closer to 0. I suspect that
> it's more difficult for Intel compiler folks to find out about these than
> for other compiler vendors, but I think various groups are trying to find a
> subsets of SSE instructions which will work on current models of various
> brands. It's easy enough to select different options for the main program
> and the important subroutines, such that the CPU brand will not be checked
> and there is no protection against running into these failures.
>
> Among the reasons for the original use of CPUID check is that there was no
> documented way to distinguish Athlons which had the SSE hardware capability
> flag on but SSE disabled in BIOS from those which could actually run SSE
> code. Also, there have always been differences among models in the numerics
> of the instructions which don't satisfy IEEE-754 (e.g. rcpps). It's
> probably too difficult for anyone to reverse engineer these sufficiently to
> get identical results to some other CPU; if AMD can't make their models
> consistent, there's not even a single target to match.
>
> My opinions are personal, probably wrong, yet subject to change.....
>
>

Gerry Thomas

2004-03-27, 12:17 am

Steve M

2004-03-27, 12:17 am

So the obvious question becomes what happens if one compiles on the
appropriate species of Pentium 4 for what one wishes to target in an AMD
processor and then executes it on said AMD ? Does the code actually run
OK ? What AMD processors support what intel compiler flags at execution
time ? Is the expected performance boost relealised for SSE/2/3 on an
AMD ? Anyone know or is willing to make available some compiled code so
we can find out ?

Steve

replace noname with s_j_madden if you want to reply by e-mail

Dr Chaos wrote:[color=darkred]
> On Wed, 17 Mar 2004 11:38:57 -0500, Steve Lionel <Steve.Lionel@intel.com> wrote:
>
>
>
> Does this mean if I compile with -xW, and run on an Athlon 64, the
> code will work and successfully use SSE2 instructions (implemented in
> Athlon 64)?
>
> if so, why the change between B,N,P vs K and W. Is there a technical
> reason or is there an annoying marketing reason? Is it to hurt
> AMD's SPECmarks? And how long would that last? Only until AMD has its
> own tuned compilers, a very temporary advantage.
>
> I don't think Intel ought to go out of its way to tune to AMD
> processors, but it also shouldn't go out of its way to needlessly
> thwart AMD's compatibility with Intel instruction sets.
>
> At some point AMD or the operating system will respond by faking
> GenuineIntel id's if necessary.
>
> I have no problem buying Intel cpus if they give the best price/performance
> for my application. I do have a problem if they try to make that
> gap from artificial means.
>
>

Steve Lionel

2004-03-27, 12:17 am

On Sat, 20 Mar 2004 00:04:27 +1100, Steve M <noname@yahoo.com> wrote:

>So the obvious question becomes what happens if one compiles on the
>appropriate species of Pentium 4 for what one wishes to target in an AMD
>processor and then executes it on said AMD ? Does the code actually run
>OK ? What AMD processors support what intel compiler flags at execution
>time ? Is the expected performance boost relealised for SSE/2/3 on an
>AMD ? Anyone know or is willing to make available some compiled code so
>we can find out ?

The Intel compiler does not care what kind of processor you compile on. There
are some OPTIONAL switches (/Qx on Windows, -x on Linux) that tell the
compiler to generate code for particular classes of Intel processors. As long
as you don't use those, the code should run fine on non-Intel processors that
properly implement the Pentium instruction set.

You can also use the options for run-time CPU dispatching, /Qax and -ax.
These allow you to specify one or two classes of Intel CPUs to target code
for. At run-time, a check will be made and, if the proper Intel CPU is found,
the targetted code paths will be taken, otherwise a generic path will be
taken.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

Dr Chaos

2004-03-27, 12:17 am

Gerry Thomas

2004-03-27, 12:17 am

"Steve Lionel" <Steve.Lionel@intel.com> wrote in message
news:p63m50p6sd6ikba6dk6h17ek2fvgjup6h7@
4ax.com...
> On Sat, 20 Mar 2004 00:04:27 +1100, Steve M <noname@yahoo.com> wrote:
>
>
> The Intel compiler does not care what kind of processor you compile on.
There
> are some OPTIONAL switches (/Qx on Windows, -x on Linux) that tell the
> compiler to generate code for particular classes of Intel processors. As
long
> as you don't use those, the code should run fine on non-Intel processors
that
> properly implement the Pentium instruction set.
>
> You can also use the options for run-time CPU dispatching, /Qax and -ax.
> These allow you to specify one or two classes of Intel CPUs to target
code
> for. At run-time, a check will be made and, if the proper Intel CPU is
found,
> the targetted code paths will be taken, otherwise a generic path will be
> taken.

It's worthwhile for IVF users to look at the VC++ Pro (the optimizing
compiler that comes with the full blown VS.NET 2003, not the minimal VC++
standard edition required by IVF) optimizations choices (blended, \G5-7)
for Intel and AMD 32/64 bit cpus. The cpuid sample that comes with VC++ Pro
interrogates without prejudice either the Genuine Intel or the Authentic
AMD cpu capabilities that it finds and the OS support for such.

--
Ciao,
Gerry T.
______
"Visual Fortran is part of the Microsoft family of Visual Tools." --
DIGITAL Visual Fortran, Getting Started, 1998.

Sponsored Links