[IMPORTANTISSIMO] Programmare videogames

[fek]

Originariamente inviato da trallallero

eccome no! guarda che arrivi tardi, ci sono gia' le classi
JKernel e JSo

No, arrivi tardi tu

http://is5.cs.man.ac.uk/apt/projects/jamaica/os.php

La CPU esegue bytecode e il kernel e' scritto in...? Java.

Further investigation is under way into implementing a complete bootstrap and runtime kernel in Java targetted for Jamaica and other hardware platforms.

[trallallero]

Originariamente inviato da fek

No, arrivi tardi tu

http://is5.cs.man.ac.uk/apt/projects/jamaica/os.php

La CPU esegue bytecode e il kernel e' scritto in...? Java.

Further investigation is under way into implementing a complete bootstrap and runtime kernel in Java targetted for Jamaica and other hardware platforms.

un kernel in java no! io scherzavo

vabbe' ma in Jamaica con tutta l'erba che si fumano potrebbero farlo anche in Cobol

e comunque sul sito non ci posso andare quindi ... non ci credo

[dnarod]

io saro anche l ultimo dei cani a programmare, ma mi chiedo: "che c e di male se l evoluzione tende ad astrarre e a lavorare a piu alto livello?" la storia dei linguaggi di programmazione e la loro evoluzione si comporta molto come l evoluzione di un cervello umano (ci sono studi che considerano l evoluzione tecnologica come logica conseguenza di quella cerebrale, e io sono quasi fermamente convinto che cio accada per il semplice fatto che la visione antropocentrica dell uomo tende a far modellare delle soluzioni che siano piu vicine al suo modo di pensare)...ripeto, se dagli spinotti intercambiabili si è passati ad assembler ci sara un motivo; se da assembler si è passati a c ci sara un motivo; se da imperativo si sta passando ad oggetti ce ne sara un altro...imho l evoluzione non è una mutua esclusione e non è detto che debba per forza uccidere cio che c era prima; quel che è certo secondo me è che piu passera il tempo e piu si potra scrivere ad alto livello qualcosa di assolutamente valido, lo vedo chiaramente...poi forse non ho capito nulla della vita, ma è la mia idea, e tra l altro per come la vedo il mondo è sempre andato cosi...morale: se non ci fidassimo della lavatrice potremmo sempre lavare i panni a mano, ma oramai penso sia assodato che la lavatrice (alto livello) sia meglio...

[trallallero]

Originariamente inviato da dnarod

io saro anche l ultimo dei cani a programmare, ma mi chiedo: "che c e di male se l evoluzione tende ad astrarre e a lavorare a piu alto livello?" la storia dei linguaggi di programmazione e la loro evoluzione si comporta molto come l evoluzione di un cervello umano (ci sono studi che considerano l evoluzione tecnologica come logica conseguenza di quella cerebrale, e io sono quasi fermamente convinto che cio accada per il semplice fatto che la visione antropocentrica dell uomo tende a far modellare delle soluzioni che siano piu vicine al suo modo di pensare)...ripeto, se dagli spinotti intercambiabili si è passati ad assembler ci sara un motivo; se da assembler si è passati a c ci sara un motivo; se da imperativo si sta passando ad oggetti ce ne sara un altro...imho l evoluzione non è una mutua esclusione e non è detto che debba per forza uccidere cio che c era prima; quel che è certo secondo me è che piu passera il tempo e piu si potra scrivere ad alto livello qualcosa di assolutamente valido, lo vedo chiaramente...poi forse non ho capito nulla della vita, ma è la mia idea, e tra l altro per come la vedo il mondo è sempre andato cosi...morale: se non ci fidassimo della lavatrice potremmo sempre lavare i panni a mano, ma oramai penso sia assodato che la lavatrice (alto livello) sia meglio...

io non son un C ... ista convinto, non voglio fare solgan del tipo "C e' meglio" o scemenze del genere. Di solio scherzo
Ma qui stiamo parlando di creare del codice macchina con un linguaggio che crea del byte code che dovra' essere interpretato
Se ci si riesce ben venga, ma non riesco a capire come sia possibile
Hanno fatto un processore apposta ? il kernel carica una vm ?
Il Java NON puo' scendere di livello come ad esempio il C col quale
scrivi anche in assempler: asm { ...}
Mi manca almeno un anello alla catena ...
Prendo il tuo esempio, immagina una pubblicita che ti dice:
da oggi la nuova lavatrice Pippo! non devi piu' mettere il sapone! se lo crea lei!

a me verrebbe un dubbio

e magari: da domani non servira' neanche l'acqua, la crea!

[dnarod]

esattamente, sicuramente prima o poi (ma per il tuo esempio si parla di moltissimi anni) troveranno il modo di sintetizzare qualsiasi cosa partendo da un mucchietto di carbonio, non è difficile da immaginare...cio di cui ho parlato pero è molto piu terra terra; non esiste solo java e il suo bytecode ad alto livello, anzi il java e uno dei linguaggi "piu nuovi", a sua volta frutto di una concezione fra le piu "nuove" per quanto riguarda la programmazione; per me non è affatto difficile ipotizzare un futuro (o evoluzione di un presente) linguaggio ad alto livello (magari anche piu di un java o di un c++) che, grazie alla ricerca, sia in grado di svolgere le stesse funzioni ma in maniera molto piu facile da capire e produrre per il nostro cervello...alla fine si tratta solo di quello: rendere human-like una cosa che è tutto fuorche quello e farlo per passi successivi...è quello che è sempre accaduto e che accade tutt ora, altrimenti staremmo ancora giocando col pong invece che con motori fotorealistici che simulano comportamenti sempre piu vicini a quella realta che NOI umani percepiamo...l idea del semplificare qualcosa aggiungendo un substrato che fitti le nostre esigenze è secondo me validissima, tant è vero che il mondo si muove in quella direzione (automazione, miniaturizzazione, multifunzionalita,...); quindi per quale motivo non dovrebbe essere cosi anche per uno strumento qualsiasi utilizzato per una delle tante attivita umane (il software nel nostro caso)? a riprova della mia ipotesi ci sono persone qui, che sono sicuramente piu dentro la materia di me (ci lavorano), che manifestano le stesse opinioni che io esprimo in maniera intuitiva (quindi generale, perche non posseggo gli strumenti per esporle in maniera tecnica) e che linkano parole di personaggi autorevoli che dicono le stesse cose...

quindi non dico che il basso livello non ha senso di esistere, dico solo che piu passera il tempo e piu sono convinto che si escogiteranno sistemi per lavorare piu ad alto livello ottimizzando la gestione delle stratificazioni inferiori (un po come l esempio che hai fatto scherzosamente del metodo getOs che restituisce un os gia fatto); sul fatto che questo sia impossibile attualmente concordo pienamente con te, ma solo perche non siamo ancora al livello evolutivo giusto; cio pero non significa che la "direzione in cui lavorare e in cui stanno lavorando tutti" non sia quella

[PGI-Bis]

Ma i linguaggi non scendono da nessuna parte. Qui qualcuno dovrebbe iniziare a dare un'occhiata al patterson-hennessy.

Se in Smalltalk creo un oggetto che si chiama "MachineAdd" e gli do due metodi, add: R1 with: R2 che fa una somma di due registri e toMachineCode: binaryStream che scrive in un flusso i bit

1000110010100000

ditemi cosa mi impedisce di usare Smalltalk per fare un sistema operativo, driver annessi e connessi, senza scrivere una parola di assembly.

Perchè non si fa? Per me è semplicissimo. Hanno investito ottantanni e stramiliardi nell'approccio procedurale e perdiana non cambieranno strada finchè non abbiano spremuto ogni goccia di soldo possibile e immaginabile in quella tecnologia. Guardate l'architettura dei processori, abbiamo lo x86 che fa schifo e piuttosto che mollarla facciamo i processori che traducono internamente i CISC in RISC.

[trallallero]

Originariamente inviato da dnarod

esattamente, sicuramente prima o poi (ma per il tuo esempio si parla di moltissimi anni) troveranno il modo di sintetizzare qualsiasi cosa partendo da un mucchietto di carbonio, non è difficile da immaginare...cio di cui ho parlato pero è molto piu terra terra; non esiste solo java e il suo bytecode ad alto livello, anzi il java e uno dei linguaggi "piu nuovi", a sua volta frutto di una concezione fra le piu "nuove" per quanto riguarda la programmazione; per me non è affatto difficile ipotizzare un futuro (o evoluzione di un presente) linguaggio ad alto livello (magari anche piu di un java o di un c++) che, grazie alla ricerca, sia in grado di svolgere le stesse funzioni ma in maniera molto piu facile da capire e produrre per il nostro cervello...alla fine si tratta solo di quello: rendere human-like una cosa che è tutto fuorche quello e farlo per passi successivi...è quello che è sempre accaduto e che accade tutt ora, altrimenti staremmo ancora giocando col pong invece che con motori fotorealistici che simulano comportamenti sempre piu vicini a quella realta che NOI umani percepiamo...l idea del semplificare qualcosa aggiungendo un substrato che fitti le nostre esigenze è secondo me validissima, tant è vero che il mondo si muove in quella direzione (automazione, miniaturizzazione, multifunzionalita,...); quindi per quale motivo non dovrebbe essere cosi anche per uno strumento qualsiasi utilizzato per una delle tante attivita umane (il software nel nostro caso)? a riprova della mia ipotesi ci sono persone qui, che sono sicuramente piu dentro la materia di me (ci lavorano), che manifestano le stesse opinioni che io esprimo in maniera intuitiva (quindi generale, perche non posseggo gli strumenti per esporle in maniera tecnica) e che linkano parole di personaggi autorevoli che dicono le stesse cose...

quindi non dico che il basso livello non ha senso di esistere, dico solo che piu passera il tempo e piu sono convinto che si escogiteranno sistemi per lavorare piu ad alto livello ottimizzando la gestione delle stratificazioni inferiori (un po come l esempio che hai fatto scherzosamente del metodo getOs che restituisce un os gia fatto); sul fatto che questo sia impossibile attualmente concordo pienamente con te, ma solo perche non siamo ancora al livello evolutivo giusto; cio pero non significa che la "direzione in cui lavorare e in cui stanno lavorando tutti" non sia quella

io non metto limiti a niente. Cioe', a niente ma che soddisfi il mio senso del "bello".
Se mi dici: un giorno avremo le lavatrici che ci vengono a prendere al lavoro avrei qualche
dubbio ma son sicuro che si potra' viaggiare nel tempo
Questo per dire che son d'accordo su quello che hai scritto ed e' la storia ad insegnarcelo:
programmatori di codice macchina quanti ne esisteranno ancora ? Assembly forse ancora ancora
ma ormai c'e' il C se proprio vuoi sporcarti le mani.

Ma il problema e' un'altro: una lavatrice la capisco, l'ho anche smontata, anzi e' piuttosto semplice come meccanismo. Riesce a simulare, in meglio, il lavaggio a mano grazie ai suoi componenti, circuito integrato (o come si chiama) etc. Un kernel in java non mi va giu'
e' presto, troppo presto per una cosa del genere, per me, quindi se c'e' qualcuno che sa come e' stato fatto, per favore lo spieghi ... grazie
Puoi rifare una memcpy in C, come ha fatto qualcuno in questo forum, per divertirti o imparare e magari riesci anche a farla piu' permormante di quella standard (ma dubito) perche' il C ti permette di scendere a livello macchina. In Java no! I processori, fino ad adesso, hanno bisogno di un eseguibile, codice macchina per partire quindi non riesco a capire come si sia riusciti (se e' vero) a fare 'sto cacchio di kernel con un linguaggio interpretato.

[trallallero]

Originariamente inviato da PGI-Bis

Ma i linguaggi non scendono da nessuna parte. Qui qualcuno dovrebbe iniziare a dare un'occhiata al patterson-hennessy.

Se in Smalltalk creo un oggetto che si chiama "MachineAdd" e gli do due metodi, add: R1 with: R2 che fa una somma di due registri e toMachineCode: binaryStream che scrive in un flusso i bit

1000110010100000

ditemi cosa mi impedisce di usare Smalltalk per fare un sistema operativo, driver annessi e connessi, senza scrivere una parola di assembly.

Perchè non si fa? Per me è semplicissimo. Hanno investito ottantanni e stramiliardi nell'approccio procedurale e perdiana non cambieranno strada finchè non abbiano spremuto ogni goccia di soldo possibile e immaginabile in quella tecnologia. Guardate l'architettura dei processori, abbiamo lo x86 che fa schifo e piuttosto che mollarla facciamo i processori che traducono internamente i CISC in RISC.

e' quello che avevo scritto qualche post fa:
quando cambieranno tecnologia e faranno i processori alla molecola di nutella o all'uranio arricchito toglieremo il C dalle balle ....

[71104]

Originariamente inviato da trallallero

[...] quindi non riesco a capire come si sia riusciti (se e' vero) a fare 'sto cacchio di kernel con un linguaggio interpretato.

evidentemente non è interpretato, ma qualche pezzo sarà stato compilato in maniera nativa; dal un programma Java nulla vieta che si possa produrre un exe o un eseguibile ELF, e magari pure un binario puro (che è quello che vuole la macchina all'avvio)

[cionci]

Originariamente inviato da 71104

un programma Java nulla vieta che si possa produrre un exe o un eseguibile ELF, e magari pure un binario puro (che è quello che vuole la macchina all'avvio)

In teoria questa cosa la puoi fare senza il supporto Sun, con GCJ...il compilatore Java GNU...

[k0nt3]

io credo che si intende l'esecuzione di bytecode (o almeno parte di esso) via hardware... è una ca#*@ata?

[Xalexalex]

Scusate se mi intrometto. Solo per fare i complimenti a tutti per la mole di cose che sapete. Sto imparando più da questa discussione che in 16 anni di vita...
Solo due cosucce:

1) Esiste un manuale di LUA (cartaceo è meglio, inglese è perfetto).
2)Tanto per animare la discussione, io uso Whitespace.

[MEMon]

Comunque se non lo sapevate ancora il linguaggio grafico g di labview è il migliore di tutti!!!!

[Racer89]

e io che so un pò di programmazione strutturata e quella orientata agli oggetti cosa dovrei fare ora?

[71104]

Originariamente inviato da Racer89

e io che so un pò di programmazione strutturata e quella orientata agli oggetti cosa dovrei fare ora?

scegliere una strada ed intraprenderla: scegli cosa ti piace fare e studia quali sono gli strumenti più adatti nel tuo settore a livello di linguaggi di programmazione

[shinya]

Originariamente inviato da Racer89

e io che so un pò di programmazione strutturata e quella orientata agli oggetti cosa dovrei fare ora?

Studiare un pò di programmazione funzionale, così sai un pò di tutto
Ti consiglio haskell. Buon viaggio!

[fek]

Originariamente inviato da trallallero

Ma qui stiamo parlando di creare del codice macchina con un linguaggio che crea del byte code che dovra' essere interpretato

Il bytecode (o il CLI in .NET) non viene interpretato
Al momento della prima esecuzione di un metodo, il Just In Time compiler lo traduce al volo in codice macchina e questo viene eseguito dalla CPU per la quale non c'e' differenza se quel codice macchina arriva da un bytecode tradotto al volo oppure da un codice C pre-compilato. Dalla seconda esecuzione in poi del metodo, la traduzione non avviene piu'. Sia in Java sia in .NET si puo' precompilare tutto una volta in codice macchina: a quel punto e' del tutto indistinguibile. In .NET puoi fare aritmetica dei puntatori e scrivere ovunque in memoria, ma non solo non e' consigliato, in quel caso l'assembly diventa "non puro" e l'utente puo' decidere di non eseguirlo se non ha certificati.

E' curioso notare come esistono situazioni in cui, attenzione, il codice intermedio in bytecode o CLI e' eseguito piu' velocemente rispetto a codice precompilato!

Guarda questo esempio:

for (int i = 0; i < numero_molto_alto; ++i)
{
  if (CalcolaQualcosa() > 0)     // 1
  {
      // esegui molto codice     // 2
  }
  else
  {
     // esegui poco codice      // 3
  }
}

Ora immagina che CalcolaQualcosa ritorni nella maggior parte dei casi un valore minore di 0, cosi' la seconda parte del branch viene eseguita spessissimo, il primo branch molto raramente.

Un compilatore C produce codice assembly nello stesso ordine in cui e' scritto il codice, prima il primo branch poi il secondo.
L'esecuzione assomiglia a qualcosa del tipo:

- Entra nel ciclo
- esegui 1, test fallisce
- esegui 3... ma... c'e' molto codice in mezzo... CACHE MISS! Carica la pagina in cui c'e' il codice di 3, esegui
- Ritorna all'inizio del ciclo

Hai un cache miss garantito quasi ad ogni ciclo

Il compilatore C non puo' fare assunzioni sul valore ritornato da CalcolaQualcosa() cosi' non puo' scambiare gli if, lo devi fare tu a mano (se te ne accorgi).

Un compilatore JIT puo' farlo invece, perche' conosce quante volte e' preso il branch 1 e quante il branch 2 e puo' girare e impacchettare il codice a suo piacimento durante l'esecuzione: gli basta ricompilare il metodo con il test invertito e i due branch invertiti. Risultato: quel codice in Java/.NET e' piu' veloce che se scritto in C date le premesse

A completare il discorso, esistono compilatori C++ che possono fare una cosa simile: si compila l'eseguibile, lo si lancia con ingressi piu' o meno comuni, si raccolgono le statistiche, si ricompila il codice con questi dati in ingresso. Il risultato e' molto simile, se non per il fatto che un JIT puo' riorganizzare quel codice anche se gli input cambiano e non sono comuni durante l'esecuzione. Un compilatore C++ non puo': una volta compilato e fatto il deploy, il codice macchina non cambia piu'.

[fek]

Originariamente inviato da trallallero

e' quello che avevo scritto qualche post fa:
quando cambieranno tecnologia e faranno i processori alla molecola di nutella o all'uranio arricchito toglieremo il C dalle balle ....

Il C o meglio il C++ o l'assembly non lo toglierai probabilmente mai dalle balle. Qualche riga di codice in assembly sara' sempre e comunque scritta. Non e' questo il punto, nessuno sano di mente vuole eliminare i linguaggi a basso livello perche' hanno il loro scopo e il loro utilizzo.

Il discorso non e' qui, il discorso e' quanto codice oggi si scrive in C++ e quanto in linguaggi ad alto livello? Quanto ieri e quanto domani? Spannometricamente, dieci anni fa probabilmente il 90% del codice si scriveva in C/C++, oggi probabilmente solo il 20/30%, domani probabilmente solo l'1%. Il codice restante si scrive con strumenti piu' ad alto livello, piu' produttivi e migliori per quegl'ambiti. Se devo scrivere un inner loop in un task scheduler che deve manipolare direttamente la CPU, oppure del codice di un driver che deve direttamente la GPU, molto probabilmente lo scrivero' in assembly o in C/C++.

[trallallero]

Non quoto niente perche hai (fek) scritto troppo

vedo che sei preparatissimo sull'argomento, io ho solo una forte conoscenza del C/C++, molto intuito e parecchia logica. Ho studiato solo ad un corso privato di 6 mesi, salvandomi tra l'altro dalla fame perche' era un periodo di boom (1998/1999)
Ma ho fatto i miei bei progettini
So che esistono tools per i programmi scritti in C/C++ che fanno analisi sulle prestazioni, sulle chiamate alle funzioni per riuscire a velocizzare al massimo l'eseguibile (io non li ho mai usati perche' non mi servono ) e fino a qui ci siamo, ti seguo. Ma stento a credere che ci sia un qualcosa che lo faccia al meglio in automatico
Impressionante!
E comunque se mi dici che il programma fatto in java viene convertito in eseguibile allora cambia tutto


PS: cos'e' il CACHE MISS ?

[fek]

Originariamente inviato da trallallero

PS: cos'e' il CACHE MISS ?

Anche il codice da eseguire e' conservato in memoria da qualche parte e dev'essere prelevato dalla memoria per poter eseguito dalla CPU.

Banalizzando molto, una CPU lavora con un modello di questo tipo:

1) fetch istruzione dalla memoria
2) decodifica istruzione dalla memoria
3) esegui istruzione

Come sicuramente sai, prelevare dati dalla memoria e' un'operazione lenta, allora le CPU fanno il prefetch di un blocco di memoria sapendo che molto probabilmente in futuro eseguiranno un'istruzione conservata vicino all'istruzione correntemente in esecuzione. In questo modo la CPU molto spesso preleva l'istruzione da una memoria molto veloce al suo interno perche' e' stato fatto il prefetch prima e non deve aspettare. Se c'e' un salto (e il salto non e' stato previsto), la CPU deve scartare tutto e andare in memoria centrale ad aspettare la nuova istruzione da eseguire (questo e' un cache miss).

Complica il tutto per CPU superscalari a esecuzione dinamica ed hai un quadro vago di come funziona una CPU

In realta' nel mio piccolo esempio di prima le CPU moderne sono in grado di accorgersi che c'e' un salto in corso e prevedere dove andare a pescare la prossima istruzione e farne prima il prefetch evitando il cache miss.

Quello infatti e' un esempio semplificato, puoi complicarlo fino al punto da mandare in crisi l'unita' di branch prediction della CPU e ritrovarti con il codice Java che va 10 volte piu' veloce di quello C in quella particolare situazione.