se doveste scegliere ora..

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

Io tralascerei la classica entrata a gamba tesa con piede a martello di 71104. Ogni tanto lo fa, non so perchè.

Certi tipi di applicazioni si fanno in C++, è un dato di fatto. Il dubbio che mi attanaglia è: si fanno in C++ per qualità intrinseche dell'ecosistema C++ o si fanno in C++ perchè l'investimento in know how è tale da non rendere economicamente conveniente il passaggio a piattaforme più recenti?

Io punto sulla seconda perchè non ci vedo niente di strano.

quoto

[phoenixbf]

Originariamente inviato da ^TiGeRShArK^

bhè..
non sono per niente d'accordo.
Innanzitutto il JAVA NON è interpretato.

Allora non stiamo parlando dello stesso linguaggio:
http://www.vlsilab.polito.it/thesis/alfonso/node87.html

Originariamente inviato da ^TiGeRShArK^

Secondo punto se fosse così come dici basterebbe scrivere solo le parti critiche dell'applicazione in Open/GL e per tutto il resto si potrebbe anche utilizzare un vero linguaggio interpretato come il Python.
E ricordo che ci sono anche svariati binding Java/Open GL

Come dicevo prima, in questo campo serve tantissima ottimizzazione, soprattutto hw.
Non sto parlando di giochini OpenGL, sto parlando di app con i contro-co*****ni e gli eseguibili compilati da codice C++ sono piu' performanti.
E lo stesso vale per l'assembler.
Se uno fosse talmente guru e pazzo da riuscire a codificare una app direttamente in assembler, le performance sarebbero ancora superiori a quelle ottenute scrivendola in C o C++.

Ripeto che non sono cose che sostengo solo io, per carita'.
C'e' una intera comunita' di sviluppatori che la pensa come me, e questa e' gente che VERAMENTE mangia codice su codice, pranzo con java e cena con C++ con dessert di Python.

Per me questo discorso finisce qui.
Nel senso che devi portarmi una applicazione scritta in java che fa le stesse identiche cose che intendo io e con eguale performance.

E questo non e' possibile fidati.

[PGI-Bis]

Sottolineo che la mia è solo un'ipotesi. Magari c'è un'altra ragione. Magari chi sviluppa quel genere di programmi ha provato a farli con altri strumenti, ha fatto i confronti e ha verificato che per le ragioni X,Y e Z le altre tecnologie non sono concorrenziali. L'hanno fatto... e non l'hanno detto a nessuno. Ma è possibile che l'abbiano fatto.

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

Qual'è l'ultimo progetto OpenGL che avete scritto in Java? E quale differenza avete notato rispetto allo stesso progetto scritto in C++?

Lo chiedo senza malizia: io non ho mai fatto questa comparazione e non so se la teoria (un programma Java per la piattaforma Java è teoricamente più performante di un programma staticamente compilato, provenga esso da sorgenti C, C++, Fortran o Assembly, per via del JIT e del Garbage Collector) messa in pratica "perda per strada" qualche pezzo.

in C++ non ho mai scritto un software OpenGL...
con il C mi limitavo ad accedere con l'inline assembly alla memoria video dato che ai tempi in cui internet non esisteva era un pò difficile procurarsi librerie grafiche che superassero le limitazioni di 320X200 256 colori e 640X480 16 colori
Per quanto riguarda Diamonds onestamente ho semplicemente usato le funzioni grafiche scritte da altri... tradotto: non mi sono messo a scrivere il Codice OpenGL effettivo ma mi sono appoggiato ai wrappers a disposizione.
Una considerazione:
Java è effettivamente limitato per le applicazioni Real-Time.
Il problema di Java nell'ambito della grafica 3d imho non dipende dalle scarse prestazioni del linguaggio, ma soprattutto dalla natura inerentemente non real-time del linguaggio.
Se stai facendo dei rendering a video di una scena non ti puoi permettere3 di perdere 500 ms perchè il GC ha deciso che deve rompere le Balle
E' pur vero però che esiste una versione Real-Time di Java, ma dal poco che ho visto è termendamente complessa da utilizzare per gestire i meccanismi tipici per le applicazioni real-time.
La soluzione migliore è imho utilizzare linguaggi di scripting per le parti meno avide di prestazioni del codice e andare ancora su C++ per le parti critiche.
Ma in effetti mi sa che è proprio quello verso cui si sta muovendo il mercato

[phoenixbf]

Originariamente inviato da PGI-Bis

Sottolineo che la mia è solo un'ipotesi. Magari c'è un'altra ragione. Magari chi sviluppa quel genere di programmi ha provato a farli con altri strumenti, ha fatto i confronti e ha verificato che per le ragioni X,Y e Z le altre tecnologie non sono concorrenziali. L'hanno fatto... e non l'hanno detto a nessuno. Ma è possibile che l'abbiano fatto.

Infatti proprio sulla mailing list OSG usci' fuori una discussione del genere, su un porting della libreria in Java.

Pero' fu immediatamente smentito, da varie persone e con diverse argomentazioni, se ho tempo la ritrovo

[^TiGeRShArK^]

Originariamente inviato da albortola

ps: pare a me o il ruby è quasi + semplice del pascal?(ovvio, da quel pochissimo che ho trovato su wikipedia..)

Il ruby dal punto di vista della leggibilità è IMHO il miglior linguaggio esistente.
Python lo trovo un pò + complesso.

[PGI-Bis]

Ok, siamo entrati nel campo della mitologia della scienza informatica .

[^TiGeRShArK^]

Originariamente inviato da phoenixbf

Ottima domanda.

E la risposta e' difficile ovviamente, adesso come adesso mi sento di dire che l'OO campera' molto a lungo ancora, mi piace come filosofia, elegante, funzionale e soprattutto modulare (questo fattore lo vedo importante anche in vista del trend delle multi-CPU)

Al momento non saprei dire se ci sia un altro paradigma ancora meglio... futuro incerto

mmmm..
non conosco le altre filosofie in voga oggi...
Ma il paradigma ad oggetti non lo vedo ancora così in voga in futuro.
Basta ricordare ke l'informatica è in continua evoluzione e non possiamo sapere cosa avremo a disposizione tra 10 anni
x questo no nmi sbilancio su scommesse del genere

[^TiGeRShArK^]

Originariamente inviato da phoenixbf

Allora non stiamo parlando dello stesso linguaggio:
http://www.vlsilab.polito.it/thesis/alfonso/node87.html

evidentemente no

Originariamente inviato da wikipedia

Compilazione Just-In-Time

Le prime implementazioni del linguaggio usavano una virtual machine che intepretava il bytecode per ottenere la massima portabilità, definita Architecture Neutral. Questa soluzione si è però rivelata poco efficiente, in quanto i programmi interpretati erano molto lenti. Per questo, tutte le implementazioni recenti di macchine virtuali Java hanno incorporato un JIT compiler, cioè un compilatore interno, che al momento del lancio traduce al volo il programma bytecode Java in un normale programma nel linguaggio macchina del computer ospite. Inoltre, questa ricompilazione è dinamica, cioè la virtual machine analizza costantemente il modello di esecuzione del codice (profiling), e ottimizza ulteriormente le parti più frequentemente eseguite, mentre il programma è in esecuzione. Questi accorgimenti, a prezzo di una piccola attesa in fase di lancio del programma, permettono di avere delle applicazioni Java decisamente più veloci e leggere. Tuttavia, anche così Java resta un linguaggio meno efficiente dei linguaggi compilati come il C++, scontando il fatto di possedere degli strati di astrazione in più, e di implementare una serie di automatismi, come il garbage collection, che se da un lato fanno risparmiare tempo ed errori in fase di sviluppo dei programmi, dall'altro consumano memoria e tempo di CPU in fase di esecuzione del programma finito.

+ chiaro ora?

Come dicevo prima, in questo campo serve tantissima ottimizzazione, soprattutto hw.
Non sto parlando di giochini OpenGL, sto parlando di app con i contro-co*****ni e gli eseguibili compilati da codice C++ sono piu' performanti.
E lo stesso vale per l'assembler.
Se uno fosse talmente guru e pazzo da riuscire a codificare una app direttamente in assembler, le performance sarebbero ancora superiori a quelle ottenute scrivendola in C o C++.

assolutamente no.
Con i compilatori attuali le prestazioni di un'applicazione scritta in C++ sono + che sufficienti.
L'assembly viene usato solo per ottimizzare le parti critiche di codice.
Se c'è un metodo che occupa il 40% della CPU e questo metodo è in una porzione dello 0.0001% del codice non mi metto certo a ottimizzare il 100% del codice ma solamente lo 0.0001% critico

Ripeto che non sono cose che sostengo solo io, per carita'.
C'e' una intera comunita' di sviluppatori che la pensa come me, e questa e' gente che VERAMENTE mangia codice su codice, pranzo con java e cena con C++ con dessert di Python.

gli ipse dixit non mi osno mai piaciuti
cmq ti assicuro che a livello di pranzo e cena (colazione solitamente non la faccio ) non sono messo male nemmeno io

Per me questo discorso finisce qui.
Nel senso che devi portarmi una applicazione scritta in java che fa le stesse identiche cose che intendo io e con eguale performance.

E questo non e' possibile fidati.

Lo so benissimo che non è possibile..l'ho scritto prima
Il problema è che bisogna ricadere nel caso precedentemente spiegato dell'ottimizzazione.
Se tu hai grandi parti di codice che NON sono soggette a limitazioni prestazionali le puoi scrivere in qualsivoglia linguaggio.
Le parti critiche le devi scrivere nel linguaggio che ti dia il miglior rapporto tempo di programmazione speso/prestazioni ottenute.
E cmq con le versione Real Time di Java magari si sarà un pò + limitati nelle prestazioni... ma a livello di funzionalità, stuttering e cose del genere le due applicazioni sono assolutamente comparabili.

[^TiGeRShArK^]

Originariamente inviato da PGI-Bis

Ok, siamo entrati nel campo della mitologia della scienza informatica .

ma la cosa + bella è mettersi a programmare in python sul cellulare durante un viaggio in macchina...altro che mitologia... è l'indice del puro rotolamento dei coglioni durante una coda di 2 ore di autostrada

[phoenixbf]

Originariamente inviato da ^TiGeRShArK^

+ chiaro ora?

Si ma il punto cruciale sono proprio questi step intermedi (tra l'altro lo dice il testo stesso). io ti parlo di un campo dove una app 3D in base al fatto che ti va a 60 FPS o 50 FPS determina il fallimento del progetto.

Originariamente inviato da ^TiGeRShArK^

assolutamente no.
Con i compilatori attuali le prestazioni di un'applicazione scritta in C++ sono + che sufficienti.
L'assembly viene usato solo per ottimizzare le parti critiche di codice.
Se c'è un metodo che occupa il 40% della CPU e questo metodo è in una porzione dello 0.0001% del codice non mi metto certo a ottimizzare il 100% del codice ma solamente lo 0.0001% critico

Percio ho usato la parola "pazzo", non penso esista qualcuno in grado di gestire un intero progetto complesso in assembler...

Anche nei giochi, alcune parti critiche dell'engine sono sritte in assembler.

Originariamente inviato da ^TiGeRShArK^

cmq ti assicuro che a livello di pranzo e cena (colazione solitamente non la faccio ) non sono messo male nemmeno io

Ah beh, anche io mangio tanto

Originariamente inviato da ^TiGeRShArK^

ma la cosa + bella è mettersi a programmare in python sul cellulare durante un viaggio in macchina...altro che mitologia... è l'indice del puro rotolamento dei coglioni durante una coda di 2 ore di autostrada

LOL

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

a me pare veramente orrido
molto meglio imho questo:

 def qsort(list)
  return [] if list.size == 0
  x, *xs = *list
  less, more = xs.partition{|y| y < x}
  qsort(less) + [x] + qsort(more)
 end

in ruby

def QuickSort(List):
  if len(List) <= 1: return List
  Pivot = List.pop()
  return QuickSort(filter(lambda x: x < Pivot, List)) + [Pivot] + QuickSort(filter(lambda x: x >= Pivot, List))

In Python

Interessante la funzione partition di Ruby. Molto elegante come linguaggio.

[DvL^Nemo]

Ruby, a lavoro qualcuno si sa interessando e ne parlano tutti bene..

[marco.r]

Originariamente inviato da ^TiGeRShArK^

a me pare veramente orrido
molto meglio imho questo:

 def qsort(list)
  return [] if list.size == 0
  x, *xs = *list
  less, more = xs.partition{|y| y < x}
  qsort(less) + [x] + qsort(more)
 end

in ruby

Non e' poi tanto diverso, soprattutto se si tiene conto che la versione su esposta scala all'aumentare di processori/core. Volendo si puo' rinunciare ad un po' di performance e riscriverlo piu' o meno come segue:

qsort [: :] = [: :]
qsort array = lt +++ eq +++ gt
  where
    pivot = array!0
    lt = qsort [: x | x <- array, x < pivot :]
    eq = [: x | x <- array, x == pivot :]
    gt = qsort [: x | x <- array, x > pivot :]

Direi che come chiarezza siamo li' (a me piace pure di piu', ma ad un certo punto e' anche questione di gusti).
Tra l'altro le VM di Python e Ruby hanno un po' di problemi nello sfruttare piu' processori, anche se probabilmente queste cose verranno prima o poi sistemate (jpython e jruby ad esempio non dovrebbero aver tali limit).

[marco.r]

Originariamente inviato da cdimauro

def QuickSort(List):
  if len(List) <= 1: return List
  Pivot = List.pop()
  return QuickSort(filter(lambda x: x < Pivot, List)) + [Pivot] + QuickSort(filter(lambda x: x >= Pivot, List))

In Python

Ha un bug
occhio ai side effects

[marco.r]

Originariamente inviato da PGI-Bis

Ok, siamo entrati nel campo della mitologia della scienza informatica .

Piu' che di mitologia direi si tratta di campanilismo . Ognuno (mi ci metto dentro pure io) tende a dire la sua senza portare molti esempi o prove concrete a sostegno delle proprie convinzioni, e d'altra parte e' difficile farlo.
Per quel che riguarda le mie, devo dire che l'impressione che ho e' che effettivamente i programmi scritti in Java e C# siano in generale sensibilmente piu' lenti di una analoga controparte C/C++, ma che questo non sia dovuto tanto al linguaggio in se, quanto alla catasta di librerie che il programmatore si trova ad dover utilizzare, quasi nessuna pensata con le performance come primo obiettivo. Ad esempio in C++ gli stream di I/O sono molto piu' difficili da estendere, ma le uniche due operazioni costose risultano in pratica essere le operazioni riempimento/svuotamento del buffer.
D'altra parte se non fosse cosi' basterebbe compilare tutto con gcj... piuttosto, soprattutto nel campo delle applicazioni desktop, piu' di qualche applicazione Python da la sensazione di essere piu' "sveglia", anche se magari non e' la piu' veloce in giro.

[cdimauro]

Originariamente inviato da marco.r

Ha un bug
occhio ai side effects

Onestamente mi sfugge: potresti indicarmi dove starebbe il bug? Grazie.

EDIT: penso d'aver capito.

def QuickSort(List):
  if len(List) <= 1: return List
  Pivot = List.pop()
  Less = filter(lambda x: x < Pivot, List)
  More = filter(lambda x: x >= Pivot, List)
  return QuickSort(Less) + [Pivot] + QuickSort(More)

Maledetta fretta.

EDIT2: è pure più leggibile. Meglio così.

[marco.r]

Il problema permane per il ciclo piu' esterno.
Secondo me meglio non modificare la lista, e lavorare in modo piu' "funzionale". In sostanza al posto di

  Pivot = List.pop()

io userei

  Pivot = List[0]
  List = List[1:]

[cdimauro]

Capito. Grazie.