-
Notifications
You must be signed in to change notification settings - Fork 18
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
Difference between MLton and MPL block-sizes ? #112
Comments
So your programs are definitely running out of memory. Often, this triggers an error message like you are seeing, but not always, because Linux might also kill your program without warning. Do you have a sense for how big the working sets are for the failing programs? To estimate working set size, you could measure the resident set size of the program when compiled with MLton. And how much memory does your machine have? Note that parallel programs use more memory than sequential programs: on P processors it's possible to need as much as a factor P times more memory. |
Oh I see. So here is the result of
I believe there's no workaround then... except splitting workings sets to share between procs 🤔 |
I'm surprised to see such a large gap. If you're willing to share, could I take a look at your code? |
For sure, just clone the git and checkout commit
To compile with MLton, simply do
... or with MPL:
Then, to run the solver on the example aforementioned:
EDIT: Some important optimizations have been made on the working sets and now the MPL-produced program is not killed anymore. Still, memory usage remains relatively huge. So, please checkout on the above mentioned commit to see the program being killed. |
Ah, I've figured it out. Here's a commit that fixes the memory problem: shwestrick/heron@e41059c The GC in MPL is integrated with the scheduler and is actually disabled entirely if the fork/join library is not loaded. So first, I needed to put this in the .mlb:
Then, there is also a heuristic in the GC design which I had to work around. At the moment, MPL avoids performing GC at the "top level" because it often interferes with parallelism. For sequential programs this is obviously broken, but we've only been running MPL on parallel programs so far! So, I put in a With these changes, when I run |
Great, this is a good start. i will investigate to which extent we can enjoy MPL's parallelism for our problem! |
Hello! I've been trying to compile our solver (Heron) with MPL instead of MLton. Our goal is to switch to MPL in order to enjoy parallelism in the future.
No runtime-args. Most of our regression tests pass, but not tests that are memory-greedy. In such cases, our program is simply killed without any information.
With runtime-args. I tried to increase the block-size to 256M. Results are slightly better but now the output is
Our solver still correctly executes with MLton. Do you think this problem is related to block-sizes ?
Known issues.
Int.toString
andReal.fromString
are used but not in parallel so it should not be relevant. None of the unsupported MLton Features are used.Thanks. Best,
The text was updated successfully, but these errors were encountered: