We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
I did some test with my desktop and found everything to be working pretty well (even faster than my M1 macbook)
Performance on a single thread is already pretty decent with slight improvement for more threads
julia> @time dd,ini,act= FUSE.init(:ITER;init_from=:scalars);
nthreads = 1 4.544329 seconds (10.68 M allocations: 1.675 GiB, 32.86% gc time, 0.14% compilation time) nthreads = 4 3.219013 seconds (10.69 M allocations: 1.675 GiB, 31.29% gc time, 0.16% compilation time) nthreads = 8 2.495964 seconds (10.69 M allocations: 1.676 GiB, 11.17% gc time, 0.10% compilation time) nthreads = 16 2.305549 seconds (10.69 M allocations: 1.677 GiB, 10.17% gc time)
Note there are no lock conflicts during the init
RunningFUSE.warmup(dd)gives some locking errors when using threads
FUSE.warmup(dd)
nthreads = 1 44.404490 seconds (366.93 M allocations: 11.523 GiB, 5.45% gc time)' nthreads = 4 39.077457 seconds (372.00 M allocations: 11.657 GiB, 6.13% gc time, 4 lock conflicts)
nthreads = 8 36.465294 seconds (373.95 M allocations: 11.715 GiB, 3.40% gc time, 8 lock conflicts) nthreads = 16 30.831370 seconds (432.66 M allocations: 13.309 GiB, 3.92% gc time, 75 lock conflicts, 0.02% compilation time) 32.200818 seconds (439.29 M allocations: 13.488 GiB, 3.87% gc time, 87 lock conflicts)
Performance with more threads gives some lock conflicts which isn't constant across different runs
The text was updated successfully, but these errors were encountered:
So it's running, just not multithreading properly?
Sorry, something went wrong.
@bclyons12 I think it's running, and the multithreading seems to accelerate the execution. However the speedup may be hindered by lock conflicts.
Two things:
Searching for @threads (and filtering out some that are certainly not the problem for this application) this is what I get:
@threads
We came to the conclusion that the lock conflicts comes from x86 problem on newer julia releases
No branches or pull requests
I did some test with my desktop and found everything to be working pretty well (even faster than my M1 macbook)
Performance on a single thread is already pretty decent with slight improvement for more threads
julia> @time dd,ini,act= FUSE.init(:ITER;init_from=:scalars);
nthreads = 1
4.544329 seconds (10.68 M allocations: 1.675 GiB, 32.86% gc time, 0.14% compilation time)
nthreads = 4
3.219013 seconds (10.69 M allocations: 1.675 GiB, 31.29% gc time, 0.16% compilation time)
nthreads = 8
2.495964 seconds (10.69 M allocations: 1.676 GiB, 11.17% gc time, 0.10% compilation time)
nthreads = 16
2.305549 seconds (10.69 M allocations: 1.677 GiB, 10.17% gc time)
Note there are no lock conflicts during the init
Running
FUSE.warmup(dd)
gives some locking errors when using threadsnthreads = 1
44.404490 seconds (366.93 M allocations: 11.523 GiB, 5.45% gc time)'
nthreads = 4
39.077457 seconds (372.00 M allocations: 11.657 GiB, 6.13% gc time, 4 lock conflicts)
nthreads = 8
36.465294 seconds (373.95 M allocations: 11.715 GiB, 3.40% gc time, 8 lock conflicts)
nthreads = 16
30.831370 seconds (432.66 M allocations: 13.309 GiB, 3.92% gc time, 75 lock conflicts, 0.02% compilation time)
32.200818 seconds (439.29 M allocations: 13.488 GiB, 3.87% gc time, 87 lock conflicts)
Performance with more threads gives some lock conflicts which isn't constant across different runs
The text was updated successfully, but these errors were encountered: