Alfonso Maruccia

Android, il successore di Dalvik si chiama ART

Una delle novità introdotte in sordina dall'ultima release dell'OS mobile potrebbe avere ricadute significative sul fronte delle prestazioni. Google si starebbe preparando a sostituire la discussa virtual machine di Android

Roma - Il debutto ufficiale di Android "KitKat" 4.4 include una novità non molto pubblicizzata ma potenzialmente importante per il futuro dell'OS mobile, vale a dire una nuova tecnologia pensata per ottimizzare l'esecuzione delle app per i singoli terminali su cui queste vengono scaricate.

ART (Android Runtime), questo il nome della nuova soluzione, è al momento un'opzione di runtime che è possibile abilitare dal menù sviluppatori dell'OS: con ART Google intende sostituire Dalvik, la discussa virtual machine Java che tra le altre cose è al centro della storica contesa legale tra Mountain View e Oracle.

I dettagli sono ancora scarsi, ma le prime indiscrezioni descrivono ART come un radicale cambiamento di prospettiva rispetto al modello adottato con Dalvik: se in quest'ultimo caso il codice Java viene interpretato ed eseguito al volo tramite compilatore just-in-time (JIT), con il nuovo approccio la fase di compilazione avviene al momento del download delle app da Google Play.
Avere a disposizione codice macchina già compilato dovrebbe portare vantaggi significativi sul fronte delle prestazioni, tanto più che ART potrebbe adottare una serie di ottimizzazioni in grado di incrementare ulteriormente tali performance sul terminale in uso. E il tutto senza interferire con la compatibilità con le app attuali.

A quando il debutto di ART e il pensionamento di Dalvik? Gli sviluppatori Android non promettono nulla ma anticipano una possibile adozione della nuova soluzione in tempo per la prossima release dell'OS mobile. Al momento il progetto è maturo e in fase di ottimizzazione.

Alfonso Maruccia
Notizie collegate
  • BusinessGoogle presenta il conto a OracleDal momento che la prima sentenza ha dato ragione a Mountain View sulla gran parte delle accuse, Google dice di esser la parte vincente e chiede il rimborso dei costi sostenuti
  • TecnologiaAndroid, è il momento di addentare KitKatGoogle annuncia il rilascio dell'ultima release del suo OS per dispositivi mobile, promettendo un'esperienza utente migliore e una maggior attenzione alle prestazioni e ai telefonini con hardware meno dotato
111 Commenti alla Notizia Android, il successore di Dalvik si chiama ART
Ordina
  • Ma non so nemmeno da dove cominciare!
    Una caterva di errori senza fine, e nessuno nel forum che se ne accorge!

    Con JAVA si intendono comunemente 2 cose MOLTO differenti fra loro:

    1) Un linguaggio di programmazione (JSL, da Java Specification Language)
    2) Un ambiente di runtime (JVM Java Virtual Machine)

    Normalmente le due cose sono legate: un programma java lo esegui su di una JVM

    Non è detto debba essere così: ci sono molti linguaggi capaci di essere eseguiti su di una JVM. Java, Scala, Python, Ruby i più noti. notare che l'implementazione di ruby per jvm è notoriamente un po' più veloce di quella scritta in C

    Ci sono dei casi in cui Java è usato come linguaggio, ma non viene compilato in bytecode java, ma in qualcos'altro. C'è modo di compilarlo DIRETTAMENTE in codice nativo. Altri lo compilano in bytecode per una virtual machine non java (caso Davlik)

    Quando qualcuno dice che su android java è lento dice qualcosa di insensato: in android java è usato solo come linguaggio. Un linguaggio non ha senso dire che è lento o veloce. Vedi javascript: hanno sempre detto che era lentissimo... ora V8 ha un compilatore JIT che lo rende veloce quasi come il nativo... ci fanno server cazzuti, in javascript... ma non è cambiato il linguaggio.

    Semmai è Davlik che è lento.

    Nell'articolo dicono che vogliono sostituire Davlik. Che c'entra java?

    Ah già.. "Davlik la discussa virtual machine java", solo che NON E' UNA virtual machine java... è una virtual machine DVK, che per coincidenza usa bytecode che originariamente era scritto in java.

    Sempre dal testo dell'articolo, pare che i programmi continueranno ad essere scritti in java, per cui il "finalmente" non si capisce da dove viene

    Ah, btw, è java (la specifica) e non davlik la contesa fra Oracle e Google!
    non+autenticato
  • - Scritto da: Alex
    > Ma non so nemmeno da dove cominciare!
    > Una caterva di errori senza fine, e nessuno nel
    > forum che se ne
    > accorge!
    >
    > Con JAVA si intendono comunemente 2 cose MOLTO
    > differenti fra
    > loro:
    >
    > 1) Un linguaggio di programmazione (JSL, da Java
    > Specification
    > Language)
    > 2) Un ambiente di runtime (JVM Java Virtual
    > Machine)
    >
    > Normalmente le due cose sono legate: un programma
    > java lo esegui su di una
    > JVM
    >
    > Non è detto debba essere così: ci sono molti
    > linguaggi capaci di essere eseguiti su di una
    > JVM. Java, Scala, Python, Ruby i più noti. notare
    > che l'implementazione di ruby per jvm è
    > notoriamente un po' più veloce di quella scritta
    > in
    > C
    >
    > Ci sono dei casi in cui Java è usato come
    > linguaggio, ma non viene compilato in bytecode
    > java, ma in qualcos'altro. C'è modo di compilarlo
    > DIRETTAMENTE in codice nativo. Altri lo compilano
    > in bytecode per una virtual machine non java
    > (caso
    > Davlik)
    >
    > Quando qualcuno dice che su android java è lento
    > dice qualcosa di insensato: in android java è
    > usato solo come linguaggio. Un linguaggio non ha
    > senso dire che è lento o veloce. Vedi javascript:
    > hanno sempre detto che era lentissimo... ora V8
    > ha un compilatore JIT che lo rende veloce quasi
    > come il nativo... ci fanno server cazzuti, in
    > javascript... ma non è cambiato il
    > linguaggio.
    >
    > Semmai è Davlik che è lento.

    Davlik è dentro Android, Davlik è lento, quindi Android è lento.

    Se e quanto toglieranno Davlik, verificheremo l'alternativa.
    Oggi l'ottimizzazione di Android è penosa, domani vedremo.
    non+autenticato
  • - Scritto da: Lesto

    > Davlik è dentro Android, Davlik è lento, quindi
    > Android è
    > lento.

    dalvik non davlik


    > Se e quanto toglieranno Davlik, verificheremo
    > l'alternativa.
    > Oggi l'ottimizzazione di Android è penosa, domani
    > vedremo.

    lento, penoso, ma rispetto a cosa? chi è la baseline?

    ti rendi conto che l'ottimizzazione assoluta non esiste? quello che si può fare è scegliere quale compromesso è il migliore per la propria situazione

    credi che i programmi che scrivi per ios producano un assembly perfetto e che sia il più veloce in assoluto?
    non+autenticato
  • - Scritto da: collione
    > - Scritto da: Lesto
    >
    > > Davlik è dentro Android, Davlik è lento,
    > quindi
    > > Android è
    > > lento.
    >
    > dalvik non davlik
    >
    >
    > > Se e quanto toglieranno Davlik, verificheremo
    > > l'alternativa.
    > > Oggi l'ottimizzazione di Android è penosa,
    > domani
    > > vedremo.
    >
    > lento, penoso, ma rispetto a cosa? chi è la
    > baseline?
    >
    > ti rendi conto che l'ottimizzazione assoluta non
    > esiste? quello che si può fare è scegliere quale
    > compromesso è il migliore per la propria
    > situazione
    >
    > credi che i programmi che scrivi per ios
    > producano un assembly perfetto e che sia il più
    > veloce in
    > assoluto?
    non avendo di mezzo aot o jit vanno sicuramente meglioOcchiolino
    non+autenticato
  • - Scritto da: Dr Doom

    > non avendo di mezzo aot o jit vanno sicuramente
    > meglio
    >Occhiolino

    non per deludere le tue aspettative, ma la compilazione aot è quella che fanno tutti i normali compilatori esistenti

    per compilazione aot, si intende creare un eseguibile a partire dai sorgenti

    è semmai la jit che potrebbe essere più lenta, ma ha il vantaggio di poter ottimizzare a runtime per la cpu su cui il programma sta girando

    se tu compili un programma per 386, non userai nessuna delle tecnologie offerte dall'ultimissimo core i7

    invece con compilazione jit, è il compilatore a creare il codice eseguibile, ottimizzandolo per il core i7 su cui sta girando
    non+autenticato
  • - Scritto da: collione

    > credi che i programmi che scrivi per ios
    > producano un assembly perfetto e che sia il più
    > veloce in assoluto?

    A guardare facebook si direbbe di noA bocca aperta

    Comunque, per quel che serve ad un sistema per smartphone, cioè che il dispositivo risponda rapidamente ai comandi dell'utente, ho l'impressione che il problema non sia la macchina virtuale o il codice nativo.
    FDG
    10893
  • ma infatti il primo problema di android è il crapware installato dagli oem

    un samsung e un nexus danno un'esperienza d'uso completamente differente, quindi è evidente che il problema sta da qualche altra parte
    non+autenticato
  • - Scritto da: collione
    > - Scritto da: Lesto
    >
    > > Davlik è dentro Android, Davlik è lento,
    > quindi
    > > Android è
    > > lento.
    >
    > dalvik non davlik

    questo riguarda anche l'OP criticone
    non+autenticato
  • eh beh, usando le sue parole, si è trattato di strafalcioniA bocca aperta
    non+autenticato
  • - Scritto da: sgobbio
    > - Scritto da: collione
    > > - Scritto da: Lesto
    > >
    > > > Davlik è dentro Android, Davlik è lento,
    > > quindi
    > > > Android è
    > > > lento.
    > >
    > > dalvik non davlik
    >
    > questo riguarda anche l'OP criticone
    Il giavaiolo tipicoA bocca aperta
    non+autenticato
  • Si ok ma il punto è che java non c'entra nulla, mentre tutti sono li a dire che è colpa di Java. Da java-fan mi rode un po' questo astio del tutto non motivato...
    non+autenticato
  • Ora che Android si lascerà alle spalle la VM Java le prestazioni faranno un ulteriore balzo in avanti... la vedo sempre più nera per iPhone, quando verrà colmato questo piccolo gap prestazionale iPhone non avrà proprio più alcuna attrattiva, già adesso ha uno schermo piccolo, poca memoria ed in compenso il prezzo più alto!
    Ora che Google sta ottimizzando Android recuperando memoria e prestazioni vedrete che anche i terminali entry level avranno prestazioni considerevoli con ben poco da invidiare ad un iPhone 4S!
    Non è un caso che quelli di apple stiano pensando di lanciare il prossimo anno un Iphone con display attorno ai 5 pollici... chissà come lo chiameranno? iPhone maxi? Con tanti saluti alla supposta frammentazione!
  • - Scritto da: Enjoy with Us
    > Ora che Android si lascerà alle spalle la VM Java
    > le prestazioni faranno un ulteriore balzo in
    > avanti... la vedo sempre più nera per iPhone,
    > quando verrà colmato questo piccolo gap
    > prestazionale iPhone non avrà proprio più alcuna
    > attrattiva, già adesso ha uno schermo piccolo,
    > poca memoria ed in compenso il prezzo più
    > alto!
    > Ora che Google sta ottimizzando Android
    > recuperando memoria e prestazioni vedrete che
    > anche i terminali entry level avranno prestazioni
    > considerevoli con ben poco da invidiare ad un
    > iPhone
    > 4S!
    > Non è un caso che quelli di apple stiano pensando
    > di lanciare il prossimo anno un Iphone con
    > display attorno ai 5 pollici... chissà come lo
    > chiameranno? iPhone maxi? Con tanti saluti alla
    > supposta
    > frammentazione!
    Ma tu sei la controparte Androidiana dei vari Maxsix, bertuccia e ruppolo?
    non+autenticato
  • Sono anni ormai che i commenti su PI sono al 95% di account macchietta, fanboy e troll.
    non+autenticato
  • - Scritto da: il pensatore
    > - Scritto da: Enjoy with Us
    > > Ora che Android si lascerà alle spalle la VM
    > Java
    > > le prestazioni faranno un ulteriore balzo in
    > > avanti... la vedo sempre più nera per iPhone,
    > > quando verrà colmato questo piccolo gap
    > > prestazionale iPhone non avrà proprio più
    > alcuna
    > > attrattiva, già adesso ha uno schermo
    > piccolo,
    > > poca memoria ed in compenso il prezzo più
    > > alto!
    > > Ora che Google sta ottimizzando Android
    > > recuperando memoria e prestazioni vedrete che
    > > anche i terminali entry level avranno
    > prestazioni
    > > considerevoli con ben poco da invidiare ad un
    > > iPhone
    > > 4S!
    > > Non è un caso che quelli di apple stiano
    > pensando
    > > di lanciare il prossimo anno un Iphone con
    > > display attorno ai 5 pollici... chissà come
    > lo
    > > chiameranno? iPhone maxi? Con tanti saluti
    > alla
    > > supposta
    > > frammentazione!
    > Ma tu sei la controparte Androidiana dei vari
    > Maxsix, bertuccia e
    > ruppolo?

    Io sto dalla parte mia, ossia del consumatore e sono contento quando escono nuovi prodotti a prezzi competitivi, sono contro tutti quei produttori che invece cercano di spremere gli utenti come limoni, di cui sicuramente Apple è un degno rappresentante, non che sia l'unico, anzi!
  • - Scritto da: Enjoy with Us
    > Io sto dalla parte mia, ossia del consumatore e
    > sono contento quando escono nuovi prodotti a
    > prezzi competitivi, sono contro tutti quei
    > produttori che invece cercano di spremere gli
    > utenti come limoni, di cui sicuramente Apple è un
    > degno rappresentante, non che sia l'unico,
    > anzi!
    Strano, quello che scrivi ha proprio l'aria di essere una grossa markettata
    non+autenticato
  • - Scritto da: il pensatore
    > - Scritto da: Enjoy with Us
    > > Io sto dalla parte mia, ossia del
    > consumatore
    > e
    > > sono contento quando escono nuovi prodotti a
    > > prezzi competitivi, sono contro tutti quei
    > > produttori che invece cercano di spremere gli
    > > utenti come limoni, di cui sicuramente Apple
    > è
    > un
    > > degno rappresentante, non che sia l'unico,
    > > anzi!
    > Strano, quello che scrivi ha proprio l'aria di
    > essere una grossa
    > markettata

    markettata? E per chi?
    Sai di scelte con android ne hai diverse non è che sei legato a Samsung, LG o Sony !
  • > markettata? E per chi?
    > Sai di scelte con android ne hai diverse non è
    > che sei legato a Samsung, LG o Sony
    > !
    sveglia
    sei legato mani e piedi a google
    non+autenticato
  • tanto legato che Amazon si è fatta il "suo" android.
    senza contare le varie "factory" tipo la famosa Cyanogen oppure OmniROM e via elencando.
    Trotterella verso lidi che conosci meglio che ti conviene.
    non+autenticato
  • - Scritto da: morticia addams

    > tanto legato che Amazon si è fatta il "suo"
    > android.
    > senza contare le varie "factory" tipo la famosa
    > Cyanogen oppure OmniROM e via elencando.
    > Trotterella verso lidi che conosci meglio che ti
    > conviene.

    https://developers.google.com/maps/documentation/a.../

    p.s.: a meno che non ti chiami Amazon, vai a finire necessariamente li.
    -----------------------------------------------------------
    Modificato dall' autore il 12 novembre 2013 10.07
    -----------------------------------------------------------
    FDG
    10893
  • si ok, ma l'amico Trotterello ha scritto una cazzata colossale

    chi mi impedisce di usare i sorgenti di android per farmi un os custom? ergo, posso liberarmi di google quando voglio

    faccio notare che ci sono svariate librerie per far girare eseguibili linux su android, pacchetti android su linux ( windows e mac!! ), libc alternative sia a glibc sia a bionic

    non mi pare proprio che l'ecosistema android/linux sia legato mani e piedi a google
    non+autenticato
  • - Scritto da: morticia addams
    > tanto legato che Amazon si è fatta il "suo"
    > android.
    Amazon è un colosso, vende hw in perdita per guadagnare sulla vendita di servizi.
    Non di certo un buon esempio il tuo.
    non+autenticato
  • Scusate, ma a questo punto non conviene dare direttamente agli sviluppatori anche le specifiche per scrivere le app in C++?
    I problemi di sicurezza non cambiano da un linguaggio all'altro, se tieni i processi isolati e gestisci bene la sicurezza a livello di sistema operativo.
    Ormai ci sono anche dei meccanismi per gestire la memoria allocata in modo intelligente.
    O mi sono perso qualcosa?
    non+autenticato
  • - Scritto da: vituzzo
    > Scusate, ma a questo punto non conviene dare
    > direttamente agli sviluppatori anche le
    > specifiche per scrivere le app in
    > C++?
    > I problemi di sicurezza non cambiano da un
    > linguaggio all'altro, se tieni i processi isolati
    > e gestisci bene la sicurezza a livello di sistema
    > operativo.
    > Ormai ci sono anche dei meccanismi per gestire la
    > memoria allocata in modo
    > intelligente.
    > O mi sono perso qualcosa?
    Ti sei perso che se scrivi in C++ o in C non ti serve Dalvik dato che Dalvik è la VM che serve a far girare codice Java.
    non+autenticato
  • - Scritto da: morticia addams
    > - Scritto da: vituzzo
    > > Scusate, ma a questo punto non conviene dare
    > > direttamente agli sviluppatori anche le
    > > specifiche per scrivere le app in
    > > C++?
    > > I problemi di sicurezza non cambiano da un
    > > linguaggio all'altro, se tieni i processi
    > isolati
    > > e gestisci bene la sicurezza a livello di
    > sistema
    > > operativo.
    > > Ormai ci sono anche dei meccanismi per
    > gestire
    > la
    > > memoria allocata in modo
    > > intelligente.
    > > O mi sono perso qualcosa?
    > Ti sei perso che se scrivi in C++ o in C non ti
    > serve Dalvik dato che Dalvik è la VM che serve a
    > far girare codice
    > Java.

    Ok, ma c'è un motivo per il quale bisogna far girare necessariamente le app all'interno di Dalvik?
    non+autenticato
  • non necessariamente sdk (java-dalvik) e ndk (c, c++) sono comunque cose differenti se hai applicazioni "near-self-contained" con molto dispendio di CPU direi che conviene ndk else..
    In ogni caso nessuno vieta nulla.
    tra l'altro puoi andare da java a c (e viceversa) via JNI
    non+autenticato
  • - Scritto da: vituzzo
    > Scusate, ma a questo punto non conviene dare
    > direttamente agli sviluppatori anche le
    > specifiche per scrivere le app in
    > C++?
    > I problemi di sicurezza non cambiano da un
    > linguaggio all'altro, se tieni i processi isolati
    > e gestisci bene la sicurezza a livello di sistema
    > operativo.
    > Ormai ci sono anche dei meccanismi per gestire la
    > memoria allocata in modo
    > intelligente.
    > O mi sono perso qualcosa?


    Perchè secondo te gli pseudo programmatori "java" conoscono il "c"?
  • - Scritto da: Enjoy with Us
    > - Scritto da: vituzzo
    > > Scusate, ma a questo punto non conviene dare
    > > direttamente agli sviluppatori anche le
    > > specifiche per scrivere le app in
    > > C++?
    > > I problemi di sicurezza non cambiano da un
    > > linguaggio all'altro, se tieni i processi
    > isolati
    > > e gestisci bene la sicurezza a livello di
    > sistema
    > > operativo.
    > > Ormai ci sono anche dei meccanismi per
    > gestire
    > la
    > > memoria allocata in modo
    > > intelligente.
    > > O mi sono perso qualcosa?
    >
    >
    > Perchè secondo te gli pseudo programmatori "java"
    > conoscono il
    > "c"?

    Beh io di mestiere faccio il programmatore Java, però all'università mi hanno fatto studiare e scrivere parecchio codice in C.
    Per lavorare come programmatore C avrei bisogno di fare qualche mese di tirocinio, ma qualche app la saprei scrivere.
    non+autenticato
  • - Scritto da: vituzzo
    > - Scritto da: Enjoy with Us
    > > - Scritto da: vituzzo
    > > > Scusate, ma a questo punto non conviene
    > dare
    > > > direttamente agli sviluppatori anche le
    > > > specifiche per scrivere le app in
    > > > C++?
    > > > I problemi di sicurezza non cambiano da un
    > > > linguaggio all'altro, se tieni i processi
    > > isolati
    > > > e gestisci bene la sicurezza a livello di
    > > sistema
    > > > operativo.
    > > > Ormai ci sono anche dei meccanismi per
    > > gestire
    > > la
    > > > memoria allocata in modo
    > > > intelligente.
    > > > O mi sono perso qualcosa?
    > >
    > >
    > > Perchè secondo te gli pseudo programmatori
    > "java"
    > > conoscono il
    > > "c"?
    >
    > Beh io di mestiere faccio il programmatore Java,
    > però all'università mi hanno fatto studiare e
    > scrivere parecchio codice in
    > C.
    > Per lavorare come programmatore C avrei bisogno
    > di fare qualche mese di tirocinio, ma qualche app
    > la saprei
    > scrivere.

    Ecco appunto e pensa a tutti quei "programmatori" Java che all'università manco ci sono andati, è gente con bassissime capacità in grado in pratica di mettere insieme solo più librerie o poco più e secondo te sarebbero disponibili a sudare sui libri per imparare un vero linguaggio di programmazione?
  • - Scritto da: Enjoy with Us

    > Ecco appunto e pensa a tutti quei "programmatori"
    > Java che all'università manco ci sono andati, è
    > gente con bassissime capacità in grado in pratica
    > di mettere insieme solo più librerie o poco più e
    > secondo te sarebbero disponibili a sudare sui
    > libri per imparare un vero linguaggio di
    > programmazione?

    Spiegami perché Java non sarebbe "un vero linguaggio di programmazione"
    Prozac
    4974
  • - Scritto da: Prozac

    > Spiegami perché Java non sarebbe "un vero
    > linguaggio di
    > programmazione"

    perchè è un demoniaco linguaggio di programmazioneA bocca aperta

    certo è potente, ha una libreria standard vastissima, senza contare le librerie di terze parti

    il problema è che ormai è diventato troppo complesso da addomesticare ( ricordo gli incubi avuti per realizzare un servizio RESTful in java )
    non+autenticato
  • Perchè nessuno di quelli che usano java sa come si programma per oggetti (e ancora meno per componenti).
    Ovviamente tutti dicono invece di saperlo fare.
    Insomma la media dei programmatori Java in circolazione è "presocratica".
    Socrate diceva che sapeva di non sapere, loro invece credono di sapere e i risultati si vedono.
    non+autenticato
  • - Scritto da: morticia addams
    > Perchè nessuno di quelli che usano java sa come
    > si programma per oggetti (e ancora meno per
    > componenti).
    > Ovviamente tutti dicono invece di saperlo fare.
    > Insomma la media dei programmatori Java in
    > circolazione è
    > "presocratica".
    > Socrate diceva che sapeva di non sapere, loro
    > invece credono di sapere e i risultati si
    > vedono.

    Cosa c'entrano i "programmatori Java" con il fatto che Java non sia "un vero linguaggio di programmazione"?

    A parte che i "programmatori Java" sono tali perché coinvolti in progetti in cui è richiesto Java. Io ne conosco molti e tutti questi "programmatori Java" sono, prima di tutto, informatici. Usano Java perché lo richiede il progetto su cui stanno lavorando. Ma, in passato, potrebbero aver usato C o C++. In futuro chissà.

    Io pure, negli ultimi 6 anni ho passato molto tempo su progetti a grande predominanza di Java. Ma nei mei 20 e passa anni da sviluppatore (ultimamente sviluppo un po' meno) ho lavorao in "Pascal" (Delphi), in C/C++, in Perl, in PHP, in Fortran...

    Poi se mi vieni a parlare di programmatori junior, neo-laureati che hanno a malapena fatto un esame di programmazione a oggetti beh... Quello è un altro discorso. E vorrei proprio vederli lavorare a oggetti in C++ visto che non sono capaci di farlo in Java...

    Dal tuo commento, il problema non è Java. Il problema sono i sedicenti programmatori Java.
    Prozac
    4974
  • con tutti i soldi e la gente che ha google ci voleva tanto ad arrivarci?
    non+autenticato
  • - Scritto da: gimpo giampo
    > con tutti i soldi e la gente che ha google ci
    > voleva tanto ad
    > arrivarci?

    Nonostante i soldi ha copiato a piene mani da Apple e ha usato, senza averne diritto, Java. Sono dei parassiti, esattamente come Samsung.
    ruppolo
    33147
  • - Scritto da: ruppolo
    > - Scritto da: gimpo giampo
    > > con tutti i soldi e la gente che ha google ci
    > > voleva tanto ad
    > > arrivarci?
    >
    > Nonostante i soldi ha copiato a piene mani da
    > Apple e ha usato, senza averne diritto, Java.

    False entrambe le affermazioni.

    > Sono dei parassiti, esattamente come
    > Samsung.

    Esattamente come chi saccheggia a piene mani da progetti open rilasciati con licenza BSD e poi rivende il prodotto finito blindandolo dietro una licenza proprietaria.......
    non+autenticato
  • - Scritto da: ruppolo

    > Nonostante i soldi ha copiato a piene mani da
    > Apple e ha usato, senza averne diritto, Java.
    > Sono dei parassiti, esattamente come
    > Samsung.

    si certo, e il processo oracle-google è stata una farsa, i giudici erano comunisti e Berlusconi santo subito Rotola dal ridere
    non+autenticato
  • - Scritto da: ruppolo
    > Nonostante i soldi ha copiato a piene mani da
    > Apple e ha usato, senza averne diritto, Java.
    > Sono dei parassiti, esattamente come
    > Samsung.

    MWAHAHAHAHAHahahah Rotola dal ridereRotola dal ridereRotola dal ridere sto rotolando giù dalla poltrona Rotola dal ridereRotola dal ridere

    ogni tanto ci vuole qualche lettura divertente e anti-stress come questaA bocca aperta adesso posso tornare a lavorare
    non+autenticato
  • - Scritto da: ruppolo
    > - Scritto da: gimpo giampo
    > > con tutti i soldi e la gente che ha google ci
    > > voleva tanto ad
    > > arrivarci?
    >
    > Nonostante i soldi ha copiato a piene mani da
    > Apple e ha usato, senza averne diritto, Java.
    > Sono dei parassiti, esattamente come
    > Samsung.

    La solita sparata del talebano ruppolo
    non+autenticato
  • "il codice Java viene interpretato ed eseguito al volo tramite compilatore just-in-time (JIT)"

    In java il codice viene O interpretato (esecuzione del byte code) O eseguito da codice nativo precedentemente compilato dal compilatore JIT, il cui risultato viene cacheato per le future esecuzioni.
    Questo processo avviene dopo un certo numero di esecuzioni, e quindi tipicamente solo per le parti che vengono eseguite molto spesso; sulle altre il guadagno di prestazioni sarebbe poco significativo.
    Questo approccio funziona molto bene su processi di tipo server, che tipicamente eseguono ripetutamente lo stesso codice e girano per molto tempo; probabilmente su un dispositivo mobile (ma direi lato client in generale, data la ben nota "debolezza" di java lato desktop) è meno efficace nel complesso e google sta tentando una via alternativa, con la speranza di prendere due piccioni con una fava e liberarsi contemporaneamente anche delle grane legate alle (presunte) violazioni di brevetti che minano Dalvik.
  • - Scritto da: pentolino
    > "il codice Java viene interpretato ed eseguito al
    > volo tramite compilatore just-in-time
    > (JIT)"
    >

    è colpa di Apple! Discorso chiuso.
    non+autenticato
  • - Scritto da: pentolino
    > Questo approccio funziona molto bene su processi
    > di tipo server, che tipicamente eseguono
    > ripetutamente lo stesso codice e girano per molto
    > tempo; probabilmente su un dispositivo mobile (ma
    > direi lato client in generale, data la ben nota
    > "debolezza" di java lato desktop) è meno efficace
    > nel complesso e google sta tentando una via
    > alternativa, con la speranza di prendere due
    > piccioni con una fava e liberarsi
    > contemporaneamente anche delle grane legate alle
    > (presunte) violazioni di brevetti che minano
    > Dalvik.
    Incredibile hanno scoperto i compilatoriA bocca aperta
    non+autenticato
  • eh? ma se ne usano già ben 2 da anni? (compilare java -> bytecode e compilatore JIT bytecode -> codice nativo)
  • quello che notato, da alcuni grafici postati da vari utenti, è che le performance indotte da art non sono lineari rispetto a dalvik

    ad esempio, il quicksort su array di 2000-3000 elementi produce un 30-40% di performance in più

    lo stesso algoritmo su array di 10.000-20.000 elementi arriva fino al 100%

    chiaramente ci sono poche informazioni per arrivare a conclusioni, ma imho hanno implementato un sistema di ottimizzazione del codice ( a la llvm per capirci )

    già prima, con dalvik, il bytecode veniva compilato in fase d'installazione

    ora viene ottimizzato a runtime a seconda del tipo di carico di lavoro
    non+autenticato
  • non credo che questi microbenchmark siano rappresentativi delle situazioni di utilizzo reale, in quanto in quel caso entrano in gioco molte più variabili che in un quicksort.
    Come hai scritto anche tu, le informazioni sono poche, nei prossimi mesi ne sapremo di più e ci sarà sicuramente chi proverà a lanciarsi in qualche esperimento.
  • - Scritto da: pentolino
    > non credo che questi microbenchmark siano
    > rappresentativi delle situazioni di utilizzo
    > reale, in quanto in quel caso entrano in gioco
    > molte più variabili che in un
    > quicksort.
    > Come hai scritto anche tu, le informazioni sono
    > poche
    Già, più che supposizioni o prove molto "sintetiche" non si trova altro..
    non+autenticato