Port of BLAS, LAPACK, etc?

1,199 views
Skip to first unread message

MikeB_2012

unread,
May 23, 2013, 11:29:28 AM5/23/13
to emscripte...@googlegroups.com
A theoretical question(s):  Javascript has a few matrix math libraries.  Some I found are:

glMatrix - up to 4x4 matrices, webgl focused
Sylvester - arbitrary size matrices incl. basic ops
numeric.js - arbitrary size matrices incl. basic ops plus SVD
Google Closure - arbitrary size matrices incl. basic ops
math.js - arbitrary size matrices incl. basic ops with possibly more advanced functionality

With the exception of the last, each appears to be a homebrew functionality.  Math.js is drawing upon JAMA which is a recognised library (well, in some circles).  Other than that, the libraries are largely unproven.  I would argue however that there is increasingly a case for javascript having a solid proven matrix math library; with the development of opencl/webcl, javascript could be a language every bit as useful in research as C/C++/Fortran while being far more 'approachable' (yeah, I know, Python/Ruby but let's meet in a pub and debate speed issues, ubiquity, approachability, etc)

So, the questions are:

a)  is it worthwhile to consider porting over some of the 'industry standard' numeric libraries like BLAS/LAPACK; and
b)  would it currently be possible?

Note that speed is a the defining issue.  Speed will come eg. opencl, webcl, js engine improvements (just look at the progress in the past two years!)


Note -  I've been developing in Matlab pretty exclusively for the past decade.  Having recently decided to make the break from that I looked around at the languages that I'd used (in order of my familiarity): Fortran/C/C++/Java/Python.  Then I looked at the language landscape and instantly related to two: Julia and Javascript/Nodejs.  All that to say, I'm not new to programming per se, but I haven't used a compiled language in a very long time so I'm a newbie all over again.

Alon Zakai

unread,
May 23, 2013, 8:43:39 PM5/23/13
to emscripte...@googlegroups.com
It's definitely possible. We might need to be careful in the wrapping API to keep it fast, but that is feasible too. The result would likely be faster than existing libraries, and possibly bring in additional functionality not present in JS libraries.

- Alon




--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Jony Hudson

unread,
May 24, 2013, 7:41:58 AM5/24/13
to emscripte...@googlegroups.com
I've looked at this a bit. You can use f2c to convert the BLAS/LAPACK code to c and then it compiles straightforwardly with emscripten. I haven't tested it yet though!

The GNU Scientific Library has a c implementation of BLAS, as well as a whole load of other useful stuff, and it also compiles well with emscripten. I haven't yet managed to get all of the tests to pass for the whole library, as there is some detail with floating point rounding which is causing very small discrepancies. But the BLAS component seems to pass all of its tests just fine.


Jony

杨成林

unread,
May 24, 2013, 10:04:11 AM5/24/13
to emscripte...@googlegroups.com
Fortran can be compiled to llvm bitcode, then to js by emscripten.
BLAS/LAPACK is like a specification, like OpenGL. They are very low level and not usually used directly. I don't think they can replace js libraries listed in the first email.


2013/5/24 Jony Hudson <jonye...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
杨成林
Yang Chenglin

MikeB_2012

unread,
May 24, 2013, 10:05:52 AM5/24/13
to emscripte...@googlegroups.com
Ah!  That's very interesting, especially the GSL (was looking at it last night and wondering ...)  Could you elaborate a bit more on your experiences eg. compilation process and challenges, tests run, etc.?

Mike

Jony Hudson

unread,
May 24, 2013, 1:26:21 PM5/24/13
to emscripte...@googlegroups.com
Hi Mike,

 it was very straightforward: following the tutorial, using emconfigure to prepare the build, and emmake to run the makefile just worked! The tests didn't run (i.e. make check doesn't work) out-of-the-box, as the makefile tries to run the output of the emmake-driven-emcc, which is bitcode, so I made a very simple script to link and jsify the test scripts and then run them with node.

Looking through the emscripten settings.js I notice that there are a number of settings related to floating point precision. I suspect playing with these might be the way to fix the rounding problems and get the tests passing.

As Alon has mentioned, the bit that would take some work and some thought would be wrapping a nice JS API around the libraries. I haven't tried that at all yet.


Jony 

Ahmed Fasih

unread,
May 30, 2013, 11:09:28 PM5/30/13
to emscripte...@googlegroups.com
Has anyone looked at Eigen? It's scope is more restricted than GSL but I'm told within that scope it excels.
Thanks,
Ahmed

jarvi...@live.com

unread,
Jun 9, 2013, 1:32:41 AM6/9/13
to emscripte...@googlegroups.com
Eigen has only header files. You don't need to compile Eigen library before use. I tried this example and it is working.

#include <iostream>
#include <Eigen/Dense>
using namespace Eigen;
int main()
{
Matrix2d mat;
mat << 1, 2,
3, 4;
Vector2d u(-1,1), v(2,0);
std::cout << "Here is mat*mat:\n" << mat*mat << std::endl;
std::cout << "Here is mat*u:\n" << mat*u << std::endl;
std::cout << "Here is u^T*mat:\n" << u.transpose()*mat << std::endl;
std::cout << "Here is u^T*v:\n" << u.transpose()*v << std::endl;
std::cout << "Here is u*v^T:\n" << u*v.transpose() << std::endl;
std::cout << "Let's multiply mat by itself" << std::endl;
mat = mat*mat;
std::cout << "Now mat is mat:\n" << mat << std::endl;
}

Oac

William Harvey

unread,
Nov 6, 2015, 5:12:33 PM11/6/15
to emscripten-discuss
Hi Everyone,

I gave this a go (with BLAS/LAPACK/ARPACK).  Proof-of-concept is here:

https://github.com/harveywi/arpack-js

This is hot off the press, and I still need to upload the build files as well as some examples.  But it appears to be doable!

I'm probably not the first person to (successfully) try it, but I'm not sure.  Is anyone familiar with any existing ports?

Cheers,

William

Jukka Jylänki

unread,
Nov 17, 2015, 5:19:07 AM11/17/15
to emscripte...@googlegroups.com
Hey, this is quite nice!

If you have some results of benchmarking between native and JS, it would be cool to hear what numbers you get. Also, Emscripten now has SIMD support, so SSE1 and SSE2 can be compiled over, which could improve performance even more, I presume these libraries do have a SIMD optimized path(?)

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Marat Dukhan

unread,
Dec 16, 2015, 6:18:54 PM12/16/15
to emscripten-discuss
A year ago I did Emscripten (and PNaCl) ports of BLIS, a high-performance linear algebra library developed at UT Austin.

The ports are now upstreamed to https://github.com/flame/blis and some benchmarks are on https://github.com/Maratyszcza/blis-bench

Regards,
Marat
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

Arb Vr

unread,
Jan 16, 2020, 7:16:21 AM1/16/20
to emscripten-discuss
Hi MikeB!

Can you share the steps and sentences that you used to convert your fortran code to EMS?

I'm trying to convert my F77 code into JS/EMS, but I don't know what are the best sentences and steps to do.

Thank you very much!
Reply all
Reply to author
Forward
0 new messages