comp.lang.ada
 help / color / mirror / Atom feed
From: Matthias Kretschmer <schreib_mir_du_spacken@gmx.de>
Subject: Re: Ada and vectorization
Date: Sun, 16 Jun 2002 22:07:09 +0200
Date: 2002-06-16T22:07:09+02:00	[thread overview]
Message-ID: <aeir5d$8fe$06$1@news.t-online.com> (raw)
In-Reply-To: dstanbro-FA230C.22490316062002@news-server.bigpond.net.au

I think, that this job should be done by the compiler itself, without 
changing the language:
a) I do not want to specify everywhere which feature to use
b) vectorisation could be useful in many places, don't we want to use it 
anywhere, we get speed gain from the vector unit?
c) there are good examples that there is no need - think of x86 architecture 
and intel's c compiler, it uses mmx/sse/sse2 if one let's him to use, 
everywhere it makes sense and the performance gain is for clean written 
programs high
d) why binding this to variables - in one place it would be usefull to use 
vectorisation for this part of code, in the other place is it not, with the 
same variables - so explicitly using it just for one bunch of array 
variables could be very inefficient comparing to another approach - why not 
grouping together variables used in records (e.g. someone using for 
3d-representation a record with x,y and z kartesian coordinates)? Ok one 
could enhance this feature, to record constructs, but why?
e) on many architectures the vector unit is just a coprocessor, so fpu could 
calculate one part and vu the other one, I think we want to let the 
optimizer decide how to use both units to get the best performance - so why 
we don't let the optimizer decide when to use vu, too?

GNAT uses as backend the GNU Compiler Suite - in 3.1 it is implemented - so 
using the same code generator, which is capable of using mmx/sse/3dnow or 
something now in some way (do not ask me how much - I just know, that 
povray is far faster after compiling it with the intel c compiler ...).

Dale Stanbrough wrote:

> Guillaume Foliard wrote:
> 
>> Hello,
>> 
>> I start to learn how to use the Intel's SSE instruction set in Ada
>> programs with inline assembly. And while reading Intel documentation (1)
>> I was asking myself if Ada could provide a clean way of vectorization
>> through its strong-typed approach. Could it be sensible, for the next Ada
>> revision, to create some new attributes for array types to explicitly
>> hint the compiler that we want to use SIMD instructions ?
>> Language lawyers comments are definitly welcome. As SIMD in modern
>> general purpose processors is largely available nowadays (SSE, SSE2,
>> Altivec, etc...), IMHO, it would be a mistake for Ada to ignore the
>> performance benefit this could bring.
> 
> 
> I think the best way to do this is via pragmas. There is one pragma -
> Annotate - which would be perfect for the job.
> I think Annotate is a Gnat only thing - the real work would have
> to be done with an ASIS like tool.
> 
> Very much like the fortran world, where the structured comments can
> be ignored by ignorant compilers, and the program still behaves
> correctly (if not as fast).
> 
> Dale

-- 
Greetings
Matthias Kretschmer



  reply	other threads:[~2002-06-16 20:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-16  9:56 Ada and vectorization Guillaume Foliard
2002-06-16 12:50 ` Dale Stanbrough
2002-06-16 20:07   ` Matthias Kretschmer [this message]
2002-06-16 22:38     ` Robert A Duff
2002-06-18  8:24       ` Matthias Kretschmer
2002-06-18 10:02         ` Dale Stanbrough
2002-06-18 16:21           ` Matthias Kretschmer
2002-06-18 19:13             ` Robert A Duff
2002-06-18 20:12               ` Matthias Kretschmer
2002-06-18 20:51                 ` Guillaume Foliard
2002-06-19  4:28                   ` Matthias Kretschmer
2002-06-18 20:13             ` Guillaume Foliard
2002-06-18 17:46           ` Ted Dennison
2002-06-16 22:45   ` Ted Dennison
2002-06-17 23:47 ` Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox