For example I am sure Java is faster at numerical processing than pure Python at least with Python you have the option of writing in native. Python has really good C interop and it maybe considered by some not part of the language but I consider that it is.
Yeah you could write native code for Java via JNI but its not easy (granted its been a while) and for reasons I can't remember why but JNI is slow (probably moving stuff on and off the heap... I can't recall).
In the telecom domain, I've dealt with data big enough that Python wasn't really feasible. Think 100 of millions of records in CSV format that need to be parsed and processed. Doing that in Python is going to be painful.
I was trying to cut a couple of columns out of a CSV and tried to write it in Java and for some reason either the CSV library was slow or maybe I didn't have the right buffered input but I ended up writing a python script that outperformed my Java code (which reminds me I meant to revisit that).
Anyway here is the python code (it might not be the exact code I used as I didn't update it but whatever):
As a matter of fact, don't know if you've heard, but data processing it kind of like.. Python's thing...
Python itself can be pretty slow. Doing image processing on data stored as list-of-lists-of-integers would be brutally slow.
On the other hand, numpy is an import away, and it can be quite fast, especially if it's been built with an optimized BLAS/ATLAS, etc.
For reference, MATLAB is about 30x slower with no special care. Pure Java on Hotspot was 5x slower except it dies on big data input due to very slow GC and goes to 50x slow.
Source: handled big audio data from hdf5 database, gigabytes sized. C++ equivalent had no vectorization or magic BLAS or anything.
There's a reason almost all deep learning is done in python.
Numba choked on the code by the way and crashed unless views were removed. And then it produced much worse performance.
> There's a reason almost all deep learning is done in python.
The heavy-lifting in e.g. TensorFlow is done in C++. Bindings to Python make sense because it is one of the few sanctioned languages inside Google, and it is widely used outside of Google and easy to pick up.
That's exactly the same as with numpy. I'm not sure what your point is. C++ is also one of the few sanctioned languages inside google, as is Java.
>Not all data is a good fit for Numpy: some data is non-numeric or not a homogenous array.
I'm curious what kind of data you're working with that can't be represented and effectively transformed in a tensor (numpy array).
I was replying to "there's a reason why...". You didn't specify that reason, so from the rest of your comment I took it to mean that Python (with numpy) was fast and good enough to write deep learning stuff. That doesn't seem to be the case for TensorFlow.
> I'm curious what kind of data you're working with that can't be represented and effectively transformed in a tensor (numpy array).
I'm not intimately familiar with the internals of numpy, but my understanding is that the basic data structure is a (multi-dimensional) array of values (not pointers). That leads to a number of questions.
If you have an array of records (dtype objects), and one of the fields is a string, am I correct that each element needs to allocate memory to hold the longest possible value that can occur for that field? What if that is not known beforehand?
How do you deal with optional fields (e.g. int or null)? Do you need to add a separate boolean to indicate null?
How do you deal with union types, e.g. each record can be one of x types, do you make a record that has a field for each of the fields of those x types? Do those fields take up space?
Tensorflow tensors are numpy arrays, or are transparently viewable as such.
>If you have an array of records (dtype objects), and one of the fields is a string, am I correct that each element needs to allocate memory to hold the longest possible value that can occur for that field? What if that is not known beforehand?
Yes, although you can also store numpy arrays of pyobjects, which are arrays of pointers. You'll be able to vectorize the code, but you won't get the same performance improvements as with a normal numpy array, because that same level of performance isn't possible with an array of pointers.
Note that for most machine learning applications, you'd preprocess your string into a vector of some kind.
>How do you deal with optional fields (e.g. int or null)? Do you need to add a separate boolean to indicate null?
Yes, but I'm not sure when you'd do that. That is, again in most machine learning applications you'd be representing things as one-hot arrays or as some kind of compressed high dimensional position vector, where 0 would represent a lack of presence of some thing.
>How do you deal with union types
dt = np.dtype((np.int32,{'real':(np.int16, 0),'imag':(np.int16, 2)})
is a 32 bit int that can also be accessed as a 16 bit complex number via .real and .imag.
It doesn't have fast libraries for everything. E.g. for the use case I brought up, it doesn't (or at least none that I could find at the time). Not all data are homogenous arrays that fit in numpy.
And are those libraries written in Python? Or in C because Python is too slow?
If you take your reasoning, any language that can bind to C (which is pretty much any language) is as fast as C. That is not very helpful when comparing the speed of languages. A slower language will force you to drop into C sooner than a faster one.
> As a matter of fact, don't know if you've heard, but data processing it kind of like.. Python's thing...
Things like audio and video codecs, or crypto code aren't written in Python.
I've done a lot of image processing in Python using libraries like PIL, numpy and opencv. Doing per-pixel operations is extremely easy in PIL - improving my dev time, but CPU wise the slowest of the bunch. I love prototyping that way, but I have to move to numpy or opencv or another language to speed it up. A recent program to do a slightly complicated color transform on a 512x512 image was taking me over 60 seconds with PIL. It was 5-10 seconds in JavaScript, and less than 1 second using numpy.
Numpy also has an inside-out order of operations compared to using vanilla Python, the reason it's fast is because you put the inside of the loop on the outside of the code. That can make it really hard to iterate on structural changes in your code. You can lose a lot of the dev time advantages by going numpy first.
Also a lot of people don't consider numpy to be a fair comparison when talking about Python's language performance. Because it's optimized compiled code underneath the Python binding, it's not representative of the speed of the Python interpreter.
I haven't looked into the guts myself, but I'd bet that for similar or equivalent operations, the way the different syntaxes are handled under the hood are wildly different. e.g. function calls are much faster than method calls on objects.
Optimized pure python can look very ugly and non-idiomatic.
I still program and sadly prefer writing code in Java over Python even though I have tons of Python scripts in my ~/bin that I have written over the years. Mainly because I just know the ecosphere better.
And thats what most people should just admit why they choose a particular programming language. As long as its good enough... better... is just what you know more of... the cost of learning something new just to replace something new for marginal speed increase isn't worth it.
So when people say Java is slow to learn, not cool or slow to develop in because the language is verbose... I say just like you: "I Dont' Care" because learning the whole ecosphere of another language is goddamn expensive (that is languages are relatively easy to learn but all the libraries, best practices and tools is another thing entirely).
However when dealing with a team often with an existing code base getting everyone on board with "X" while potentially porting to "X" is fairly expensive. Its generally only worthwhile because of actual technical limitations and not productivity. Even the promise of safety (ie prevention of bugs) I would probably consider higher than productivity (although I suppose that is in way productivity).
Regardless productivity is really hard to measure and especially predict unlike other technical things.
I have hard time believing Java folks made an argument on productivity unless you meant for that parenthetical statement to be only applied to Scala. Regardless productivity is a far more complicated than raw speed (particularly if you get into maintenance as some languages are easy to pump out code but harder to maintain... oh perl.. the pain...).
And yeah I have seen the C++ folks complain about Python but this in my experience has been video game programming which is clearly not the domain the author is in or talking about (I think given the microservice discussions). Hence why I would like to know more about these folks complaining.
# Am I defining foo for the first time or am I mutating
foo = "stuff"
And of course you can't define constants.
IIRC for lambdas its that they can't span multiple lines and I believe they are getting removed (I'm not a python 3 expert)?
What I have heard complaints about Python are (and I don't agree with all these points):
* Its not statically typed
* The python 2/3 compatibility
* It has some design flaws: GIL, variable assigning, mutable variables, lambdas, indentation (I don't agree with all these but this is complaints I have heard).
* The plethora of packaging (ie its not unified)
I guess one could argue its slow because it can't do concurrency well but that really isn't raw speed.
Then the author started comparing string processing of programmer time from a study which... doesn't help the authors point at all.
* Python has and will always be fast at string processing and most people know this
* The people that complain about python speed are almost certainly not doing string processing
* I have serious questions about the study in general (many languages have changed quite a bit since then)