Dear Michal,

Thank you for keeping your eye on toolbox development (and sorry for delay in reply).

Our main development platform is Windows meaning that hotfixes and new features usually appear on Windows first.

Usually updated GNU Linux & MacOSX versions follow the Windows release timely (within several days to 1-2 weeks at max).

Situation is different with the current release - 4.4.5.12698, since we also want to try new workaround for famous MATLAB issue on GNU Linux, see [1]. This needs full re-built of GCC (we maintain our version to make it usable) and all related code. This causing delay in releasing new toolbox for Linux.

References.

[1] https://www.advanpix.com/2016/02/22/matlab-error-cannot-load-any-more-object-with-static-tls/

Under "MATLAB instance" I mean the worker in "parfor". MATLAB spawns the required number of  workers automatically. Each of them with its own set of toolboxes, etc.

Every instance of MATLAB loads independent copy of toolbox with default settings (precision, etc.).

Thus, precision should be set up globally, using global settings file - see the mpstartup.m script in toolbox directory.

Also please check the mp.NumberOfThreads setting in the script and how to use it for optimal performance with "parfor".

Thank you very much for your report on this important issue!

We have just fixed it. Please upgrade to newest version of toolbox - 4.4.4.12672.

Would highly appreciate further feedback.

Thank you for your support Michal! This would definitely help us a lot :). 

One more thing - the difference in performance happens only in quadruple precision mode.

Try for example other than 34 setting in mp.Digits().

That is because quadruple case is where low-level optimizations matters the most - and Intel compiler is the best at this level. 

Other, true multiplrecision code has more uniform performance across the platforms / compilers, since memory bottlenecks is the most important issue there.

Thank you,

Pavel.

Dear Michal,

We do explicitly state that toolbox's performance is lower on *Nix systems. For example, please check this comparison post: https://www.advanpix.com/2016/04/27/performance-of-elementary-functions/

However, we do not consider such performance difference is too dramatic or of any "deceiving nature" from our side.

First of all, Linux is mainly used on high-performance computers with many CPU/cores. High number of cores/CPU compensate the performance loss and actually results in higher speed, if enough cores are used. (Please open mpstartup.m script in toolbox directory and read comments for mp.NumberOfThreads command for optimal tuning).

Secondly,  toolbox performance is higher on GNU Linux in some other areas (e.g. matrix computations for moderate precision ranges) compared to Windows version. Thanks to better thread balance, etc. 

MacOSX allows even better thread handling, which leads to even higher performance. Also different CPUs have different capabilities, instruction set, cache sizes, etc - it is natural for software to deliver variable performance in such diverse environments.

Thirdly, toolbox performance is the highest on *nix systems compared to any other competing software.

This is the most important.

Overall 10% of our users rely on GNU Linux (and 15% use MacOSX). We work hard to provide the best performance everywhere, but some things are out of our control. I am sorry for such inconveniences.

Majority of toolbox functions are implemented in C/C++ for the sake of speed. 

But "bsxfun" is one of the functions we implement using M-language. 

It has quite convoluted structure to cover many different use cases = extra overhead.

Manually coded special cases (like yours) are faster thanks to minimal overhead - all operations in this expression are  implemented directly in toolbox core in C/C++ with optimizations for CPU cache, etc.

Hi Michal,

There is no bug in GNU Linux version of toolbox.

The difference in performance is because we have better development tools for Windows.

We have full stack of Intel development tools on Windows: Intel Compiler (ICC), Intel Profiler (VTune), etc.

This allows us to reach much better performance on Windows compared to other platforms. 

We are non-for-profit company and we cannot afford full stack of Intel development tools for ALL platforms - Intel gives us no discounts despite our multiple requests.  

Thus we are using GCC on GNU Linux and MacOSX. GCC stack of tools is good but it is light years behind the Intel compiler. In fact, we maintain our own version of GCC to make it of acceptable quality.

Hopefully we will be able to use Intel tools on all platforms in future

Dear Jason, 

Toolbox already overloads all element-wise operations. Moreover, the error message is perfectly valid, as arrays have incompatible dimensions - in fact,  all MATLABs up to 2016a return the same error message for this operation.

However a year ago (starting from R2016b), MATLAB developers added "implicit arithmetic expansion" to make this kind of operations valid [1].

IMHO the feature is questionable, as it could break old code (e.g. see [2]) and it makes new code incompatible with older MATLABs. 

This feature is not implemented in toolbox for the time being, please use classic MATLAB's techniques. 

For example, A = bsxfun(@times,x,y) does exactly this.

[1] https://blogs.mathworks.com/loren/2016/10/24/matlab-arithmetic-expands-in-r2016b/

[2] http://undocumentedmatlab.com/blog/afterthoughts-on-implicit-expansion 

Dear Iuliia,

Thank you for the question. 

Yes, indeed, fmincon is in our todo list and actually we have beta version of fmincon (not included in toolbox yet). 

What optimization algorithm do you use in fmincon? So far our code supports "trust-region-reflective" and "active-set".

I will send you the code by email in a minute.