Nuova unità di misura: il nakamoto

[Stemby]

Simbolo: nak

http://forum.bitcoin.org/index.php?topic=22343.msg301564#msg301564

Dite che possa essere utile/carino/divertente?

Se sì, buttiamo giù una bozza di articolo da scrivere su Wikipedia.

Ciao!

[1714127389]

1714127389

[1714127389]

1714127389

[1714127389]

1714127389

[1714127389]

1714127389

[rb1205]

Secondo me sarebbe una cosa da proporre sulla board delle discussioni generali.

[Stemby]

Sì, ma prima dobbiamo chiarirci per bene le idee noi.

rb1205, è una cosa che ti potrebbe piace?

[Stemby]

http://it.wikipedia.org/wiki/Utente:Stemby/Quaderno_di_brutta

Se vi convince la pubblico e poi potete eventualmente integrarla.

Ciao!

[rb1205]

Non sono convinto che possa prendere piede, il mhash/sec è già molto chiaro ed immediato così.

[Stemby]

il mhash/sec è già molto chiaro ed immediato così.

Nel nostro uso sì, ma perché sappiamo cosa significa 1 hash (che non è un'unità di misura standard).

Il nak per esempio potrebbe essere utilizzato direttamente dai produttori di schede video nelle schede tecniche dei loro prodotti. Di sicuro non possono parlare di Mhash/s, a meno di mettere in nota cosa si intende per hash.

[RockDJ]

Secondo me potrebbe essere un'idea carina anche se effettivamente vedo molte difficoltà di accettazione.

Ho 3 osservazioni:

- Bisognerebbe che tutti fossero d'accordo anche sul forum principale (in inglese), per evitare di creare inutili incomprensioni e "ghettizzazioni" (non so se intendevi questo rb)
- Direi che, visto che si parla sempre di Mhash/s e visto che da qui in poi le velocità aumenteranno sempre di più,  sarebbe più intelligente usare la misura più usata, quindi 1Nak = 1Mhash/s
- I Mhash/s danno più idea di velocità

Ad ogni modo, come dici tu rb, prima di scrivere su wiki ed eventualmente proporla a tutta la comunità bisogna a mio parere costruire una proposta ben solida e completa.

[ZEB-DEMON]

Secondo me potrebbe essere un'idea carina anche se effettivamente vedo molte difficoltà di accettazione.

Ho 3 osservazioni:

- Bisognerebbe che tutti fossero d'accordo anche sul forum principale (in inglese), per evitare di creare inutili incomprensioni e "ghettizzazioni" (non so se intendevi questo rb)
- Direi che, visto che si parla sempre di Mhash/s e visto che da qui in poi le velocità aumenteranno sempre di più,  sarebbe più intelligente usare la misura più usata, quindi 1Nak = 1Mhash/s
- I Mhash/s danno più idea di velocità

Ad ogni modo, come dici tu rb, prima di scrivere su wiki ed eventualmente proporla a tutta la comunità bisogna a mio parere costruire una proposta ben solida e completa.

già, proponila in bitcoin discussion.

[qed]

il mhash/sec è già molto chiaro ed immediato così.

Nel nostro uso sì, ma perché sappiamo cosa significa 1 hash (che non è un'unità di misura standard).

Il nak per esempio potrebbe essere utilizzato direttamente dai produttori di schede video nelle schede tecniche dei loro prodotti. Di sicuro non possono parlare di Mhash/s, a meno di mettere in nota cosa si intende per hash.

Invece, scriverci una nak senza specificare avrebbe proprio senso!  La cosa è comunque insensata visto che gli hash/s diepndono dall'algoritmo della funzione di hash utilizzata, dai restati pezzi di hardware del computer, dai drivers... Ad essere pignoli sarebbe molto più significativo scrivere il punteggio 3DMark, cosa anch'essa assurda.

[Stemby]

Invece, scriverci una nak senza specificare avrebbe proprio senso!

Beh, se esiste una definizione cosa altro devi specificare?

Non è che ogni volta che parli di "metri" metti in nota la definizione di metro...

La cosa è comunque insensata visto che gli hash/s diepndono dall'algoritmo della funzione di hash utilizzata

Che è fisso. Effettivamente nella definizione andrebbe indicato.

dai restati pezzi di hardware del computer, dai drivers...

Questo non mi è chiaro, invece. È ovvio che, per proseguire l'esempio dei produttori di schede video, dovranno eseguire dei test in condizioni standard. Ma questo vale per qualunque cosa.

[qed]

Invece, scriverci una nak senza specificare avrebbe proprio senso!

Beh, se esiste una definizione cosa altro devi specificare?

Non è che ogni volta che parli di "metri" metti in nota la definizione di metro...

La cosa è comunque insensata visto che gli hash/s diepndono dall'algoritmo della funzione di hash utilizzata

Che è fisso. Effettivamente nella definizione andrebbe indicato.

dai restati pezzi di hardware del computer, dai drivers...

Questo non mi è chiaro, invece. È ovvio che, per proseguire l'esempio dei produttori di schede video, dovranno eseguire dei test in condizioni standard. Ma questo vale per qualunque cosa.

La tua definizione di questo nak si baserebbe sugli hash/s (che a tuo dire non è una unità di misura adeguata).

C'è molta più roba oltre l'ultima frase che non ti è chiara.

[rb1205]

Non vedo dove sia il problema dal punto di vista formale, se si definisce un nak come un'operazione di hashing SHA-256 di 80 byte di dati svolto al secondo dal dispositivo in esame, più ovviamente l'overhead dovuto a controlli e a modifiche. Si può teoricamente tirare fuori in modo indiretto noti l'algoritmo, il clock del dispositivo, il numero di clock richiesto da ogni operazione e la quantità di stream processors presenti.

Il problema secondo me è più di opportunità, non credo possa aver seguito.

[qed]

Non vedo dove sia il problema dal punto di vista formale, se si definisce un nak come un'operazione di hashing SHA-256 di 80 byte di dati svolto al secondo dal dispositivo in esame, più ovviamente l'overhead dovuto a controlli e a modifiche. Si può teoricamente tirare fuori in modo indiretto noti l'algoritmo, il clock del dispositivo, il numero di clock richiesto da ogni operazione e la quantità di stream processors presenti.

Il problema secondo me è più di opportunità, non credo possa aver seguito.

Non è possibile perché l'algoritmo SHA-256 non ha un unico modo di essere parallelizzato ed i drivers hanno troppo peso sulla velocità computazionale delle varie implementazioni.

[rb1205]

Suvvia, la stessa cosa si applica per le prestazioni 3D, eppure questo non impedisce di valutare le prestazioni di una scheda usando parametri sintetici tipo 3Dmark o l'FPS dei giochi di riferimento.

Ad ogni modo, non mi risulta che i driver abbiano eccessiva influenza nei confronti nelle prestazioni in OpenCL come nel 3D. L'SDK sicuramente, ma per motivi molto più pragmatici e prevedibili (quando non sono bug, vedasi 2.2 e 2.3).

E per quanto riguarda l'algoritmo di mining da valutare, ovviamente andrebbe personalizzato da architettura ad architettura in modo da massimizzare la resa.

[Stemby]

Il problema secondo me è più di opportunità

Su questo posso essere d'accordo, ma è comunque sempre un passettino avanti rispetto ad un generico "hash al secondo".

Provate a vedere se ora l'articolo vi sembra sufficientemente solido per essere sottoposto alla critica internazionale (una volta tradotto in inglese).

Ciao!

[qed]

Suvvia, la stessa cosa si applica per le prestazioni 3D, eppure questo non impedisce di valutare le prestazioni di una scheda usando parametri sintetici tipo 3Dmark o l'FPS dei giochi di riferimento.

Ad ogni modo, non mi risulta che i driver abbiano eccessiva influenza nei confronti nelle prestazioni in OpenCL come nel 3D. L'SDK sicuramente, ma per motivi molto più pragmatici e prevedibili (quando non sono bug, vedasi 2.2 e 2.3).

E per quanto riguarda l'algoritmo di mining da valutare, ovviamente andrebbe personalizzato da architettura ad architettura in modo da massimizzare la resa.

SDK sono i "drivers" per l'OpenCL.

[rb1205]

SDK sono i "drivers" per l'OpenCL.

  Non direi proprio... Il driver si occupa di interpretare le chiamate hardware aggiungendosi modularmente al kernel dell'OS. Gli SDK, compreso quello di stream e di APP, sono dei supporti alla programmazione composti da un'insieme di librerie, compilatori, interpreti, debugger e chi piu ne ha più ne metta, che fungono da supporto al software utente. Non hanno un granchè a che fare.

Se poi intendi che SDK come CAL/APP e CUDA forniscono un'implementazione di OpenCL, ok, ma non credo che questo li qualifichi come driver! Non dal punto di vista prestazionale, quantomeno.

[qed]

SDK sono i "drivers" per l'OpenCL.

  Non direi proprio... Il driver si occupa di interpretare le chiamate hardware aggiungendosi modularmente al kernel dell'OS. Gli SDK, compreso quello di stream e di APP, sono dei supporti alla programmazione composti da un'insieme di librerie, compilatori, interpreti, debugger e chi piu ne ha più ne metta, che fungono da supporto al software utente. Non hanno un granchè a che fare.

Se poi intendi che SDK come CAL/APP e CUDA forniscono un'implementazione di OpenCL, ok, ma non credo che questo li qualifichi come driver! Non dal punto di vista prestazionale, quantomeno.

Pensala come vuoi, è un pezzo di software che determina come viene usato l'hardware e le sue prestazioni. Hai un PM :-)