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

Arithmetic operations very slow #25

Open
aplavin opened this issue Oct 14, 2018 · 4 comments
Open

Arithmetic operations very slow #25

aplavin opened this issue Oct 14, 2018 · 4 comments

Comments

@aplavin
Copy link

aplavin commented Oct 14, 2018

It looks like this package has a lot of overhead for simple math operations - about 50 times slower than normal floats and uses 20 times more memory! Not even talking about number of allocations.

using BenchmarkTools
using Measurements

a = randn(1000, 1000)
b = randn(1000, 1000)
@btime a ./ b;
#  1.791 ms (4 allocations: 7.63 MiB)
a, b = a  b, b  a
@btime a ./ b;
#  88.498 ms (4000004 allocations: 175.48 MiB)

For comparison, an extremely basic implementation from rosettacode has only 4x overhead, which is completely reasonable:

using Main.NumericError

a = randn(1000, 1000)
b = randn(1000, 1000)
a, b = Measure.(a, b), Measure.(b, a)
@btime a ./ b;
#  6.797 ms (4 allocations: 15.26 MiB)

Any chance that performance of Measurements.jl can be improved?

@giordano
Copy link
Member

Yes, I'm aware that for large calculations the performance is not ideal. Try computing the mean of a large vector 😣 However, for a large set of uncorrelated measurements there is the weightedmean functions which is much faster and probably what the user is after.

The extremely basic implementation from rosettacode is fast because it doesn't deal with correlation:

julia> x1 = Measure(100, 1.1) # from rosettacode
100.0 ± 1.1

julia> x1-x1
0.0 ± 1.5556349186104046

julia> x = measurement(100, 1.1) # from this package
100.0 ± 1.1

julia> x-x
0.0 ± 0.0

Dealing with correlation is the main source of the overhead. I prefer something slow but correct to something fast but unreliable.

Any chance that performance of Measurements.jl can be improved?

Not from me, currently, but patches are always welcome 🙂 The important thing is that functionalities are maintained, this should be an under-the-hood only change. I've the feeling that performance can be improved, but I've never looked into this very deeply. Thanks for opening this issue!

@aplavin
Copy link
Author

aplavin commented Oct 14, 2018

I see, correlations indeed can be quite important and it is far from obvious how to speed up calculations while maintaining them. However it would be useful to have another mode (or type, or something) for fast computations without tracking correlations. For even moderately-sized datasets x50 slowdown is very significant, and what is often needed is just simple uncertainty propagation with independent observations.

@giordano
Copy link
Member

what is often needed is just simple uncertainty propagation with independent observations

It's not that simple. If x is a measurement, f(x) is a quantity correlated with x, then if you perform calculations involving both x and f(x) (or another quantity derived from x) you have to take care of correlation between them. Correlation is not important only if you're going to perform a single operation with a one-argument only function, and then stop

@giordano
Copy link
Member

However it would be useful to have another mode (or type, or something) for fast computations without tracking correlations.

I see your point, and it shouldn't be too hard to implement what you ask, but in my opinion its utility would be very limited (see above message) and would greatly confuse users (which type should I use? With correlation or not? What if I later change my mind?).

Some overhead compared to plain-bit numbers is to be expected, this type is going to do much more than adding or multiplying simple Float64 numbers. Large overhead comes when several quantity are involved, performance of calculations involving Measurement objects currently goes as O(n^2). It would be really great if someone could find a way to improve performance to O(n).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants