previsione per uscita versione stabile 13.0 64bit

[Blallo]

appunto...devi elaborare un tt di dati da indirizzare per un tot di ram alla volta no? se ne indirizzi il doppio per ogni operazione fai prima credo...
EDIT se così non è ditemi come è almeno imparo una cosa nuova

[Vito]

La ram occupata resta la stessa, solo che la cpu al posto d un N bit ne sposta 2N,
questo non ha effetto sulla quantità di RAM usata perchè se un programma occupa 100M
che io abbia 32bit o 64bit è lo stesso.La differenza sta nel fatto che il processore li elabora più velocemente e quindi
ecco perchè nelle applicazioni multimediali risalta questo effetto.
Il processore preleverà dalla memoria centrale (ma questa è molto approssimata come cosa perchè c'è la cache di mezzo)
un quantitativo maggiore di bit e quindi si avrà la sensazione di maggiore fluidità.

Poi ovviamente per la velocità di trasferimento c'è comunque il problema della differenza di velocità memoria/cpu ecc ecc...
Ma meglio non ingarbugliarsi in questi discorsi.

Esempio:

Un'istruzione occupa 64bit, se il sistema operativo è ottimizzato per i 64bit con un colpo di clock ed un solo accesso in memoria il processore porterà l'istruzione e la eseguirà.
Se non hai l'ottimizzazione per i 64 bit ma per i 32: il processore con due colpi di clock (e quindi ben due accessi in memoria) preleverà l'istruzione.
Ovviamente ho presupposto che il bus dati sia a 64bit.

[Mario Vanoni]

appunto...devi elaborare un tt di dati da indirizzare per un tot di ram alla volta no? se ne indirizzi il doppio per ogni operazione fai prima credo...
EDIT se così non è ditemi come è almeno imparo una cosa nuova

[OT]
Illusione,
se il programma non sa usare 2/4/8/16/32 CPU in contemporanea,
anche 4/8/16/32/64/128GB di RAM non servono.

Vedi
make -j NUMERO bzImage
quale esempio pratico, riproducibile!

Quali programmi odierni sono capaci di fare quanto fa make(1)?

[Blallo]

no vabbè quello è normale...io dicevo la stessa cosa di vito cioè che indirizzi più memoria per clock rispetto al 32 bit...mi sarò espresso male..
è normale che se un programma è fatto in modo da dividersi il carico su esempio 2 cpu è normale che andrà ancora più veloce e con meno sforzo di cpu

[Mario Vanoni]

no vabbè quello è normale...io dicevo la stessa cosa di vito cioè che indirizzi più memoria per clock rispetto al 32 bit...mi sarò espresso male..
è normale che se un programma è fatto in modo da dividersi il carico su esempio 2 cpu è normale che andrà ancora più veloce e con meno sforzo di cpu

Infatti, sto testando
pbzip2 (parallel bzip2) con gli stessi parametri del thread
viewtopic.php?f=2&t=28988
bzip2 ha impiegato 64 ore,
pbzip2 dopo un'ora il 3.6% compresso, occhio e croce 28 ore,
aspettiamo il risultato finale.

Secondo top usa 200% CPU e tutti i 4GB di memoria,
con kernel 2.6.30 statico.

[Blallo]

no vabbè quello è normale...io dicevo la stessa cosa di vito cioè che indirizzi più memoria per clock rispetto al 32 bit...mi sarò espresso male..
è normale che se un programma è fatto in modo da dividersi il carico su esempio 2 cpu è normale che andrà ancora più veloce e con meno sforzo di cpu

Infatti, sto testando
pbzip2 (parallel bzip2) con gli stessi parametri del thread
viewtopic.php?f=2&t=28988
bzip2 ha impiegato 64 ore,
pbzip2 dopo un'ora il 3.6% compresso, occhio e croce 28 ore,
aspettiamo il risultato finale.

Secondo top usa 200% CPU e tutti i 4GB di memoria,
con kernel 2.6.30 statico.

dimensione di ciò che comprimi? (forse questo? bzip2 -9 -f -v * time 64 hours, du -hs 651GB)

[Mario Vanoni]

dimensione di ciò che comprimi? (forse questo? bzip2 -9 -f -v * time 64 hours, du -hs 651GB)

Esatto, dopo 2.5 ore compresso il 9.2%, quindi veloce.

[Blallo]

decisamente....
quindi direi che se si è possibilitati ne vale proprio la pena il passaggio a 64

[Communico]

Si ma in quel caso il guadagno non è per i 32 bit, ma perchè usa due processori. è ovvio che ci metta circa la metà del tempo...

[Mario Vanoni]

Si ma in quel caso il guadagno non è per i 32 bit, ma perchè usa due processori. è ovvio che ci metta circa la metà del tempo...

Non solo, importante l'algoritmo del programmatore,
pbzip2 userebbe 4 CPU con una Core 2 quad.

man pbzip2
-p# Where # is the number of processors (default: autodetect)

pbzip2 -y
...
-p# : where # is the number of processors (default: autodetect [2])
...

bzip2 ha impiegato 64 ore,
pbzip2 dopo esattamente 4 ore ha compresso 3272 files di 22197,
quindi quasi il 15%, cioe` usera` circa 28 ore, meno della meta`!

[Communico]

Si ma in quel caso il guadagno non è per i 32 bit, ma perchè usa due processori. è ovvio che ci metta circa la metà del tempo...

Non solo, importante l'algoritmo del programmatore,
pbzip2 userebbe 4 CPU con una Core 2 quad.

man pbzip2
-p# Where # is the number of processors (default: autodetect)

pbzip2 -y
...
-p# : where # is the number of processors (default: autodetect [2])
...

bzip2 ha impiegato 64 ore,
pbzip2 dopo esattamente 4 ore ha compresso 3272 files di 22197,
quindi quasi il 15%, cioe` usera` circa 28 ore, meno della meta`!

Si si ovviamente anche quello, e volendo ci sarebbe anche da considerare che operazioni hai fatto con il pc mentre comprimevi.
Quello che volevo dire è che, come hai scritto, in questo caso il miglioramento è proprio da imputare alla struttura del programma, non ai 32/64 bit

[Bart]

Fare una previsione sull'uscita è impensabile. Questa volta PJV ha rivoluzionato parecchie cose. Secondo me, magari mi sbaglio, aspetta kde 4.3 e ciò vorrebbe dire avere slackware a fine agosto o settembre. C'è anche da dire che KDE 4 attualmente ha parecchie lacune, una su tutte k3b. Manca un vero software di masterizzazione e il porting mi sembra ancora lontano dalla stable.

[Vito]

Fare una previsione sull'uscita è impensabile. Questa volta PJV ha rivoluzionato parecchie cose. Secondo me, magari mi sbaglio, aspetta kde 4.3 e ciò vorrebbe dire avere slackware a fine agosto o settembre. C'è anche da dire che KDE 4 attualmente ha parecchie lacune, una su tutte k3b. Manca un vero software di masterizzazione e il porting mi sembra ancora lontano dalla stable.

Ma sì, aspettare non farà male...
Anche perchè io preferisco aspettare un po' di più per poi trovare una 13.0 stabile e con tutte le migliorie possibili

[Mario Vanoni]

13.0 ancora quest'anno
13.1 fine anno o inizio 2010
13.2 veramente usabile ???

Resto al 12.2 32-bit, e` stabile,
quindi aspetto il 13.2 64-bit ...
E comprero` le due versioni!

Ma prima non arrischio alcuna macchina.

Eccezione possibile:
che quelli della LKML decidano
di non supportare piu` gcc 4.2.4 per i nuovi kernel.

[navajo]

13.0 ancora quest'anno
13.1 fine anno o inizio 2010
13.2 veramente usabile ???

Resto al 12.2 32-bit, e` stabile,
quindi aspetto il 13.2 64-bit ...
E comprero` le due versioni!

Ma prima non arrischio alcuna macchina.

Eccezione possibile:
che quelli della LKML decidano
di non supportare piu` gcc 4.2.4 per i nuovi kernel.

Mario, credo che l' ultima parte non sarà realizzata entro i prossimi anni.
In primis perchè Linux non perderà, almeno per me, la dote della compatibilità con macchine datate, e poi perchè il salto definitivo ai 64 bit non sarà totale e definitivo fino a quando qualcuno non lo sarà definitivamente.
ps per provare un 64 bit che sia veramente stabile, e che va come un treno, prova debian lenny.
Ti assicuro che rimarrai piacevolmente sorpreso.