Provide a IntCounter and IntGauge

[siddontang]

Mostly, we use the integer for counter and gauge, so it is more efficient to use atomic int64 directly than float64.

[breezewish]

prometheus-go implements similar optimizations, but leaving a nicer interface (transparent to users): prometheus/client_golang@ae69392

[siddontang]

cool, but we should support math.Trunc, and do a benchmark to compare Trunc + Int Atomic and Float Atomic.

[breezewish]

yes. I will do a benchmark. If the performance impact of math.trunc is minimal, I prefer this way.

[breezewish]

According to the benchmark, adding a trunc check (and uses float as interface) will slow down about 20%~30% compared to AtomicInt:

Mac:

test counter::bench_atomic_f64                          ... bench:          11 ns/iter (+/- 2)
test counter::bench_atomic_u64                          ... bench:           4 ns/iter (+/- 0)
test counter::bench_atomic_u64_trunc                    ... bench:           6 ns/iter (+/- 2)

Linux:

test counter::bench_atomic_f64                          ... bench:          11 ns/iter (+/- 1)
test counter::bench_atomic_u64                          ... bench:           6 ns/iter (+/- 0)
test counter::bench_atomic_u64_trunc                    ... bench:           8 ns/iter (+/- 0)

However it is still nearly 30%~50% faster than the AtomicFloat. In addition, the f64 is as slow as the RwLock implementation (with is used as a replacement without nightly).

[siddontang]

how about using https://github.com/prometheus/client_golang/pull/367/files#diff-4eafde073feb6e8d8a2aefcc731b59c4R91 instead of math.Trunc?

[breezewish]

According to the rust book,

Casting from a float to an integer will round the float towards zero.

I guess it is equal to if (v.round() as u64) as f64 == v. Will update the benchmark for this later.

[breezewish]

Time consumption of these two are exactly the same.