Somebackground for people reading this in the future (in case it's not locked). I tend to do my programming in a high level language to understand the problem first. After covering all possible corner cases I proceed to translating the code to C++ (or C).
This is a very opinionated post based on my expirience for one particular project. I have not used the latest version of the coder, but I do have expirience with the equivalent product (embedded coder) for converting matlab code to C++ that was included as part of the former Real Time Workshop product. These comments should still apply. Your mileage may vary.
In my situation, the embedded coder was used to make a processing block that fit into part of a larger audio application. The processing block had the job of processing a constant stream of sample buffers in real time. I made the original algorithm in matlab, and the conversion tool made it fairly simple to convert an early prototype into something that could be compiled to native code and used in a real time application. It was also nice to assume that the converted code was functioning numerically identically to the original without possibility of human error in the conversion process (assuming superhuman abilities of Mahworks engineers).
As the algorithm grew in complexity, i started worrying more and more about how to code the matlab interface to the function so that after conversion, it would be easy to interface with the C++ framework (I wanted to monitor the internal states in real time). This eventually started using as much time as the actual algorithm development itself, thus defeating the purpose of using such a tool. I could have broken down the algorithm into smaller chunks and then glued them together using C++, but then I'd loose the ability to have a direct Matlab-only comparison of he complete algorithm.
The coder supports a subset of the Matlab language. In some cases, supported functions are limited in some way. For example, in the application that I was working on, I wanted to be able to modify the characteristics of a filter in real time. I could not use the standard Matlab filter prototyping functions, because the code generation tool would not allow calls to the filter prototyping function with variable arguments. I ended up spending time with a DSP book developing my own implementation, even though we have a signal processing toolbox license.
I got frustrated with the interface issues and coded the algorithm by hand in C++. For my application, there was a 75% performance boost in the favour of the hand written code over the converted code. Performance differences will be very different depending on your application, probably the version of the conversion tool used, and your fondness of your profiler. The conversion tool itself is a complex product that has many settings to learn. Trying to work out how to tweak settings and the matlab code to improve performance uses more time that could be spent hand coding.
I now prefer a more test-assisted approach. I code a prototype in Matlab and tweak until I am sure that it behaves as I want it too. I then think in C++ and recode the algorithm in a way that is more natural to that language. I then make a mex file that interfaces with my C++ code so I can test it against my trusted matlab equivalent. For the problem space that I work in, this is a much more efficient (human and machine) way to get stuff done.
In conclusion, this is just the opinion of one user. Perhaps (as suggesred in a comment on your original post) you should sign up for the trial to see how you get along. However, if you are a bit of a C++ ninja, testing by building mex files does not require an expensive license for an add-on product and it will make you a better developer.
Comparing MATLAB and C or C++ for performance is very complicated. C or C++ are going to be faster in most cases, but in some linear algebra applications it is possible that MATLAB will execute the fastest. I remember a professor that claimed he had FORTRAN applications that ran slower than the equivalent in MATLAB. There are a lot of case studies on this - I would recommend you look at the different studies comparing the speed that turn up in google and compare them to what you're doing to make your decision.
Where I work, we've developed a good management scheme for our Simulink models and their dependencies. Then I've developed a script to proceed with the autocoding step and a colleague developed project files in an IDE, such that upon running my script, all source files are dispatched to a proper folder structure and the project can be readily compiled in the IDE, where someone else also deployed a wrapper code to interface the autocoded software.
The trick (IMHO) is to automate your process the best you can as early as you can. By doing so, you can develop very complex models and then create C code for production in a couple hours. And you can update the models all you like, but the code keeps easy to maintain.
Also, you should really put some testing in place to verify that the generated code does indeed represent the model you had. This is not guaranteed, and while I think Matlab Coder is pretty reliable, it is not error-free.
As it has been said above it depends upon ur application. I tried to convert the decoder (of a communication system) it gives the accurate results but for large number of bits it is slower than its own MATLAB version. So my conclusion was to convert MATLAB code to C by hand.
Another benefits I know: Since it's optimized for technical programming, you may have better performance when writing application on this field. The performance is very dependable, take a look at this question, it provides some helpful information.
I think MATLAB has lots of limitation over normal C coding. I agree that there are so many inbuilt blocks which can be used directly but if you write a code in MATLAB then it will take nearly 5 times longer in comparison to C code because from defining variables to taking loops, switch cases, its very time consuming in MATLAB modeling
You can also generate C/C++ code from multiple entry-point functions or with multiple signatures and then test each function or signature for equivalence with MATLAB source code. For more information, see Equivalence Test C/C++ Code for Multiple Entry-Point Functions and Function Signatures.
To write an equivalence test that generates and tests C/C++ code, define a test class that inherits from matlabtest.coder.TestCase. In your test class, include a methods block with the Test attribute. In the methods block, add a function to contain the test.classdef tEquivalence You can generate code that accepts variable-sized inputs by using the output of coder.typeof (MATLAB Coder) as a build-time input. However, if you specify build-time inputs using coder.typeof, you must specify real run-time inputs for the execute method.
By default, the test case generates code in a temporary directory. To preserve the generated files, use the PreserveInFolder name-value argument in the build method. When the equivalence test fails, MATLAB preserves the generated files regardless of whether or not you use this name-value argument.
Equivalence tests use the MATLAB test framework, which means you can use MATLAB test customizations such as parameterizations. Parameterized tests allow you to test different parameter combinations with less code than if you coded each combination separately. For more information, see Create Basic Parameterized Test.
To customize how MATLAB Coder builds your C/C++ code in the equivalence test, create an instance of a code generation configuration parameter object for your desired build type by using coder.config (MATLAB Coder) and pass the object to the build method.
If you want to test C code, you can use MATLAB Coder to bring the code into MATLAB. You can then write unit tests by using the MATLAB testing framework. You can write richer, more flexible tests by taking advantage of the advanced numerical computing and visualization capabilities of MATLAB.
If you have Embedded Coder, you can run unit tests on generated standalone code (static library or shared library) by using the unit tests with software-in-the-loop (SIL) execution or processor-in-the-loop (PIL) execution.
TestKalmanFilter tests whether the error between the predicted position and actual position exceeds the specified tolerance. The unit tests are class-based unit tests. For more information, see Author Class-Based Unit Tests in MATLAB.
Although you want to test the MEX function, the unit tests in TestKalmanFilter call the original MATLAB function from which you generated the MEX function. When MATLAB Coder runs the tests, it replaces the calls to the MATLAB function with calls to the MEX function. You cannot run these tests directly in MATLAB because MATLAB does not recognize the coder.ceval calls in callKalmanFilter.
The unit tests load the variable position from position.mat and pass position to callKalmanFilter. Therefore, the input to callKalmanFilter must have the properties that position has. In the MATLAB workspace, if you load position.mat, you see that position is a 2-by-310 array of doubles.
When the app runs the test file, it replaces calls to callKalmanFilter in the unit test with calls to callKalmanFilter_mex. The unit tests run on the MEX function instead of the original MATLAB function.
Run the units tests on the MEX function. Specify that the test file is run_unit_tests_kalman and that the function is callKalmanfilter. When coder.runTest runs the test file, it replaces calls to callKalmanFilter in the unit test with calls to callKalmanFilter_mex. The unit tests run on the MEX function instead of the original MATLAB function.
3a8082e126