Home > Archive > Fortran > July 2004 > Re: First Fortran program vectorized with experimental version of GNU Fortran.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: First Fortran program vectorized with experimental version of GNU Fortran.
|
|
|
| On Tue, 13 Jul 2004 23:51:37 +0200, Toon Moene
<toon@moene.indiv.nluug.nl> wrote:
>I wrote:
>
>
>Perhaps there's interest in her talk at the GCC Summit.
>
>Here's the underlying paper - sorry, the URL is quite long because it
>comes from Google's cache:
>
>http://www.google.com/search?q=cach...cc+summit&hl=nl
>
>[ It turns up slightly garbled in my Mozilla (1.6) screen, but still
> readable ]
>
>Hope this is useful.
Can someone explain to me how the program was vectorized.
I have worked with a vectorizing compiler which had assembly language
support for vectorization.
Is this what they had?
| |
| Aart Bik 2004-07-13, 8:58 pm |
|
"john" <z2345678998765432y@sbcglobal.net> wrote in message
news:h5s8f0pklml0stsn6nt52dv7n1cpeq6fa7@
4ax.com...
> Can someone explain to me how the program was vectorized.
>
> I have worked with a vectorizing compiler which had assembly language
> support for vectorization.
>
> Is this what they had?
A vectorizing compiler is a compiler that can automatically detect and
exploit vector instructions (whether these instructions are also supported
in the assembly language is irrelevant for this definition, but they usually
are). Traditionally, vectorizing compilers targeted rather expensive
supercomputers, such as pipelined vector processors. Today, vectorizing
compilers are becoming popular again to target multimedia extensions in your
desktop, such as the MMXT technology and Streaming-SIMD-extensions for IA-32
processors. See http://www.intelcompiler.com/ for specific information on
the Intel compilers and links to related research.
--
Aart Bik, Senior Staff Engineer, Intel Corporation
2200 Mission College Blvd. SC12-301, Santa Clara CA 95052
email: aart.bik@intel.com URL: http://www.aartbik.com/
| |
| James Van Buskirk 2004-07-14, 8:57 pm |
| "Aart Bik" <aart.bik@intel.com> wrote in message
news:cd1ut9$ee8$1@news01.intel.com...
> A vectorizing compiler is a compiler that can automatically detect and
> exploit vector instructions (whether these instructions are also supported
> in the assembly language is irrelevant for this definition, but they
usually
> are). Traditionally, vectorizing compilers targeted rather expensive
> supercomputers, such as pipelined vector processors. Today, vectorizing
> compilers are becoming popular again to target multimedia extensions in
your
> desktop, such as the MMXT technology and Streaming-SIMD-extensions for
IA-32
> processors. See http://www.intelcompiler.com/ for specific information on
> the Intel compilers and links to related research.
Can the Intel compilers actually vectorize anything? I've got
some code that is intended to be vectorizable, but I have my
doubts as to whether any current compiler is capable. It would
be quite a bit of work for me to sift through years of Intel
SPAM to figure out how to download Intel's compiler, download the
M$ toolkit, install them, figure out the required compiler
switches, compile, save to CD-ROM, take *.exe down to COMPUSA,
carry out timings on SSE2-capable machine... could you or
someone at Intel determine whether your compiler can vectorize
my examples with significantly less effort than this?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Aart J.C. Bik 2004-07-14, 8:57 pm |
|
"James Van Buskirk" <not_valid@comcast.net> wrote in message
news:mSjJc.92054$XM6.13798@attbi_s53...
> Can the Intel compilers actually vectorize anything? I've got
> some code that is intended to be vectorizable, but I have my
> doubts as to whether any current compiler is capable. It would
> be quite a bit of work for me to sift through years of Intel
> SPAM to figure out how to download Intel's compiler, download the
> M$ toolkit, install them, figure out the required compiler
> switches, compile, save to CD-ROM, take *.exe down to COMPUSA,
> carry out timings on SSE2-capable machine... could you or
> someone at Intel determine whether your compiler can vectorize
> my examples with significantly less effort than this?
For someone who is not willing to try out the compiler and does not even own
SSE2-capable IA32-processors, you sure expect a lot of service :-)
Nevertheless, feel free to contact me directly with your examples....
| |
| James Van Buskirk 2004-07-16, 3:58 pm |
| "Jan Vorbrüggen" <jvorbrueggen-not@mediasec.de> wrote in message
news:2lpgicFfd7ehU2@uni-berlin.de...
> I am under the impression that you skip the last few steps - the
> Intel compiler will inform you which of the loops it managed to
> vectorize.
Why are you under the impression that I wanna vectorize loops?
It seems to me that there are some who believe that too much
computing power is too good for the unwashed masses such as
myself and that whenever action is taken to limit the computing
power I can access it is taken as a function of maximum possible
throughput, not the throughput my programs will actually
achieve. Thus, processor capabilities beyond what the 486 had
such as pipelining and SIMD can in principle limit the processing
power usable in real code because at some point the max throughput
limit is reached, processors are throttled back, not because of
the actual performance anyone really attains but because the
max throughput counting pipelining and SIMD has passed some
imaginary line in the sand. It's really hard for the current
crop of programming languages to express algorithms in any way
other than purely sequential 486-style code, but somehow one
has to be able to do so or else one loses out on a big chunk of
the processor's capabilities, and Fortran seems a better candidate
than most languages for breaking with the sequential paradigm.
But you have to be able to vectorize everything to take advantage
of SIMD, and not everything is a subset of loops. Take a look
at some of the code on my home page:
http://home.comcast.net/~kmbtib/index.html
The code samples come in pairs: an fft*.i90 file and an fft*.f90
file. The *.i90 file is the (linear) code and the *.f90 is a
test file for it. If you look at the *.i90 files you will see
that the code is grouped as real and imaginary parts of the
calculation mixed together followed by a combination step that
creates a complex result from these parts. 2-way SIMD seems
to be a no-brainer because all the compiler has to do is combine
each real part calculation with the adjacent imaginary part
calculation, assuming alignment of the complex input matrix.
Intel's compiler does in fact seem to have a certain capability
in this regard, which I think you will agree is a good thing.
I don't know whether that capability extends to vectorizing code
when the two halves of a given vector are physically separated
in the code as written. It can be easier to write a code
generator if it is not required to group SIMD components
together and you can count on the compiler to do it for you,
but this seems to me to be a difficult thing for it to do. The
code generator scaled2g.f90 writes code like this.
In summary, I think you would be unhappy if a compiler didn't
take advantage of pipelining opportunities and I think you
should be similarly unhappy when it doesn't detect and implement
the SIMD potential latent in a given source. If you think
about it, you may also be able to come up with a wide variety
of SIMD possibilities that don't match what occurs in the
more popular benchmarks.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
|
|
|
|
|