Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break into separately requirable parts #3

Open
rreusser opened this issue Apr 27, 2016 · 4 comments
Open

Break into separately requirable parts #3

rreusser opened this issue Apr 27, 2016 · 4 comments

Comments

@rreusser
Copy link
Contributor

rreusser commented Apr 27, 2016

I don't quite know how emscripten works, but elmapack.js ends up at 3.6 MB. When I compile it, it's 5+ MB. That's prohibitive for web use. Do you think it's possible to break this into separate parts? Seems possible to build up a dependency graph to figure out which files to build, but not sure if it's possible to get the parts to talk to each other after passing them through emscripten. (In other words, dynamically linking them)

@rreusser
Copy link
Contributor Author

rreusser commented Apr 27, 2016

Ah, see: https://github.com/kripken/emscripten/wiki/Linking

This is gonna take some research 😄

In the mean time, trying a build with -Oz to see if that reduces the bundle size.

@likr
Copy link
Owner

likr commented Apr 28, 2016

Yes, we need to divide the module.

Currently, I edit src/export-functions.js and rebuild emlapack.js for production use. Only functions listed in export-functions and their dependencies are contained in rebuilt emlapack.js.

I'll research dynamic linking. Thank you for your suggestion !

@rreusser
Copy link
Contributor Author

That makes sense. (Perhaps this is why your bundle size is smaller. -Oz only got it down to 5MB for me.)

Linking is interesting, but it sounds like it may be significantly slower since it can't make the same assumptions about memory location… or something.

My use case is that I'd love to wrap the functions and make them very easily usable. To streamline it for the end-user, it seems possible to build a dependency graph and automate the process of selecting which functions to compile. Like you'd select svd and get just the bundle you need.

@rreusser
Copy link
Contributor Author

Lots more work to do, but made a quick script that just uses regexes and tons of looping to build a dependency graph. Need to expand to cover libf2c and lapack, but it only has to be done once, so it doesn't really need to be efficient. It builds an object of format:

dependencies = { caxpy: [ 'scabs1' ],
  cgbmv: [ 'xerbla', 'lsame' ],
  cgemm: [ 'xerbla', 'lsame' ],
  cgemv: [ 'xerbla', 'lsame' ],
  cgerc: [ 'xerbla' ],
  cgeru: [ 'xerbla' ],
  chbmv: [ 'xerbla', 'lsame' ],
  chemm: [ 'xerbla', 'lsame' ],
  chemv: [ 'xerbla', 'lsame' ],
  cher: [ 'xerbla', 'lsame' ],
  cher2: [ 'xerbla', 'lsame' ],
  cher2k: [ 'xerbla', 'lsame' ],
  cherk: [ 'xerbla', 'lsame' ],
  chpmv: [ 'xerbla', 'lsame' ],
  chpr: [ 'xerbla', 'lsame' ],
  chpr2: [ 'xerbla', 'lsame' ],
  ...

Kinda silly to do it this way, but with a bit more info, seems like this could be used to build a stripped-down version of emlapack, right? Of course this all assumes that emscripten/llvm doesn't automatically strip dead code from static libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants