
Turing.jl: A Fresh Approach to Probabilistic Programming in Julia - indescions_2017
http://turing.guru/
======
indescions_2017
Link to introductory video from JuliaCon 2017 talk:

JuliaCon 2017 | Turing: a Fresh Approach to Probabilistic Programming | Kai Xu

[https://www.youtube.com/watch?v=DJWNQg7uuCg](https://www.youtube.com/watch?v=DJWNQg7uuCg)

------
coolio222
Does anyone knows the difference to other languages like STAN?

Both use Hamiltonian Monte Carlo. As far as I know STAN cannot model factors
but can restrict a variable to integers. In this case, Turing.jl and STAN do
the same and switch back to slower MCMC.

So why should I switch to turing.jl?

Their wiki shows that turing.jl is about 10 times slower than STAN:

    
    
      Results
      Model 	Turing 	Stan 	Ratio
      Simple Gaussian Model 	1.2 	0.06 	20.24
      Bernoulli Model 	1.53 	0.05 	32.73
      School 8 	2.34 	0.1 	24.41
      Binormal (sampling from the prior) 	0.88 	0.11 	8.37
      Kid 	32.66 	4.72 	6.92
      LDA-vec 	23.94 	3.78 	6.34
      LDA 	72.78 	3.78 	19.28
      Mixture-of-Categorical 	22.28 	6.41 	3.48
      NOTE 1
      Numbers here are inference time in second - smaller number   indicates better performance.

~~~
ChrisRackauckas
We're setting up parameter estimation in DifferentialEquations.jl with both
Stan.jl and Turing.jl as separate but connected projects. For generated data
from the Lotka-Volterra equations, Turing.jl seems to be able to recover the
four parameters well in minutes, whereas Stan was running for a few hours and
didn't get it right. It's hard to know if it's because of the difference in
the ODE solver and the accuracy there (Stan has to use its internal solvers,
whereas Turing.jl gets to use our whole stack. For testing we chose Tsit5
which should be to some extent equivalent to their rk45, but without knowing
the details of their solver it's hard to know how different it truly is) or
due to the chosen method for MCMC method. One major advantage of Turing.jl
though is it lets us use our full stack: Distributions.jl, all of JuliaDiffEq
(ODE/SDE/DAE/DDE/etc. solvers), whereas Stan requires you use their two ODE
solvers. So we're going to finish up this DiffEq->Stan automatic generation
bridge for testing and benchmarking purposes, but the Turing.jl route looks
much more promising. They have done a really good job.

~~~
wululiyu
I'm surprised you're able to get Turing to run faster, to be honest. I looked
at Turing and was impressed by it, but in general my experience with MCMC
libraries in Julia is similar to what the OP posted, being much slower than
Stan (MAMBA and Turing being the two Julia libraries I've tried--both have
seemed nice but have run significantly slower on the tasks I've used them
for).

Incidentally, I haven't been able to get Turing to run on Julia 0.6, and am
not going to reinstall an earlier version just for Turing. I've been waiting
for a little while now.

My experience with Turing and MAMBA have kind of diminished my enthusiasm for
Julia. Both libraries kind of represent what I was looking for in Julia
(similar to what you mention about using your Julia stack), but the speed was
a kind of a rude awakening. I'm kind of coming to the opinion that LLVM-based
languages need to demonstrate much more consistent performance before they're
really ready to replace C (Rust, Nim, and Crystal seem like they might be on
their way, though).

I recommend someone thinking about Julia pay attention to these benchmarks:

[https://github.com/kostya/benchmarks](https://github.com/kostya/benchmarks)

Yes, Julia is really fast with some things, but for other things it's much
slower, and those slow parts become the lowest common denominator.

Hopefully things improve, though, because I do like Turing and MAMBA on paper.

~~~
Tarrosion
> Yes, Julia is really fast with some things, but for other things it's much
> slower

No sane person would deny this :) Regarding those benchmarks, however, I would
note that:

a) They are two major Julia versions old, many of the benchmarks Julia appears
in are string-centric, and since then Julia's string handling has been
improved.

b) Glancing through I see a few pretty basic ways in which the Julia code
could be sped up without doing anything convoluted

~~~
wululiyu
The benchmarks are based on old Julia--something I've wondered about--but they
still are consistent with my experience (and with the benchmarks the OP
posted).

I really like Julia, so I don't want to come across as a hostile critic, more
of a friendly one. I'm someone who has, and continues to try, Julia for lots
of things. But repeatedly I've bumped into this phenomenon where Julia is
maybe 3-5x slower than what you'd see in C, maybe more, and am faced with what
that means in practice. It's not just Turing, and it's not just a single
version of Julia. It's a heck of a lot better than Python or R, but when I
realize it's still significantly faster to do something in C, and you're going
to wrap something around C anyway, maybe Python or R would be better just
because of the resource base associated with them.

Maybe there's some fundamental issue I haven't grappled with, like Julia will
never actually be as fast as C, and I just need to be aware of what that
means, practically speaking... I don't know. Maybe it will eventually hit that
performance range, and it's just a matter of optimizing algorithm choice and
whatnot. But I get the sense that the way I was hoping to use Julia isn't
actually doable, at least at the moment.

I do think many people are coming to Julia because of some sense they can get
the performance of C with the expressivity of Python, and at the moment I
think that's an unrealistic expectation for a lot of things. I think the
parent post in this subthread exemplifies that quite well: for many, many
reasons, it shouldn't be surprising that Stan outperforms Turing. If this was
any other language, it would be a matter of course. But because of the
expectations set up for Julia, you see discussions like this.

~~~
one-more-minute
If you can turn one of those trials into a small example and post it on the
forums, it'd be well worthwhile. We've often helped folks squeeze the last few
bits of performance out of their code – and really, anything past 2x of C is
considered a bug.

------
peatmoss
Am I missing something here, or is there zero content about this project
linked from the landing page?

~~~
StefanKarpinski
I think the wiki is the documentation:
[https://github.com/yebai/Turing.jl/wiki](https://github.com/yebai/Turing.jl/wiki).
It's linked in the upper right corner. I agree that the fact that the three
big items on the page are not links is a bit confusing.

~~~
peatmoss
Ah, thank you. Apparently dividing my screen vertically made my web browser
too narrow, and thus the links disappeared entirely.

~~~
cristoperb
Yep, it looks like there's a CSS @media query which completely hides those
navigation links on screen sizes < 992px. That's not very useful responsive
design.

------
mac01021
Why name this particular library after that particular mathematician?

