Dado el thread here¿Por qué Numpy es "lento" por sí mismo?
Parece que numpy no es el más ideal para cálculos ultrarrápidos. ¿Alguien sabe qué gastos generales debemos tener en cuenta al usar numpy para el cálculo numérico?
Bueno, depende de lo que quieras hacer. XOR es, por ejemplo, poco relevante para alguien interesado en hacer álgebra lineal numérica (para lo cual numpy es bastante rápido, gracias al uso de bibliotecas BLAS/LAPACK optimizadas debajo).
En general, la gran idea detrás de obtener un buen rendimiento de numpy es amortizar el costo del intérprete sobre muchos elementos a la vez. En otras palabras, mueva los bucles desde el código python (lento) a C/Fortran loops en algún lugar en el numpy/BLAS/LAPACK/etc. internos (rápido). Si tiene éxito en esa operación (llamada vectorización), el rendimiento generalmente será bastante bueno.
Por supuesto, obviamente puede obtener un rendimiento aún mejor si elimina el intérprete de python y utiliza, por ejemplo, C++. Si este enfoque realmente tiene éxito o no depende de lo bueno que seas en la programación de alto rendimiento con C++ vs. numpy, y qué operación exactamente intentas hacer.
Realmente no puedo decir, pero supongo que hay dos factores:
Quizás numpy está copiando más cosas? el tejido es a menudo más rápido cuando se evita la asignación de arreglos temporales grandes, pero esto no debería importar aquí.
numpy tiene un poco de sobrecarga utilizado para iterar sobre (posiblemente) matrices multidimensionales. Esta sobrecarga normalmente sería eclipsada por el número de crujidos, pero un xor es realmente muy rápido, así que todo lo que realmente importa es la sobrecarga.
Siempre que tenga una expresión como x = a * b + c/d + e, se termina con una matriz temporal para a * b, una matriz temporal para c/d, uno para una de las sumas y, finalmente, una asignación para el resultado. Esta es una limitación de los tipos de Python y la sobrecarga del operador. Sin embargo, puede hacer cosas in situ de forma explícita utilizando los operadores de asignación aumentada (*=, +=, etc.) y tener la seguridad de que no se realizan copias.
En cuanto a la razón específica, NumPy funciona más lentamente en ese punto de referencia, es difícil de decir, pero probablemente tiene que ver con la sobrecarga constante de verificar los tamaños, mapeo de tipos, etc. que Cython/etc. no tienes que preocuparte En problemas más grandes, probablemente lo veas acercarse.
Su sub-pregunta: a = sin (x), ¿cuántos viajes de ida y vuelta hay?
El truco es pasar una matriz numpy a sin (x), luego solo hay una 'ida y vuelta' para toda la matriz, ya que numpy devolverá una matriz de valores sin. No hay pitón para bucle involucrado en esta operación.
Acepto que una vez que los datos se pasan al lado fortran, es rápido. Estoy más interesado en la sobrecarga de la interfaz de código compilado/python. diga la línea 'a = sin (x)' los datos pasaron por un viaje redondo de python a C. Quiero saber cuántas capas de sobrecarga ha atravesado y si portar esto a cython haría un trabajo mucho mejor. – leon