Add slim dedicated implementation of Parallel loop APIs

[kg]

#57283 made Parallel.Invoke/For/ForEach work in WASM but there's a lot of cruft attached, the ideal long term solution is a simple custom implementation that doesn't pull in unnecessary dependencies. This probably pairs well with a wasm implementation of PLINQ.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

#57283 made Parallel.Invoke/For/ForEach work in WASM but there's a lot of cruft attached, the ideal long term solution is a simple custom implementation that doesn't pull in unnecessary dependencies. This probably pairs well with a wasm implementation of PLINQ.

Author:	kg
Assignees:	-
Labels:	arch-wasm
Milestone:	-

[ghost]

Tagging subscribers to this area: @dotnet/area-system-threading-tasks
See info in area-owners.md if you want to be subscribed.

Issue Details

---

#57283 made Parallel.Invoke/For/ForEach work in WASM but there's a lot of cruft attached, the ideal long term solution is a simple custom implementation that doesn't pull in unnecessary dependencies. This probably pairs well with a wasm implementation of PLINQ.

Author:	kg
Assignees:	-
Labels:	arch-wasm, area-System.Threading.Tasks
Milestone:	7.0.0

[stephentoub]

@kg, is this still something we might do or should we close it?

[kg]

@kg, is this still something we might do or should we close it?

I don't have the data I would need to answer this. I think it's a question of whether the normal parallel APIs have too much overhead (in both time and code size) on the current implementation. Do we have benchmarks for them that already run?

[stephentoub]

Do we have benchmarks for them that already run?

I don't see any benchmarks for these in dotnet/performance.

[kg]

I would lean towards not doing anything unless we hear feedback from users that it's necessary, especially since we will eventually have actual threading available and the slim version will not be useful in that scenario. These APIs have a lot of overhead in their design to begin with.

We would have the ability to conditionally ship either the slim or non slim version depending on whether we have threads, at least. So if we build a slim implementation it won't make the threaded scenario worse.

[stephentoub]

SGTM.