3 ms·
In my opinion that is the wrong question to ask. The right question is: How fast will my code be. Numpy has been heavily optimised and is written in C and not P
by wallnuss 9y ago
In my opinion that is the wrong question to ask.
The right question is: How fast will my code be. Numpy has been heavily optimised and is written in C and not Python.
Take a look at the link below, comparing a simple sum in different languages (among them Python and Numpy). The power of Julia is that there is no privileged code. Your code will be as fast as the base library.
http://nbviewer.jupyter.org/github/alanedelman/18.337_2017/blob/282c25c9229187b18a7c61e7167387c31f40f15e/lectures/Lecture01_0906%20AutoDiff%20%26%20JuliaIsFast/JuliaIsFast.ipynb http://nbviewer.jupyter.org/github/alanedelman/18.337_2017/b...
- 81212w1 9y agoI find this benchmark a bit disorganized, but it seems that the "hand-written" Julia function is as slow as the "hand-written" C function. The C function is of course naive. I'm pretty sure that a hand-unrolled loop would be faster.
- wallnuss 9y agoYou are absolutely right, an optimised C Programn would be as fast or faster than the Numpy implementation.
- improbable22 9y agoYes to this. When you're calling some big fast package (be it some field-specific thing, or just matrix algebra) the language you're in doesn't matter that much. In terms of speed, but also in terms of effort -- you spend most of your time reading this field-specific package's manual. What's liberating is that for the things which aren't covered by such packages, there's no huge penalty for just writing it yourself. In speed but in effort too -- it's quicker to write the loop than to figure out how to make np.einsum do what you have in mind.