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
Clapack as so #1236
Clapack as so #1236
Conversation
The next emscripten version allows us to use the built-in preload wasm mechanism instead of writing our own. It will also make it so that we don't have to traverse the entire filesystem every time. #1223 |
Should we postpone this until the next emscripten release, which I guess will happen soon? |
Sounds like a plan, current preloading is a bit of a bodge.
…--------------------
Note: I am currently part time, my working days are Wednesday to Friday. Responses may be delayed outside these times.
On 12 Feb 2021 12:02, Roman Yurchak <notifications@github.com> wrote:
The next emscripten version allows us to use the built-in preload wasm mechanism instead of writing our own.
Should we postpone this until the next emscripten release, which I guess will happen soon?
Otherwise this looks very promising indeed thanks @joemarshall<https://github.com/joemarshall> !
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1236 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAK6Y665WWUXNVGCR6EDDOTS6UKDRANCNFSM4XPODWTA>.
This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment.
Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored
where permitted by law.
|
Actually, it occurs to me that the thing I just did to make shared libraries in separate packages work - just overriding FS.open for the duration of the package load, could also be pretty trivially altered to remove the need to go through the whole file tree looking for anything added by the new package. Would save having to wait on the changes to emscripten (do they make preloading of wasm work with side modules, or with LZ4 or something?), and for side modules with shared libraries in, they need loadDynamicLibrary as well as instantiating the wasm, so I think the code will need to stay in or be added as a load plugin somehow or else shared lib modules won't work. |
So maybe it is worth putting this in. I'm easy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's true that it would be nice to have,
-rw-r--r-- 1 root root 21M Feb 12 16:51 scipy.data
-rw-r--r-- 1 root root 379K Feb 12 16:51 scipy.js
earlier rather than later. I'd also like to look into updating scipy version next, and this would likely be useful there. The changes with patching FS.open
look manageable to me.
Could you please resolve merge conflicts?
for lib_name in link_libs: | ||
arg = os.path.join(lapack_dir, f"{lib_name}") | ||
new_args.append(arg) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also remove the INLINING_LIMIT=5
and the -Os
for CLAPACK below, that was an attempt to reduce its size when statically linking, that's no longer relevant.
src/pyodide.js
Outdated
loadPackageChain = loadPackageChain.then(() => promise.catch(() => {})); | ||
await promise; | ||
Module.FS.open = oldOpen; | ||
console.log("LIBS:", allLibs); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably remove this debugging line, or at least use messageCallback
if defined.
We now use emscripten 2.0.14. @joemarshall Would you be able to merge master in and address the above comments? I can help if necessary. |
Yeah can do
…--------------------
Note: I am currently part time, my working days are Wednesday to Friday. Responses may be delayed outside these times.
On 23 Feb 2021 14:44, Roman Yurchak <notifications@github.com> wrote:
We now use emscripten 2.0.14. @joemarshall<https://github.com/joemarshall> Would you be able to merge master in and address the above comments? I can help if necessary.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1236 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAK6Y65M3F6T3DDRK4ZJWADTAO5MRANCNFSM4XPODWTA>.
This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment.
Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored
where permitted by law.
|
it had an HTTP error on build_packages, I think someone with better circleCI permissions than me needs to force rerun of the testws |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two comments otherwise LGTM.
The next emscripten version allows us to use the built-in preload wasm mechanism instead of writing our own. It will also make it so that we don't have to traverse the entire filesystem every time.
and for side modules with shared libraries in, they need loadDynamicLibrary as well as instantiating the wasm, so I think the code will need to stay in or be added as a load plugin somehow or else shared lib modules won't work.
So if I understand correctly we still need the current code, and only using --use-preload-plugins
(or calling emscripten_run_preload_plugins()
on each file) by itself won't be enough? cc @dalcde Should we look into that in a separate PR after this one is merged?
src/pyodide.js
Outdated
// and means doing a long async operation in firefox, | ||
// which can cause warning messages | ||
await preloadWasm(); | ||
self.pyodide._module.reportUndefinedSymbols(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self.pyodide._module.reportUndefinedSymbols(); | |
Module.reportUndefinedSymbols(); |
That was changed earlier in #1195
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still needs reverting..
Co-authored-by: Roman Yurchak <rth.yurchak@gmail.com>
I think preload plugins only compiles and instantiates the wasm, it doesn't do the stuff about bringing symbols from the wasm into the global namespace. It's why even if you use preload plugins you can't call into a module until you dlopen it or otherwise link it in. (I.e. emscripten-core/emscripten#7220 ) |
Incidentally, it is pretty trivial to use the same logic I use here for detecting .so files in shared library modules and apply it to the other module loads, thus removing the need to scan the whole file system. I can put that in as a separate pr once this one is in. |
Can we write our own preload plugin to do this?
|
Now you mention it, that is obviously the right way to do this, can't believe I missed it.
…--------------------
Note: I am currently part time, my working days are Wednesday to Friday. Responses may be delayed outside these times.
On 24 Feb 2021 21:58, Dexter Chua <notifications@github.com> wrote:
Can we write our own preload plugin to do this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1236 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAK6Y6ZJZPHTAIQMQP3JNILTAVY6LANCNFSM4XPODWTA>.
This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment.
Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored
where permitted by law.
|
hopefully the latest push works, now using preload_plugins for everything (with an override for the shared lib packages) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! This does look much better indeed.
src/pyodide.js
Outdated
// and means doing a long async operation in firefox, | ||
// which can cause warning messages | ||
await preloadWasm(); | ||
self.pyodide._module.reportUndefinedSymbols(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still needs reverting..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last thing I forgot: could you please add one (or in this case probably even two) changelog entries to docs/project/changelog.md
. Thanks!
Changelog added |
And support for shared-library packages in general.
So it doesn't have to be included multiple times in scipy (scipy is now 21mb)
It is mostly a surprisingly minor change, except that I had to change it so that it loads wasm asynchronously in even in firefox. Otherwise scipy couldn't link to clapack in firefox. It also loads shared library packages before anything else when you import, this is important because it means that linked in (as opposed to dlopen) shared library calls work fine. I couldn't work out why they didn't, but they didn't work in firefox.
There's a limitation to this which is that shared libraries that depend on other shared library packages may or may not work, I'm not sure...
Closes #473
Closes #240