Related articles |
---|
[2 earlier articles] |
Re: Death by pointers. chase@centerline.com (1995-09-06) |
Re: Death by pointers. hbaker@netcom.com (1995-09-11) |
Re: Death by pointers. graham.matthews@pell.anu.edu.au (1995-09-12) |
Re: Death by pointers. chase@centerline.com (1995-09-12) |
Re: Death by pointers. preston@tera.com (1995-09-13) |
Re: Death by pointers. ECE@dwaf-hri.pwv.gov.za (John Carter) (1995-09-23) |
Re: Death by pointers. stefan.monnier@epfl.ch (Stefan Monnier) (1995-09-25) |
Newsgroups: | comp.compilers |
From: | Stefan Monnier <stefan.monnier@epfl.ch> |
Keywords: | optimize, parallel |
Organization: | Ecole Polytechnique Federale de Lausanne |
References: | 95-09-099 95-09-061 95-09-120 |
Date: | Mon, 25 Sep 1995 10:13:30 GMT |
In article 95-09-120,
John Carter <ECE@dwaf-hri.pwv.gov.za> wrote:
] >to ensure better use of cache lines, but in C, it cannot be, because
] >some_array_ptr MIGHT be aliased to global. For large enough values of
] >m, the transformed piece of code is at least 3 times faster on a
] >high-performance workstation. Fortran rules usually allow this
] >transformation.
[...]
] Parallel programming can be really hairy if you go at it at fine time
] grain, but there is more than enough going on on a modern workstation
] to merely paralell process at a very high level.
Now tell us all how you want to recode the above-mentionned loop so as to
compensate the factor of 3 speed decrease by a factor of (at least) 3
parallelism. (since this is probably the inner loop, it probably eats up around
80% of the program's time. Don't bother parallelise the rest before you
parallelise the loop).
Stefan
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.