# / in ram vs prelink

## HoX

Qualcuno sa spiegarmi che differenza c'è tra questo e prelink? Mi riferisco soprattutto alla parte inerente alle librerie (step 3 del primo)... quale conviene e perché?[/url]

----------

## gutter

Penso che siano due cose totalmente differenti  :Smile: 

Nel primo caso carichi delle intere directory in ram nel secondo alcune librerie.

----------

## cloc3

 *Anema wrote:*   

> Qualcuno sa spiegarmi che differenza c'è tra questo e prelink?

 

sono cose diverse.

il prelink è relativo alla procedura di ricerca delle librerie in avvio di programma.

se l'eseguibile non è prelinkato, esegue in partenza un processo dinamico di ricerca dei collegamenti alle librerie.

se l'eseguibile viene prelinkato dopo la compilazione, la collocazione delle librerie viene inserito staticamente nel codice e la ricerca ha efficacia immediata (fino ad aggiornamento o spostamento della libreria stessa - tieni conto che gli utenti gentoo modificano spesso gli assetti del proprio sistema).

il mounting in ram è una modalità di collocare stabilmente una parte di codice dei programmi più utilizzati direttamente in ram, in modo che, all'avvio, sia risparmiata del tutto la fase di caricamento.

----------

## HoX

Uhm... ok... ma quale delle due mi conviene utilizzare?

----------

## Ic3M4n

il prelink da risultati meno ecclatanti rispetto alla ram, però puoi farlo su qualsiasi macchina, anche con uno sputo di ram.

l'altro necessita di avere una buona dose di ram e di essere un po' scafati in quanto il fare tutti quei passaggi implica un maggior apporto intellettuale dell'"oggetto" che sta tra monitor e sedia. Devi spostare librerie e file nel filesystem, non sempre l'aggiornamento è come dovrebbe automatico etc etc.

alla fine non si può avere un consiglio chiaro, dipende un po' da come ognuno la pensa. Io personalmente utilizzo il prelink, anch'esso può provocare acuni problemi, però finora sono stato fortunato. Alla fine la mia gentoo rulla di brutto lo stesso, specialmente se comparata con altri sistemi operativi magari proprietari   :Wink: 

----------

## Kernel78

 *cloc3 wrote:*   

> il mounting in ram è una modalità di collocare stabilmente una parte di codice dei programmi più utilizzati direttamente in ram, in modo che, all'avvio, sia risparmiata del tutto la fase di caricamento.

 

A voler essere estremamente pignoli non viene risparmiata la fase di caricamento ma viene ridotta di diverse unità di misura.

Al lancio di un programma vengono cercati nel filesystem le librerie necessarie e vengono caricate in ram, questo succede sia che il filesystem sia su un hd, sia che sia in ram sia che si trovi su un nastro magnetico.

Il fatto che il file della libreria risieda in ram non significa che venga saltata la parte del caricamento.

P.S. mi è venuto in mente adesso (e forse è una cavolata) ma si potrebbe tenere / in ram E usare il prelink in modo che la / in ram riduca i tempi di caricamento e il prelink diminuisca i tempi della ricerca delle librerie da caricare.

----------

## HoX

 *Kernel78 wrote:*   

> [mi è venuto in mente adesso (e forse è una cavolata) ma si potrebbe tenere / in ram E usare il prelink in modo che la / in ram riduca i tempi di caricamento e il prelink diminuisca i tempi della ricerca delle librerie da caricare.

 

cioè usarli entrambi in modo tale da aumentare ancora di più le performance?

----------

## Kernel78

 *Anema wrote:*   

>  *Kernel78 wrote:*   [mi è venuto in mente adesso (e forse è una cavolata) ma si potrebbe tenere / in ram E usare il prelink in modo che la / in ram riduca i tempi di caricamento e il prelink diminuisca i tempi della ricerca delle librerie da caricare. 
> 
> cioè usarli entrambi in modo tale da aumentare ancora di più le performance?

 

Si, teoricamente è fattibile ma non ho idea di quanto minimale possa essere il vantaggio ad usare prelink su una / in ram ...

----------

## xveilsidex

 *Kernel78 wrote:*   

>  *cloc3 wrote:*   il mounting in ram è una modalità di collocare stabilmente una parte di codice dei programmi più utilizzati direttamente in ram, in modo che, all'avvio, sia risparmiata del tutto la fase di caricamento. 
> 
> A voler essere estremamente pignoli non viene risparmiata la fase di caricamento ma viene ridotta di diverse unità di misura.
> 
> Al lancio di un programma vengono cercati nel filesystem le librerie necessarie e vengono caricate in ram, questo succede sia che il filesystem sia su un hd, sia che sia in ram sia che si trovi su un nastro magnetico.
> ...

 

intendi qualcosa del tipo preload? cioè caricare al boot in ram tutti quei programmi librerie ecc piu utilizzate in modo che al primo doppio click l'applicazione parti subito?

----------

## djinnZ

preload: non più usato, dire ad ld di caricare intere librerie in ram, libc non è più compatibile con questa opzione (era sulle vecchie RH che si usava) se non erro e devono essere previsti degli accorgimenmti particolari.

montare in ram: velocizzi di molto l'avvio ma riduci le risorse. Poi se hai 4GB di RAM e ti limiti a firefox+OOo, è una scheggia.

prelink: l'unico difetto è che aumenti la dimensione degli eseguibili, che alle volte non puoi fare l'undo (un grazie a drittz che da un lato mi ha suggerito l'alternativa dall'altro mi ha portato sfiga). Aumentando la dimensione degli eseguibili aumenti il tempo che il sistema richiede per passare dal disco alla ram, cosa che oggi è uno dei principali colli di bottiglia dell'intero sistema. 

--as-need: senza prelink ti porta una riduzione dei tempi d'avvio simile al solo prelink mentre con prelink non cambia la velocità in se stessa ma l'aumento di dimensioni degli esguibili è meno significativo. Poi ci sono i problemi di compatibilità e senza portage-bashrc è inutile che ci provi.

upx: comprimi i file e li decomprimi in ram, riduci di molto il tempo di caricamento dei bestioni (i soliti OOo, mozilla etc) ma non  hai alcuna differenza sulle prestazioni. UPX+prelink+--as-need è teoricamente (molto teoricamente, molto ricer) possibile a patto di comprimere gli eseguibili "prelinkati" e di fare una seria cernita di quello che può e non può essere compresso/prelinkato (ovvero molti pochi programmi reggono entrambe le cose) e ti basta un bel prelink -afmR per perdere senza speranza alcuna di recupero l'intero sistema.

Se cerchi prestazioni ottimizza per applicazione e usa il mount in ram (anche se una cosa che velocizza enormemente è usare la anche ram per pipe semafori e file temporanei ma questo complica di molto il partizionamento).

Se sei capace di capire quando come e perchè la compilazione si blocca per problemi di linking puoi anche pernsare al --as-need (glibc e gcc neanc he per sogno, avvisato) ed all'upx (anche qui attenzione a non comprimere ld e libc) e qui dovresti raggiungere il massimo (ci sto lavoricchiando a tempo perso e le prime prove sono incoraggianti).

In realtà l'unico programma che beneficerebbe veramente del prelink (oltre a kde) è OOo e forse mozilla, molti altri applicativi non considerano del tutto la differenza.

----------

## cloc3

 *xveilsidex wrote:*   

> 
> 
> intendi qualcosa del tipo preload?

 

non credo.

da quanto capisco, montare in ram significa utilizzare una parte della ram come disco virtuale.

all'avvio del programma vi sarà comunque uno spostamento di codice dal disco virtuale alla ram reale, ma immagino che ciò avvenga con un singolo ciclo ram per ogni buffer contiguo, cioè in tempo zero.

----------

