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)

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
But other way around, i.e. breaking code that never assumed anything by removing nondeterminism... sounds weird
1 reply
enjoinedmot
@enjoinedmot:matrix.org
[m]
thank you WGH
HackerFoo
@hackerfoo:sandbox.hackerfoo.com
[m]
Rayon tests fail on my machine. I'm not sure if it's the new compiler or M1 Mac specific: rayon-rs/rayon#956
Ritchie Vink
@ritchie46

Hi all.. We use rayon extensively in polars and can have multiple levels of par_iter.

Now my understanding is that if the outer par_iter has sufficient groups and the inner par_iter also has many groups we can get stackoverflow due to work stealing.

I believe this can be resolved by setting with_min_len and that is a solution I want to investigate. But before I do so I have a question of another possible path.

Is it possible to retrieve the depth of par_iter calls? . Something like this. This shows two levels of nesting, but we can actually have more.


// this would be level 1
fn inner_work(seq) {
    if par_level == 0 {
        seq.par_iter().some_work()
    } else {
       seq.iter().some_work()
    }
}

// this would be level 0
fn outer_work(seq) {
   seq.par_iter().map(inner_work).collect()
}
wagnerf42
@wagnerf42
hi
we could actually write an adaptor giving you access to that info but i don't think any of the actual adaptors will allow you to retrieve it
outside of manually splitting with rayon::iter::split
Ritchie Vink
@ritchie46
That would be great. Would that be in the scope of the project? It would make it much easier for use to predict if some parallelizing job might sefgault due to SO or not.
Josh Stone
@jistone:fedora.im
[m]
could you pass your own par_level parameter through inner_work/some_work()?
I guess it depends whether you just want par_iter nesting, or the full depth of work-stealing nesting -- but we don't really track that
Ritchie Vink
@ritchie46

could you pass your own par_level parameter through inner_work/some_work()?

In this trivial example we can. But in polars we can have aribitrary nesting as expressions may call expressions. It is very hard to track in there are so many operation that may par_iter and may be very deep.

I guess it depends whether you just want par_iter nesting, or the full depth of work-stealing nesting -- but we don't really track

I am only interested in the par_iter nesting. Then we could apply a rule of thumb that the outer level has parallelization priority and can make the inner levels 1..n sequential.

xmac94x
@xmac94x:matrix.org
[m]
Hi everyone :) I just noticed some weird behavior on our game velorem where we are waiting for some threads to finish in places where we wouldn't have thought they would. I opened a issue with the details: rayon-rs/rayon#969 . Not sure if this is a bug, but we noticed that a threadpool.spawn inside a parallel iterator will let the parallel iterator wait until the spawn completed. Which is not always what we want. Do you know any good workaround for that problem ? Maybe already others experienced it (:
Josh Stone
@jistone:fedora.im
[m]
xmac94x: I think this is the nature of work-stealing, but see my reply on the issue for gory details
(also, don't take my word as gospel!)
xmac94x
@xmac94x:matrix.org
[m]
I understand that rayon is using work-stealing, but not why its not having a check to not steal unreleated work inside a par_iter ? Or even steal work from other scopes
Josh Stone
@jistone:fedora.im
[m]
it has no concept of what is "related"
there's one global queue for each pool, and each thread within the pool has a local deque
Miguel Raz Guzmán Macedo
@miguelraz
Hello!
I'm looking for a good collection of serial vs Rayon's parallelization benchmarks snippets
Thinking of stuff like
Dot product calculation,
Independently processing many strings in a big file
or anything numeric/related to linear algebra