4 ms·

But javascript does not have something like numpy. You can easily get one to two orders of magnitude faster using numpy when applicable, and a MP3 decode certai

by cdavid 16y ago

But javascript does not have something like numpy. You can easily get one to two orders of magnitude faster using numpy when applicable, and a MP3 decode certainly falls in that category.

pcwalton 16y ago
Flusspferd (http://flusspferd.org/ http://flusspferd.org/) has GMP bindings, and there's no reason that node.js (for example) couldn't be hooked up to GMP as well.
acqq 16y ago
It's true that Numpy is much faster. I believe there's a lot of native code in Numpy and once we consider the libraries encoded in C, any language can be as fast as any other, as soon as we can offload enough to the libraries (for example, Perl has also some official C extension mechanisms: http://perldoc.perl.org/h2xs.html http://perldoc.perl.org/h2xs.html and even old Visual Basic was able to call DLL's written in C). However, I'd really like if at least something that's now a part of Numpy (which I believe is now even more a language extension than a library) would become the part of the Python language.
- cdavid 16y ago
  Numpy does have a lot of C code compared to most python packages, but I don't think that's the right way to look at it. If numpy was only about something being in C instead of python, it would not be that interesting. But numpy brings you abstractions on top of python which are useful and even more high level than python, and that's what is interesting: abstractions which do make your code faster (when applicable, of course). From the blog's profiling posts, a lot of time seems to be spent into MDCT and polyphase decoding: both could be coded quite efficiently in numpy (I hope to add MDCT itself in scipy, actually). About being part of python: I don't think it would be a right move (and has been given up from both python and numpy), because numpy is quite big, and depends on quite hairy dependencies if you care about speed. I don't think it is fair to say that numpy is a language extension - numpy feels more natural than say twisted from a python integration POV. But I am a numpy developer, so maybe not the best judge.
  - acqq 16y ago
    > I don't think it would be a right move because numpy is quite big, and depends on quite hairy dependencies if you care about speed. Maybe having some default build to have the main functionality and have some way to use the hairiy dependencies otherwise? As you say: > Numpy brings you abstractions (...) which are useful and even more high level than python, That's what's a loss for Python as the language. I don't expect to have the access to every FORTRAN-coded scientific library routine in Python by default, but being able to use the right abstractions in the langauge and not through something like the patch... maybe that can happen once? I understand, of course, that the current state is easier for you and for Python developers.

by cdavid 16y ago

But javascript does not have something like numpy. You can easily get one to two orders of magnitude faster using numpy when applicable, and a MP3 decode certainly falls in that category.

pcwalton 16y ago

Flusspferd (http://flusspferd.org/ http://flusspferd.org/) has GMP bindings, and there's no reason that node.js (for example) couldn't be hooked up to GMP as well.

acqq 16y ago

It's true that Numpy is much faster. I believe there's a lot of native code in Numpy and once we consider the libraries encoded in C, any language can be as fast as any other, as soon as we can offload enough to the libraries (for example, Perl has also some official C extension mechanisms: http://perldoc.perl.org/h2xs.html http://perldoc.perl.org/h2xs.html and even old Visual Basic was able to call DLL's written in C). However, I'd really like if at least something that's now a part of Numpy (which I believe is now even more a language extension than a library) would become the part of the Python language.

cdavid 16y ago
Numpy does have a lot of C code compared to most python packages, but I don't think that's the right way to look at it. If numpy was only about something being in C instead of python, it would not be that interesting. But numpy brings you abstractions on top of python which are useful and even more high level than python, and that's what is interesting: abstractions which do make your code faster (when applicable, of course). From the blog's profiling posts, a lot of time seems to be spent into MDCT and polyphase decoding: both could be coded quite efficiently in numpy (I hope to add MDCT itself in scipy, actually). About being part of python: I don't think it would be a right move (and has been given up from both python and numpy), because numpy is quite big, and depends on quite hairy dependencies if you care about speed. I don't think it is fair to say that numpy is a language extension - numpy feels more natural than say twisted from a python integration POV. But I am a numpy developer, so maybe not the best judge.
- acqq 16y ago
  > I don't think it would be a right move because numpy is quite big, and depends on quite hairy dependencies if you care about speed. Maybe having some default build to have the main functionality and have some way to use the hairiy dependencies otherwise? As you say: > Numpy brings you abstractions (...) which are useful and even more high level than python, That's what's a loss for Python as the language. I don't expect to have the access to every FORTRAN-coded scientific library routine in Python by default, but being able to use the right abstractions in the langauge and not through something like the patch... maybe that can happen once? I understand, of course, that the current state is easier for you and for Python developers.