# Resistance to modernization **URL:** \ **Category:** Uncategorized\ **Created:** [August 8, 2022, 8:23pm UTC](https://fortran-lang.discourse.group/t/resistance-to-modernization/4136 "2022-08-08T20:23:21Z")\ **Posts on this page:** 1\ **Showing post:** 110
**Author:** ![zaikunzhang](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zaikunzhang/32/785_2.png) [@zaikunzhang](https://fortran-lang.discourse.group/u/zaikunzhang)\ **Post date:** [August 19, 2022, 7:28pm UTC](https://fortran-lang.discourse.group/t/resistance-to-modernization/4136/110 "2022-08-19T19:28:24Z")
I am a MATLAB user, so I would like to share my personal view, which may be wrong. > [@RonShepard](#): > > I’m not really a Matlab user, but I’ve watched over the shoulder those who are. If you have some code in Matlab that performs poorly, then the “solution” is to write the code in fortran, compile it, and then link that compiled code into Matlab. No, this is not true (it might have been true last century, but I did not know computers yet at that time). Here is what I copy-paste from the [official documentation of MEX](https://www.mathworks.com/help/matlab/call-mex-files-1.html) (N.B.: it is not my opinion; I only paste it here for your reference; the bold fonts of the last sentence are by me): > [@](#): > > You can call your own C programs from the MATLAB command line as if they were built-in functions. These programs are called MEX functions, and the function name is the MEX file name. MEX functions are not appropriate for all applications. MATLAB is a high-productivity environment whose specialty is eliminating time-consuming, low-level programming in compiled languages. In general, do your programming in MATLAB. **Do not use MEX functions unless your application requires it.** > [@RonShepard](#): > > there is not a way to actually optimize loops and expressions in the Matlab scripting code to achieve optimal performance. One must go outside the language, with fortran, or C, or assembly, to step beyond scripting level performance. This is not true either. First of all, loops: **MATLAB users do not write loops** unless loops are intrinsically needed for the algorithm being coded (e.g., a line search algorithm for optimization intrinsically needs a loop, but a matrix-matrix product is NOT intrinsically a loop). Instead, they write almost everything in terms of matrix/vector operations (that’s in the name: MATrix LAB), which provide most likely the best representation of the mathematics and logic of the algorithm under consideration. I would like to quote my elaboration in the post [Automatic arrays and intrinsic array operations: to use or not to use?](https://fortran-lang.discourse.group/t/automatic-arrays-and-intrinsic-array-operations-to-use-or-not-to-use/4070): > [@Automatic arrays and intrinsic array operations: to use or not to use?](https://fortran-lang.discourse.group/t/automatic-arrays-and-intrinsic-array-operations-to-use-or-not-to-use/4070/1): > > Indeed, as a common principle in MATLAB programming, you should **never** code a matrix/vector operation in loops. **It is a bad practice to re-invent any tool that the language intrinsically provides.** You may argue that this is because MATLAB is slow at loops as a scripting language. But I understand it from a more philosophical perspective: **why does the language provide the functionality if we are not encouraged to use it?** Second, expressions: all the built-in operations (e.g., matrix-matrix/vector multiplication/addition, matrix factorization, linear solver …) are optimized and they are performant **out of the box** unless your problem is extraordinary or you specify a wrong platform-dependant option (most users do not and need not know how to specify such an option, because it is rarely needed). In addition, MATLAB optimizes expressions (up to a certain level). For example, suppose that you write ```auto x = y*B' ``` where `B'` is the transpose of a matrix `B`, `y` is a row vector, and `*` is a matrix-vector product. According to my test ( **without any tuning** ), MATLAB will not take the transpose of B, but will automatically calculate it as ```auto x = (B*y')' ``` > [@RonShepard](#): > > Is it possible to write, compile, and tune applications for optimal performance in these languages, or must the programmer go outside of the language to achieve these things? Sure. See [Performance of the MATLAB Compiler: Speedups by Two Orders of Magnitude Are Possible](https://www.mathworks.com/company/newsletters/articles/performance-of-the-matlab-compiler-speedups-by-two-orders-of-magnitude-are-possible.html), which is an announcement made in 1996. I did not check what is the current status, but it seems to have elvolvded to the [MATLAB coder](https://www.mathworks.com/products/matlab-coder.html), but I am not sure since I have never used/needed it. > [@RonShepard](#): > > but with the popular fortran compilers one also has some control within the language over which instructions are allowed, how expressions are evaluated, how loops are optimized, how parallelization can be exploited, and so on. Loops are rarely needed as mentioned above. MATLAB does provide (some) control on how the matrix-vector operations are evaluated — you can specify the library to link to, but you do not need to do so unless your platform is unusual (hence most users do not know the existence of such an option). Admittably, it does not provide control on how **expressions** should be evaluated — but why should the user control it if it is already optimized? To de-optimize it? For parallelization in MATLAB, see [the documentation of `parfor`](https://www.mathworks.com/help/parallel-computing/parfor.html) for example — **wait,** you do not really need to read the documentation. Just write ```auto parfor iter = 1 : maxiter % Your parallel code here end ``` and it will work surprisingly well without any tuning or specifying any option. Of course, if you would like to control its behavior, you do need to consult the documentation, but most users do not need. --- _[View the full topic](https://fortran-lang.discourse.group/t/resistance-to-modernization/4136)._