This is not surprising behavior. Take a look at the following documentation:
<http://www.mathworks.com/help/simulink/ug/designing-your-model-for-effective-acceleration.html>
In the documentation above you should find the following statement -
"Note: In some instances, Normal mode output might not precisely match the output from Accelerator mode because of slight differences in the numerical precision between the interpreted and compiled versions of a model."
When you use Rapid Accelerator mode, the solver itself is hard coded, so there would be further numerical differences there as well.
Here is a Blog post desribing one such example of this behavior:
<http://blogs.mathworks.com/seth/2011/03/18/different-results-in-accelerated-mode-versus-normal-mode/>
If you would like to find out the exact point in the generated code that causes the divergence, you may want to use the Code Generation Verification API:
<http://www.mathworks.com/help/rtw/examples/using-code-generation-verification.html?searchHighlight=code+generation+verification>
Here is another of blog involving a more than slight difference in performance of generated code and Normal mode performance. This is clearly a very special case where code generation results are very different from actual results due to a numerical singularity:
<http://blogs.mathworks.com/seth/2011/02/01/wrong-answers-and-gimbal-lock/>
If your results slowly diverge, or if the difference in behavior, per time-step, is not dramatically different, the issue may be caused by compiler optimizations.
Particularly, if you are using 32 bit MATLAB with a Visual Studio 2010 compiler (set with 'mex -setup'), there are a list of compiler optimization that are used by default. Turning off optimizations, or using different optimization flags could reduce the difference in results between RSim Executables and Normal Mode:
Hunt through your .mk file (this you your make file), and search for the keyword 'OPTIMIZATION_FLAGS' :
Now set this to:
OPTIMIZATION_FLAGS = /Od /Oy- /arch:IA32
or
OPTIMIZATION_FLAGS = /Od /Oy- /arch:SSE
or
OPTIMIZATION_FLAGS = /Od /Oy- /arch:AVX
By default, if no flag is specified, the '/arch:SSE2' flag is used, and this is what is likely causing the difference.
Here are the discription of these flags from the Microsoft website:
/arch:IA32
Specifies no enhanced instructions and also specifies x87 for floating point calculations.
/arch:SSE
Enables the use of SSE instructions.
/arch:SSE2
Enables the use of SSE2 instructions. This is the default instruction on x86 platforms if no /arch option is specified.
/arch:AVX
Enables the use of Intel Advanced Vector Extensions instructions.
It is more likely for RSim model behavior to be different for 32 bit installations of MATALB than 64, because the 64 bit MSVC 2010 compiler optimization are not extremely different from our own solver's optimizations.
