info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Velocita' di stampa
3 views
Skip to first unread message
guido84
Jun 8, 2017, 5:55:17 AM6/8/17
to
Con un programma, per generare disposizioni, scelgo di farmi
tutte le disposizioni degli elementi 1 x 2 a 13 a 13, cioe' deve
stamparmi in output tutte le colonne del totocalcio: 1.594.323.
Ho dato il comando per l'uscita: a video, in un file, su /dev/null.
I tempi, con time, sono stati i seguenti:
$ time ./disp -pr 1x2 13
real 1m56.431s
user 0m0.852s
sys 1m55.572s
$ time ./disp -pr 1x2 13 > /tmp/totocalcio
real 0m0.290s
user 0m0.252s
sys 0m0.040s
$ time ./disp -pr 1x2 13 > /dev/null
real 0m0.260s
user 0m0.256s
sys 0m0.000s
Domande:
1. Questo procedimento puo' essere un test per la velocita' dell'
hardware?
2. Se si', di che cosa? (a) scheda grafica, (b) monitor, (c) entrambi.
3. Perche' verso /dev/null il tempo di sistema e' nullo?
4. Ho il sospetto che c'entri Linux, perche' adesso ho dato lo stesso
comando per stamparle a video su terminale, invece che da console, ed
ecco i risultati (ci mette meno della meta' perche' annulla o quasi
il tempo di sistema?):
$ time ./disp -pr 1x2 13
real 0m44.622s
user 0m0.628s
sys 0m1.100s
P.S. Crosspost icol.development & icol.iniziare
--
Saluti,
Guido
tutte le disposizioni degli elementi 1 x 2 a 13 a 13, cioe' deve
stamparmi in output tutte le colonne del totocalcio: 1.594.323.
Ho dato il comando per l'uscita: a video, in un file, su /dev/null.
I tempi, con time, sono stati i seguenti:
$ time ./disp -pr 1x2 13
real 1m56.431s
user 0m0.852s
sys 1m55.572s
$ time ./disp -pr 1x2 13 > /tmp/totocalcio
real 0m0.290s
user 0m0.252s
sys 0m0.040s
$ time ./disp -pr 1x2 13 > /dev/null
real 0m0.260s
user 0m0.256s
sys 0m0.000s
Domande:
1. Questo procedimento puo' essere un test per la velocita' dell'
hardware?
2. Se si', di che cosa? (a) scheda grafica, (b) monitor, (c) entrambi.
3. Perche' verso /dev/null il tempo di sistema e' nullo?
4. Ho il sospetto che c'entri Linux, perche' adesso ho dato lo stesso
comando per stamparle a video su terminale, invece che da console, ed
ecco i risultati (ci mette meno della meta' perche' annulla o quasi
il tempo di sistema?):
$ time ./disp -pr 1x2 13
real 0m44.622s
user 0m0.628s
sys 0m1.100s
P.S. Crosspost icol.development & icol.iniziare
--
Saluti,
Guido
Piergiorgio Sartor
Jun 8, 2017, 1:27:43 PM6/8/17
to
On 2017-06-08 11:55, guido84 wrote:
> Con un programma, per generare disposizioni, scelgo di farmi
> tutte le disposizioni degli elementi 1 x 2 a 13 a 13, cioe' deve
> stamparmi in output tutte le colonne del totocalcio: 1.594.323.
>
> Ho dato il comando per l'uscita: a video, in un file, su /dev/null.
> I tempi, con time, sono stati i seguenti:
>
> $ time ./disp -pr 1x2 13
> real 1m56.431s
> user 0m0.852s
> sys 1m55.572s
>
> $ time ./disp -pr 1x2 13 > /tmp/totocalcio
> real 0m0.290s
> user 0m0.252s
> sys 0m0.040s
>
> $ time ./disp -pr 1x2 13 > /dev/null
> real 0m0.260s
> user 0m0.256s
> sys 0m0.000s
>
>
> Domande:
> 1. Questo procedimento puo' essere un test per la velocita' dell'
> hardware?
Dubito.
> Con un programma, per generare disposizioni, scelgo di farmi
> tutte le disposizioni degli elementi 1 x 2 a 13 a 13, cioe' deve
> stamparmi in output tutte le colonne del totocalcio: 1.594.323.
>
> Ho dato il comando per l'uscita: a video, in un file, su /dev/null.
> I tempi, con time, sono stati i seguenti:
>
> $ time ./disp -pr 1x2 13
> real 1m56.431s
> user 0m0.852s
> sys 1m55.572s
>
> $ time ./disp -pr 1x2 13 > /tmp/totocalcio
> real 0m0.290s
> user 0m0.252s
> sys 0m0.040s
>
> $ time ./disp -pr 1x2 13 > /dev/null
> real 0m0.260s
> user 0m0.256s
> sys 0m0.000s
>
>
> Domande:
> 1. Questo procedimento puo' essere un test per la velocita' dell'
> hardware?
> 2. Se si', di che cosa? (a) scheda grafica, (b) monitor, (c) entrambi.
Di solito *prima* si decide cosa testare, poi
si progetta il test in modo da poter fare la
misura nel migliore dei modi possibili.
Escluderei il monitor, pero`...
> 3. Perche' verso /dev/null il tempo di sistema e' nullo?
Il tempo che vedi e` solo quello prima di
entrare nel kernel, quando si arriva in
quel punto, questi (il kernel) butta via
i dati, il che non costa nulla.
> 4. Ho il sospetto che c'entri Linux, perche' adesso ho dato lo stesso
> comando per stamparle a video su terminale, invece che da console, ed
> ecco i risultati (ci mette meno della meta' perche' annulla o quasi
> il tempo di sistema?):
>
> $ time ./disp -pr 1x2 13
> real 0m44.622s
> user 0m0.628s
> sys 0m1.100s
Uno e` testo l'altro e grafico?
Nel primo caso dovrebbe essere piu` veloce.
bye,
--
piergiorgio
guido84
Jun 8, 2017, 2:39:34 PM6/8/17
to
Il 8/6/2017 19:26:08 Piergiorgio Sartor scrisse:
nella console F2 (ci vado con ctrl-alt-F2) e' piu' lento, aprendo
invece una finestra-terminale si vede anche che le righe scorrono
piu' veloci.
Puo' dipendere dal framebuffer? forse un tempo quando non c'era
era diverso. Io nella console ci sto sempre se devo scrivere
molto (ad esempio per programmare) per questioni oculistiche,
la modalita' grafica mi stanca la vista.
--
Saluti,
Guido
>On 2017-06-08 11:55, guido84 wrote:
>> $ time ./disp -pr 1x2 13
>> real 1m56.431s
>> user 0m0.852s
>> sys 1m55.572s
...............
>> $ time ./disp -pr 1x2 13
>> real 1m56.431s
>> user 0m0.852s
>> sys 1m55.572s
>> 4. Ho il sospetto che c'entri Linux, perche' adesso ho dato lo stesso
>> comando per stamparle a video su terminale, invece che da console, ed
>> ecco i risultati (ci mette meno della meta' perche' annulla o quasi
>> il tempo di sistema?):
>> $ time ./disp -pr 1x2 13
>> real 0m44.622s
>> user 0m0.628s
>> sys 0m1.100s
>Qual'e` la differenza tra "terminale" e "console"?
>Uno e` testo l'altro e grafico?
>Nel primo caso dovrebbe essere piu` veloce.
Grazie per le precedenti risposte, qui invece e' il contrario:
>> comando per stamparle a video su terminale, invece che da console, ed
>> ecco i risultati (ci mette meno della meta' perche' annulla o quasi
>> il tempo di sistema?):
>> $ time ./disp -pr 1x2 13
>> real 0m44.622s
>> user 0m0.628s
>> sys 0m1.100s
>Qual'e` la differenza tra "terminale" e "console"?
>Uno e` testo l'altro e grafico?
>Nel primo caso dovrebbe essere piu` veloce.
nella console F2 (ci vado con ctrl-alt-F2) e' piu' lento, aprendo
invece una finestra-terminale si vede anche che le righe scorrono
piu' veloci.
Puo' dipendere dal framebuffer? forse un tempo quando non c'era
era diverso. Io nella console ci sto sempre se devo scrivere
molto (ad esempio per programmare) per questioni oculistiche,
la modalita' grafica mi stanca la vista.
--
Saluti,
Guido
Piergiorgio Sartor
Jun 8, 2017, 2:54:33 PM6/8/17
to
On 2017-06-08 20:39, guido84 wrote:
[...]
Allora, il terminale testo, senza FB, e` la cosa
piu` veloce, ma ha anche una risoluzione un po'
limitata, direi 80x25 o forse 132x50 o simile.
Con FB invece e` piu` flessibile, fa anche grafica,
ma e` lento perche` le operazioni, forse tutte, di
"drawing" sono fatte dal kernel, usando la CPU.
In "console", cioe` con X ed il resto, di solito
e` la GPU, tramite il suo driver, a fare le varie
operazione di "drawing".
Di solito la GPU e` veloce.
Credo vi sia un parametri di boot (kernel cmdline),
tipo "nomodeset" o simile, che blocca la creazione
del FB e lascia il terminale in testo puro.
bye,
--
piergiorgio
[...]
>> Qual'e` la differenza tra "terminale" e "console"?
>> Uno e` testo l'altro e grafico?
>
>> Nel primo caso dovrebbe essere piu` veloce.
>
> Grazie per le precedenti risposte, qui invece e' il contrario:
> nella console F2 (ci vado con ctrl-alt-F2) e' piu' lento, aprendo
> invece una finestra-terminale si vede anche che le righe scorrono
> piu' veloci.
>
> Puo' dipendere dal framebuffer? forse un tempo quando non c'era
Ah! E` terminale con FB, non direttamente testo.
>> Uno e` testo l'altro e grafico?
>
>> Nel primo caso dovrebbe essere piu` veloce.
>
> Grazie per le precedenti risposte, qui invece e' il contrario:
> nella console F2 (ci vado con ctrl-alt-F2) e' piu' lento, aprendo
> invece una finestra-terminale si vede anche che le righe scorrono
> piu' veloci.
>
> Puo' dipendere dal framebuffer? forse un tempo quando non c'era
Allora, il terminale testo, senza FB, e` la cosa
piu` veloce, ma ha anche una risoluzione un po'
limitata, direi 80x25 o forse 132x50 o simile.
Con FB invece e` piu` flessibile, fa anche grafica,
ma e` lento perche` le operazioni, forse tutte, di
"drawing" sono fatte dal kernel, usando la CPU.
In "console", cioe` con X ed il resto, di solito
e` la GPU, tramite il suo driver, a fare le varie
operazione di "drawing".
Di solito la GPU e` veloce.
Credo vi sia un parametri di boot (kernel cmdline),
tipo "nomodeset" o simile, che blocca la creazione
del FB e lascia il terminale in testo puro.
bye,
--
piergiorgio
Alessandro Pellizzari
Jun 9, 2017, 1:32:22 AM6/9/17
to
On 08/06/17 10:55, guido84 wrote:
> $ time ./disp -pr 1x2 13
> real 1m56.431s
> $ time ./disp -pr 1x2 13
> real 1m56.431s
> $ time ./disp -pr 1x2 13 > /tmp/totocalcio
> real 0m0.290s
> real 0m0.290s
> $ time ./disp -pr 1x2 13 > /dev/null
> real 0m0.260s
> real 0m0.260s
> 1. Questo procedimento puo' essere un test per la velocita' dell'
> hardware?
No. Quello lo puoi fare solo pilotando l'hardware a basso livello.
> hardware?
> 2. Se si', di che cosa? (a) scheda grafica, (b) monitor, (c) entrambi.
aspettare che il testo sia effettivamente su schermo prima di tornare a
fare conti), mentre su disco hai buffering da parte del kernel, a meno
che non chiami sync dopo ogni scrittura.
> 4. Ho il sospetto che c'entri Linux, perche' adesso ho dato lo stesso
> comando per stamparle a video su terminale, invece che da console, ed
> ecco i risultati (ci mette meno della meta' perche' annulla o quasi
> il tempo di sistema?):
che lo schermo sia aggiornato.
Bye.
Giovanni
Jun 9, 2017, 3:53:30 AM6/9/17
to
On 06/08/2017 07:26 PM, Piergiorgio Sartor wrote:
> Qual'e` la differenza tra "terminale" e "console"?
> Uno e` testo l'altro e grafico?
Anche la console è un terminale come tutti gli altri e può essere di
> Qual'e` la differenza tra "terminale" e "console"?
> Uno e` testo l'altro e grafico?
tipo testo o grafico.
La console è il terminale su cui il kernel invia i suoi messaggi
informativi. Di default è il device "tty00" ma può essere
riprogrammata con opzioni al boot.
Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >
guido84
Jun 9, 2017, 5:14:09 AM6/9/17
to
Il 9/6/2017 07:32:20 Alessandro Pellizzari scrisse:
dipendesse dal minitor non velocissimo. Quindi verso /dev/null
non deve (come m'ha detto anche Piergiorgio) neppure fare il
buffering.
>> 4. Ho il sospetto che c'entri Linux, perche' adesso ho dato lo stesso
>> comando per stamparle a video su terminale, invece che da console, ed
>> ecco i risultati (ci mette meno della meta' perche' annulla o quasi
>> il tempo di sistema?):
>Probabilmente perche` manda il comandi di ridisegno a X ma non aspetta
>che lo schermo sia aggiornato.
Si' e capisco anche perche' il monitor si resetta ogni volta che
dalla console passo a X o viceversa: cambia chi lo gestisce.
Grazie e ciao
--
Saluti,
Guido
>On 08/06/17 10:55, guido84 wrote:
>Dal fatto che la syscall per stampare su schermo e` sincrona (deve
>aspettare che il testo sia effettivamente su schermo prima di tornare a
>fare conti), mentre su disco hai buffering da parte del kernel, a meno
>che non chiami sync dopo ogni scrittura.
Grazie dell'info, mi hai tranquillizzato perche' pensavo
>Dal fatto che la syscall per stampare su schermo e` sincrona (deve
>aspettare che il testo sia effettivamente su schermo prima di tornare a
>fare conti), mentre su disco hai buffering da parte del kernel, a meno
>che non chiami sync dopo ogni scrittura.
dipendesse dal minitor non velocissimo. Quindi verso /dev/null
non deve (come m'ha detto anche Piergiorgio) neppure fare il
buffering.
>> 4. Ho il sospetto che c'entri Linux, perche' adesso ho dato lo stesso
>> comando per stamparle a video su terminale, invece che da console, ed
>> ecco i risultati (ci mette meno della meta' perche' annulla o quasi
>> il tempo di sistema?):
>Probabilmente perche` manda il comandi di ridisegno a X ma non aspetta
>che lo schermo sia aggiornato.
dalla console passo a X o viceversa: cambia chi lo gestisce.
Grazie e ciao
--
Saluti,
Guido
guido84
Jun 9, 2017, 5:14:09 AM6/9/17
to
Il 8/6/2017 20:53:09 Piergiorgio Sartor scrisse:
lasciano due bande dello schermo, sopra e sotto, inutilizzate
e questo e' fastidiosissimo.
>Con FB invece e` piu` flessibile, fa anche grafica,
>ma e` lento perche` le operazioni, forse tutte, di
>"drawing" sono fatte dal kernel, usando la CPU.
>In "console", cioe` con X ed il resto, di solito
>e` la GPU, tramite il suo driver, a fare le varie
>operazione di "drawing".
>Di solito la GPU e` veloce.
Grazie delle info e ciao
--
Saluti,
Guido
>On 2017-06-08 20:39, guido84 wrote:
>> Puo' dipendere dal framebuffer? forse un tempo quando non c'era
>Ah! E` terminale con FB, non direttamente testo.
>Allora, il terminale testo, senza FB, e` la cosa
>piu` veloce, ma ha anche una risoluzione un po'
>limitata, direi 80x25 o forse 132x50 o simile.
............
>> Puo' dipendere dal framebuffer? forse un tempo quando non c'era
>Ah! E` terminale con FB, non direttamente testo.
>Allora, il terminale testo, senza FB, e` la cosa
>piu` veloce, ma ha anche una risoluzione un po'
>limitata, direi 80x25 o forse 132x50 o simile.
>Credo vi sia un parametri di boot (kernel cmdline),
>tipo "nomodeset" o simile, che blocca la creazione
>del FB e lascia il terminale in testo puro.
Si', se non li metto mi fa 80 colonne e va bene, ma 25 righe
>tipo "nomodeset" o simile, che blocca la creazione
>del FB e lascia il terminale in testo puro.
lasciano due bande dello schermo, sopra e sotto, inutilizzate
e questo e' fastidiosissimo.
>Con FB invece e` piu` flessibile, fa anche grafica,
>ma e` lento perche` le operazioni, forse tutte, di
>"drawing" sono fatte dal kernel, usando la CPU.
>In "console", cioe` con X ed il resto, di solito
>e` la GPU, tramite il suo driver, a fare le varie
>operazione di "drawing".
>Di solito la GPU e` veloce.
--
Saluti,
Guido
0 new messages