Opinion sobre los array en Python

[Marcos Sánchez Provencio]

Para la galería, el programa en Python:

import Numeric
tabla1=Numeric.zeros((1000,1000))
print "Comienzo"
for y in xrange(1000):
    for x in xrange(1000):
        tabla1[y,x]=1
        tabla1[x,y]=2
print "Fin"

marcos en renata:~$ time python xxnum.py
Comienzo
Fin
 
real    0m23.558s
user    0m20.731s
sys     0m0.154s

Por comparar, el programa en C (ya corregido con las llaves)
real    0m0.285s
user    0m0.127s
sys     0m0.066s

Unas 160 veces más lento.

Conclusiones:
* ¿Es Python un lenguaje adecuado para hacer bucles huecos? No.
* Pues no se me ocurre ninguna otra.

Antonio Castro wrote:

>On Fri, 16 Apr 2004, Hernan Foffani wrote:
>
>  
>
>>Antonio Castro escribio:
>>    
>>
>>>Me he decidido a hacer una comparación de eficiencia entre dos
>>>programas que usan arrays de identicas características. Uno está
>>>programa realizado en C y otro realizado en Python recurriendo
>>>a una lista de listas. Es decir:
>>>      
>>>
>>tratando de no hacer hincapie en la violación de segmento de tu
>>programa C, que lo solucionas poniendo un par de {} en el segundo
>>for ;-), estas comparando cosas distintas.
>>    
>>
>
>Cierto falta las llaves. Y que hablamos de cosas distintas ya lo sé
>pero es muy pertinente la comparación cuando te ves por narices obligado
>a hacerlo todo con listas.
>
>  
>
>>para hacer la comparación equivalente deberías considerar como
>>*minimo* que:
>>  1. las listas de python son de tamaño dinámico. (vuelve a
>>  codificar los dos programas permitiendo que las pruebas se
>>  hagan con distintos tamaños especificados por linea de comandos)
>>  2. las listas de python alojan objetos de cualquier tipo.
>>    
>>
>
>Tambien lo sé, pero precisamente por eso son ineficientes cuando lo
>que se trata es de hacer algo muchísimo más sencillo.
>
>  
>
>>>Resumiendo.  El programa C es unas 50 veces más rápido y estoy
>>>seguro de que no estoy sorprendiendo a casi nadie con ello.
>>>      
>>>
>>a mí si.
>>me sorprende que *solo* sea 50.  ¿está bien hecha la prueba?
>>hubiera jurado que un buen compilador C hubiera optimizado
>>tu programa a un simple:
>>  main() { printf("Comienzo\n"); printf("End\n"); }
>>;-)
>>    
>>
>
>Tu fijate bien lo que estas diciendo. El código genera una serie de
>instrucciones porque se produce un resultado en el interiora del array
>(tabla1).   Yo he optado por no sacar ni hacer nada con ese resultado
>porque es un ejemplo.  Queda bastante claro que no es un programa serio
>pero con este ejemplo queda igualmente claro cual es el problema que
>planteo. Bastaría con poner un problema concreto y decirte resuelvelo
>de forma eficiente con Python. Si el problema se basa en el uso de arrays
>no podrás hacerlo eficientemente en Python.
>
>  
>
>>>Yo creo que se podría incluir soporte para estructuras tipo array.
>>>
>>>Me pregunto si para no romper el enfoque dinámico de Python
>>>lo suyo sería que hubiera que instanciar el objeto tabla pasandole
>>>un elemento de muestra y una lista de tamaños un para cada
>>>dimensión del array. Para un array de 1000x1000 sería algo así:
>>>
>>>tabla1=array(elem_muestra, 1000,1000)
>>>      
>>>
>>no cambiaría mucho.  la unica ventaja es prealojar 1000x1000
>>elementos.  pero como un programa normal hace muchas mas cosas ese
>>supuesto ahorro solo se obtiene una vez y de hecho es posible
>>prealojar 1M de elementos en el python actual.
>>recuerda que en C ese array se aloja en tiempo de *compilación*!
>>    
>>
>
>Para nada de acuerdo. Ese no es el problema. El alojamiento
>podría hacerse dinamicamente en C con un malloc().
>
>Acceder dentro de una estructura tipo array con elementos de
>tamaños constante se implementa a nivel de generación de código
>con una aritmética de punteros muy sencila y muy eficaz.
>
>Una lista es otra cosa. Los elementos pueden ser heterogeneos,
>puedes insertar y eliminar un elemento en cualquier posicion y
>todo eso esta muy bien, pero tiene un precio que para ciertos casos
>puede representar un serio problema de eficiencia.
>
>Una lista puede implementar un array mientras que lo contrario no es
>cierto,  pero eso no es excusa para hacerlo todo con listas. Incluso
>se pueden implementar otras muchas estructuras de datos, pilas, colas,
>grafos, conjuntos, etc.. pero un array es algo muy básico y muy util a
>mi modo de ver.
>
>Para cavar prefiero usar una pala a una cuchara y para comer sopa
>prefiero usar la cuchara a una pala.
>
>  
>
>>además, en el estado actual del parser/compilador/interprete de
>>python, pasarle al constructor de la lista un "elem_muestra" es
>>irrelevante.  (hoy) no hay nada que pueda hacer mejor (o mas rapido)
>>sabiendo que todos los elementos serán de tipo int o cualquier
>>otra cosa.
>>    
>>
>
>Exacto lo has captado. Este es el problema de hoy.
>
>  
>
>>optimizar python no es sencillo.  hay varias alternativas en
>>uso y en estudio.  desde generar codigo C a partir de anotaciones
>>y/o extensiones al lenguaje hasta ideas sobre compiladores JIT.
>>
>>-H.
>>    
>>
>
>No sirve para este caso por las razones que dije en el mensaje
>anterior. Si no se da algún soporte en el propio lenguaje el
>resultado no será eficiente.
>
>Hay multitud de casos donde usar una lista en lugar de un array es
>un inconveniente muy serio y Python es un leguaje de propósito muy
>general con una biblioteca de módulos impresionante. Sin los arrays
>en mi opinión queda cojo.
>
>
>  
>