| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
structure.
|
|
|
|
|
|
- Fixed tests
- Added methods
- Renamed casting methods to be shorter
- Added unsafe versions
Closes #7150
|
|
|
|
|
|
- Fixed tests
- Added methods
- Renamed casting methods to be shorter
closes #7150
|
|
|
|
|
|
|
|
|
|
|
|
These intrinsics are synthesized, so maybe they should be in another
file. But since they are just a single line of code each, based on the
bswap intrinsics and aren't really intended for public consumption (they should be exposed as a
single function / trait) I thought they would fit here.
|
|
Conflicts:
src/libstd/rt/comm.rs
src/libstd/rt/mod.rs
src/libstd/rt/sched.rs
src/libstd/rt/task.rs
src/libstd/rt/test.rs
src/libstd/rt/tube.rs
src/libstd/rt/uv/uvio.rs
src/libstd/rt/uvio.rs
src/libstd/task/spawn.rs
|
|
|
|
|
|
|
|
|
|
It can sometimes be useful to have maps/sets of floating point values.
Doing arithmetic with floats and then using them as keys is, of course, not a good idea.
|
|
This allows mass-initialization of large structs without having to specify all the fields.
I'm a bit hesitant, but I wanted to get this out there. I don't really like using the `Zero` trait, because it doesn't really make sense for a type like `HashMap` to use `Zero` as the 'blank allocation' trait. In theory there'd be a new trait, but then that's adding cruft to the language which may not necessarily need to be there.
I do think that this can be useful, but I only implemented `Zero` on the basic types where I thought it made sense, so it may not be all that usable yet. (opinions?)
|
|
|
|
This is to make sure we track optimizing `vec::from_elem`.
|
|
Moves all the remaining functions that could reasonably be methods to be methods, except for some FFI ones (which I believe @erickt is working on, possibly) and `each_split_within`, since I'm not really sure the details of it (I believe @kimundi wrote the current implementation, so maybe he could convert it to an external iterator method on `StrSlice`, e.g. `word_wrap_iter(&self) -> WordWrapIterator<'self>`, where `WordWrapIterator` impls `Iterator<&'self str>`. It probably won't be too hard, since it's already a state machine.)
This also cleans up the comparison impls for the string types, except I'm not sure how the lang items `eq_str` and `eq_str_uniq` need to be handled, so they (`eq_slice` and `eq`) remain stand-alone functions.
|
|
|
|
Conflicts:
src/libstd/rt/sched.rs
src/libstd/rt/task.rs
src/libstd/rt/test.rs
src/libstd/task/mod.rs
src/libstd/task/spawn.rs
|
|
|
|
|
|
|
|
replaced with OrdIterator
|
|
|
|
|
|
|
|
|
|
This moves them all into the traits submodule, and delegates Ord
to the TotalOrd instance. It also deletes the stand-alone lt, gt,
ge and le functions.
|
|
|
|
|
|
The first two become map_chars and lev_distance. Also, remove a few
allocations in rustdoc.
|
|
|
|
|
|
|
|
|
|
|
|
HashMaps with floats as keys.
|
|
This is caused by StrVector having a generic implementation for &[S]
and so #5898 means that method resolution of ~[~[1]].concat() sees that
both StrVector and VectorVector have methods that (superficially) match.
They are now connect_vec and concat_vec, which means that they can actually be
called.
|
|
r? @brson
links to issues: #7065 the race that's fixed; #7066 the perf improvement I added. There are also some minor cleanup commits here.
To measure the performance improvement from replacing the exclusive with an atomic uint, I edited the ```msgsend-ring-rw-arcs``` bench test to do a ```write_downgrade``` instead of just a ```write```, so that it stressed the code paths that accessed ```read_count```. (At first I was still using ```write``` and saw no performance difference whatsoever, whoooops.)
The bench test measures how long it takes to send 1,000,000 messages by using rwarcs to emulate pipes. I also measured the performance difference imposed by the fix to the ```access_lock``` race (which involves taking an extra semaphore in the ```cond.wait()``` path). The net result is that fixing the race imposes a 4% to 5% slowdown, but doing the atomic uint optimization gives a 6% to 8% speedup.
Note that this speedup will be most visible in read- or downgrade-heavy workloads. If an RWARC's only users are writers, the optimization doesn't matter. All the same, I think this more than justifies the extra complexity I mentioned in #7066.
The raw numbers are:
```
with xadd read count
before write_cond fix
4.18 to 4.26 us/message
with write_cond fix
4.35 to 4.39 us/message
with exclusive read count
before write_cond fix
4.41 to 4.47 us/message
with write_cond fix
4.65 to 4.76 us/message
```
|
|
The code compiles and runs under windows now, but I couldn't look up any
symbol from the current executable (dlopen(NULL)), and calling looked
up external function handles doesn't seem to work correctly under windows.
|
|
|
|
|
