Il 10/04/2017 13:27, Gianluca Esposito ha scritto:
Poi sei sicuro che siano così distanti le performance dell'algoritmo
in python e quelle in fortran? magari prova a creare una applicazione
non in multithreading, ma in multiprocessing, così sfrutti tutti e 20
i core e soprattutto MISURA le performance di uno e dell'altro.
Sapevo che in multiprocessing non ci sarebbe il problema, però sono
completamente ignorante al riguardo, quindi ho evitato di discutere
questo punto. Sono ovviamente d'accordo riguardo alla necessità di
misurare le performance onde evitare di perdere tempo ad cazzum.
Se ancora sei distante, in python esistono molte librerie matematiche
che in realtà sono compilate in c e hanno un binding a python, prova
ad usare una di quelle.
Uso numpy con soddisfazione. Andando off-topic però vorrei fare un rant
sui binding a python: se sono fatti male sono scomodi da usare. Cosa
intendo con "fatti male": non sono pythonici! Per esempio, tempo fa
provai pyside, adesso sto provando openbabel.
Se ancora non ti sei avvicinato, individua la parte di codice lenta e
riscrivi solo quella parte in c e poi la richiami dal programma python
e in python questa operazione è molto facile.
Sapevo della possibilità ma non ci ho mai giocato.
Come vedi prima di scegliere un linguaggio compilato perchè è più
veloce, ci sono un bel pò di ragionamenti e prove da fare.
Certo. Ad esempio a me piace python anche per la quantità di librerie
già pronte. Dell'articolo io più che altro contesto il "continua a
buttare hardware al problema", indipendentemente dalla scelta del
linguaggio.
Per le app non ha alcun senso, possono essere ottimizzatissime, ma
magari controllano la rete wifi ogni millisecondo e la batteria te la
ammazzano lo stesso.
Giusto, alla fine mi sono permesso un rant su cose che esulano dalla
scelta del linguaggio.
Ciao,
Davide
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
