CUDA, divizibilitate și socoteli noi de software-hardware în aprilie 2019
8 aprilie 2019 a fost altă zi mare la numere.
În N-uri, la numerele al căror numitor abundențial (de la fracția redusă „suma divizorilor / număr”) este maxim 10, am depășit 8 megaocteți binari (8388608 octeți), la cota 28198 de numere.
Și apoi am atins și 28200.
Am tot așteptat să văd dacă se ajunge la 8 MB plini, și uite c-a fost loc și pentru asta.
Și pe 15 aprilie am adus în casă o cameră web A4Tech, poate oi avea nevoie de video cu cineva sau ceva.
La CUDA nu știu dacă divizibilitatea cu rest poate fi simulată pe virgula mobilă în precizia extinsă (arbitrară), mai ales că în bibliotecile disponibile și găsite (CUMP, GPUPREC, CAMPARY), exclusiv pe numere cu virgulă, extinse pe limburi de la double, lipsesc capacități importante ca partea întreagă / partea fracționară, sau echivalentul funcției fmod de la tipul double, care trata restul. Poate la ceva numere ÎNTREGI pe CUDA, dar codul pentru ele nu este disponibil (la IEEE figurează o documentație despre o astfel de bibliotecă de întregi pe CUDA, din 2010, făcută de doi chinezi - Kaiyong Zhao și Xiaowen Chu - și care se cheamă GPUMP, dar nu știu dacă are codul acolo, chiar și contra plată la descărcare). Ar trebui să îmi fac cont la IEEE și să îi întreb dacă se poate descărca biblioteca în mod contra cost, nefiind „sursă deschisă” sau open-source.
Pe double, dacă îl împarți pe 10 la 3 și apoi rezultatul îl înmulțești tot cu trei, poți să obții ceva cu zecimale 999999999, diferit de 10 printr-o marjă (epsilon sau delta) verificabilă, și tot îți dai seama de indivizibilitate astfel. Sau chiar fără epsilon, ajunge că 9.99999998 (să zicem) este INEGAL cu 10.
Numai că atunci când lucram cu tipul Flash (cu virgulă) al bibliotecii MIRACL de precizie arbitrară (2010) pe Borland C++ în linia de comandă (Command Prompt în Windows), știu că o astfel de înmulțire înapoi dădea exact numărul natural de la care se plecase, fără coadă zecimală de imprecizie.
Dacă este la fel și pe tipurile cu virgulă mobilă, de precizie extinsă, de la bibliotecile CUDA de mai sus?...
Nu am verificat, ce-i drept. Dar, în lipsa operatorului de tip modulus și a funcțiilor trunc/frac, împărțirea cu înmulțire înapoi ar fi soluția rămasă pentru a verifica atunci când s-a depășit puterea maximă de factor prim cu care un număr este divizibil (pentru construirea sumei divizorilor pe bază de produs de modelări de puteri de factori primi), admițând că rezultatul înmulțirii, la expirarea divizibilității, NU coincide în mod întreg cu deîmpărțitul inițial (număr natural), ca la Flash în MIRACL în 2010. Ar fi destul overhead - încărcătură în plus - aici cu operațiile, când în mod normal o funcție de tip rest face doar împărțirea și returnează restul, fără înmulțire înapoi, dar dacă la tipurile extinse se ajunge tot înapoi la numărul natural inițial (ca la 3.333333... * 3 = 10 fix), atunci degeaba, nu se dovedește nimic cu divizibilitatea.
În plus, prin codul bibliotecilor aritmetice CUDA de precizie extinsă pe virgulă mobilă de mai sus, nici nu am văzut o funcție de tipul conversie la string (recunosc totuși a nu fi studiat încă toate fișierele, rând pe rând), care, dacă stringuim un „double extins” dintr-acelea, ne dă voie să vedem dacă numărul conține punct, apropo de povestea cu indivizibilitatea și partea fracționară a câtului.
Totuși, dacă o astfel de funcție trebuia să fie prin fișierele cu operații mai de bază, sigur n-am găsit-o.
Prin comparație, la GMP, la întregi de pildă, avem mpz_get_str() cu 3 argumente (șirul, baza de numerație a conversiei - de la 2 la 62 dacă nu mă înșel - și numărul), și analog mpf_get_str() la numerele reale, cu aceeași argumentație și aritate (asta din urmă e numărul de argumente).
*
Poate că la GPUMP, la întregi, se verifică restul la extinse și-aș putea lucra acolo, dar întâi să o pot descărca de la IEEE (și poate să iau între timp o placă de 11 GB video GDDR6 cu 4352 de nuclee CUDA pentru putere sporită), și să văd dacă numerele merg mai repede așa decât pe GMP cu C pe procesor clasic.
Am nevoie să mai câștig destul între timp, să pot lua aceste lucruri. Și forajul numeric continuă cu resursele actuale - am trecut și de cota 28286 (15 aprilie). Tot mai este loc de numere.
**
Pentru moment, numărul de nuclee CUDA recunoscute pe plăcile video din casă este: 768 la ASUSPRIME (GTx 1050 Ti) + 640 la THREADRIPPER (GTX 1050) + câte 384 la XPOWER și AORUS (GT 1030-uri), total 2196 de nuclee peste 1 GHz fiecare.
Ar mai fi 384 la SLI PLUS, tot pe o GT 1030, numai că interogatorul deviceQuery din măruntaiele folderului „samples” de la CUDA dă o eroare, nu o recunoaște, nu știu de ce.
***
Aceste plăci video sunt GDDR5, dar Veritonul are și el o placă GT 9500 de 1 GB, GDDR3, din anul 2011. Dar nici acolo nu a fost recunoscută ca fiind capabilă de CUDA, deși cred că are 32 de nuclee sub 1 GHz.
Cu toate nucleele recunoscute, 2612 în fel și chip ar fi.
******
Iar pe 13-14 aprilie din 2019 am dat jos sistemele de operare Ubuntu 18.10 de pe AORUS și XPOWER, și-am pus la loc Arch Linuxul pe ele (varianta 2019.04). În sâmbăta de 8 decembrie 2018 făcusem mișcarea inversă, de la Arch Linux la Ubuntu, pentru că se blocau la terminarea pornirii, atunci când ecranul ar fi trebuit populat video cu Desktop-ul. Dacă resetam BIOS-ul fără detaliile de overclocking, scăpam; dar NU am vrut așa.
Și iată că acum am venit înapoi, toată casa are Arch Linux, ca înainte.
La instalări am văzut că nu mai este valabil pachetul wpa_actiond, când se face pacstrap de /mnt pe stick-ul de instalare, cu conexiune la Internet; l-am înlocuit cu CUDA, care este cel mai mare pachet dintre toate cele prinse.
Și la XPOWER fișierele au fost instalate mult mai lent, am încheiat noaptea târziu.
În fine, acum înapoi cu Arch Linux peste tot. Și așa Ubuntu urma joia asta să aibă versiune nouă (19.04 non-LTS).
Și-o să și-o aibă într-adevăr, însă nu pentru mine.
************
P.S. Iar a început Aorusul cu obrăzniciile de tip blocaj de sistem, de la o vreme, chiar dacă am mai tăiat la frecvențe să stea și la 4200 MHz cel mai jos; am umblat și răs-umblat la setările de voltaj, frecvență, LLC, current protection și chiar de memorie.
Spre deosebire de 2018, când se bloca și repede restarta pe nepusă masă, acum, pur și simplu... îngheț de sistem.
Nu știu dacă ultimele setări l-au potolit rezonabil, trebuie tratat cu mănuși ca un copil fragil.
În N-uri, la numerele al căror numitor abundențial (de la fracția redusă „suma divizorilor / număr”) este maxim 10, am depășit 8 megaocteți binari (8388608 octeți), la cota 28198 de numere.
Și apoi am atins și 28200.
Am tot așteptat să văd dacă se ajunge la 8 MB plini, și uite c-a fost loc și pentru asta.
Și pe 15 aprilie am adus în casă o cameră web A4Tech, poate oi avea nevoie de video cu cineva sau ceva.
La CUDA nu știu dacă divizibilitatea cu rest poate fi simulată pe virgula mobilă în precizia extinsă (arbitrară), mai ales că în bibliotecile disponibile și găsite (CUMP, GPUPREC, CAMPARY), exclusiv pe numere cu virgulă, extinse pe limburi de la double, lipsesc capacități importante ca partea întreagă / partea fracționară, sau echivalentul funcției fmod de la tipul double, care trata restul. Poate la ceva numere ÎNTREGI pe CUDA, dar codul pentru ele nu este disponibil (la IEEE figurează o documentație despre o astfel de bibliotecă de întregi pe CUDA, din 2010, făcută de doi chinezi - Kaiyong Zhao și Xiaowen Chu - și care se cheamă GPUMP, dar nu știu dacă are codul acolo, chiar și contra plată la descărcare). Ar trebui să îmi fac cont la IEEE și să îi întreb dacă se poate descărca biblioteca în mod contra cost, nefiind „sursă deschisă” sau open-source.
Pe double, dacă îl împarți pe 10 la 3 și apoi rezultatul îl înmulțești tot cu trei, poți să obții ceva cu zecimale 999999999, diferit de 10 printr-o marjă (epsilon sau delta) verificabilă, și tot îți dai seama de indivizibilitate astfel. Sau chiar fără epsilon, ajunge că 9.99999998 (să zicem) este INEGAL cu 10.
Numai că atunci când lucram cu tipul Flash (cu virgulă) al bibliotecii MIRACL de precizie arbitrară (2010) pe Borland C++ în linia de comandă (Command Prompt în Windows), știu că o astfel de înmulțire înapoi dădea exact numărul natural de la care se plecase, fără coadă zecimală de imprecizie.
Dacă este la fel și pe tipurile cu virgulă mobilă, de precizie extinsă, de la bibliotecile CUDA de mai sus?...
Nu am verificat, ce-i drept. Dar, în lipsa operatorului de tip modulus și a funcțiilor trunc/frac, împărțirea cu înmulțire înapoi ar fi soluția rămasă pentru a verifica atunci când s-a depășit puterea maximă de factor prim cu care un număr este divizibil (pentru construirea sumei divizorilor pe bază de produs de modelări de puteri de factori primi), admițând că rezultatul înmulțirii, la expirarea divizibilității, NU coincide în mod întreg cu deîmpărțitul inițial (număr natural), ca la Flash în MIRACL în 2010. Ar fi destul overhead - încărcătură în plus - aici cu operațiile, când în mod normal o funcție de tip rest face doar împărțirea și returnează restul, fără înmulțire înapoi, dar dacă la tipurile extinse se ajunge tot înapoi la numărul natural inițial (ca la 3.333333... * 3 = 10 fix), atunci degeaba, nu se dovedește nimic cu divizibilitatea.
În plus, prin codul bibliotecilor aritmetice CUDA de precizie extinsă pe virgulă mobilă de mai sus, nici nu am văzut o funcție de tipul conversie la string (recunosc totuși a nu fi studiat încă toate fișierele, rând pe rând), care, dacă stringuim un „double extins” dintr-acelea, ne dă voie să vedem dacă numărul conține punct, apropo de povestea cu indivizibilitatea și partea fracționară a câtului.
Totuși, dacă o astfel de funcție trebuia să fie prin fișierele cu operații mai de bază, sigur n-am găsit-o.
Prin comparație, la GMP, la întregi de pildă, avem mpz_get_str() cu 3 argumente (șirul, baza de numerație a conversiei - de la 2 la 62 dacă nu mă înșel - și numărul), și analog mpf_get_str() la numerele reale, cu aceeași argumentație și aritate (asta din urmă e numărul de argumente).
*
Poate că la GPUMP, la întregi, se verifică restul la extinse și-aș putea lucra acolo, dar întâi să o pot descărca de la IEEE (și poate să iau între timp o placă de 11 GB video GDDR6 cu 4352 de nuclee CUDA pentru putere sporită), și să văd dacă numerele merg mai repede așa decât pe GMP cu C pe procesor clasic.
Am nevoie să mai câștig destul între timp, să pot lua aceste lucruri. Și forajul numeric continuă cu resursele actuale - am trecut și de cota 28286 (15 aprilie). Tot mai este loc de numere.
**
Pentru moment, numărul de nuclee CUDA recunoscute pe plăcile video din casă este: 768 la ASUSPRIME (GTx 1050 Ti) + 640 la THREADRIPPER (GTX 1050) + câte 384 la XPOWER și AORUS (GT 1030-uri), total 2196 de nuclee peste 1 GHz fiecare.
Ar mai fi 384 la SLI PLUS, tot pe o GT 1030, numai că interogatorul deviceQuery din măruntaiele folderului „samples” de la CUDA dă o eroare, nu o recunoaște, nu știu de ce.
***
Aceste plăci video sunt GDDR5, dar Veritonul are și el o placă GT 9500 de 1 GB, GDDR3, din anul 2011. Dar nici acolo nu a fost recunoscută ca fiind capabilă de CUDA, deși cred că are 32 de nuclee sub 1 GHz.
Cu toate nucleele recunoscute, 2612 în fel și chip ar fi.
******
Iar pe 13-14 aprilie din 2019 am dat jos sistemele de operare Ubuntu 18.10 de pe AORUS și XPOWER, și-am pus la loc Arch Linuxul pe ele (varianta 2019.04). În sâmbăta de 8 decembrie 2018 făcusem mișcarea inversă, de la Arch Linux la Ubuntu, pentru că se blocau la terminarea pornirii, atunci când ecranul ar fi trebuit populat video cu Desktop-ul. Dacă resetam BIOS-ul fără detaliile de overclocking, scăpam; dar NU am vrut așa.
Și iată că acum am venit înapoi, toată casa are Arch Linux, ca înainte.
La instalări am văzut că nu mai este valabil pachetul wpa_actiond, când se face pacstrap de /mnt pe stick-ul de instalare, cu conexiune la Internet; l-am înlocuit cu CUDA, care este cel mai mare pachet dintre toate cele prinse.
Și la XPOWER fișierele au fost instalate mult mai lent, am încheiat noaptea târziu.
În fine, acum înapoi cu Arch Linux peste tot. Și așa Ubuntu urma joia asta să aibă versiune nouă (19.04 non-LTS).
Și-o să și-o aibă într-adevăr, însă nu pentru mine.
************
P.S. Iar a început Aorusul cu obrăzniciile de tip blocaj de sistem, de la o vreme, chiar dacă am mai tăiat la frecvențe să stea și la 4200 MHz cel mai jos; am umblat și răs-umblat la setările de voltaj, frecvență, LLC, current protection și chiar de memorie.
Spre deosebire de 2018, când se bloca și repede restarta pe nepusă masă, acum, pur și simplu... îngheț de sistem.
Nu știu dacă ultimele setări l-au potolit rezonabil, trebuie tratat cu mănuși ca un copil fragil.
Comentarii
Trimiteți un comentariu