You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Can I use mapConcurrently with afterwards sorting the results of the list? #148
Actually, I can. But it looks like the main benefit of the using mapConcurrently for me in the case -- the speed up of overall computations disappears, the resulting sorted list is obtained not faster than just from simple mapM with no asynchronous operations. This is the case when sorting is done either in the strict manner (even with force from deepseq) or lazy (the default one).
Intuitively, the function pipe of mapConcurrently and sort should give the results approximately in the same time, as sum of both mapConcurrently and sort alone, no matter of further their usage by sorting or just printing to the IO stream.
There are many reasons you might not be seeing a parallel speedup. Do you have a reason to believe this is a problem with mapConcurrently in particular?
There are many reasons you might not be seeing a parallel speedup. Do you have a reason to believe this is a problem with mapConcurrently in particular?
Well, if I use just IO operations (e. g. print) afterwards mapConcurrently, the speedup is present. If I use sorting (Data.List.sortOn e. g., with force or without it, with $! or without it) in between, then it looks that there is no speedup at all. It can be at the end of sort, but I would like to have at least nice explanation for the possible reasons (or better, to find a way to deal with situation).
That sounds surprising, but I don't know of any issue with mapConcurrently that would lead to that behaviour. Suggest more investigation, have you tried ThreadScope?
That sounds surprising, but I don't know of any issue with mapConcurrently that would lead to that behaviour. Suggest more investigation, have you tried ThreadScope?
No, actually not. It looks like it is worthy to do this.
That sounds surprising, but I don't know of any issue with mapConcurrently that would lead to that behaviour. Suggest more investigation, have you tried ThreadScope?
I use NixOS. Threadscope fails to build for it because of dependencies conflict.
I think it can be related to the realtime Linux kernel with the 6.1* branch. It has some strange behaviour on my machine, but when I switched to 5.15 LTS RT series the other issue with combining streams has disappeared.
I think it can be related to the realtime Linux kernel with the 6.1* branch. It has some strange behaviour on my machine, but when I switched to 5.15 LTS RT series the other issue with combining streams has disappeared.
Well, no, the issue with the sorting is still present on the 5.15.* realtime Linux kernels. Therofore, it is not primarily related to Linux kernel.
Activity
simonmar commentedon Aug 30, 2023
There are many reasons you might not be seeing a parallel speedup. Do you have a reason to believe this is a problem with
mapConcurrentlyin particular?Oleksandr-Zhabenko commentedon Aug 30, 2023
Well, if I use just IO operations (e. g.
print) afterwardsmapConcurrently, the speedup is present. If I use sorting (Data.List.sortOne. g., withforceor without it, with$!or without it) in between, then it looks that there is no speedup at all. It can be at the end of sort, but I would like to have at least nice explanation for the possible reasons (or better, to find a way to deal with situation).simonmar commentedon Aug 30, 2023
That sounds surprising, but I don't know of any issue with
mapConcurrentlythat would lead to that behaviour. Suggest more investigation, have you tried ThreadScope?Oleksandr-Zhabenko commentedon Aug 30, 2023
No, actually not. It looks like it is worthy to do this.
Oleksandr-Zhabenko commentedon Aug 30, 2023
I use NixOS. Threadscope fails to build for it because of dependencies conflict.
414owen commentedon Nov 21, 2023
I've jailbroken threadscope's dependency constraints on NixOS with this command, in the past:
@Oleksandr-Zhabenko
Oleksandr-Zhabenko commentedon Nov 21, 2023
I think it can be related to the realtime Linux kernel with the 6.1* branch. It has some strange behaviour on my machine, but when I switched to 5.15 LTS RT series the other issue with combining streams has disappeared.
Oleksandr-Zhabenko commentedon Jan 6, 2024
Well, no, the issue with the sorting is still present on the 5.15.* realtime Linux kernels. Therofore, it is not primarily related to Linux kernel.