Re: More efficient MEX or MEX-like interface

[Fredrik Lingvall]

David Bateman 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.
>
> I thought that it some cases there were additional copies of object
> when a pointer was requested even for non complex data due to
> const/non-const issues. I would not suggest altering Octave to have
> matlabs split real/imag parts of matrix values form as that is not C99
> compatible and we'd just have to but the parts back together when
> calling external libraries.
Does this mean that BLAS/LAPACK expects complex data stored in the same
way as complex data is currently stored in Octave?

/F