Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 29 10:33
    willcrozi ready_for_review #970
  • Sep 29 10:32
    willcrozi synchronize #970
  • Sep 26 19:20
    cuviper synchronize #964
  • Sep 25 04:29
    BedDweller closed #980
  • Sep 25 02:18
    BedDweller opened #980
  • Sep 24 19:32
    bors[bot] closed #978
  • Sep 24 19:32

    bors[bot] on master

    Fix typos Found via `codespell… Merge #978 978: Fix typos r=cu… (compare)

  • Sep 24 19:27

    bors[bot] on staging

    Fix typos Found via `codespell… Merge #978 978: Fix typos r=cu… (compare)

  • Sep 24 19:27

    bors[bot] on staging.tmp

    (compare)

  • Sep 24 19:27

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • Sep 24 19:27

    bors[bot] on staging.tmp

    Fix typos Found via `codespell… [ci skip][skip ci][skip netlify… (compare)

  • Sep 24 12:24
    kianmeng review_requested #978
  • Sep 24 12:23
    kianmeng synchronize #978
  • Sep 24 12:22
    kianmeng edited #978
  • Sep 24 12:22
    kianmeng synchronize #978
  • Sep 24 12:21
    kianmeng synchronize #978
  • Sep 24 12:07
    willcrozi synchronize #970
  • Sep 23 23:07
    bors[bot] closed #979
  • Sep 23 23:07

    bors[bot] on master

    Fix tiny typo in licensing sect… Merge #979 979: Fix tiny typo … (compare)

  • Sep 23 23:01

    bors[bot] on staging

    Fix tiny typo in licensing sect… Merge #979 979: Fix tiny typo … (compare)

Josh Stone
@jistone:fedora.im
[m]
@oliver-giersch: I just published rayon 1.5.2
oliver-giersch
@oliver-giersch
@jistone:fedora.im Hey thanks! Much appreciated
epilys
@epilys:matrix.org
[m]
Hello all
Would a PR adding wasm target code to run jobs on the main process (without WebWorkers/threads) be accepted?
so that you can compile crates that use rayon to wasm without having to do any changes.
Josh Stone
@jistone:fedora.im
[m]
@epilys there are two similar issues already open:
rayon-rs/rayon#591
rayon-rs/rayon#861
spawn is the biggest challenge that I know of, if code expects that to make independent progress
I think this shouldn't be hard-coded for wasm targets, but it could be a feature that users may want to enable in wasm builds
epilys
@epilys:matrix.org
[m]
Yeah that makes more sense. My team needs it for our compiler so we are interested in contributing it.
thank you 😊
forbisc
@forbisc
If I have two different threads that are spawning task into different rayon::scope, and they share the global thread pool. Is there any reason to believe that rayon would fairly share the threads among the different scopes? Basically I'm wondering if it would give roughly equal time or resources to each scope, or is that behavior not determined?
Josh Stone
@jistone:fedora.im
[m]
@forbisc: there's no concept of fairness. the threads use work stealing when they are idle, taking tasks from any other thread's queue, with no visibility into their "origin" like scopes.
task stealing happens at the front of the queue, essentially FIFO, but it's random which thread is stolen from.
broadly speaking, rayon is opportunistic, trying to maximize execution throughput. I think tokio would be a better fit if you're concerned about fairness or latency.
forbisc
@forbisc
Thank you! Makes sense. Rayon does not make any guarantees about which thread will be stolen from (if multiple threads have tasks waiting).
zr40
@zr40:zr40.nl
[m]
I'm iterating over a list of files that each contain a number of items that I'd want to process in parallel. Right now I'm basically doing files.into_par_iter().filter_map(get_items_from_file).flat_map_iter(process_item).collect(). However this way get_items_from_file can only return all the items in a file at once. What would be a way to provide these items to the iterator as soon as they're available?
Josh Stone
@jistone:fedora.im
[m]
zr40: it sounds like get_items_from_file would do well in a flat_map_iter
zr40
@zr40:zr40.nl
[m]
how would that let get_items_from_file return items before it’s done?
Josh Stone
@jistone:fedora.im
[m]
I was thinking as a regular Iterator, but I can't guess more without knowing what that function is doing
zr40
@zr40:zr40.nl
[m]
the function takes one file and returns the N items that are present in the file
Josh Stone
@jistone:fedora.im
[m]
well sure, but can you do that incrementally in Iterator::next?
zr40
@zr40:zr40.nl
[m]
ah, you meant that I could implement an Iterator. Sure I can do that. get_items_from_file is built like a state machine so that shouldn't be too hard to adapt
enjoinedmot
@enjoinedmot:matrix.org
[m]
Hello people! I recently inherited a project with rayon in its dependencies, and I made a patch that changed .into_par_iter() to .into_iter() after finding the proeject wouldn't compile due to a trait bound error.
If anyone with specific knowledge has a moment, could you let me know if this should change at all the result of the logic that was changed? To me it looks like it should only be a performance hit, but I wanted to make sure.
WGH
@WGH:torlan.ru
[m]
So you basically removed parallelism here, no?
9 replies
enjoinedmot
@enjoinedmot:matrix.org
[m]
It does compile and seems to work after the change to .into_iter() Also, this might be out of scope, but actually just satisfying the trait bound and restoring the logic to what it was would be great, but I didn't get success right away. If anyone has general or specific advice I would be very grateful.
It seemed to me like that was the case, but I just jumped into these crates so I thought I might ask an expert. 😄
Dirkjan Ochtman
@djc
you should probably explain more about the trait bound issue so you can just keep it going in parallel :)
enjoinedmot
@enjoinedmot:matrix.org
[m]
I can find the trait bound error...
here's the trait bound error. 48 | pub struct Iter<T> { | ------------------ doesn't satisfy rayon::range::Iter<u32>: Iterator | = note: the following trait bounds were not satisfied: rayon::range::Iter<u32>: Iterator which is required by &mut rayon::range::Iter<u32>: Iterator
The project is complex, so there was some amount of backporting and updating in uneven ways before I came to it. At some point the logic that used .into_par_iter() didn't compile anymore.
Dirkjan Ochtman
@djc
that must have been due to some particular change in the code base?
enjoinedmot
@enjoinedmot:matrix.org
[m]
but it's safe to say that .into_par_iter() is not deterministic..?
the very next line is .step_by(c as usize) - where c is a variable that's set a long way up the stack.
So I would think .step_by() would consume the result of the previous line. Which would be reached in a non-deterministic way, but would in fact always result in the same return.
but I am not an expert so I thought I would ask. 😅
WGH
@WGH:torlan.ru
[m]
usually rayon is used in such way it wouldn't matter
enjoinedmot
@enjoinedmot:matrix.org
[m]
It's better to know I should be concerned with such a change rather than just assuming it's okay though. 😄 thank you @djc and WGH for responding.
I appreciate your crate! I might be spending more time with it soon... 😄
WGH
@WGH:torlan.ru
[m]
I mean it's usually wrapping a bit of logic that's trivially parallelizable, and the results are aggregated in a way it's easy to reason about
What method is called on the resulting iterator, for instance?
enjoinedmot
@enjoinedmot:matrix.org
[m]
.step_by()
WGH
@WGH:torlan.ru
[m]
And then?
enjoinedmot
@enjoinedmot:matrix.org
[m]
.ennumerate()
WGH
@WGH:torlan.ru
[m]
Those are unsubstantial
enjoinedmot
@enjoinedmot:matrix.org
[m]
I think my core question is - will .step_by() ever see anything different by changing to .into_iter() rather than into_par_iter()? If it does, then I need to get into the trait bound issues.
I might need to anyway, but... 😅
If this is a 'fix' that only slows performance, that might mean I could wait to return to this issue
WGH
@WGH:torlan.ru
[m]
It won't, but this is the wrong question, because things down the line might change
But this whole question looks silly: I can imagine a code that breaks from parallelization because it assumes particular determinism