• R/O
  • HTTP
  • SSH
  • HTTPS

List of commits

Tags
No Tags

Frequently used words (click to add to your profile)

javac++androidlinuxc#windowsobjective-ccocoa誰得qtpythonphprubygameguibathyscaphec計画中(planning stage)翻訳omegatframeworktwitterdomtestvb.netdirectxゲームエンジンbtronarduinopreviewer

rayonパッケージ


RSS
Rev. Time Author
9dc5b44 2018-08-09 06:28:33 Josh Stone

Add a workaround for rust#52966

c328aff 2018-08-09 03:08:05 Josh Stone

Force lazy_static 1.0.2 for older CI

5107676 2018-07-17 12:33:18 bors[bot]

Merge #583

583: Release rayon 1.0.2 and rayon-core 1.4.1 r=nikomatsakis a=cuviper

This updates the test and demo dependencies, then it's about time for
new rayon and rayon-core releases!

Co-authored-by: Josh Stone <cuviper@gmail.com>

c90e1ba 2018-07-12 05:19:36 Josh Stone

Release rayon 1.0.2 / rayon-core 1.4.1

1eea820 2018-07-12 05:19:16 Josh Stone

Update rayon-demo dependencies

23e7d9b 2018-07-12 05:19:16 Josh Stone

Update rand to 0.5

b35e9d7 2018-07-12 02:34:06 bors[bot]

Merge #584

584: Fix doc links to avoid warning on nightly r=cuviper a=LukasKalbertodt

Hi there!

- one link was just a typo (incorrect `::*`)
- the other one was a wrong intra-link (which are still unstable)

I converted the wrong intra-link to a normal one for now. Would be awesome if this can be merged, as `cargo doc` is quite noisy on nightly when you have many dependencies :)

Co-authored-by: Lukas Kalbertodt <lukas.kalbertodt@gmail.com>

2179f45 2018-07-11 17:23:46 Lukas Kalbertodt

Fix doc links to avoid warning on nightly

- one link was just a typo (incorrect `::*`)
- the other one was a wrong intra-link (which are still unstable)

c2150b1 2018-07-03 02:52:57 bors[bot]

Merge #578

578: Implement opt_len for ranges of large integers r=nikomatsakis a=cuviper

If the length of a range of `i64`, `u64`, `i128`, or `u128` would
actually fit in `usize`, we can return that from `opt_len` to enable
some optimizations, namely indexed `collect` into vectors. To drive
such ranges, we'll actually iterate over `(0..len)` instead, and then
map it to the larger type.

Co-authored-by: Josh Stone <cuviper@gmail.com>

8ba64ab 2018-06-28 02:45:58 bors[bot]

Merge #563

563: [WIP] Add try_fold, try_for_each, try_reduce r=nikomatsakis a=cuviper

There are six variations here, matching the existing non-try suite:

- `try_fold` and `try_fold_with`
- `try_for_each` and `try_for_each_with`
- `try_reduce` and `try_reduce_with`

All of them operate on `Try::Ok` values similar to the exiting non-try
methods, and short-circuit early to return any `Try::Error` value seen.
This `Try` is a pub-in-private clone of the unstable `std::ops::Try`,
implemented for `Option<T>` and `Result<T, E>`.

TODO and open questions:

- [ ] Needs documentation, examples, and tests.
- [x] Should we wait for `Iterator::try_fold` and `try_for_each` to
reach rust stable? They were stabilized in rust-lang/rust#49607,
but there's always a chance this could get backed out.
- **Resolved**: they're stable in 1.27
- [x] Should we wait for stable `std::ops::Try`? We could just keep
ours private for now, and change to publicly use the standard
trait later (on sufficiently new rustc).
- **Resolved**: keep our pub-in-private `Try` for now.
- [x] Should `try_fold` and `try_fold_with` continue to short-circuit
globally, or change to only a local check?
- When I first implemented `try_reduce_with`, I use a `try_fold` +
`try_reduce` combination, like `reduce_with`'s implementation, but
I didn't like the idea of having double `full: AtomicBool` flags
in use.
- If `try_fold` only errors locally, then other threads can continue
folding normally, and you can decide what to do with the error
when you further reduce/collect/etc. e.g. A following `try_reduce`
will still short-circuit globally.
- **Resolved**: changed to just a local check.

Closes #495.

Co-authored-by: Josh Stone <cuviper@gmail.com>

800c736 2018-06-20 07:51:32 Josh Stone

Add generic tests for try_fold

e2336fe 2018-06-20 02:57:43 Josh Stone

Make it clearer that we're driving some ranges indexed

151df5c 2018-06-20 02:48:01 Josh Stone

Fix overflow in usize as i64

383af35 2018-06-19 11:54:34 Josh Stone

Implement opt_len for ranges of large integers

If the length of a range of `i64`, `u64`, `i128`, or `u128` would
actually fit in `usize`, we can return that from `opt_len` to enable
some optimizations, namely indexed `collect` into vectors. To drive
such ranges, we'll actually iterate over `(0..len)` instead, and then
map it to the larger type.

b864f48 2018-06-15 09:56:15 Josh Stone

Document ParallelIterator::try_*

93d96bd 2018-06-15 09:56:15 Josh Stone

Break out try_reduce_with to avoid unwanted constraints

Even though we already know `Self::Item: Send`, this doesn't apply
constraints to its `Try::Ok` and `Error`. Therefore, if we map to
`Result<Option<Ok>, Error>` at a high level, we have to require extra
`Send` bounds to make sure that map is `Send`, like:

<Self::Item as Try>::Ok: Send,
<Self::Item as Try>::Error: Send

We can avoid this by implementing a custom `Consumer`, where we only
hold it as a `Result` in the low level `Folder` regardless of `Send`.

da16c2c 2018-06-15 01:22:45 bors[bot]

Merge #577

577: bump docopt to 1 r=cuviper a=ignatenkobrain



Co-authored-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>

d8ff8bd 2018-06-14 15:22:54 Igor Gnatenko


bump docopt to 1

a4aef05 2018-06-07 06:45:34 Josh Stone

Remove the global short-circuit from try_fold

It will now only consider the locally-folded items for short-circuit
behavior. It's expected that this will commonly be followed by a
`try_reduce` or the like with its own global effect.

8842e9d 2018-06-07 06:27:02 Josh Stone

simplify TryReduceFolder::full

1257f47 2018-06-07 06:15:38 Josh Stone

Avoid two-layer tries, doubling short-circuit logic

dedb06c 2018-06-07 06:15:38 Josh Stone

Add try_reduce_with

2104bc6 2018-06-07 06:15:38 Josh Stone

Fix try_fold/reduce fullness

b407051 2018-06-07 06:15:38 Josh Stone

Add try_for_each and try_for_each_with

3b91b55 2018-06-07 06:15:38 Josh Stone

Emulate Try for stable rustc

036993a 2018-06-07 06:15:38 Josh Stone

WIP try_fold, try_fold_with, and try_reduce

efed926 2018-06-07 06:12:19 bors[bot]

Merge #550

550: add bridge from Iterator to ParallelIterator r=cuviper a=QuietMisdreavus

Half of https://github.com/rayon-rs/rayon/issues/46

This started getting reviewed in https://github.com/QuietMisdreavus/polyester/pull/6, but i decided to move my work to Rayon proper.

This PR adds a new trait, `AsParallel`, an implementation on `Iterator + Send`, and an iterator adapter `IterParallel` that implements `ParallelIterator` with a similar "cache items as you go" methodology as Polyester. I introduced a new trait because `ParallelIterator` was implemented on `Range`, which is itself an `Iterator`.

The basic idea is that you would start with a quick sequential `Iterator`, call `.as_parallel()` on it, and be able to use `ParallelIterator` adapters after that point, to do more expensive processing in multiple threads.

The design of `IterParallel` is like this:

* `IterParallel` defers background work to `IterParallelProducer`, which implements `UnindexedProducer`.
* `IterParallelProducer` will split as many times as there are threads in the current pool. (I've been told that https://github.com/rayon-rs/rayon/pull/492 is a better way to organize this, but until that's in, this is how i wrote it. `>_>`)
* When folding items, `IterParallelProducer` keeps a `Stealer` from `crossbeam-deque` (added as a dependency, but using the same version as `rayon-core`) to access a deque of items that have already been loaded from the iterator.
* If the `Stealer` is empty, a worker will attempt to lock the Mutex to access the source `Iterator` and the `Deque`.
* If the Mutex is already locked, it will call `yield_now`. The implementation in polyester used a `synchronoise::SignalEvent` but i've been told that worker threads should not block. In lieu of https://github.com/rayon-rs/rayon/issues/548, a regular spin-loop was chosen instead.
* If the Mutex is available, the worker will load a number of items from the iterator (currently (number of threads * number of threads * 2)) before closing the Mutex and continuing.
* (If the Mutex is poisoned, the worker will just... stop. Is there a recommended approach here? `>_>`)

This design is effectively a first brush, has [the same caveats as polyester](https://docs.rs/polyester/0.1.0/polyester/trait.Polyester.html#implementation-note), probably needs some extra features in rayon-core, and needs some higher-level docs before i'm willing to let it go. However, i'm putting it here because it was not in the right place when i talked to @cuviper about it last time.

Co-authored-by: QuietMisdreavus <grey@quietmisdreavus.net>
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>

d488733 2018-06-07 04:21:37 QuietMisdreavus

updates to IterBridge + add ParallelBridge to prelude

8bf18d7 2018-06-07 03:19:24 QuietMisdreavus

tweak ParallelBridge and IterBridge

11bd211 2018-06-07 02:55:50 bors[bot]

Merge #536

536: Stabilize the rayon testsuite r=nikomatsakis a=cuviper



Co-authored-by: Josh Stone <cuviper@gmail.com>