jfpuget

If you think job offers are written in such a dumb way that netgear could be regarded as an ISP then I would agree with you. What evidence do you have of this?

Just added clojure to the query to see what it gives. You can do it too, simply follow the link I give in the article. Closure is a bit less popular than Julia, hence not significant at this point. See https://www.indeed.com/jobtrends/q-python-and-%28%22machine-...

I don't have the data. I use indeed.com trend queries. All we can do is to select which keywords to use.

I think you are spot on.

I did not include rust in the article, but it is easy to add it to the query. I just did it, and rust appears in 0% of job offers, see https://www.indeed.com/jobtrends/q-python-and-%28%22machine-...

Agreed. I welcome suggestions on how to distinguish both using keywords in job offers.

You can add them to the queries I used to see the results. Look for pointer in the article. Reason I didn't include matlab was that I didn't include any commercial product. To your point I could have included Octave still. I just did it, and Octave is at 0%: https://www.indeed.com/jobtrends/q-python-and-%28%22machine-...

Not sure where you get this from. The most popular machine learning framework, scikit-learn, runs fine in 3.5. I am also using xgboost with Python 3.5 (yes, xgboost is a major open source for machine learning, just look at what framework is used by most Kaggle competition winners). TensorFlow, mxnet also support 3.5. I would have agreed with you a year ago, but there has been a major shift in use from 2.7 to 3.5 in 2016.

edited for typo.

I didn't include it indeed, but you can try yourself. Just modify the query of my article (look for pointers).

You're absolutely right, and the data doesn't allow to split between api vs core implementation.

Several prominent open sources are written primarily in C++. TensorFlow is a good example.

Lua isn't missed, read the article again. it is just that it just that Lua appears in exactly 0% of the job offers on indeed.com.

I fully agree on using search correlations. Fortunately, this is not the case here. This is not about any search. This is about actual keywords occurring in actual job offers. I thought I explained it clearly, sorry if you missed it.

Thanks a lot. I'll have a look at using OpenCL in my case too.

Exactly.

Note that you execute C code anyway when you use Python standard implementation (CPython). Point is to use the best C code you can get with limited effort.

The waypoints are not distributed regularly, but the track points are.

Here is why performance mattered in my case.

I needed to predict future positions of the cyclist (see https://www.ibm.com/developerworks/community/blogs/jfp/entry...). The computation relied mostly on weather forecasts provided for each track points.

I then needed to know where to start my computation, i.e. find the track point closest to the current location of the cyclist.

Thank you for the suggestion.

At first glance, it does not seem to provide an object for dealing with a finite set of points. Using it would require first to transform the track into a continuous line, via interpolate(), then project() each waypoint to find the nearest point on that line. Issue is that this will not give me one of the original points of the track, which is what I needed.

But I may be wrong.

Lol and thanks. I'll reuse that one for sure!

Thank you, you made Pypy move higher on my todo list.

You have a good point about gc and memory layout. That's why I like C or C++ when writing high performance software. You can control memory locality more easily than with other languages.

No, I am not ;)

More seriously, are you unhappy with the default layout of developerWorks blogs? What change do you suggest? Not that I am in any way responsible for it, but I can certainly pipe your suggestions to the power that be.

I updated the post with Julia running times on the same machine as the one used for Python.

I agree that the first question is a very interesting one. I would be interested in the answer myself.

I made it clear however that I was going to answer a different question: did the Julia team wrote Python benchmarks the best way for Python?

That's all what the post is about: how to run Python code faster.

I will need way more Julia experience to be able to even think about answering the first question. The only thing I am 100% sure is that these micro benchmarks do not help answering that question.

The issue is that the Python code uses arbitrary precision while Julia code uses 64 bits. Python may be slower because of that. One way to get rid of this discrepancy is to compile with typed Cython, or with Numba, which is what I did. The other way would be to benchmark Julia with BigInt. Either way would be fair IMHO.

In light of your comment, it is interesting to see that Swift team just agreed to remove C style for loop.

https://lists.swift.org/pipermail/swift-evolution-announce/2...

Thanks. I did look at that page recently, and felt Numpy support was still experimental. But I'll give it a fair try.

What would motivate me would be that Pypy supports the packages I need for my day job, including Pandas, Scipy, and Scikit-learn. Do you know if there are plans to have these on top of Pypy?

Thank you, great comment, it spurred a great discussion.

Let me just clear one thing: I am not trying to represent Julia in any way. I wouldn't be legitimate for that at all. I tried to not write anything negative about the Julia language. Let me know if you think i did, in which case I'll modify my text.

To your point about compilers in charge of speeding up code, I see Numba doing more and more. I hope it will cover all of Python soon.

I did not try Pypy because last time I checked, it wasn't supporting Numpy. It means that Pypy would not been able to run these micro benchmarks as Numpy is used in some of them.

Please let me know if Numpy is supported now in Pypy. I'd be happy to add Pypy in the mix in that case.

And you lose python interactivity. If I have to compile code then I use C or C++ directly.

Agreed.

I didn't use C. Read again ;)

Pypy was not an option either, details in the post now.