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
