Since I contributed the Numba JIT timing earlier in the thread, it seems
only fair to note that the modified Julia version with the properly
preallocated data is now 17% faster than the Numba version on my computer.
Overall, this seems to support my thesis that good Julia code is on par or
slightly faster than the Python code using the JIT libraries (Numba, Hope,
Parakeet, etc.) with the added benefit of not requiring external libraries.
I've also seen some cases where the difference is even more pronounced in
the favor of Julia because of the ability to use @simd to prod the LLVM
vectorizer along and the ability to exert precise control over memory
allocations, but this is highly use case specific.
On Tuesday, July 26, 2016 at 12:47:53 AM UTC+3, Tim Holy wrote:
>
> Given the apparent interest in the topic and the decisions that people
> seem to
> be making, it seems worth pointing out that folks are still using
> apples-to-
> oranges comparisons on this benchmark.
>
> There are at least two important differences:
> - in the other languages, `linspace` allocates a vector, but in Julia it
> (currently) creates a compact object from which values are computed
> on-the-fly.
> That computation involves a division, and division is slow.
> - The languages like C aren't doing bounds-checking. You might imagine
> adding
> `@inbounds` to the Julia version. But `@inbounds` has no impact on
> LinSpace
> objects in julia 0.4. In julia 0.5, it does work like you'd expect
> (thanks,
> Blake Johnson).
>
> Combining these observations, we can `collect` the values into a `Vector`
> and
> then use `@inbounds`. For me the version below is nearly twice as fast as
> the
> original:
>
> function benchmark()
> nsamples = 1000000
> x = collect(linspace(0, 5, nsamples))
> y = zeros(nsamples)
> # attempt to trigger JIT to compile all functions needed in the loops
> # before profiling
> a = cos(0.0); a = 1.5*2.5; a = 1.5+2.5;
> println("\nBrutal-force loops, 100 times:")
> @time begin
> for m = 1:100
> @inbounds for n = 1:nsamples
> y[n] = cos(2*x[n]+5);
> end
> end
> end
> end
> benchmark();
>
> Best,
> --Tim
>
> On Monday, July 25, 2016 2:02:41 PM CDT Zhong Pan wrote:
> > Agree that while raw speed is important, in most situations it wouldn't
> be
> > the most important reason to choose one programming language over
> another.
> >
> > I came from the angle of an engineer in a small company. For myself, the
> > main attraction of Julia was the easiness to achieve decent speed
> without
> > making much explicit effort: that means what feels more natural
> vectorized
> > will be vectorized, while what feels more natural in a loop will be in a
> > loop; that means I don't need to resort to another language or a library
> > only for improving speed; and that means apart from sticking to a couple
> > good habits, I can use objects, functions etc. the same way inside a
> loop
> > vs. outside. None of these is critical by itself, but they add up to an
> > uninterrupted flow of thoughts while writing code to explore, try, fail,
> > and retry, for many iterations.
> >
> > During this "less careful" prototyping, 1-2x slow down is fine, but with
> > Julia I know I won't sit there for tens of minutes waiting for a result
> > while debating myself whether I should rewrite it in C++ or rehaul the
> code
> > with Cython etc.; instead I can rest assured that as long as my algo and
> > coding have no mistakes or major flaws, the speed is close to what I
> will
> > get even if I make several times more effort to rewrite it in C++.
> >
> > Another big deal for me is the resulted removal of the barrier between
> > prototype and production code. For production I can review and improve
> my
> > code carefully, but rewriting it in a less expressive language is too
> much.
> >
> > I was a huge fan of Python (heck I even persuaded my previous boss, a
> VP,
> > to pick up Python - though I don't know if he really had time to finish
> it.
> >
> > :-)). However, the slow raw speed and the over-freedom to change class
> >
> > definition anywhere always gave me the itch to find something better. My
> > brother at JPL who worked on Python projects also complained about
> having
> > to think really hard to vectorize almost everything and then couldn't
> > easily understand what he was doing a few months later because the code
> was
> > too unnatural for the problem; the indentation was also a big headache
> as
> > collaborators use different editors with different tab definitions.
> >
> > So I'm really happy to have found Julia, which gave me the same joy as
> > coding in Python and removed the main itches.
> >
> > -Zhong
>
>
>
