Newsgroup: it.comp.lang.c++
Titolo: questione cosmica per performance python , c++

Ciao a tutti,
a breve il gruppo di programmatori col quale lavoro comincera'
l'analisi di un framework per applicazione 3D. Il target e' farlo
multipiattaforma ed utilizza librerie esterne come motore di
rendering.
La questione che adesso ci sta facendo discutere e' : tale framework
deve essere pensato in C++ o in Python?
Mi spiego: c'e' il partito del "facciamolo in C++ e poi wrappiamo
tutto in python"
oppure del "facciamolo tutto in python"
Dal momento che ci sono parecchi aspetti da tenere conto, tra cui le
performance , la velocita' di sviluppo futura (prima ci sara'
un'aseguata analisi) e anche il fatto che debba essere
multipiattaforma, volevo chiedere un vostro parere in merito.
Scusate ma mi tocca crosspostare ;)
Ciao
w

whatazor:

Difficile poter dare consigli a distanza su una questione cosi'
complicata, comunque se il motore di rendering e' una biblioteca
esterna allora si puo' almeno pensare di poterlo fare in Python.
Anche se il programma (framework) ha GUI, GTK, WX o QT dovrebbe essere
sufficiente nella maggior parte dei casi.
Se il codice non deve eseguire cose troppo pesanti, allora Python puo'
andare bene; ma in certi casi per velocizzare un programma non basta
velocizzarne qualche routine, per cui conviene fare uno studio in
anticipo per capire se siete in tale situazione. In tal caso vi serve
un linguaggio piu' veloce, al limite anche Java.
Infine c'e' il problema della distribuzione, il codice C++ puo' essere
compilato, e non richiede un interprete esterno che magari deve essere
installato (e tra l'altro aiuta a nascondere i sorgenti, il che in
certi casi e' da tenere di conto).
Se il sistema finale sara' molto grande, e/o lavorate in molte
persone, o se nel gruppo di lavoro ci sono poche persone conoscenti/
amanti della programmazione dinamica, allora Python ne viene
svantaggiato.
In generale suggerirei di cominciare a scriverlo in Python/Psyco, e
riscriverne eventuali parti che risultano sperimentalmente lente in C/
Cython/D (o perfino C++), ma tenendo di conto delle eccezioni che ho
segnalato.
Salve,
bearophile

deve essere pensato in C++ o in Python?
Per le performance, il C++ � da preferire. Escluderei Python se devi
spaccare i secondi. In ogni caso, il C++ � un linguaggio molto
complesso e - con tutto il rispetto per i programmatori nel tuo team -
perch� venga fuori qualcosa di minimamente usabile � necessario che il
linguaggio sia conosciuto bene e venga adoperato al meglio. Altrimenti
si rischia di compromettere seriamente le performance.


-
Togli .xyz dalla mia email per contattarmi.
Remove .xyz from my address in order to contact me.
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E


Adesso siamo piu' nell'analisi dell'analisi infatti, tentando di
capire come gestirla al meglio perche' le feature request di questo
progetto sono chiare fino ad un certo punto, nonostante ci sia la
linea guida.
ciao!
w

 si rischia di compromettere seriamente le performance.
Effettivamente uno dei punti che pensavamo dolenti del python, anche
leggendo articoli (magari datati) erano le performance piu' scadenti e
non di poco. Dopo vari benchmark ci siamo dovuti un attimo ricredere
nel senso che le prestazioni non sono poi cosi' lontane, tenendo conto
poi che la performance vera e propria e' richiesta nella
visualizzazione 3d e la lib e' gia' scritta in c++ e wrappata. Cmq
dovremo testare ancora parecchio per farci un'idea dei colli di
bottiglia che possiamo incontrare.
Per il resto non posso che concordare con te.

nel senso che le prestazioni non sono poi cosi' lontane
Non sono comunque comparabili a quelle di un codice ben ottimizzato
C++. Ripeto: se è per spaccare il bit, non hai concorrente migliore
del C++ o addirittura del C (sempre a non voler perdere portabilità e
scendere a livello assembly, naturalmente; cosa, peraltro, che per una
libreria di grafica non sarebbe del tutto folle). Chiaro poi che le
performance dipendono strettamente dalle implementazioni di un
linguaggio, non dal linguaggio in sé. Le implementazioni più comuni di
Python interpretano il codice e la garbage collection non assicura la
distruzione immediata degli oggetti. In una libreria dove le
performance devono essere sotto controllo, forse anche la distruzione
deterministica diventa importante.

bisogna reiterare l'analisi. 
Il problema è che voi, come molti, confondete l'analisi con la
progettazione ;-)

 distruzione immediata degli oggetti. 
from __future__ import with è tuo amico.
Oltretutto di recente mi sto rendendo sempre più conto che spesso e 
volentieri in codice che utilizza massicciamente dizionari e insiemi (e 
li utilizza per ottimizzare ad alto livello gli algoritmi) si riescono 
ad avere performance *eccellenti*. Performance che duplicare in C è 
costosissimo (fra cui scrivere parecchio codice altamente efficiente 
per gestire tavole di hash e compagnia briscola). In C++ le cose 
migliorano parecchio, ma anche li bisogna prestare parecchia attenzione 
a quello che si fa, altrimenti ci si mangia parecchia efficienza per 
motivi "cretini".
-- 
I have never designed a language for its own sake.
Niklaus Wirth

motivi "cretini".
<autoquote mode on>
"il C++ è un linguaggio molto complesso e perché venga fuori qualcosa
di minimamente usabile è necessario che il linguaggio sia conosciuto
bene e venga adoperato al meglio. Altrimenti si rischia di
compromettere seriamente le performance"
<autoquote mode off>

 <autoquote mode off>
Si si, su questo siamo d'accordo. Il punto è che non è completamente 
marziano il fatto che il codice 'banale' in Python funzioni in modo 
ragionevolmente efficiente e il codice 'banale' in C++ potrebbe non 
esserlo altrettanto.
A questo punto si vede quanto costa scrivere codice non banale in C++ e 
se l'incremento delle performance vale la candela. La risposta non è 
scontata.
Tra l'altro il punto è completamente vuoto, per come la vedo. Le 
soluzioni in cui C++ e Python interagiscono sono un numero sempre 
maggiore. Anche in campo videoludico, per dire. Non solo: parecchi 
giochi che *non* usano Python mettono in piedi strutture simili, un 
motore in C++ scriptato in qualcos altro.
Tornando a noi, ribadisco: quando il codice fa pesante uso di dizionari 
e insiemi, Python risulta sorprendentemente veloce.
-- 
If you optimize everything, you will always be unhappy.
Donald Knuth

 rendering.
Ti consiglio di guardare Ogre, Irrlicht e CrystalSpace 3d prima di 
iniziare a codificare, sono tutti e tre multiplatform, in C++ e 
scriptabili, inoltre hanno svariati anni di sviluppo alle spalle.
Se non vorrete usare un framework gia` fatto (cosa che vi consiglio, non 
si sviluppa un framework 3d in meno di un paio di anni uomo oggigiorno), 
perlomeno vedere i problemi che un framework 3d deve risolvere e come 
sono stati risolti in questi 3 popolari framework opensource usati anche 
in applicazioni commerciali potrebbe esservi utile!
Di sicuro non vi consiglio di scrivere il core del framework in python, 
ma dargli un bind python e scrivere l'applicazione in python e` una 
strada percorribile.
Bye,
  Gabry

 scriptabili, inoltre hanno svariati anni di sviluppo alle spalle.
Ma oltre a fare videogiochi fanno anche qualcosa di piu' serio tipo 
triangolarizzare una nurbs con una tolleranza voluta?