[GUIDA] Setup ambiente di sviluppo Rom su Linux Ubuntu

[loxdegio]

Direi sul nuovo AMD 16 core o su uno xeon... Comunque per ora per nessun processore target desktop ha senso generare quel numero di jobs...
Come ho detto sopra infatti in quel modo si rischia solo di intasare il Process Control Block con una coda infinita di processi da eseguire e peggiorare così le prestazioni della macchina...

Inviato dal mio GT-S7500 usando Androidiani App

[KlaasMad]

Ho visto solo ora questa discussione... Intanto faccio I complimenti a Dionysus per la voglia e la precisione... Comunque volevo consigliare, per il sync delle sorgenti, di usare - j<numero thread supportati dal vostro processore>+1 -c

Vi spiego meglio il perché di ciò: in pratica ogni job corrisponde a un processo: sì moltiplica il numero di processi in esecuzione per aumentare il parallelismo e quindi scaricare più dati contemporaneamente. Se il nostro processore non supporta più di 4 thread è inutile inizializzare 32 job che al posto di velocizzare le cose rallentano la macchina e basta.
L'altra opzione serve per fare il fetch solo del branch che ci interessa... Esempio: vogliamo scaricare la cm-10.2? In condizioni normali repo controllerebbe le modifiche e lo stato anche di tutti gli altri branch mentre con -c lo forziamo a controllare solo quello che effettivamente stiamo scaricando

Considerate che con un - j5 (processore 2 core multi thread) -c io ci metto circa 3 ore a fare il sync delle sorgenti pulite

Inviato dal mio GT-S7500 usando Androidiani App

Se non sbaglio la mia CPU dovrebbe essere simile alla tua.... ho un core i5 e sul sito della Intel dice che ha 2 core fisici e gestisce 4 thread quindi un -j5 dovrebbe essere adeguato giusto?

Qui si apre un mondo di discussione che forse sarebbe meglio lasciare chiuso. Per quanto riguarda il download, anzi, il sync tramite repo, è possibile settare anche -j64 visto che i processi di controllo con i sorgenti in locale e quelli in remoto sono semplici, ma (eh sì, ci sono i ma):
- google limita l'accesso ai sorgenti (tipo tutti i project chiamati external e bionic) a macchine che syncano con < -j4, per cui spesso compare l'errore di sync o addirittura interrompe il sync stesso, chiedendoti nome utente e psw.
- sebbene il sync si possa mandare anche a 128 o anche più, si ha anche un altro bottleneck che è la banda italiana in download ed in upload (perché oltre a scaricare, mandi anche dei piccoli pacchetti per il controllo di quel che hai e di quel che ha il remoto e quindi conta anche l'upload, che in media, in Italia, sta sotto il megabit.

Discorso diverso invece per make qui è valido il discorso che fai, ma:
- ci sono diverse scuole di pensiero: c'è chi dice di buildare ad un numero = core fisici + thread
- altra scuola di pensiero è make a -jX dove X sta per core fisici + thread +1
- altra scuola fa equivalere -jX a 2(core fisici + thread)

Io ho voluto fare un po' di test per capire quale sia l'ottimo ed ho notato su un AMD APU A6-3400M quad core con 4 threads, con su Mint 16 XFCE, buildando la Slim ho provato make -jX bacon (quindi anche con lo zipping, alignment e l'ottimizzazione degli apk):
- make -j1 bacon ci impiega circa 5 ore
- make -j2 bacon ci impiega 4 ore
- make -j4 bacon ci impiega circa 2 ore
- make -j6 bacon ci impiega sempre 2 ore e comincia a laggare il file manager
- make -j16 bacon ci impiega poco meno di 2 ore ma mi lagga anche il mouse, pc inutilizzabile per il lasso di tempo del build.

Traete voi le conclusioni, e anzi, mi piacerebbe confrontarmi con la velocità di build che ottenete con le vostre macchine.

[loxdegio]

Guarda la questione è che io con un

 repo sync -j5 -c

ho ottenuto un tempo complessivo di DL delle source di 3 ore 3 ore e mezza, contro il giorno e mezzo - 2 a cui arrivavo con il

 repo sync -j40

che veniva suggerito dalla prima guida che ho seguito: io vi invito a provare, se mi sbaglio o se è stato un caso fortuito fatemelo sapere. Contate che ho un Intel core duo 2 dual core ( techn. a 45nm ) e una linea a 7Mb/s Alice (dettagli utili per chi volesse fare una contro prova) e con questo metodo ho scaricato le sources della Replicant 4.2 della CM10.2 e della 11.0

Inoltre riguardo la questione dei -jX, ti passo volentieri la storia delle scuole di pensiero. Ma ieri ho dato un esame universitario per il quale mi sono dovuto studiare fork() e fondamenti di scheduling dei processi, ci ho sclerato sopra per un semestre se non ho davvero capito un tubo, come mi sembra dalla discussione, merito davvero di non aver passato questo appello.

Comunque il succo della storia è che al di là del process scheduler (che potrebbe essere un CFS piuttosto che un BFS o quel che vi pare), il processore può macinare ( realmente in parallelo ) solamente un numero di processi quanti sono i thread che effettivamente supporta ( nel caso migliore di pipeline non interrotta da un qualsiasi evento ovviamente ), quindi non vedo il senso di allocarne più di quelli che effettivamente sono supportati dal parallelismo del processore (se vogliamo essere sinceri già mi sembra eccessivo per me allocarne 5, però ho notato che si quadagna quel mezzo secondo ogni n job processati quindi a quanto pare male non fa), e siccome anche repo mi pare che per introdurre il famoso parallelismo faccia ricorso alla system call fork() ( come al solito accetto correzioni in caso di errore ) quindi il discorso rimane lo stesso che per make.

Opinione personale, condivisibile o no in ogni caso, come ogni opinione personale che si rispetti

Poi c'è la questione ovviamente del processore, tecnologia, clock, ottimizzazione interna che possono influire sui tempi di processamento del tutto e il mio non è proprio tra gli ultimi usciti ( anche se devo dire che per essere un core duo da portatile si comporta veramente benissimo ). Lascio ora aperta la parola a chi vuole replicare dopo mille modifiche

[KlaasMad]

Guarda la questione è che io con un

 repo sync -j5 -c

ho ottenuto un tempo complessivo di DL delle source di 3 ore 3 ore e mezza, contro il giorno e mezzo - 2 a cui arrivavo con il

 repo sync -j40

che veniva suggerito dalla prima guida che ho seguito: io vi invito a provare, se mi sbaglio o se è stato un caso fortuito fatemelo sapere. Contate che ho un Intel core duo 2 dual core ( techn. a 45nm ) e una linea a 7Mb/s Alice (dettagli utili per chi volesse fare una contro prova) e con questo metodo ho scaricato le sources della Replicant 4.2 della CM10.2 e della 11.0

Inoltre riguardo la questione dei -jX, ti passo volentieri la storia delle scuole di pensiero. Ma ieri ho dato un esame universitario per il quale mi sono dovuto studiare fork() e fondamenti di scheduling dei processi, ci ho sclerato sopra per un semestre se non ho davvero capito un tubo, come mi sembra dalla discussione, merito davvero di non aver passato questo appello.

Comunque il succo della storia è che al di là del process scheduler (che potrebbe essere un CFS piuttosto che un BFS o quel che vi pare), il processore può macinare ( realmente in parallelo ) solamente un numero di processi quanti sono i thread che effettivamente supporta ( nel caso migliore di pipeline non interrotta da un qualsiasi evento ovviamente ), quindi non vedo il senso di allocarne più di quelli che effettivamente sono supportati dal parallelismo del processore (se vogliamo essere sinceri già mi sembra eccessivo per me allocarne 5, però ho notato che si quadagna quel mezzo secondo ogni n job processati quindi a quanto pare male non fa), e siccome anche repo mi pare che per introdurre il famoso parallelismo faccia ricorso alla system call fork() ( come al solito accetto correzioni in caso di errore ) quindi il discorso rimane lo stesso che per make.

Proverò l'opzione -c, anzi guarda, metto già da ora in download i sorgenti della omni che era da ieri che ci pensavo di fare un porting per ariesve e ti dico che risultati ottengo col download. Per ulteriore metodo di comparazione, lo sto facendo mentre sto buildando la carbon per SII con toolchain sabermod a -j4, vediamo se influisce particolarmente (e lo faccio senza symlinks ad altri sorgenti ).

Poi, aggiungo, che avevo letto in una guida da qualche parte che solitamente il kernel specifico android (1gb di sorgenti per meno di una decina di mb), si può buildare anche a -j32 vista l'esigua dimensione dello stesso. Questo lo riporto solo per la cronaca, mai provato qualcosa del genere.

EDIT: eccallà

[loxdegio]

Perfetto io tra un salto in mente e l'altro ho modificato ulteriormente il mio post sopra, quindi credo che ora differisca un po' dal tuo quote

[KlaasMad]

Perfetto io tra un salto in mente e l'altro ho modificato ulteriormente il mio post sopra, quindi credo che ora differisca un po' dal tuo quote

Purtroppo tutto quello che so sui sistemi operativi e sull'hw la so per passione e non ed studio accademico, per cui la mia conoscenza è limitata sto rimediando con dei corsi al MIT, ma fino ad allora, nada, non so controbattere

[loxdegio]

Figurati... Io ho recuperato solo quest'anno... Altrimenti saremmo stati entrambi allo stesso livello

[LordJackJack]

Secondo voi posso installare ubuntu per compilare nella virtualbox? Oppure spreco troppe risorse? (pc di partenza con 1TV di HDD, 8GB di ram, processore i7, Win8 non rimovibile. È l'unico a 64bit che ho in casa...)

[loxdegio]

Secondo voi posso installare ubuntu per compilare nella virtualbox? Oppure spreco troppe risorse? (pc di partenza con 1TV di HDD, 8GB di ram, processore i7, Win8 non rimovibile. È l'unico a 64bit che ho in casa...)

Guarda... Non è questione di sprecare le risorse... È questione che non sfrutti a pieno la macchina (=ci metti più tempo) Secondo me è sempre meglio informarsi un attimo, perdere un po' di tempo e riservarsi una partizione per installare nativo... Opinione personale Comunque

Inviato dal mio GT-S7500 usando Androidiani App

[LordJackJack]

Lo supponevo... Avevo installato varie versioni precedenti a 32 bit su pc con Windows XP, in partizioni separate e in virtualbox e avevo notato la differenza, ma volevo avere il parere di qualcuno più esperto...

Invece, ci sono le guide per imparare a compilare a cui si accenna alla fine di questa? Potreste darmi il link, per favore? (se possibile in italiano...)