[Beowulf] Re: Redmond is at it, again

[Robert G. Brown]

On Thu, 10 Jun 2004, Suvendra Nath Dutta wrote:

> 
> On Jun 9, 2004, at 11:11 PM, Robert G. Brown wrote:
> 
> > Scripting languages aren't toys, but neither are they ideal high
> > performance computing vehicles, for the most part.
> >
> 
> I know you say for the most part, but I think this is a perception that 
> we should really look at. Prof. Edelman was really able to challenge 
> this perception with his MATLAB*P. The notion is that MATLAB's 
> implementation of LAPack is really excellent. So if used judiciously 
> (especially as a set of mathematical libraries rather than a scripting 
> engine) it can be faster than most direct implementation of code 
> written in C/C++.

Now really, how can that be?  After all, it is just a library, written
in all probability in C and linked to matlab so that matlab calls can
execute the library functions.  matlab itself is likely written in C or
C++.  Matlab's data structures are almost certainly going to be accessed
through a higher degree of indirection than data structures one might
create inside a dedicated function program, and data access speed alone
can improve by 10-20% from that.  Finally, in C one can implement linear
algebra code in particular using ATLAS, which can all by itself speed
operations up by as much as a factor of three.

Any scripting language to which I can bind an arbitrary code module CAN
be made as fast as launching the code module from a shell, sure.
This is cheating, though -- using the language as a de facto C-running
shell with a more sophisticated data interface than e.g. bash.

And yes, a well-written code module bound to matlab will certainly be
able to beat a badly written module in raw C, especially if it doesn't
really need to run up against any of the warts in matlab's data model or
operational model (and know, I don't know what those warts are except by
hearsay:-).  However this too is obviously cheating.

The fair comparison is well-written C (or C++) code to well written
matlab code, for problems where one CANNOT just encapsulate the
well-written C code "intact" in a matlab enabled call and avoid its
intrinsic overhead altogether except for startup and shutdown.

With that said, I would agree that for some classes of problems and
especially humans, there are efficiency advantages at the human level
associated with wrapping up all that C and hiding it inside an
interactive interface, be it perl, python, mathematica.

> Of course MATLAB's prohibitive licensing policy essentially chokes off 
> any such effort.

Yes, but there are visual python, octave, and more out there that are
open source and that seem to have good overlap with the
human-simplification element of mathematica.  There are even bindings
for some of the advanced scientific libraries for some of these
scripting languages, so you really ARE getting professionally written
and optimized algorithms implemented in efficient code in the underlying
libraries.  I'm hoping that eventually they mature.  MATLAB's licensing
policy provides the open source community with a strong incentive to
contribute and bring them along to maturity...

   rgb

> 
> Suvendra
> 

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu