Putting aside the discussion regarding productivity, there is a case where I have found execution time to matter. Scaling an application which uses an unsharded database. The long transaction durations and number of connctions were bottlenecking db throughput. The particular app was a Ruby/Rails monolith.
Yes, Python is Slow, and I Don’t Care
201–206 of 206 posts
Re: Yes, Python is Slow, and I Don’t Care
#202Earlier quoted context omitted.
>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…
> That's exactly the same as with numpy. I'm not sure what your point is. 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 effecti…
>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.
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.
Re: Yes, Python is Slow, and I Don’t Care
#203Earlier quoted context omitted.
By blazingly fast you mean 100x slower than C++ equivalent and only 20x slower is you're very careful to avoid accidental copies. 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 BLA…
As I'll often say to these comments, then you're doing things wrong. Numpy code can be written to never leave the numpy sandbox, and at that point it should be as fast or faster than naive c++ (because you'll be getting SSE and stuff for free). There's a reason almost all deep learning is done in python.
The first time you have to return into python all the gains evaporate.
As I said, we improved python code a few times and it never even got near.
What it did was a bunch of convolutions, dot products, multiplications, fft, gamma probability equations. Even vector comparisons used numpy. Used direct hdf5 interface numpy has and fast view interface for overlaps.
Numba choked on the code by the way and crashed unless views were removed. And then it produced much worse performance.
Re: Yes, Python is Slow, and I Don’t Care
#204Earlier quoted context omitted.
> A type can't tell you that. Yes, it can! --- but you don't necessarily want to confound your program with such a thing. The old adage about the cure being worse than the disease applies.
> Yes, it can! Ok, how? Other than an Ada example, or dependently-typed languages that aren't use in production, can you offer an example?
> Other than an Ada example, or dependently-typed languages that aren't use in production...
Every time someone gives you an answer, you modify the question to exclude it. Eventually you will have excluded everything that refutes the fallacy in your original post, but it is still there.
Re: Yes, Python is Slow, and I Don’t Care
#205Earlier quoted context omitted.
Which is the reason why it makes sense to write new applications in a dynamic language, and later port critical parts of it to more static compiled ones.
s/port critical parts of it to/dump everything and rewrite from scratch in
Sure, whatever it takes. I've just written the same thing at another recent thread, so we agree on that.