Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

*: use AtomicU64 in value #64

Merged
merged 9 commits into from
Sep 19, 2016
Merged

*: use AtomicU64 in value #64

merged 9 commits into from
Sep 19, 2016

Conversation

overvenus
Copy link
Member

Atomic value:

test counter::bench_counter_no_labels                   ... bench:          14 ns/iter (+/- 0)
test counter::bench_counter_with_label_values           ... bench:          98 ns/iter (+/- 7)
test counter::bench_counter_with_mapped_labels          ... bench:         367 ns/iter (+/- 53)
test counter::bench_counter_with_prepared_mapped_labels ... bench:         213 ns/iter (+/- 18)
test gauge::bench_gauge_no_labels                       ... bench:          14 ns/iter (+/- 0)
test gauge::bench_gauge_with_label_values               ... bench:          94 ns/iter (+/- 7)

Mutex value:

test counter::bench_counter_no_labels                   ... bench:          44 ns/iter (+/- 2)
test counter::bench_counter_with_label_values           ... bench:         136 ns/iter (+/- 4)
test counter::bench_counter_with_mapped_labels          ... bench:         400 ns/iter (+/- 44)
test counter::bench_counter_with_prepared_mapped_labels ... bench:         250 ns/iter (+/- 4)
test gauge::bench_gauge_no_labels                       ... bench:          43 ns/iter (+/- 1)
test gauge::bench_gauge_with_label_values               ... bench:         131 ns/iter (+/- 7)

cc #59

@siddontang
Copy link
Contributor

I prefer extracting these to a AtomicFloat structure.

- cargo test $FEATURE
script:
- cargo test --features dev
- cargo test --features="dev nightly"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why two cargo test?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to test nigltly feature too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so why not test "dev nightly" directly?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default feature uses Mutex<f64>, the nightly uses AtomicF64.

@@ -41,6 +42,8 @@ mod registry;
mod vec;
mod histogram;
mod push;
#[cfg(feature="nightly")]
mod atomicf64;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where is atomicf64?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, my fault, now it's here, please review.

pub val_type: ValueType,
pub label_pairs: Vec<LabelPair>,

#[cfg(not(feature = "nightly"))]
pub val: RwLock<f64>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wrap all in AtomicF64, not in value.
Histogram will use AtomicF64 too. It is not good to use RwLock and AtomicF64 in two places and we have too many nightly cfg flags.

@siddontang
Copy link
Contributor

Histogram can use AtomicF64 too.

pub fn inc_by(&self, delta: f64) {
loop {
let current = self.inner.load(Ordering::Acquire);
let new = current.as_f64() + delta;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just use std::mem::transmute?


#[cfg(feature = "nightly")]
#[test]
fn test_atomic_atomicf64() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's ok to use the same test case no matter features is enable or not.

// See the License for the specific language governing permissions and
// limitations under the License.

#[cfg(not(feature = "nightly"))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not put these into a submodule and then reexport it like:

#[cfg(feature = "nightly")]
mod imp {
...
}

#[cfg(not(feature = "nightly"))]
mod imp {
...
}

pub use imp::AtomicF64;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@overvenus
Copy link
Member Author

@siddontang
I will send a PR for histogram separately.

@siddontang
Copy link
Contributor

LGTM

PTAL @BusyJay @disksing

@siddontang
Copy link
Contributor

It is ok to use AtomicF64 in histogram here.


#[inline]
pub fn get(&self) -> f64 {
self.inner.load(Ordering::Acquire).as_f64()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ordering::Relex is enough

Copy link
Member

@BusyJay BusyJay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rest LGTM


#[inline]
pub fn set(&self, val: f64) {
*(self.inner).write().unwrap() = val;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why parentheses?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better readability.

Copy link
Member

@BusyJay BusyJay Sep 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. It make no sense to put self.inner into parentheses. It should be either *(self.inner.write().unwrap()) = val or *self.inner.write().unwrap() = val.

}
}

trait Transform64bits: Copy {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why define a trait? Isn't it enough to just use the transmute function?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too many unsafe code block, although they are the same. I think as_u64 and as_f64 are handy.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you have more lines of code than it needs to when just using transmute. If you don't want to unsafe everywhere, just define two wrapper functions should the work too.

@BusyJay
Copy link
Member

BusyJay commented Sep 19, 2016

LGTM

@siddontang siddontang merged commit 500e8f5 into tikv:master Sep 19, 2016
kamalmarhubi added a commit to kamalmarhubi/rust-prometheus that referenced this pull request Nov 4, 2016
This builds on the work in tikv#64 to allow stable Rust users to get atomics
if they run on 64-bit architectures.
kamalmarhubi added a commit to kamalmarhubi/rust-prometheus that referenced this pull request Nov 4, 2016
This builds on the work in tikv#64 to allow stable Rust users to get atomics
if they run on 64-bit architectures.
kamalmarhubi added a commit to kamalmarhubi/rust-prometheus that referenced this pull request Nov 4, 2016
This builds on the work in tikv#64 to allow stable Rust users to get atomics
if they run on 64-bit architectures.

Tested:
  Ran tests on the following combinations (all unknown-linux-gnu):
    - stable Rust x86_64
    - stable Rust i686
    - nightly Rust x86_64
    - nightly Rust i686
    - nightly Rust x86_64 with `--features=nightly`
    - nightly Rust i686 with `--features=nightly`
@overvenus overvenus deleted the atomic-value branch November 4, 2016 05:30
kamalmarhubi added a commit to kamalmarhubi/rust-prometheus that referenced this pull request Nov 4, 2016
This builds on the work in tikv#64 to allow stable Rust users to get atomics
if they run on 64-bit architectures.

Benchmark improvements:

    name                                                old ns/iter  new ns/iter  diff ns/iter   diff %
    counter::bench_counter_no_labels                    49           16                    -33  -67.35%
    counter::bench_counter_with_label_values            195          139                   -56  -28.72%
    counter::bench_counter_with_mapped_labels           715          371                  -344  -48.11%
    counter::bench_counter_with_prepared_mapped_labels  436          219                  -217  -49.77%
    gauge::bench_gauge_no_labels                        48           15                    -33  -68.75%
    gauge::bench_gauge_with_label_values                167          115                   -52  -31.14%
    histogram::bench_histogram_no_labels                179          30                   -149  -83.24%
    histogram::bench_histogram_timer                    276          138                  -138  -50.00%
    histogram::bench_histogram_with_label_values        363          137                  -226  -62.26%

Benchmarks run with default features (no "nightly" feature) on
nightly-2016-09-22, which corresponds roughly to 1.12.0.

Tested:
  Ran tests on the following combinations (all unknown-linux-gnu):
    - stable Rust x86_64
    - stable Rust i686
    - nightly Rust x86_64
    - nightly Rust i686
    - nightly Rust x86_64 with `--features=nightly`
    - nightly Rust i686 with `--features=nightly`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants