Comments (8)
To answer your question about the performance, yes, it does affect performance in the following case:
The example is a bit contrieved since ideally you would use the sampler
if you want to sample from the same distribution in a loop (similar to how the Random
docs show that you should construct and use a Random.Sampler
if you want to call rand
repeatedly - BTW there's an issue to unify sampler
with Random.Sampler
a bit more: #1316).
The single variate sampling does not use sampler
s, hence it behaves differently.
from distributions.jl.
The reason for this observation is that sampler(Beta(...))
is not type stable: Depending on the parameters, a different algorithm is used for sampling. #1350 "fixed" the performance and allocation issues arising from this type instability with a function barrier. Based on the benchmarks in that PR it seems it doesn't harm performance anymore.
from distributions.jl.
Ok, that explains a bit the situation. The real issue is that sampler(Beta(..., ...))
is type-unstable and depends on the parameters. But can it always return the same object, which would simply have an if
inside depending on the parameters? E.g.
sampler(d::Beta) = BetaSampler(d, other_fields...) # type-stable, always returns the same
function rand!(rng, sampler::BetaSampler, container)
if some_condition(sampler)
one_algorithm!(rng, container)
else
another_algorithm!(rng, container)
end
end
Or a specialized method for rand!
for Beta
would also solve this issue entirely, e.g.
function rand!(rng, dist::Beta, n)
if some_condition(dist)
rand!(rng, OnerBetaSampler(dist), n)
else
rand!(rng, AnotherBetaSampler(dist), n)
end
end
from distributions.jl.
But can it always return the same object
The motivation for sampler
is to precompute algorithm-dependent quantities when drawing multiple variates. The number and type of these quantities are quite different for different algorithms, as you can see in https://github.com/JuliaStats/Distributions.jl/blob/master/src/samplers/gamma.jl. Always computing all of these would be a bit wasteful I think.
from distributions.jl.
Or a specialized method for rand! for Beta would also solve this issue entirely
I still wonder, is there any issue here? It seems the function barrier in #1350 fixed the performance issues.
from distributions.jl.
It shouldn't recompute algorithm-dependent quantities in my second proposal with a specialized rand!
since it basically exactly the same code with an explicit static if
statement (multiple dispatch is really just a sophisticated runtime if
statement).
To answer your question about the performance, yes, it does affect performance in the following case:
julia> foo(x, dist) = foreach(1:100_000) do _
rand!(dist, x)
end
julia> x = zeros(10);
julia> dist = Beta(1, 1)
Beta{Float64}(α=1.0, β=1.0)
julia> sr = sampler(dist)
julia> @btime foo($x, $dist);
30.232 ms (100000 allocations: 6.10 MiB)
julia> @btime foo($x, $sr);
27.726 ms (0 allocations: 0 bytes)
It's not much in this particular example, but it does accumulate in our larger program and it also allocates extra (while the whole idea of rand!
is to sample in place)
from distributions.jl.
Another thing, I mentioned that sampling a single point is fine and is in fact type-stable.
julia> @report_opt rand(Beta(1, 1))
No errors detected
That suggests that there is a potential for improvement for the in-place version
from distributions.jl.
In the real code the distribution is not the same unfortunately
from distributions.jl.
Related Issues (20)
- Add Fisher Information Matrix function
- Changing the type from `Float` to `Int` breaks `mean` of `MixtureModel`
- `0 <= cdf(Normal(),x) <= 1` not always true. HOT 4
- `0 <= cdf(truncated(Normal(2.5, 0.2), lower=0.0),x)` not always true. HOT 3
- Suggestion: 3-argument cdf() HOT 1
- Error in xval in gumbel
- New GPL dependency introduced through AliasTables HOT 5
- Unexpected behavior of `truncated` for zero variance distributions at the lower bound HOT 2
- Type instability of mixture distributions
- Bug in quantile() for some special cases of a MixtureModel
- Rename `ValueSupport` subtypes to more specific names HOT 1
- Who is maintaining Distributions.jl? HOT 3
- cdf of InverseGaussian HOT 1
- Support parametrization of Beta (Mean and variance Beta(μ, σ²)) HOT 1
- `Distributions.jl` and `RecursiveArrayTools.jl` do not work together.
- Degenerate Distribution interface is probably necessary HOT 1
- Better samplers for Bernoulli(p) and Geometric(1/2) random variables HOT 2
- Is there a reason `rand(TDist(nu))` does not obey the type of `nu`? HOT 10
- How to draw a density sample from a multivariate normal HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from distributions.jl.