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
race for and hyper for need to improve (maybe for in general) #2844
Comments
|
It all depends on the workload that you're giving per iteration. In this example, the workload is very small compared to overhead of starting threads, cutting up the batches, collecting results. If you run this with the snapper, you'll see it takes a long time before even the first worker thread is started. Before that, it is just building the |
|
Further to the fact that adding two numbers together is simply not enough work to make the parallelism worth it, the code is also not threadsafe, since it writes to |
|
Also, there's something very wrong with: I'm not sure what the intent is here, but initializing the same array from multiple threads, is very bad indeed. Probably the only reason this code doesn't segfault, is that it actually never got around to running it from more than one thread. This happens if the overhead of managing batches and setting up the next batch, is larger than the time it takes to run a batch asynchronously. |
|
Ah, right. Very wrong. That should have been @sum-fib[$_]. I'm not at my best, today... |
I guessed that's what was meant, but unless you declared a fixed-size array up front, it's still not safe, due to the resize operation. |
|
@jnthn What would be the best way to illustrate this, then? Set up a channel and do something a bit more complicated inside the loop that writes to that channel? |
|
@JJ A |
|
Ah, great. Thanks. Also, I get an error here: |
|
you're causing the fibonacci array to be reified from multiple threads. that's not possible with an iterator like gather/take or the (current implementation of) the ... operator |
|
OK. Thanks. It's better now if I close this. |
The Problem
A 100k loop with race takes 3x the simple for loop. Same with hyper. But it gets worse: if the loop is twice the size, it times out after 10 seconds. Also the for loop without hyper or race.
Expected Behavior
Doubling the size should maybe have improved the time for hyper/race, reducing the overhead.
Steps to Reproduce
Environment
perl6 -v):https://gist.github.com/Whateverable/9a525148d40a3ff0e96963906e9e0263
The text was updated successfully, but these errors were encountered: