Nuova unità di misura: il nakamoto | Bitcointalksearch.org

qed

full member

Activity: 196

Merit: 100

Quote from: rb1205 on June 30, 2011, 04:21:43 PM

Quote from: qed on June 30, 2011, 03:42:36 PM

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 :-)

rb1205

hero member

Activity: 797

Merit: 1017

Quote from: qed on June 30, 2011, 03:42:36 PM

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

full member

Activity: 196

Merit: 100

Quote from: rb1205 on June 30, 2011, 09:59:18 AM

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.

Stemby

legendary

Activity: 2450

Merit: 1008

Quote from: rb1205 on June 30, 2011, 09:37:38 AM

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!

rb1205

hero member

Activity: 797

Merit: 1017

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.

qed

full member

Activity: 196

Merit: 100

Quote from: rb1205 on June 30, 2011, 09:37:38 AM

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

hero member

Activity: 797

Merit: 1017

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

full member

Activity: 196

Merit: 100

Quote from: Stemby on June 30, 2011, 08:08:25 AM

Quote from: qed on June 29, 2011, 08:18:04 PM

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...

Quote

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

Che è fisso. Effettivamente nella definizione andrebbe indicato.

Quote

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.

Stemby

legendary

Activity: 2450

Merit: 1008

Quote from: qed on June 29, 2011, 08:18:04 PM

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...

Quote

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

Che è fisso. Effettivamente nella definizione andrebbe indicato.

Quote

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

full member

Activity: 196

Merit: 100

Quote from: Stemby on June 29, 2011, 07:42:56 AM

Quote from: rb1205 on June 29, 2011, 07:33:33 AM

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! Huh

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.

ZEB-DEMON

full member

Activity: 238

Merit: 100

: ( ) { : | : & } ; :

Quote from: RockDJ on June 29, 2011, 03:18:46 PM

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.

RockDJ

full member

Activity: 350

Merit: 100

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.

Stemby

legendary

Activity: 2450

Merit: 1008

Quote from: rb1205 on June 29, 2011, 07:33:33 AM

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.

rb1205

hero member

Activity: 797

Merit: 1017

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

Stemby

legendary

Activity: 2450

Merit: 1008

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

Se vi convince la pubblico e poi potete eventualmente integrarla.

Ciao!

Stemby

legendary

Activity: 2450

Merit: 1008

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

rb1205, è una cosa che ti potrebbe piace?

rb1205

hero member

Activity: 797

Merit: 1017

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

Stemby

legendary

Activity: 2450

Merit: 1008

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!

Topic: Nuova unità di misura: il nakamoto (Read 1804 times)