[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changing octave to exploit multi-core hardware
From: |
Jaroslav Hajek |
Subject: |
Re: Changing octave to exploit multi-core hardware |
Date: |
Tue, 25 Mar 2008 17:15:09 +0100 |
On Tue, Mar 25, 2008 at 3:45 PM, John W. Eaton <address@hidden> wrote:
> On 25-Mar-2008, Quentin Spencer wrote:
>
> | What about multithreading the mapper functions? I guess we're relying on
> | external libraries to actually perform the computations of many of the
> | functions, but I would assume (correct me if I'm wrong) that octave does
> | the looping through the individual elements of an array. It would seem
> | that it would be very straightforward to make the computation of
> | something like cos([1:1000]) faster by just splitting up portions of
> | large arrays and sending them to separate processors.
>
> OK. In the current sources (not 3.0 or the release-3-0-x branch) the
> loop for all single-argument mapper functions is
>
> template <class U, class F>
> Array<U>
> map (F fcn) const
> {
> octave_idx_type len = length ();
>
> const T *m = data ();
>
> Array<U> result (dims ());
> U *p = result.fortran_vec ();
>
> for (octave_idx_type i = 0; i < len; i++)
> {
> OCTAVE_QUIT;
>
> p[i] = fcn (m[i]);
> }
>
> return result;
> }
>
> (this is in liboctave/Array.h).
>
> What would need to happen to send this computation to multiple
> processors? Is it necessary to add special code to enable parallel
> execution of this loop on systems that can do that? If so I'm not
> sure desireable to do that for this loop and every other one like it
> where we could maybe benefit from embarrassingly simple parallelism.
> Cluttering Octave's sources with special code for this just seems
> silly to me. Shouldn't that sort of detail be handled by the compiler
> and and OS kernel automatically?
>
> jwe
>
A single OpenMP directive could do that, or even autoparallelization
with some compilers,
e.g. Intel C++. But there are two obstacles: first, the OCTAVE_QUIT
macro (which breaks independence of cycles) and second, there is no
guarantee that F has no side effects.
--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
- Changing octave to exploit multi-core hardware, Leonardo Ecco, 2008/03/24
- Changing octave to exploit multi-core hardware, John W. Eaton, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, Michael Goffioul, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, Aaron Birenboim, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, Quentin Spencer, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, John W. Eaton, 2008/03/25
- Re: Changing octave to exploit multi-core hardware,
Jaroslav Hajek <=
- Re: Changing octave to exploit multi-core hardware, John W. Eaton, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, Jaroslav Hajek, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, John W. Eaton, 2008/03/25
Re: Changing octave to exploit multi-core hardware, Michael Creel, 2008/03/25