Can I use mapConcurrently with afterwards sorting the results of the list?

[Oleksandr-Zhabenko]

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.

[simonmar]

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?

[Oleksandr-Zhabenko]

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).

[simonmar]

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?

[Oleksandr-Zhabenko]

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.

[Oleksandr-Zhabenko]

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.

[414owen]

I use NixOS. Threadscope fails to build for it because of dependencies conflict.

I've jailbroken threadscope's dependency constraints on NixOS with this command, in the past:

$ NIXPKGS_ALLOW_BROKEN=1 nix-build -E 'with import <nixpkgs> {}; haskell.lib.doJailbreak haskellPackages.threadscope'
$ ./result/bin/threadscope

@Oleksandr-Zhabenko

[Oleksandr-Zhabenko]

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]

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.