Re: More efficient MEX or MEX-like interface

[David Bateman]

John W. Eaton wrote:
> | though its the choice that FreeMat made and if Octave chooses to go that 
> | way, then optimizing that interface becomes a priority.
>
> One of the primary sources of efficiency problems for the MEX
> interface is the difference in the way Octave handles data
> internally.  For example, Octave stores complex data in arrays of
> pairs of real and imaginary values while Matlab stores them in
> separate real and imaginary arrays.  Since the MEX interface allows
> direct access to the pointers to the real and imaginary arrays,
> passing data in that arrangement forces a copy in Octave but not in
> Matlab.  So if we want better effiency with this interface, I think we
> have to rewrite much of the internals of Octave to store complex data
> differently.
>   
Taking a quick look at the code I see a couple of other major sources of 
inefficiency.

1) prhs in the call to mexFunction causes a copy of the octave_value 
data in all cases, not just for complex data. For example consider the 
code from ov-re-mat.cc

mxArray *
octave_matrix::as_mxArray (void) const
{
 mxArray *retval = new mxArray (mxDOUBLE_CLASS, dims (), mxREAL);

 double *pr = static_cast<double *> (retval->get_data ());

 mwSize nel = numel ();

 const double *p = matrix.data ();

 for (mwIndex i = 0; i < nel; i++)
   pr[i] = p[i];

 return retval;
}

It would be good is we could also have a use methods like

const mxArray *
octave_matrix::as_mxArray (void) const
{
 mxArray *retval = new mxArray (mxDOUBLE_CLASS, dims (), mxREAL);
 retval.set_data (matrix.fortran_vec ());
 return retval;
}

and we'd need an appropriate const version of set_data added to the mex 
interface. Is this possible or am I missing something?

2) The memory allocated with mxCalloc, etc internally to a mex function 
must be copied to an octave_value when leaving the function, as mxCalloc 
allocate with ::calloc, etc (or rather ::malloc and memset). This 
doesn't play well with the C++ new/delete method of allocating memory 
which is the reason for the need for the copy. Frankly, I don't see an 
easy way of addressing this.

Regards
David


--
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary