previsione per uscita versione stabile 13.0 64bit
Moderatore: Staff
Regole del forum
1) Citare sempre la versione di Slackware64 usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware64, se l'argomento è Slackware32 o generale usate rispettivamente il forum Slackware o Gnu/Linux in genere.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare sempre la versione di Slackware64 usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware64, se l'argomento è Slackware32 o generale usate rispettivamente il forum Slackware o Gnu/Linux in genere.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
- Blallo
- Packager
- Messaggi: 3302
- Iscritto il: ven 12 ott 2007, 11:37
- Nome Cognome: Savino Liguori
- Slackware: 14.2 / 12.2
- Kernel: 4.4.14-smp
- Desktop: DWM
- Località: Torino / Torremaggiore (FG)
- Contatta:
Re: previsione per uscita versione stabile 13.0 64bit
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
EDIT se così non è ditemi come è almeno imparo una cosa nuova
Github: https://github.com/8lall0
- Vito
- Staff
- Messaggi: 4182
- Iscritto il: mar 5 dic 2006, 17:28
- Nome Cognome: Vito
- Desktop: MacOS
- Località: Monaco (DE)
- Contatta:
Re: previsione per uscita versione stabile 13.0 64bit
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.
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.
"Stat rosa pristina nomina, nomina nuda tenemus." [ Umberto Eco - Il nome della rosa]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
-
- Iper Master
- Messaggi: 3174
- Iscritto il: lun 3 set 2007, 21:20
- Nome Cognome: Mario Vanoni
- Slackware: 12.2
- Kernel: 3.0.4 statico
- Desktop: fluxbox/seamonkey
- Località: Cuasso al Monte (VA)
Re: previsione per uscita versione stabile 13.0 64bit
[OT]jimmy_page_89 ha scritto: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
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
- Packager
- Messaggi: 3302
- Iscritto il: ven 12 ott 2007, 11:37
- Nome Cognome: Savino Liguori
- Slackware: 14.2 / 12.2
- Kernel: 4.4.14-smp
- Desktop: DWM
- Località: Torino / Torremaggiore (FG)
- Contatta:
Re: previsione per uscita versione stabile 13.0 64bit
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
è 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
Github: https://github.com/8lall0
-
- Iper Master
- Messaggi: 3174
- Iscritto il: lun 3 set 2007, 21:20
- Nome Cognome: Mario Vanoni
- Slackware: 12.2
- Kernel: 3.0.4 statico
- Desktop: fluxbox/seamonkey
- Località: Cuasso al Monte (VA)
Re: previsione per uscita versione stabile 13.0 64bit
Infatti, sto testandojimmy_page_89 ha scritto: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
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
- Packager
- Messaggi: 3302
- Iscritto il: ven 12 ott 2007, 11:37
- Nome Cognome: Savino Liguori
- Slackware: 14.2 / 12.2
- Kernel: 4.4.14-smp
- Desktop: DWM
- Località: Torino / Torremaggiore (FG)
- Contatta:
Re: previsione per uscita versione stabile 13.0 64bit
dimensione di ciò che comprimi? (forse questo? bzip2 -9 -f -v * time 64 hours, du -hs 651GB)Mario Vanoni ha scritto:Infatti, sto testandojimmy_page_89 ha scritto: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
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.
Github: https://github.com/8lall0
-
- Iper Master
- Messaggi: 3174
- Iscritto il: lun 3 set 2007, 21:20
- Nome Cognome: Mario Vanoni
- Slackware: 12.2
- Kernel: 3.0.4 statico
- Desktop: fluxbox/seamonkey
- Località: Cuasso al Monte (VA)
Re: previsione per uscita versione stabile 13.0 64bit
Esatto, dopo 2.5 ore compresso il 9.2%, quindi veloce.jimmy_page_89 ha scritto: dimensione di ciò che comprimi? (forse questo? bzip2 -9 -f -v * time 64 hours, du -hs 651GB)
- Blallo
- Packager
- Messaggi: 3302
- Iscritto il: ven 12 ott 2007, 11:37
- Nome Cognome: Savino Liguori
- Slackware: 14.2 / 12.2
- Kernel: 4.4.14-smp
- Desktop: DWM
- Località: Torino / Torremaggiore (FG)
- Contatta:
Re: previsione per uscita versione stabile 13.0 64bit
decisamente....
quindi direi che se si è possibilitati ne vale proprio la pena il passaggio a 64
quindi direi che se si è possibilitati ne vale proprio la pena il passaggio a 64
Github: https://github.com/8lall0
-
- Packager
- Messaggi: 200
- Iscritto il: sab 3 mag 2008, 19:59
- Nome Cognome: Stefano Cereda
- Slackware: current
- Kernel: 2.6.29.1
- Desktop: kde 4.2.2
- Località: Seriate (BG)
Re: previsione per uscita versione stabile 13.0 64bit
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...
-
- Iper Master
- Messaggi: 3174
- Iscritto il: lun 3 set 2007, 21:20
- Nome Cognome: Mario Vanoni
- Slackware: 12.2
- Kernel: 3.0.4 statico
- Desktop: fluxbox/seamonkey
- Località: Cuasso al Monte (VA)
Re: previsione per uscita versione stabile 13.0 64bit
Non solo, importante l'algoritmo del programmatore,Communico ha scritto: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...
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`!
-
- Packager
- Messaggi: 200
- Iscritto il: sab 3 mag 2008, 19:59
- Nome Cognome: Stefano Cereda
- Slackware: current
- Kernel: 2.6.29.1
- Desktop: kde 4.2.2
- Località: Seriate (BG)
Re: previsione per uscita versione stabile 13.0 64bit
Si si ovviamente anche quello, e volendo ci sarebbe anche da considerare che operazioni hai fatto con il pc mentre comprimevi.Mario Vanoni ha scritto:Non solo, importante l'algoritmo del programmatore,Communico ha scritto: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...
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`!
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
Re: previsione per uscita versione stabile 13.0 64bit
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
- Staff
- Messaggi: 4182
- Iscritto il: mar 5 dic 2006, 17:28
- Nome Cognome: Vito
- Desktop: MacOS
- Località: Monaco (DE)
- Contatta:
Re: previsione per uscita versione stabile 13.0 64bit
Ma sì, aspettare non farà male...Bart ha scritto: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.
Anche perchè io preferisco aspettare un po' di più per poi trovare una 13.0 stabile e con tutte le migliorie possibili
"Stat rosa pristina nomina, nomina nuda tenemus." [ Umberto Eco - Il nome della rosa]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
-
- Iper Master
- Messaggi: 3174
- Iscritto il: lun 3 set 2007, 21:20
- Nome Cognome: Mario Vanoni
- Slackware: 12.2
- Kernel: 3.0.4 statico
- Desktop: fluxbox/seamonkey
- Località: Cuasso al Monte (VA)
Re: previsione per uscita versione stabile 13.0 64bit
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.
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
- Staff
- Messaggi: 3884
- Iscritto il: gio 8 gen 2004, 0:00
- Nome Cognome: Massimiliano
- Slackware: 13.37 (x86_64)
- Kernel: 2.6.37.6
- Desktop: KDE 4.7.0 (Alien)
- Località: Roma
Re: previsione per uscita versione stabile 13.0 64bit
Mario, credo che l' ultima parte non sarà realizzata entro i prossimi anni.Mario Vanoni ha scritto: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.
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.