questione cosmica per performance python , c++
whatazor
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
bearoph...@lycos.com
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
Andrea Laforgia
wrote:
>a breve il gruppo di programmatori col quale lavoro comincera'
>l'analisi di un framework per applicazione 3D.
Yet another? Esistono molti framework per applicazioni 3D, � veramente
necessario farne uno da zero?
>La questione che adesso ci sta facendo discutere e' : tale framework
>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.
Alan Franzoni
> 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.
"Multipiattaforma" quanto? :P
> La questione che adesso ci sta facendo discutere e' : tale framework
> deve essere pensato in C++ o in Python?
"Pensato" in che senso? Di solito quando progetti un design pensi molto
limitatamente al linguaggio che ci sta sotto, quanto esso č parte
dell'implementazione.
IMHO dovreste semplicemente pensare a quali parti comporranno il vostro
framework, e poi prendere il linguaggio piů adatto per ogni parte.
Python dovrebbe consentirvi poi di fare da "collante" in maniera
adeguata tra le varie parti. Non ha senso pensare al linguaggio da usare
prima di compiere delle scelte di design.
--
Alan Franzoni <alan.fra...@gmail.com>
-
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
whatazor
<alan_franzoni_inva...@geemail.com.invalid> wrote:
> whatazor ha scritto:
>
> > 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.
>
> "Multipiattaforma" quanto? :P
windows, mac e linux
>
> > La questione che adesso ci sta facendo discutere e' : tale framework
> > deve essere pensato in C++ o in Python?
>
> "Pensato" in che senso? Di solito quando progetti un design pensi molto
> limitatamente al linguaggio che ci sta sotto, quanto esso è parte
> dell'implementazione.
In realta' questa affermazione l'abbiamo un po' confutata (ci abbiamo
discusso sopra) e a nostro parere il design viene modificato in base
al linguaggio (o linguaggi) con cui viene sviluppato successivamente,
ovvero se si analizza e successivamente si sceglie un linguaggio poi
bisogna reiterare l'analisi. Sapendo che cmq e' un passo successivo
quello di scegliere il linguaggio, stavamo gia' discutendo su
quell'aspetto e cominciando a leggere documentazione e testare tool di
sviluppo alternativi a quelli che abbiamo usato finora (tutto c++ e
ide vs).
> IMHO dovreste semplicemente pensare a quali parti comporranno il vostro
> framework, e poi prendere il linguaggio più adatto per ogni parte.
> Python dovrebbe consentirvi poi di fare da "collante" in maniera
> adeguata tra le varie parti. Non ha senso pensare al linguaggio da usare
> prima di compiere delle scelte di design.
>
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
whatazor
<a.lafor...@andrealaforgia.it.invalid> wrote:
> On Fri, 18 Jul 2008 01:43:02 -0700 (PDT), whatazor <dan...@gmail.com>
> wrote:
>
> >a breve il gruppo di programmatori col quale lavoro comincera'
> >l'analisi di un framework per applicazione 3D.
>
> Yet another? Esistono molti framework per applicazioni 3D, � veramente
> necessario farne uno da zero?
ci sono alte sfere che prendono decisioni per noi, abbiamo diversi
progetti in un futuro piu' o meno imminente che richiedono la
creazione di un framework che cmq di base abbia la visualizzazione 3d
(come quello precedente che utilizziamo)
> >La questione che adesso ci sta facendo discutere e' : tale framework
> >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.
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.
Andrea Laforgia
wrote:
>ci sono alte sfere che prendono decisioni per noi, abbiamo diversi
>progetti in un futuro piu' o meno imminente che richiedono la
>creazione di un framework che cmq di base abbia la visualizzazione 3d
>(come quello precedente che utilizziamo)
Ok, non conosco il vostro contesto, per cui non mi pronuncio in
merito. Reputo solo molto strano che non si possa estendere/adattare
un framework esistente. Parlo per me: se anche ci fossero "alte sfere"
che prendono decisioni, io gli farei presente che esistono sistemi già
pronti. In queste cose si corre il grosso rischio di reinventare una
ruota e per giunta quadrata.
>non di poco. Dopo vari benchmark ci siamo dovuti un attimo ricredere
>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.
Andrea Laforgia
wrote:
>> "Pensato" in che senso? Di solito quando progetti un design pensi molto
>> limitatamente al linguaggio che ci sta sotto, quanto esso è parte
>> dell'implementazione.
>
>In realta' questa affermazione l'abbiamo un po' confutata (ci abbiamo
>discusso sopra) e a nostro parere il design viene modificato in base
>al linguaggio (o linguaggi) con cui viene sviluppato successivamente,
>ovvero se si analizza e successivamente si sceglie un linguaggio poi
>bisogna reiterare l'analisi.
Il problema è che voi, come molti, confondete l'analisi con la
progettazione ;-)
Enrico Franchi
> 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).
Sul C/C++ vs. Asm è una vecchia questione. *Oggi* per battere in Asm un
buon compilatore C++ (leggi Intel, per dirne uno) ci vuole qualcuno con
*parecchie* skill sul funzionamento dettagliato dei processori, che
sappia 'a mente' riordinare le istruzioni per sfruttare parallelismo
implicito dell'architettura etc etc etc. Di fatto è spesso e volentieri
non ci si riesce.
Specie se teniamo conto che portabilità persa per portabilità persa si
possono usare OpenMP et similia per sfruttare il parallelismo
*esplicitamente* in una moderna architettura multicore.
> Le implementazioni più comuni di
> Python interpretano il codice
No. Python è compilato in bytecode, questo è eseguito. In particolare
prima di pensare 'è la stessa cosa', faccio notare che molte delle
operazioni più frequenti (a livello di bytecode) sono di fatto chiamate
di procedura altamente ottimizzate.
> e la garbage collection non assicura la
> 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
Andrea Laforgia
<ri...@despammed.com> wrote:
>Sul C/C++ vs. Asm è una vecchia questione. *Oggi* per battere in Asm un
>buon compilatore C++ (leggi Intel, per dirne uno) ci vuole qualcuno con
>*parecchie* skill sul funzionamento dettagliato dei processori
Esatto. Non è un compito facile.
>> Le implementazioni più comuni di
>> Python interpretano il codice
>
>No. Python è compilato in bytecode, questo è eseguito.
Python non è compilato (non eri tu quello che trovava insensate le
espressioni "linguaggio compilato" e "linguaggio interpretato"?), sono
i programmi scritti con esso ad essere compilati. E poi che palle!,
sempre la solita - trita e ritrita - obiezione. E mi trovo, tutte le
volte, a specificare quello vuol dire "interpretare". Python è un
linguaggio compilato in bytecode, che viene eseguito dalla VM. Questa
è un'altra accettabile accezione di "interpretare". Non far finta di
non saperlo :-)
<snip sulla religiosa difesa di Python>
>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".
<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>
Enrico Franchi
> Python non è compilato (non eri tu quello che trovava insensate le
> espressioni "linguaggio compilato" e "linguaggio interpretato"?),
> sono i programmi scritti con esso ad essere compilati.
Si, ero io. E di fatto la trovo una distinzione piuttosto rilevante. Mi
sono permesso di glissare principalmente perchè rispondevo ad
un'ineccepibile "le implementazioni più comuni".
> E poi che
> palle!, sempre la solita - trita e ritrita - obiezione. E mi trovo,
> tutte le volte, a specificare quello vuol dire "interpretare". Python
> è un linguaggio compilato in bytecode, che viene eseguito dalla VM.
> Questa è un'altra accettabile accezione di "interpretare". Non far
> finta di non saperlo :-)
Come vuoi. Ma ci sarebbe il problema dei processori attuali che di
fatto 'interpretano' il codice macchina x86, poichè internamente sono
macchine RISC. Per cui bisognerebbe saltare fuori con il discorso che
un programma C++ potrebbe essere 'parzialmente interpretato' a seconda
di quali istruzioni vengono usate dal compilatore (alcune istruzioni
sono proprio microprogrammi della CPU).
IMHO in questo modo non ce ne si viene più fuori e considero l'uso meno
ambiguo quello che parla di 'interprete' come di qualcosa che prende un
linguaggio e lo esegue.
In tal senso la PVM *è* un interprete e in tal caso il bytecode python
è interpretato praticamente. Una tipica piattaforma Java invece
*ricompila* il bytecode. L'implementazione standard di Ruby 1.8
interpreta direttamente il linguaggio, idem bash e altre robe.
> <snip sulla religiosa difesa di Python>
Non è una difesa religiosa. Trovo questo commento anzi un poco
offensivo.
Mi limito a dire che spesso e volentieri si riesce a scrivere codice
Python *notevolmente* efficiente, e in particolare quando il codice si
presta in modo naturale all'uso di dizionari e insiemi questo accade
visto e considerato che le implementazioni di tali strutture dati in
Python sono sconvolgemente curate e veloci.
Esattamente come posso dire che imparando ad usare bene i generatori si
riesce ad avere codice scritto ad alto livello che usa poca memoria (e
questo spesso e volentieri porta ad eccellenti performance).
> <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>
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
Gabriele Greco
> 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.
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
GuGu
> iniziare a codificare, sono tutti e tre multiplatform, in C++ e
> 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?