-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
[Multithreading] PROXY_TO_PTHREAD & MAIN_THREAD_EM_ASM causes perf degradation #22570
Comments
To be clear this is not some kind of regression? i.e. you are not claiming that some previous version of emscripten had a faster version of As far as I know there are no delays built into the proxying system. The call to @tlively are you aware of any reason for such a delay? @ravisumit33 perhaps you could share a example of simple program that demonstrates the delay you are talking about? |
Are you doing anything on the main UI thread that is likely to be blocking it? i.e. are you doing synchronous proxying to your background thread? i.e. can you give more details on what you mean by "I used proxying to proxy events coming from UI to this detached thread"? |
Sorry to not provide complete details about the issue. I am doing an async proxy to the detached thread. My main application thread isn't the main UI thread. I instantiate wasm in a web-worker. |
I will try to reproduce in a simple program. Just to be clear, delay isn't in proxying from main application thread to the detached thread. Delay comes in receiving the response from the background (detached) thread which is sending the response back in a synchronous way ( |
So you have the following JS contexts: 0: The main browser UI thread Is that correct? |
I think think this aspect could be a clue, since its not the most common setup. Can you explain a little more about this setup? I assume you create this worker using the normal |
Yes list of JS contexts is correct. I create the worker instantiating wasm using |
Instead of using An example program that demonstrates the issue would certainly be helpful. |
I think we should try to get to the bottom of this since |
By the way I see that you have edit: I see you are using 3.1.56, would upgrading to the latest version be difficult? |
Were you able to build a reproducer? If you are able to run experiments, can you confirm if the issue also occurs when you run the main application thread on the main browser thread? |
Sorry for replying late. I tried multiple approaches to build the reproducer but failed to do so. While trying to build the reproducer, I did both profiling and added logs for timestamp before sending to main applicaiton thread and after message is received on the main application thread. The message was getting received almost instantly. Then, I did the same on my codebase and weirdingly here also the the message was getting received almost instantly as seen by the difference of timestamps (
I am still exploring the root cause of the issue. |
I am unable to build my codebase with 3.1.57 and have opened a new issue for that: #22646 |
Can't run the main application thread on the main browser thread in my codebase due to its structure and that will involve a whole lot of changes. |
Please include the following in your bug report:
Version of emscripten/emsdk:
I am trying to port my application from single-threaded to multi-threaded environment. I cannot ensure max number of threads required at a time by my application, thus I finalized using
PROXY_TO_PTHREAD
. In single-threaded mode, my application used to work like below:main
function does some initialization. Aftermain
function exits, we keep the runtime alive.To port this architecture into multi-threaded environment I used
PROXY_TO_PTHREAD
to create a proxied main thread and kept that thread alive for further processing. I used proxying to proxy events coming from UI to this detached thread. Once done, this thread calledMAIN_THREAD_EM_ASM
to send the response back to the main application thread. Also, this is the onlyMAIN_THREAD_EM_ASM
that the detached thread does. Rest is C++ execution without waiting on anything else.Functionality wise, this model worked well. But when doing performance analysis I figured out that I had a degradation of around 200-400 ms. Upon profiling, I could see that detached thread completed work in time but was waiting for around 200-400 ms for the
MAIN_THREAD_EM_ASM
to complete i.e. for main application thread to receive the response. Also, the main application thread was completey idle around this time. This can be seen in the below screenshot.Is this performance degradation expected? Is there any other way I could model my app to get away with this? How can I minimise the time taken by the detached thread to send back the response?
The text was updated successfully, but these errors were encountered: