From: Jeff on
I have stumbled across a chorus of posts on the issue of compiled local parallel processing restrictions today, while researching the problem of getting multi-thread performance from compiled MATLAB code. The lack of support for local parallel workers is not only puzzling, but downright embarrassing. People to whom one distributes applications are interested in solving real problems in a semi-turn key fashion. In my experience, every one of them running multi-core processors wonders why "fancy" scientific computing software refuses to utilize the resources they've invested in. It is an endless source of phone calls. I am beginning to consider the compiler one of the most useless $5000 ever spent.

MATLAB gets many kudos from me for its products, but disabling these features seems to be a short-sighted business decision. Perhaps they've sold a few more licenses to a tiny group of large-scale cluster customers, but it robs the compiler of practical utility for a much, much larger user base. It inevitably drives any developer trying to deploy real applications away from Mathworks to their open-source competitors or back to plain old C code.

In addition, I have recently discovered that MATLAB MCR (a) refuses to multi-thread even native MATLAB BLAS operations on certain Linux installations and (b) apparently employs thread locking in a manner that forces multiple deployed applications on a single machine to run in a deadly slow, time-shared sequential manner.

Coupling all of this, one begins to wonder what exactly the compiler is for, other than delivering toy demos? I would be happy to be disavowed of any of these observations by a Mathworks representative. Otherwise, I would politely like to add my voice to the chorus asking MathWorks to rethink these hobbled product decisions.

Jeff
From: Matt J on
Hmmm. Thanks for making me aware of this fine print. I too was hoping to deploy MATLAB compiled parallel code to a multicore machine. I guess I'll have to scratch that option...