3 ms·
Now try doing these tests on arrays of user defined types. Or use one of those fast functions as the kernel of an ODE solver and compare to julia. Anyone can ga
by eigenspace 6y ago
Now try doing these tests on arrays of user defined types. Or use one of those fast functions as the kernel of an ODE solver and compare to julia. Anyone can game microbenchmarks on arrays of Float64s, doing so shouldn't impress anyone. If Numpy can do it, you know it's not impressive.
The point of Julia is that Float64 and Int aren't special. They're on the same footing as whatever types you cook up, and our performant multiple dispatch system lets you build a vibrant interacting package ecosystem filled with user defined types doing targeted overloads of other functions.
It's the multiple dispatch and composability of julia code that matters. The important part of the performance of Julia is that we can get the ecosystem benefits of writing pure julia code without paying with runtime performance penalties.
- mfsch 6y agoEven for floats & ints, try doing some array operations without allocating memory for intermediate results. In Julia, I can write whole PDE simulations that never allocate intermediate values inside the time integration loop. I haven’t done serious work with NumPy in a while, but I’m pretty sure that’s impossible for anything non-trivial, even a simple FD stencil such as `du[2:end-1] = D * (u[1:end-2] - 2*u[2:end-1] + u[3:end]) / dx^2`.
- eigenspace 6y agoAbsolutely. Numpy's performance model is so brittle that one needs to be very selective when they cherry-pick their microbenchmarks. My rule of thumb is that if your cherrypicked microbenchmark involves one specialized Numpy function call, it'll be fast, but if there is two separate specialized Numpy function calls it'll be slow.