6 ms·

I'm curious. I would like to know if it is worth to learn a new language only for speed reasons or if it's better to hope in improvements in Python... What do y

I'm curious. I would like to know if it is worth to learn a new language only for speed reasons or if it's better to hope in improvements in Python... What do you think? Anyway awesome! It's going well :))

deleted 12y ago
[deleted]
leephillips 12y ago
I wouldn't expect mainline Python to get significantly faster. You can get huge improvement in speed by using various libraries, alternative interpreters, and other strategies - but you'll always be going beyond "pure", standard Python. Julia is designed with numerical performance in mind, and gets impressive results out of the box. But, because of the aforementioned, that by itself would probably not be a compelling reason to learn a new language. Such reasons would be Julia's design, which may make it preferable to you once you've learned more about it. Read up on multiple dispatch, built-in networked computing, and array syntax. I find the design around multiple dispatch to be much more sensible than Python's object-oriented approach.
- coldtea 12y ago
  >I wouldn't expect mainline Python to get significantly faster. Why not? JS did. And before you mention that it's the de facto language of the web, so of course had tons of commercial backing, well, PHP did too (with PHP7, but also with recent 3 releases really working on speed and less memory use). We have this Dropbox initiative too, and renewed talk about Python optimization. For Python it's an obvious shortcoming, with some low-hanging fruits available.
  - jurip 12y ago
    It's been an obvious shortcoming for over 20 years, though. Maybe it'll get better some day, but at this point it's probably best not to count on it.
  - StefanKarpinski 12y ago
    The tricky thing about Python is that it's a classic two-language system how performance critical extensions to the language are all implemented. That was never the case with JavaScript since there was no way to extend it in C. So the V8 team was free to do anything they wanted to make JS fast so long as it still behaved like JS. Alex Rubinsteyn explained the problem far better than I will manage to in this blog post: http://www.phi-node.com/2013/06/how-fast-can-we-make-interpreted-python.html http://www.phi-node.com/2013/06/how-fast-can-we-make-interpr... The conclusion is that if you do all the things you can to make Python faster without breaking compatibility with CPython (thereby losing all of SciPy): > "In the best cases, such as when lots of integers are being manipulated in a loop, [you] might get up to 3X faster than the regular Python interpreter. More often, the gains hover around a meager 20%."
    - coldtea 12y ago
      One way might be to make the regular C extension API have a performance drop (e.g use it through some translation layer facade) and introduce a new C extension API alongside it that plays well with the necessary changes in the language. Do you think that will be feasible for Python?
      - StefanKarpinski 12y ago
        Honestly, I just don't think this is going to happen in Python, but I could very well be wrong. The biggest impediment had been Guido van Rossum's (IMO understandable) reluctance to accept performance improvements that increase the complexity of the standard implementation. The fact that he works at Dropbox, which is also the home of the Pyston project gives some hope of him being more supportive of this kind thing in the future, but that's pretty thin.
alephnil 12y ago
It depends what you want. If you think of the ordinary CPython interpreter, that is unlikely to ever reach the speed of Julia, and I don't think that is even a priority for the Python developers. So if execution speed is very important for you, go for Julia. On the other hand, it is not likely that Julia will even come close to have a similar ecosystem of libraries as you can find in Python in the foreseeable future. The exception is Numerics-heavy fields, which is Julias focus area, where there is a lot of good libraries.
andreasvc 12y ago
If you subscribe to the idea of a division of labor between systems and scripting languages, then Python + its C based extensions (Cython, Numpy, etc.) is ideal, as it already has an extensive scientific ecosystem. Julia combines the two in a single language. See this blog post and the one that follows it: http://graydon2.dreamwidth.org/3186.html http://graydon2.dreamwidth.org/3186.html
- marcodena 12y ago
  nice post!
- lottin 12y ago
  Do one thing and do it well, seems like a good idea. Of course, do everything better than anyone else is even better, but is it really possible? I'm not sold on the idea of a one-size-fits-all programming language.
  - coldtea 12y ago
    Well, if there was some theorical barrier, and if we were indeed talking of making the "100% perfect" language" yes. But in real life things preventing using a language in more domains are mostly mere bad design, lack of some features and legacy baggage. Case in point with Python. It's not that we want it to be faster or lower level than C to use in kernels. We just want it to be 10x, 20x faster, something entirely possible (Javascript JITs prove it can be done for even the most dynamic of languages), and we just want it to be able to tap into multicore CPUs (something that would also be entirely possible if it was slightly better designed). So it's not like there's some huge theoritical barrier to achieving this stuff. It's mostly money (like those spend by Apple, Google and Mozilla to their JIT JS engines), and the will to drop some backwards compatibility (which they did with 3.0 but for marginal benefits instead of addressing useful stuff).
- srean 12y ago
  It is light years far from ideal. There are two variants of this much parroted line (i) Numpy, Scipy are just C loops, and (ii) 'just do the intensive parts in C', both leave a lot more to be desired. Yes numpy, scipy indeed dispatch to precompiled C and sometimes Fortran loops but the problem lies elsewhere, in its vectorization paradigm. It is just extremely wasteful. There are two problems: (a) it is not expressive enough to capture efficient computation without generating unnecessary intermediate arrays whose sole objective is to make it possible to write the computation as a vectorized operation. Unlike Matlab in the past, numpy, scipy are at least smart about broadcasting. This often allows one to avoid constructing those intermediates in memory. However, this comes at an extra indirection that affects all array operations via the stride vector. You pay the cost of indirection whether you need it or not. (b) The second problem is generation of temporaries when you chain several binary operations. These temporaries get allocated, filled and destroyed over and over again within a single expression which itself might be in a loop. This costs computation, memory, not to mention GC pressure. There is of course numexpr but it is also quite limiting. For instance you cannot index or slice from within a numexpr expression. It offers limited set of reduce operations, in an expression you can use only one, and it must be the last one in the sequence of operations. Then there is 'write to C'. If we have not eliminated the need to write C we have not really solved the hard problems have we. I think the whole point was to avoid writing low level code because it is error prone, tedious and that it often comes at the cost of productivity. The drop down to C imposes an unnecessary break in flow and forces you to tackle the impedance mismatch. Tools like Cython eases this a bit. You cannot for example use numpy array expressions efficiently from Cython, you have to write those tedious low level indexing code. If I were to write C, I would rather write it in C syntax and take advantage of the decades of tooling around C syntax. Cython is great and an awesome community effort, but it still quite a simple compiler and has limitations. So far I have been talking only about ease of use, quality of programming experience etc etc, but that is not the only issue here. The problem is calls to C and more importantly callbacks from C to Python are expensive enough to be non-ignorable. If you have a hot loop where you go back and forth between C/Fortran world and Python thats going to incur a serious hit. The solution is to make the containing piece of Code into C/Fortran/Cython, so it ends up swallowing more and more of the application logic, leaving only but a shell of I/O in the Python world. Its not the end of the world but not quite the rosy picture you give. Another issue is cultural, its common among many newer programmers not to have really experienced fast runtimes, of course this is a generalization and does not apply to all, but have seen it happen frequently enough. They are greatly amazed by what I would call only modest improvement in runtimes and they would be cheering "Wow! so speed much fast!" etc. All of these make me be really hopeful about Julia. Interacting with the community gives me the feeling that they get it. Julia is an expressive language, already quite performant and not saddled by limitations of vectorization. I do like the terseness of vectorized expressions over loops, this is being filled by devectorize.jl. Yes there are more libraries available in R or Scipy but given the ease with which one can code in Julia I dont see this to be an unsurmountable problem. Every language has to begin somewhere and unlike say other competing solutions like Torch7 I find the community very friendly, responsive and pragmatic. It seems they spend conscious effort to keep it that way. So, Julia community, here is wishing all the best. I do love Python a lot, and I mean really really a whole lot (except for its OOP parts) but this self cheering gets a little too much at times.
marcodena 12y ago
thanks to all. I'm studying AI, so maybe there will be something good for Julia BUT we are reaching only now good libraries for Python. They are porting good R libraries, there is Theano, pandas, scikit-learn, pylearn2 etc. With Julia? Let's see but it's a shame we start again :(((
- idunning 12y ago
  You can call Python packages from Julia, so not entirely starting from scratch! For example here is pandas: https://github.com/malmaud/Pandas.jl https://github.com/malmaud/Pandas.jl
x43b 12y ago
It is interesting. I held off on learning Python because Matlab was there (paid by school/employer), it ran reasonably fast, and all the libraries (toolboxes) were there. Now I'm trying to jump to Julia and many of my Python friends are making the exact same arguments (you'll never get the community/libraries/support) that used to made against Python in favor of Matlab. Anyway, as a long time Matlab user, Julia just feels incredibly 'natural' to me.
grayclhn 12y ago
Julia's a nice language even without the speed improvements. It's less overtly object oriented than Python, which could be a pro or con for you. I like its multiple dispatch, for example. But it is pretty fast too :)
pjmlp 12y ago
> if it's better to hope in improvements in Python. I don't see PyPy ever replacing CPython, so I guess better look elsewhere if execution speed matters.

deleted 12y ago

[deleted]

leephillips 12y ago

I wouldn't expect mainline Python to get significantly faster. You can get huge improvement in speed by using various libraries, alternative interpreters, and other strategies - but you'll always be going beyond "pure", standard Python. Julia is designed with numerical performance in mind, and gets impressive results out of the box. But, because of the aforementioned, that by itself would probably not be a compelling reason to learn a new language. Such reasons would be Julia's design, which may make it preferable to you once you've learned more about it. Read up on multiple dispatch, built-in networked computing, and array syntax. I find the design around multiple dispatch to be much more sensible than Python's object-oriented approach.

coldtea 12y ago
>I wouldn't expect mainline Python to get significantly faster. Why not? JS did. And before you mention that it's the de facto language of the web, so of course had tons of commercial backing, well, PHP did too (with PHP7, but also with recent 3 releases really working on speed and less memory use). We have this Dropbox initiative too, and renewed talk about Python optimization. For Python it's an obvious shortcoming, with some low-hanging fruits available.
- jurip 12y ago
  It's been an obvious shortcoming for over 20 years, though. Maybe it'll get better some day, but at this point it's probably best not to count on it.
- StefanKarpinski 12y ago
  The tricky thing about Python is that it's a classic two-language system how performance critical extensions to the language are all implemented. That was never the case with JavaScript since there was no way to extend it in C. So the V8 team was free to do anything they wanted to make JS fast so long as it still behaved like JS. Alex Rubinsteyn explained the problem far better than I will manage to in this blog post: http://www.phi-node.com/2013/06/how-fast-can-we-make-interpreted-python.html http://www.phi-node.com/2013/06/how-fast-can-we-make-interpr... The conclusion is that if you do all the things you can to make Python faster without breaking compatibility with CPython (thereby losing all of SciPy): > "In the best cases, such as when lots of integers are being manipulated in a loop, [you] might get up to 3X faster than the regular Python interpreter. More often, the gains hover around a meager 20%."
  - coldtea 12y ago
    One way might be to make the regular C extension API have a performance drop (e.g use it through some translation layer facade) and introduce a new C extension API alongside it that plays well with the necessary changes in the language. Do you think that will be feasible for Python?
    - StefanKarpinski 12y ago
      Honestly, I just don't think this is going to happen in Python, but I could very well be wrong. The biggest impediment had been Guido van Rossum's (IMO understandable) reluctance to accept performance improvements that increase the complexity of the standard implementation. The fact that he works at Dropbox, which is also the home of the Pyston project gives some hope of him being more supportive of this kind thing in the future, but that's pretty thin.

alephnil 12y ago

It depends what you want. If you think of the ordinary CPython interpreter, that is unlikely to ever reach the speed of Julia, and I don't think that is even a priority for the Python developers. So if execution speed is very important for you, go for Julia. On the other hand, it is not likely that Julia will even come close to have a similar ecosystem of libraries as you can find in Python in the foreseeable future. The exception is Numerics-heavy fields, which is Julias focus area, where there is a lot of good libraries.

andreasvc 12y ago

If you subscribe to the idea of a division of labor between systems and scripting languages, then Python + its C based extensions (Cython, Numpy, etc.) is ideal, as it already has an extensive scientific ecosystem. Julia combines the two in a single language. See this blog post and the one that follows it: http://graydon2.dreamwidth.org/3186.html http://graydon2.dreamwidth.org/3186.html

marcodena 12y ago
nice post!
lottin 12y ago
Do one thing and do it well, seems like a good idea. Of course, do everything better than anyone else is even better, but is it really possible? I'm not sold on the idea of a one-size-fits-all programming language.
- coldtea 12y ago
  Well, if there was some theorical barrier, and if we were indeed talking of making the "100% perfect" language" yes. But in real life things preventing using a language in more domains are mostly mere bad design, lack of some features and legacy baggage. Case in point with Python. It's not that we want it to be faster or lower level than C to use in kernels. We just want it to be 10x, 20x faster, something entirely possible (Javascript JITs prove it can be done for even the most dynamic of languages), and we just want it to be able to tap into multicore CPUs (something that would also be entirely possible if it was slightly better designed). So it's not like there's some huge theoritical barrier to achieving this stuff. It's mostly money (like those spend by Apple, Google and Mozilla to their JIT JS engines), and the will to drop some backwards compatibility (which they did with 3.0 but for marginal benefits instead of addressing useful stuff).
srean 12y ago
It is light years far from ideal. There are two variants of this much parroted line (i) Numpy, Scipy are just C loops, and (ii) 'just do the intensive parts in C', both leave a lot more to be desired. Yes numpy, scipy indeed dispatch to precompiled C and sometimes Fortran loops but the problem lies elsewhere, in its vectorization paradigm. It is just extremely wasteful. There are two problems: (a) it is not expressive enough to capture efficient computation without generating unnecessary intermediate arrays whose sole objective is to make it possible to write the computation as a vectorized operation. Unlike Matlab in the past, numpy, scipy are at least smart about broadcasting. This often allows one to avoid constructing those intermediates in memory. However, this comes at an extra indirection that affects all array operations via the stride vector. You pay the cost of indirection whether you need it or not. (b) The second problem is generation of temporaries when you chain several binary operations. These temporaries get allocated, filled and destroyed over and over again within a single expression which itself might be in a loop. This costs computation, memory, not to mention GC pressure. There is of course numexpr but it is also quite limiting. For instance you cannot index or slice from within a numexpr expression. It offers limited set of reduce operations, in an expression you can use only one, and it must be the last one in the sequence of operations. Then there is 'write to C'. If we have not eliminated the need to write C we have not really solved the hard problems have we. I think the whole point was to avoid writing low level code because it is error prone, tedious and that it often comes at the cost of productivity. The drop down to C imposes an unnecessary break in flow and forces you to tackle the impedance mismatch. Tools like Cython eases this a bit. You cannot for example use numpy array expressions efficiently from Cython, you have to write those tedious low level indexing code. If I were to write C, I would rather write it in C syntax and take advantage of the decades of tooling around C syntax. Cython is great and an awesome community effort, but it still quite a simple compiler and has limitations. So far I have been talking only about ease of use, quality of programming experience etc etc, but that is not the only issue here. The problem is calls to C and more importantly callbacks from C to Python are expensive enough to be non-ignorable. If you have a hot loop where you go back and forth between C/Fortran world and Python thats going to incur a serious hit. The solution is to make the containing piece of Code into C/Fortran/Cython, so it ends up swallowing more and more of the application logic, leaving only but a shell of I/O in the Python world. Its not the end of the world but not quite the rosy picture you give. Another issue is cultural, its common among many newer programmers not to have really experienced fast runtimes, of course this is a generalization and does not apply to all, but have seen it happen frequently enough. They are greatly amazed by what I would call only modest improvement in runtimes and they would be cheering "Wow! so speed much fast!" etc. All of these make me be really hopeful about Julia. Interacting with the community gives me the feeling that they get it. Julia is an expressive language, already quite performant and not saddled by limitations of vectorization. I do like the terseness of vectorized expressions over loops, this is being filled by devectorize.jl. Yes there are more libraries available in R or Scipy but given the ease with which one can code in Julia I dont see this to be an unsurmountable problem. Every language has to begin somewhere and unlike say other competing solutions like Torch7 I find the community very friendly, responsive and pragmatic. It seems they spend conscious effort to keep it that way. So, Julia community, here is wishing all the best. I do love Python a lot, and I mean really really a whole lot (except for its OOP parts) but this self cheering gets a little too much at times.

marcodena 12y ago

thanks to all. I'm studying AI, so maybe there will be something good for Julia BUT we are reaching only now good libraries for Python. They are porting good R libraries, there is Theano, pandas, scikit-learn, pylearn2 etc. With Julia? Let's see but it's a shame we start again :(((

idunning 12y ago
You can call Python packages from Julia, so not entirely starting from scratch! For example here is pandas: https://github.com/malmaud/Pandas.jl https://github.com/malmaud/Pandas.jl

x43b 12y ago

It is interesting. I held off on learning Python because Matlab was there (paid by school/employer), it ran reasonably fast, and all the libraries (toolboxes) were there. Now I'm trying to jump to Julia and many of my Python friends are making the exact same arguments (you'll never get the community/libraries/support) that used to made against Python in favor of Matlab. Anyway, as a long time Matlab user, Julia just feels incredibly 'natural' to me.

grayclhn 12y ago

Julia's a nice language even without the speed improvements. It's less overtly object oriented than Python, which could be a pro or con for you. I like its multiple dispatch, for example. But it is pretty fast too :)

pjmlp 12y ago

> if it's better to hope in improvements in Python. I don't see PyPy ever replacing CPython, so I guess better look elsewhere if execution speed matters.