Experimental MEX version

Investigate the advantages and disadvantages of using the MEX interface instead of the Engine interface.

Benchmarking

engEvaluate["r=rand(1,50000000);"]
engGet["r"]; // AbsoluteTiming

• Engine gives 0.9 s.
• MEX with mexGetVariable() gives 0.73 s.
• MEX with mexGetVariablePtr() gives 0.52 s.

What would MEX give us that Engine can't?

• better performance:

  • faster data transfer (only one interprocess transfer)
  • much lower constant overhead for each call
  • Avoids excessive duplication of memory during data transfer

• Getting, and possibly setting, classdef objects (e.g. MException)

• Getting and setting MATLAB function handles. Why is this useful? Setting user-defined handles is probably not particularly useful, and should be strongly discouraged even if supported. However, some useful classes (e.g. biograph!) have members which are function handles. Without supporting function handles we can't seamlessly transfer these objects. *Thus the main reason for supporting function handles is for round-tripping complex objects, but their internal structure shouldn't be exposed to users).

• The biggie: supporting callbacks to Mathematica while making use of the data translation framework that we already have. This would make it possible to apply many numerical algorithms (optimization, integration, ODE solving, curve fitting, etc.) that MATLAB has to functions defined in Mathematica.

##Possible problems that the transition to MEX may bring

• mexEvalString() doesn't return the output, but this can be worked around by evalc().

• directly evaluated commands are not JITted, but this is already worked around by making MEvaluate write them to a script first

• would lose showing/hiding the command window on Windows

• MATLAB would be accessed/started in a different way --- investigate if this brings any problems

• anything else?