-
Notifications
You must be signed in to change notification settings - Fork 24
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
Make billiard tables be Tuple
instead of Vector
#30
Comments
The package to use here is Unrolled.jl. But a benchmark on whether this makes the code slower or not should be made. The benchmark can be done using the current implementation of: function next_collision(
p::AbstractParticle{T}, bt::Vector{<:Obstacle{T}})::Tuple{T,Int} where {T}
tmin::T = T(Inf)
ind::Int = 0
for i in eachindex(bt)
tcol::T = collisiontime(p, bt[i])
# Set minimum time:
if tcol < tmin
tmin = tcol
ind = i
end
end#obstacle loop
return tmin, ind
end |
@btime typeof($bt2[2]) <: PeriodicWall;
1.706 ns (0 allocations: 0 bytes)
@btime typeof($bt[2]) <: PeriodicWall;
90.531 ns (0 allocations: 0 bytes) bt = billiard_buminovich()
p = randominside()
bt2 = (bt...)
@btime next_collision($p, $bt);
1.237 μs (8 allocations: 128 bytes)
@btime next_collision($p, $bt2);
36.266 ns (0 allocations: 0 bytes) the only difference is that We may not need |
This could possibly increase performance.
With combination of the last answers of this discourse post: https://discourse.julialang.org/t/is-there-a-way-to-forward-getindex-for-tuples-in-a-type-stable-way/2889/20
it could lead to major improvements.
One needs to do proper benchmarking and profiling during this change!
(this issue should be solved at the same time with #51 )
The text was updated successfully, but these errors were encountered: