From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2ac7208e3d69354f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-18 21:32:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!194.25.134.62!newsfeed00.sul.t-online.de!newsmm01.sul.t-online.com!t-online.de!news.t-online.com!not-for-mail From: Matthias Kretschmer Newsgroups: comp.lang.ada Subject: Re: Ada and vectorization Date: Wed, 19 Jun 2002 06:28:56 +0200 Organization: Private Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.t-online.com 1024460935 01 6901 MNIpbNISS9AESQ 020619 04:28:55 X-Complaints-To: abuse@t-online.com X-Sender: 520099920815-0001@t-dialin.net User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:26348 Date: 2002-06-19T06:28:56+02:00 List-Id: Guillaume Foliard wrote: > Matthias Kretschmer wrote: > >> As suggest in this thread using pragma for loops only isn't enough I >> think (so making it complicated I think - bloating the language up), >> because if you just think about something like: >> a := a1*a2; >> b := b1*b2; >> c := c1*c2; >> d := d1*d2 >> wouldn't be cool if it is vectorized? you may say, throw anything in an >> array and then put it in a loop, but can't it happen, that these a,b,c >> and d aren't related, so putting it together into one array wouldn't be >> very wise. > > Even if there not related from a semantic point of view, they are from a > computational point of view. For the sake of performance, if performance > matters of course, why should not we layout data in a efficient manner ? > This does not break data abstraction, just the layout. Well I consider this as very ugly, I think - just looking at some compilers I don't feel unwise or stupid - that the compiler has to care about how to rearrange stuff, so it runs fast. Do we always want to read these nice optimization manuals for every new CPU that comes up? I do not want it - for C I can just wait till a new version of icc is out and magic the same code runs much faster on the new cpu (as it was with P4 and before with P3 ans so on ...). > >> Btw. are there Ada compilers available (beside gcc 3.1 - yes the backend >> is capable of using the vector units of at least x86-based cpus as stated >> on gcc.gnu.org) which currently use vectorization and/or inter-procedure >> optimization? > > Just a precision here, GCC 3.1 does not vectorize, it just uses the vector > unit in a scalar manner as a faster x87 FPU. > Have you got any links talking about "inter-procedure optimization" ? ah ok - then I got something wrong - but this is of course available in other compilers ... for the last point just look at the icc documents - afaik it uses the same technique, didn't found useful abstract information about this stuff :( The Intel C Manual itself holds a short abstract what is done with these optimizations enable (btw. inter-procedure optimization is available across module borders - it would be nice to have it, too, for ada across package borders). Btw. refering to you other post - I know that it isn't really trivial to transform a sequential program to a parallel one, but why should be going one abstraction level back be the right step, maybe if it is getting a problem for compiler design, we should even try to find some other solution, even if we loose Ada on the way... On the other hand, the parallelization of code is done in cpus today - they are rearranging the code, so it can be executed in parallel, nothing else has to be done now in the compiler. -- Greetings Matthias Kretschmer