Repository 32bit  Forum
Repository 64bit  Wiki

Novita da Pat su Twitter

Area di discussione libera.

Moderatore: Staff

Regole del forum
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
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.

Novita da Pat su Twitter

Messaggioda Ymildir » mar dic 22, 2009 23:33

Ho notato solo ora il messagio di Pat su Twitter dove dice:

Considering compiling future 32-bit x86 Slackware packages for i686 and finally leaving i486 and i586 support behind...

Ora, a me come utente Desktop non cambia nulla, ma cosa comporterebbe?

conraid ha scritto:Tra l'altro in twitter Pat chiede anche quale opzioni del kernel abilitare, mi sembra una cosa più interessante questa.
Contagiato dal web2.0 si sta aprendo di più :-)
Ultima modifica di Ymildir il mer dic 23, 2009 11:28, modificato 2 volte in totale.
Ymildir
Linux 1.0
Linux 1.0
 
Messaggi: 3
Iscritto il: sab ott 31, 2009 19:25
Slackware: 13
Kernel: 2.6.29.6
Desktop: xfce

Re: Cambio di architettura per Slackware

Messaggioda slucky » mar dic 22, 2009 23:55

curiosità interessante :) ,se dai un'occhiata, qui se ne parla:

http://www.linuxquestions.org/questions ... 86-198431/
"...and what exactly is a dream....and what exactly is a joke."

"Jugband Blues" ( Syd Barrett )
Avatar utente
slucky
Iper Master
Iper Master
 
Messaggi: 2378
Iscritto il: mar mag 01, 2007 14:30
Slackware: 14.1
Kernel: default
Desktop: xfce

Re: Cambio di architettura per Slackware

Messaggioda Ymildir » mer dic 23, 2009 0:07

guardando il link che hai messo, deduco che non ci sara nessuno differenza. In quanto l'architettura i486 orami è osoleta, o sbaglio?
Ymildir
Linux 1.0
Linux 1.0
 
Messaggi: 3
Iscritto il: sab ott 31, 2009 19:25
Slackware: 13
Kernel: 2.6.29.6
Desktop: xfce

Re: Cambio di architettura per Slackware

Messaggioda submax82 » mer dic 23, 2009 0:21

forse la decisione è ovvia ma ci sono processori come K6-II e K6-III ma anche dei vecchi pentium che in alcune applicazioni possono ancora essere sfruttati...

oppure anche se il tutto sarà ottimizzato per i686 si potrà far girare slack anche su proc i586 ... scusate ma mi è venuto sto dubbio... :-k
Avatar utente
submax82
Staff
Staff
 
Messaggi: 3202
Iscritto il: mar ago 30, 2005 23:00
Desktop: xfce
Distribuzione: SalixOS

Re: Cambio di architettura per Slackware

Messaggioda DanBadJar » mer dic 23, 2009 9:25

In teoria coi pacchetti compilati su i686 si dovrebbe avere un sistema un po' più reattivo. Vedasi Archlinux.
Avatar utente
DanBadJar
Linux 3.x
Linux 3.x
 
Messaggi: 1027
Iscritto il: ven lug 28, 2006 18:27
Località: Bologna
Nome Cognome: Daniele Malavasi
Slackware: 13.1
Kernel: 2.6.34.1
Desktop: XFCE - Gnome

Re: Cambio di architettura per Slackware

Messaggioda conraid » mer dic 23, 2009 10:47

Fine di Slackware come sistema per vecchi PC (distribuzioni storiche come redhat e debian se non sbaglio hanno ancora la compilazione i386 per esempio), tutto li.
Questa, ed altre decisioni prese, fanno pensare ad una scelta del team di fare di Slackware una distribuzione su cui costruire il proprio ambiente di lavoro, soprattutto come workstation o come desktop per chi vuole "imparare"

Tanto parliamoci chiaro, come server e client in ambiti enterprise non è adatta (mancanza di alcune cose troppo usate, vedesi pam, ldap-server, etc...)

E poi ormai non so quanto un 486 sia diffuso, anche in ambiti embedded. Magari alcuni pentium resistono, ma come sistema di firewalling o simile. Ed anche qui si trovano distribuzioni più indicate e specializzate

Tra l'altro in twitter Pat chiede anche quale opzioni del kernel abilitare, mi sembra una cosa più interessante questa.
Contagiato dal web2.0 si sta aprendo di più :-)
Avatar utente
conraid
Staff
Staff
 
Messaggi: 12016
Iscritto il: mer lug 13, 2005 23:00
Località: Livorno
Nome Cognome: Corrado Franco
Slackware: current

Re: Novita da Pat su Twitter

Messaggioda Ymildir » mer dic 23, 2009 11:23

conraid ho cambiato il titolo del topic cosi da poter continuare la discussione qua senza bisogno di aprire un nuovo 3d. Tornando al fatto che Pat chiede quale opzioni abilitare nel kernel, ho dato un occhiata veloce al .config del kernel huge-smp e ho visto che c'e praticamente di tutto e di più abilitato, cos'altro puo abilitare?
Ymildir
Linux 1.0
Linux 1.0
 
Messaggi: 3
Iscritto il: sab ott 31, 2009 19:25
Slackware: 13
Kernel: 2.6.29.6
Desktop: xfce

Re: Novita da Pat su Twitter

Messaggioda conraid » mer dic 23, 2009 11:29

Ymildir ha scritto:conraid ho cambiato il titolo del topic cosi da poter continuare la discussione qua senza bisogno di aprire un nuovo 3d. Tornando al fatto che Pat chiede quale opzioni abilitare nel kernel, ho dato un occhiata veloce al .config del kernel huge-smp e ho visto che c'e praticamente di tutto e di più abilitato, cos'altro puo abilitare?


Non guardare huge, ma il generic. Se leggi le note di Slackware dice per esempio di non segnalare bug se non provati con il kernel generic (huge è solo per le emergenze)
Però il kernel è cambiato molto.
Comprimerlo in quale formato? Quale scheduler scegliere? Se passa a 686 quale opzioni abilitare? Togliere il supporto a x86 generic? Penso si riferisca a queste cose. Non certo a quali driver includere.
Avatar utente
conraid
Staff
Staff
 
Messaggi: 12016
Iscritto il: mer lug 13, 2005 23:00
Località: Livorno
Nome Cognome: Corrado Franco
Slackware: current

Re: Novita da Pat su Twitter

Messaggioda Calzo » dom gen 03, 2010 11:57

[EDIT: scusate se torno un attimo all'argomento originale]
Sarebbe veramente ora che si passasse a i686. Anche perchè la Slack è più ottimizzata per il 686 di quanto si creda (a causa di un -mtune=i686 nelle librerie), ma meno di quanto dovrebbe ;)
Mi spiego meglio: recentemente mi sono documentato un po' sulle modalità di accesso al kernel. Arch linux usa le istruzioni SYSENTER/SYSEXIT per l'accesso al kernel, mentre la Slackware usa INT 80h. Su sistemi come il P3, P4 e superiori, la INT 80h è molto più lenta su PC performanti! Inoltre la SYSENTER è supportata dal kernel 2.5.53 se non sbaglio peroprio per sopperire a questi problemi prestaizionali.

Tutto questo però non è legato all'intero sistema, ma solo alle glibc. Ci sono programmi che compilati per i486 o per i7 non subiscono il ben che minimo guadagno.
La ricompilazione delle glibc invece mi ha permesso di triplicare la velocità delle chiamate di sistema. Se volete provare, uno dei benchmark che avevo fatto è questo:
Codice: Seleziona tutto
#include <stdio.h>
#include <time.h>
#include <unistd.h>

#define K 1000000
#define TIMEVARPTR   (&t)

#ifdef STATIC_VDSO
#   define SYSTEMCALL "call 0xffffe414;"
#else
#   define SYSTEMCALL "call *%gs:0x10;"
#endif

#define sys_time() __asm__( \
   "leal t, %ebx;"   \
   "mov  $0xD, %eax;"   \
   SYSTEMCALL   \
   "mov  %eax,t;"   \
   );

time_t t=0;
unsigned long i;

int main(int c, char **v)
{
   if(c>1)
     { 
   puts("Time()");
   while(i++ < K) {
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);   
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
      t = time(TIMEVARPTR);
   }
     } else
     {
   puts("__asm__ ");
   while(i++ < K)
     {
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
        sys_time();
     }
     }   
//   printf("Time is %d\n", t);
   return 0;
}

Questo programma effettua 20 milioni di chiamate time(). Le uniche note rilevanti sulla compilazione riguardano il VDSO. Controllate il valore di /proc/sys/vm/vdso_enabled:
    > Se ò 0 o 1, il VDSO è disabilitato e NON compilate con -DSTATIC_VDSO
    > Se è 2, allora si può compilare con -DSTATIC_VDSO
    > Se è 0 o 1 e compilate con -DSTATIC_VDSO il codice __asm__ dara un SEGFAULT
    > "%gs:0x10" e "0xffffe414" possono variare con il kernel o la distro. Su slack 10.2 per eempio l'indirizzo statico è 0xffffe400. Per capirlo bisogna disassemblare il dso del processo o lggere /proc/<pid>/map per capire quali sono gli indirizzi della libreria virtuale linux-gate.so
Il test è stato fatto su un P4 2.4GHz e su un Celeron 2.8GHz entrambi con Slackware 13, kernel 2.6.32.2 ottimizzato, glibc 2.9 di default (ossia che implementano l'INT 80h per saltare nel kernel).
Il test è stato fatto in init 3 da utente senza X caricato, lanciando:
Codice: Seleziona tutto
time misura_time 1 ; time misura_time
lanciato con un qualsiasi parametro utilizzerà le librerie glibc, altrimenti userà le istruzioni SYSENTER/SYSEXIT.

conraid ha scritto:Fine di Slackware come sistema per vecchi PC (distribuzioni storiche come redhat e debian se non sbaglio hanno ancora la compilazione i386 per esempio), tutto li.

Su questo non ne sarei molto convinto. Inoltre la Slack non è più da qualche versione per i386, ma credo che non dia problemi a molti che magari la installano.
Tornando sull'istruzione SYSENTER che non è supportata nei Pentium2, si può disabilitare semplicemente caricando il kernel con il parametro nosep. Così facendo l'indirizzo virtuale __kernel_vsyscall (che viene deciso dal kenrnel in fase di caricamento del processo) puterà appunto appunto ad un'area in cui verrà effettuato l'INT80h.
In altre parole call %gs:0x10 chiamerà poi l'INT 80h (e successivamente ci sarà un ret) il che implica una leggera perita prestazionale nei sistemi che avranno le librerie i686, ma di fatto non supportano queste operazioni.

Io slackbuild modificato per avere le glibc con queste features l'ho postato qui ...così faccio anche un po' di spam :D ;)

bye
Ultima modifica di Calzo il dom gen 10, 2010 11:12, modificato 2 volte in totale.
Avatar utente
Calzo
Linux 2.0
Linux 2.0
 
Messaggi: 112
Iscritto il: sab ott 06, 2007 21:21
Località: MN
Slackware: 10.2 | 13
Desktop: Fluxbox | KDE

Re: Novita da Pat su Twitter

Messaggioda slucky » dom gen 03, 2010 12:49

conraid ha scritto:
Fine di Slackware come sistema per vecchi PC ....


speriamo di no, ma il mio giudizio è di parte, utilizzando vari ed eventuali vecchi macinini...... :)

calzo ha scritto:
Inoltre la Slack non è più da qualche versione per i386, ma credo che non dia problemi a molti che magari la installano.


confermo! finora tutto sommato (13 compresa) funziona....certo, non sarà una scheggia, però è abbastanza usabile! :)
"...and what exactly is a dream....and what exactly is a joke."

"Jugband Blues" ( Syd Barrett )
Avatar utente
slucky
Iper Master
Iper Master
 
Messaggi: 2378
Iscritto il: mar mag 01, 2007 14:30
Slackware: 14.1
Kernel: default
Desktop: xfce

Re: Novita da Pat su Twitter

Messaggioda Mario Vanoni » dom gen 03, 2010 13:55

@Calzo
Intel Core 2 Dual 1.866GHz L2 cache 4096kB e 4 GB di RAM
vedasi il mio profilo per il resto

less /proc/sys/vm/vdso_enabled
1

time misura_time 1
0m6.442s
time misura_time
0m2.981s

ricompilato con -O2 -s -static non cambia niente

Curiosita`, che valori hai raggiunto?
Mario Vanoni
Iper Master
Iper Master
 
Messaggi: 3174
Iscritto il: lun set 03, 2007 20:20
Località: Cuasso al Monte (VA)
Nome Cognome: Mario Vanoni
Slackware: 12.2
Kernel: 3.0.4 statico
Desktop: fluxbox/seamonkey

Re: Novita da Pat su Twitter

Messaggioda Calzo » dom gen 03, 2010 16:25

Mario Vanoni ha scritto:ricompilato con -O2 -s -static non cambia niente

Si bhè il codice è molto stringato quindi di ottimizzazioni non dovrebbe farne molte (non funziona neanche l'unrol-loop). Io non ho messo ottimizzazioni perchè non volevo rischiare che mi tagliasse via il codice assembly... che non ho messo neppure come volatile #-o

Mario Vanoni ha scritto:Curiosita`, che valori hai raggiunto?

Premesso che ora ho le librerie aggiornate e quindi non posso postare i valori esatti, la prova inizialmente mi dava 9,5s con le librerie originali (che usano la "INT 80h") e 3,2-3,3 quelle che usano la SYSENTER.Ad ogni modo anche ora non variano di molto; il test ora io lo devo fare così:

compilo con gcc -satatic misura_time.c -o misura_time e lo eseguo come ho detto prima.

- Con VDSO di default (/proc/sys/vm/vdso_enabled=1, ma anche 2) ho:
$ time misura_time 1 ; time misura_time
Time()
real 0m3,455s
__asm__
real 0m3.322s

- Con VDSO=0 (# echo 0 > /proc/sys/vm/vdso_enabled) che equivale a usare ancora INT 80h ho:
$ time misura_time 1 ; time misura_time
Time()
real 0m9,525s
__asm__
real 0m9,509s

Quindi confermo: ho grosso modo triplicato le prestazioni... chiaramente le prestazioni delle chiamate di sistema e basta

bye

PS: questi valori sono relativi al P4 2.4GHz, 512k cache
Avatar utente
Calzo
Linux 2.0
Linux 2.0
 
Messaggi: 112
Iscritto il: sab ott 06, 2007 21:21
Località: MN
Slackware: 10.2 | 13
Desktop: Fluxbox | KDE

Re: Novita da Pat su Twitter

Messaggioda Mario Vanoni » dom gen 03, 2010 17:10

Calzo ha scritto:
Mario Vanoni ha scritto:ricompilato con -O2 -s -static non cambia niente

Si bhè il codice è molto stringato quindi di ottimizzazioni non dovrebbe farne molte (non funziona neanche l'unrol-loop). Io non ho messo ottimizzazioni perchè non volevo rischiare che mi tagliasse via il codice assembly... che non ho messo neppure come volatile #-o

Mario Vanoni ha scritto:Curiosita`, che valori hai raggiunto?

Premesso che ora ho le librerie aggiornate e quindi non posso postare i valori esatti, la prova inizialmente mi dava 9,5s con le librerie originali (che usano la "INT 80h") e 3,2-3,3 quelle che usano la SYSENTER.Ad ogni modo anche ora non variano di molto; il test ora io lo devo fare così:

compilo con gcc -satatic misura_time.c -o misura_time e lo eseguo come ho detto prima.

- Con VDSO di default (/proc/sys/vm/vdso_enabled=1, ma anche 2) ho:
$ time misura_time 1 ; time misura_time
Time()
real 0m3,455s
__asm__
real 0m3.322s

- Con VDSO=0 (# echo 0 > /proc/sys/vm/vdso_enabled) che equivale a usare ancora INT 80h ho:
$ time misura_time 1 ; time misura_time
Time()
real 0m9,525s
__asm__
real 0m9,509s

Quindi confermo: ho grosso modo triplicato le prestazioni... chiaramente le prestazioni delle chiamate di sistema e basta

bye

PS: questi valori sono relativi al P4 2.4GHz, 512k cache

Molto interessante,
i tuoi due tempi sono simili tra di loro, Time() e __asm__,
nei miei Time() consuma piu` del doppio di __asm__,
quindi e` plausibile che', piu` L2 cache hai, migliore la prestazione,
la frequenza del processore va in secondo piano,
2.4GHz vs 1.866GHz, e la RAM e` di secondaria importanza!
Mario Vanoni
Iper Master
Iper Master
 
Messaggi: 3174
Iscritto il: lun set 03, 2007 20:20
Località: Cuasso al Monte (VA)
Nome Cognome: Mario Vanoni
Slackware: 12.2
Kernel: 3.0.4 statico
Desktop: fluxbox/seamonkey

Re: Novita da Pat su Twitter

Messaggioda Calzo » lun gen 04, 2010 10:07

Mario Vanoni ha scritto:Molto interessante,
i tuoi due tempi sono simili tra di loro, Time() e __asm__,
nei miei Time() consuma piu` del doppio di __asm__,
NONONONO! calma. Forse nonn mi sono spiegato. Io ho ricompilato le librerie ed ora uso la Sysenter al posto dell'INT 80h. Quindi per vedere qual è il miglioramento tra le librerie NON ottimizzate e quelle ottimizzate (che uso ora) devo settare echo 0 > /proc/sys/vm/vdso_enabled.
Quindi il time() che dà 9.5s è la mia condizione precedente, mentre l'__asm__ che da i 3.3s è quello che ottengo con le librerie ottimizzate. E' chiaro quindi che se ho le librerie ottimizzate e /proc/sys/vm/vdso_enabled=1 allora la funzione time() è praticamente uguale a quella __asm__ che o scritto io.
Quindi ripeto: io con le glibc-2.9 di default impiego 9.5s (in condizioni ottimali) per eseguire 20 milioni di Time.

Mario Vanoni ha scritto:quindi e` plausibile che, piu` L2 cache hai, migliore la prestazione,
la frequenza del processore va in secondo piano
Concordo al 100% e azzardo anche che forse essendo il Centrino/Core duo riprogettati partendo dal P3, rispondano meglio all'INT 80h (e agli interrupt software in generale) rispetto al P4.

bye
Ultima modifica di Calzo il dom gen 10, 2010 11:11, modificato 1 volta in totale.
Avatar utente
Calzo
Linux 2.0
Linux 2.0
 
Messaggi: 112
Iscritto il: sab ott 06, 2007 21:21
Località: MN
Slackware: 10.2 | 13
Desktop: Fluxbox | KDE

Re: Cambio di architettura per Slackware

Messaggioda Bart » lun gen 04, 2010 11:40

conraid ha scritto:Tra l'altro in twitter Pat chiede anche quale opzioni del kernel abilitare, mi sembra una cosa più interessante questa.
Contagiato dal web2.0 si sta aprendo di più :-)
Ma voi siete iscritti a twitter? Devi essere iscritto per seguire la pagina di Volkerdi?
Bart
Staff
Staff
 
Messaggi: 4248
Iscritto il: dom ago 08, 2004 23:00
Località: Rimini

Prossimo

Torna a Libera

Chi c’è in linea

Visitano il forum: Nessuno e 1 ospite