Progresul hardware, episodul 57: Peste vară cu tetrada; noi programe pentru lucrul numeric (iunie-iulie 2018)
La ASUS PRIME 7900X-ul stă cu coolerul Corsair H115i, sunt 32 de GB de DDR4-4133 și trei hard disk-uri, unul de 500 de GB și două de câte 4 TB, placa video de 4 GB GT1050 OC Windforce, GDDR5.
La noul SLI PLUS 7740X-ul cel nou stă cu coolerul Arctic Liquid Freezer AC 360, 64 de GB de DDR4-3000 (ca anul trecut în august), cu un SSD SATA3 de 240 de GB și două hard disk-uri, unul de 2 TB, altul de 3 TB, placa video NVidia GT1030 de 2 GB, GDDR5.
La XPOWER GAMING 7980XE-ul nedelidded e cu coolerul EKWB, radiator cvadruplu EK Coolstream XE cu patru FF5 Vardare de 3000 de RPM, 128 de GB de DDR4-3333 (la 3400 rulează) și are un NVME PCI-E de 1 TB, plus șapte hard disk-uri: unul de 2 TB, unul de 4 TB, două de 5 TB și trei de 6 TB (i l-am pus și pe al treilea, da), placa video NVidia GT1030 de 2 GB ca la SLI PLUS, GDDR5.
La AORUS 7980XE-ul delidded stă cu alt cooler EKWB cu radiator Coolstream XE cvadruplu, patru Vardare FF5-120 ca la XPOWER, cu monoblock (la XPOWER este waterblock obișnuit), 128 de GB de DDR4-4000, un NVME PCI-E de 480 de GB, alt NVME PCI-E de 1024 de GB sau 1 TB cu cântec, un hard disk extern de 1000 de GB sau 1 TB (pentru numerele marginale, dar nu numai), un stick USB de 64 (61) de GB pentru numere (mai există stick-uri în casă, dar nu la numere), un SSD SATA3 de 1024 de GB sau alt 1 TB cu cântec, plus șase hard diskuri mari: două de 8 TB, două de 10 TB și două de 12 TB, placa video este Zotacul GT1030 de 2 GB, GDDR5.
Veritonul stă cu vechea lui configurație de i5-650, cu cooler comercial de la asamblare (stock), 16 GB de DDR3-1333, un hard disk SATA2 de 1 TB (1000 de GB) și placa video NVidia GT9500 de 1 GB, GDDR3 (sau 2?). Ziceam că el nu mai intră la numere.
În total, acum pentru numere stau 8500 + 5240 + 35000 + 63589 = 112329 de GB zecimali, cu ajustările de rigoare la spațiile partițiilor de pe discuri, sau vreo 112 TB.
Cu tot cu Veritonul și cele câteva IDE-uri vechi rămase în casă, sunt între 113 și 114 TB în casă.
Așadar, 112 TB pentru numere.
În continuarea așteptării Threadripperului de 32 de nuclee, pe 8 iulie 2018 a fost atins, în sfârșit, pragul de 25000 de numere, asta la fondul 1.
Pe 9 iulie sunt chiar 25006.
Mai urmează altele.
Am avut convingerea că mai există suficiente numere până la 25000 și chiar mai departe. Adunarea neîncetată de numere de fond 1 arată că povestea cu numerele chiar merită să continue, și-am să mai fac treabă pentru ca numerele să aibă foarte bune condiții de căutare și strângere a lor în fișiere, și ca hardware, și ca volum de lucru.
De aceea ar merita și un Threadripper în casă.
În System Monitor la Arch Linux, ar urma să se vadă șaizeci și patru de dreptunghiuri închipuind procesoarele virtuale, cu culori diferite.
Răcirea o vreau făcută tot cu piese de EKWB, radiator cvadruplu (unul nou), patru ventilatoare EK-Furious Vardar FF5-120, CryoFuel incolor (predistilat sau concentrat+cu apa mea distilată) și pompă DC Elite PWM cu rezervor de EK-RES 150 (sau poate altul potrivit). Va trebui ca într-una din zile să îmi fac iar curaj și să merg la ING ca să întreb cât credit mai am voie să fac, de astă dată direct pe cinci ani.
Toată tetrada știe că în N-uri sunt 25006 numere.
La 20 iulie 2018 sunt 25118 numere în fondul 1 și 115 TB alocați pentru numere (acum este și al doilea hard disk de 3 TB în casă, un Toshiba numit 3T, sus la Aorus).
66589 + 35000 + 8500 + 5240 GB (minus partiționarea) = 115329 de GB zecimali, fără TB-ul de la Veriton, care continuă să nu mai intre la numere.
Threadripper-ul s-ar putea să vină în septembrie. Sau în noiembrie dacă se mărește salariul.
S-ar putea ca al doilea credit să ia locul primului, înghițindu-l (credit de consum cu refinanțare) și, devenit unic credit mai mare, cu peste 30000 de lei rămași pot dota Threadripper-ul pe cinste.
Mai vedem cum merg numerele.
24 iulie: La ASUS PRIME am pus cel mai recent BIOS, pe 1401, și am mai făcut o reformă în codul numerelor, ca să fie fișiere speciale (DIST.TXT și DIST2.TXT) unde să fie, pentru fiecare program recent aflat în rulare, date despre fișierele implicate, intervalul de căutare, cât s-a mișcat programul în depozitul numeric ales (GIG sau LPT), direcția (sus sau jos, adică înmulțire ori împărțire) și intervalul factorilor de legătură folosiți - asta pentru DIST - și, în DIST2, tot pentru fiecare program recent, folderul și comanda de repornire din zona unde a fost întrerupt, ca în caz de cădere de curent sau repornire nedorită a vreunei mașinării din tetradă să pot, oarecum repede, repune în mișcare căutarea numerică de unde s-a întrerupt, și să știu bine cum se cheamă fiecare fișier, plus, dacă suprascriu între timp vreun NUMSIMPL sau MODPRIM(E) ori MODIFSUM (teoretic și pe altele), să știu din DIST.TXT, pentru fișierul de rezultate rămas în aer, cum căuta conform fișierului-generator care a fost suprascris (ca să pot relua și acolo căutarea, în pofida suprascrierii codului declanșator).
Fișierele text DIST și DIST2, aici implicate, se șterg și se populează cu date de fiecare dată când apelez RECONST-ul. RECONST.cc se bazează pe headerul GMP64.h, unde sunt niște metode speciale (RECIDENTE2, DIST2) prin care sunt atinse acele două fișiere de audit numeric; în afară de asta, fiecare NUMSIMPL, MODPRIM, MODSPRIM, MODIFSUM, HMODIFSUM, MODSPAR, MODPRIMSUM, MODPARSUM(E) și celelalte fișiere căutătoare pe care le-am reformat în 2018 trebuie să pregătească date pentru altă funcție din acel GMP64.h (RECIDENTE se cheamă), din ele trebuiesc trimise acolo, la prelucrare pentru mai departe, datele privind numele fișierului declanșator de căutare (NUMSIMPL.cc), numele executabilului (./numsimpl), folderul de unde se lansează (/NUMERIC/2/), numele fișierului mare de tip depozit numeric, din care se iau numerele de bază dinspre care se pleacă în căutare (/run/media/root/8TB/LPT120.LPT, /run/media/root/10T/GIG110.TXT), puterea de 10 de la care se pornește (110 de exemplu), cea la care trebuie ajuns (cum ar fi 120), cifra cu care să înceapă numerele de la puterea de 10 de plecare (1, de obicei, dar poate fi nevoie și de alta, mai ales când a fost întrerupere), numele fișierului cu rezultate numerice, cu tot cu locul unde este (/run/media/root/1TB/CAPARBIOBALD.NUM2), cât de mari sunt, în medie, numerele de la începutul fișierului de rezultate și de la sfârșitul lui și cât de mult s-a urcat (dacă în medie numerele de început au 109 cifre și încep cu 7, atunci jos 108 cu 7, iar dacă sus 116 cifre cu cifra 6 la început, atunci 116 cu 6, și atunci urcarea ar fi de tipul 7 cu 8, adică șapte ordine complete de mărime a puterii lui 10 între 108 și 116, iar în ordinul de mărime incomplet, cum 6 de sus este mai mic decât 7 de jos și nu se trece peste ordin, avem că 7 intră în 60 de opt ori), plus care a fost direcția de plecare a numerelor, în sus (dacă variabila „r” din fișierul declanșator este 1) sau în jos dacă r este 0, r fiind și el dat ca parametru la RECIDENTE, și limitele de jos și de sus ale numerelor prime (NUMSIMPL, MODPRIM) sau neprime (MODIFSUM) de legătură între numere, de pildă factori între 300 și 600, și atunci 300 și 600 se dau la RECIDENTE și ei.
Astfel, este mai ușor de reconstituit un traseu numeric dacă se întrerupe taman când nu trebuie.
Tot năzuiesc la Threadripper pentru mai încolo. Deocamdată nici nu a apărut.
Mai este și DIST.cc, menit să arate, pur și simplu, cât s-a urcat într-un fișier de rezultate numerice sau într-un depozit, de la început la sfârșit (de preferință să fie sortat crescător fișierul), tot așa, cu jos și cu sus & „urcă cu”, iar pentru el se apelează funcția DIST din GMP64.h (DIST2 este o variantă mai bine elaborată a lui DIST).
Fișierele de rezultate aflate în căutare curentă trebuie să aibă extensia .NUM2, iar după terminarea căutării (cu sau fără întrerupere, la întrerupere se reia cu alt nume de fișier*), le redenumesc cu .NUM1, apoi sortatorul crescător LITUAN le reschimbă în .NUM, ceea ce înseamnă că sunt gata de cules din ele rezultatele noi pentru depozite. La RECONST sunt căutate fișierele cu .NUM2.
*Apropo de schimbarea numelui unui fișier de rezultate, fiecare fișier-sursă declanșator trebuie apelat cu o listă de parametri la argv, și se spune de exemplu ./numsimpl 100 110 /run/media/root/8TB/LPTUAN110.LPT a 1 sau ./MODPRIME 90 100 /run/media/root/12T/GIG100.TXT b 3. Primele două numere de după numele executabilului sunt josul și susul intervalului de căutare numerică pe puteri de zece, apoi vine numele depozitului numeric de la ale cărui elemente se pleacă în căutare de noutăți, în sus sau în jos (* sau /), litera a înseamnă că se păstrează numele fișierului de rezultate așa cum l-am scris în codul declanșator (/run/media/root/480G/BOHAIDER.NUM2), iar dacă este b, atunci numele devine /run/media/root/480G/BOHAIDER2.NUM2, litera b fiind preferată în DIST2.TXT pentru căutările de după întrerupere, când fișierele de reluare trebuie să difere de primele (nu am voie să anexez ceva sau, mai rău, să suprascriu un fișier de rezultate deja oprit).
Câteodată fișierele cu 2 ajung ele însele vechi și nici litera b nu mă mai ajută să dau nume noi, atunci trebuie să schimb eu manual numele-sursă, iar alteori invers, mă ajută a dacă prima dată am dat cu b. 1 sau 4 este prima cifră cu care să înceapă de jos numerele, și în DIST2.TXT diferă de 1 de multe ori după o întrerupere.
Dacă pornesc din principiu o căutare într-un depozit numeric, este cu cifra 1 de la limita de jos (eventual de la jumătate) a LPT-ului sau a GIG-ului; prima cifră diferită de 1 face parte din anormal, la întrerupere (acum nu mi se mai repornește vreun sistem pe motiv de instabilitatea setărilor de overclocking, dar am avut două pene de curent în ultimele zile - sper să nu mai fie).
Funcția care redenumește cu 2 este REN3 din GMP64.h. Mai mult, acum fiecare fișier declanșator (inclusiv FACTORSUBM-urile și VECUNSUB) trebuie să pornească la drum în două trepte. Cum adică?
La argv, penultimul parametru trebuie să fie litera a sau b de mai sus, sub c (codul ASCII mai mic decât al literei „c”), și atunci se apelează funcția PREP1 din GMP64.h, unde se face din oficiu compilarea fișierului .cc și, mai departe, se relansează acest executabil - treapta a doua -, din primul executabil ieșindu-se cu return în main după apelul lui PREP1. La a doua treaptă, litera din argv crește cu două poziții, adică se face c sau d, și dacă este d din b, se apelează REN3.
De ce două trepte? Ca dacă am ceva de schimbat în fișierul declanșator sau trebuie să-i apelez executabilul din DIST2.TXT, să nu mai stau să scriu g++ în consolă, mai salvând timp; g++-ul se scrie în PREP1. Dacă vreau să pun în funcțiune un program, este suficient să scriu numele executabilului sau să-l copiez din DIST2 și mai departe g++-ul se face din oficiu.
La noul SLI PLUS 7740X-ul cel nou stă cu coolerul Arctic Liquid Freezer AC 360, 64 de GB de DDR4-3000 (ca anul trecut în august), cu un SSD SATA3 de 240 de GB și două hard disk-uri, unul de 2 TB, altul de 3 TB, placa video NVidia GT1030 de 2 GB, GDDR5.
La XPOWER GAMING 7980XE-ul nedelidded e cu coolerul EKWB, radiator cvadruplu EK Coolstream XE cu patru FF5 Vardare de 3000 de RPM, 128 de GB de DDR4-3333 (la 3400 rulează) și are un NVME PCI-E de 1 TB, plus șapte hard disk-uri: unul de 2 TB, unul de 4 TB, două de 5 TB și trei de 6 TB (i l-am pus și pe al treilea, da), placa video NVidia GT1030 de 2 GB ca la SLI PLUS, GDDR5.
La AORUS 7980XE-ul delidded stă cu alt cooler EKWB cu radiator Coolstream XE cvadruplu, patru Vardare FF5-120 ca la XPOWER, cu monoblock (la XPOWER este waterblock obișnuit), 128 de GB de DDR4-4000, un NVME PCI-E de 480 de GB, alt NVME PCI-E de 1024 de GB sau 1 TB cu cântec, un hard disk extern de 1000 de GB sau 1 TB (pentru numerele marginale, dar nu numai), un stick USB de 64 (61) de GB pentru numere (mai există stick-uri în casă, dar nu la numere), un SSD SATA3 de 1024 de GB sau alt 1 TB cu cântec, plus șase hard diskuri mari: două de 8 TB, două de 10 TB și două de 12 TB, placa video este Zotacul GT1030 de 2 GB, GDDR5.
Veritonul stă cu vechea lui configurație de i5-650, cu cooler comercial de la asamblare (stock), 16 GB de DDR3-1333, un hard disk SATA2 de 1 TB (1000 de GB) și placa video NVidia GT9500 de 1 GB, GDDR3 (sau 2?). Ziceam că el nu mai intră la numere.
În total, acum pentru numere stau 8500 + 5240 + 35000 + 63589 = 112329 de GB zecimali, cu ajustările de rigoare la spațiile partițiilor de pe discuri, sau vreo 112 TB.
Cu tot cu Veritonul și cele câteva IDE-uri vechi rămase în casă, sunt între 113 și 114 TB în casă.
Așadar, 112 TB pentru numere.
În continuarea așteptării Threadripperului de 32 de nuclee, pe 8 iulie 2018 a fost atins, în sfârșit, pragul de 25000 de numere, asta la fondul 1.
Pe 9 iulie sunt chiar 25006.
Mai urmează altele.
Am avut convingerea că mai există suficiente numere până la 25000 și chiar mai departe. Adunarea neîncetată de numere de fond 1 arată că povestea cu numerele chiar merită să continue, și-am să mai fac treabă pentru ca numerele să aibă foarte bune condiții de căutare și strângere a lor în fișiere, și ca hardware, și ca volum de lucru.
De aceea ar merita și un Threadripper în casă.
În System Monitor la Arch Linux, ar urma să se vadă șaizeci și patru de dreptunghiuri închipuind procesoarele virtuale, cu culori diferite.
Răcirea o vreau făcută tot cu piese de EKWB, radiator cvadruplu (unul nou), patru ventilatoare EK-Furious Vardar FF5-120, CryoFuel incolor (predistilat sau concentrat+cu apa mea distilată) și pompă DC Elite PWM cu rezervor de EK-RES 150 (sau poate altul potrivit). Va trebui ca într-una din zile să îmi fac iar curaj și să merg la ING ca să întreb cât credit mai am voie să fac, de astă dată direct pe cinci ani.
Toată tetrada știe că în N-uri sunt 25006 numere.
La 20 iulie 2018 sunt 25118 numere în fondul 1 și 115 TB alocați pentru numere (acum este și al doilea hard disk de 3 TB în casă, un Toshiba numit 3T, sus la Aorus).
66589 + 35000 + 8500 + 5240 GB (minus partiționarea) = 115329 de GB zecimali, fără TB-ul de la Veriton, care continuă să nu mai intre la numere.
Threadripper-ul s-ar putea să vină în septembrie. Sau în noiembrie dacă se mărește salariul.
S-ar putea ca al doilea credit să ia locul primului, înghițindu-l (credit de consum cu refinanțare) și, devenit unic credit mai mare, cu peste 30000 de lei rămași pot dota Threadripper-ul pe cinste.
Mai vedem cum merg numerele.
24 iulie: La ASUS PRIME am pus cel mai recent BIOS, pe 1401, și am mai făcut o reformă în codul numerelor, ca să fie fișiere speciale (DIST.TXT și DIST2.TXT) unde să fie, pentru fiecare program recent aflat în rulare, date despre fișierele implicate, intervalul de căutare, cât s-a mișcat programul în depozitul numeric ales (GIG sau LPT), direcția (sus sau jos, adică înmulțire ori împărțire) și intervalul factorilor de legătură folosiți - asta pentru DIST - și, în DIST2, tot pentru fiecare program recent, folderul și comanda de repornire din zona unde a fost întrerupt, ca în caz de cădere de curent sau repornire nedorită a vreunei mașinării din tetradă să pot, oarecum repede, repune în mișcare căutarea numerică de unde s-a întrerupt, și să știu bine cum se cheamă fiecare fișier, plus, dacă suprascriu între timp vreun NUMSIMPL sau MODPRIM(E) ori MODIFSUM (teoretic și pe altele), să știu din DIST.TXT, pentru fișierul de rezultate rămas în aer, cum căuta conform fișierului-generator care a fost suprascris (ca să pot relua și acolo căutarea, în pofida suprascrierii codului declanșator).
Fișierele text DIST și DIST2, aici implicate, se șterg și se populează cu date de fiecare dată când apelez RECONST-ul. RECONST.cc se bazează pe headerul GMP64.h, unde sunt niște metode speciale (RECIDENTE2, DIST2) prin care sunt atinse acele două fișiere de audit numeric; în afară de asta, fiecare NUMSIMPL, MODPRIM, MODSPRIM, MODIFSUM, HMODIFSUM, MODSPAR, MODPRIMSUM, MODPARSUM(E) și celelalte fișiere căutătoare pe care le-am reformat în 2018 trebuie să pregătească date pentru altă funcție din acel GMP64.h (RECIDENTE se cheamă), din ele trebuiesc trimise acolo, la prelucrare pentru mai departe, datele privind numele fișierului declanșator de căutare (NUMSIMPL.cc), numele executabilului (./numsimpl), folderul de unde se lansează (/NUMERIC/2/), numele fișierului mare de tip depozit numeric, din care se iau numerele de bază dinspre care se pleacă în căutare (/run/media/root/8TB/LPT120.LPT, /run/media/root/10T/GIG110.TXT), puterea de 10 de la care se pornește (110 de exemplu), cea la care trebuie ajuns (cum ar fi 120), cifra cu care să înceapă numerele de la puterea de 10 de plecare (1, de obicei, dar poate fi nevoie și de alta, mai ales când a fost întrerupere), numele fișierului cu rezultate numerice, cu tot cu locul unde este (/run/media/root/1TB/CAPARBIOBALD.NUM2), cât de mari sunt, în medie, numerele de la începutul fișierului de rezultate și de la sfârșitul lui și cât de mult s-a urcat (dacă în medie numerele de început au 109 cifre și încep cu 7, atunci jos 108 cu 7, iar dacă sus 116 cifre cu cifra 6 la început, atunci 116 cu 6, și atunci urcarea ar fi de tipul 7 cu 8, adică șapte ordine complete de mărime a puterii lui 10 între 108 și 116, iar în ordinul de mărime incomplet, cum 6 de sus este mai mic decât 7 de jos și nu se trece peste ordin, avem că 7 intră în 60 de opt ori), plus care a fost direcția de plecare a numerelor, în sus (dacă variabila „r” din fișierul declanșator este 1) sau în jos dacă r este 0, r fiind și el dat ca parametru la RECIDENTE, și limitele de jos și de sus ale numerelor prime (NUMSIMPL, MODPRIM) sau neprime (MODIFSUM) de legătură între numere, de pildă factori între 300 și 600, și atunci 300 și 600 se dau la RECIDENTE și ei.
Astfel, este mai ușor de reconstituit un traseu numeric dacă se întrerupe taman când nu trebuie.
Tot năzuiesc la Threadripper pentru mai încolo. Deocamdată nici nu a apărut.
Mai este și DIST.cc, menit să arate, pur și simplu, cât s-a urcat într-un fișier de rezultate numerice sau într-un depozit, de la început la sfârșit (de preferință să fie sortat crescător fișierul), tot așa, cu jos și cu sus & „urcă cu”, iar pentru el se apelează funcția DIST din GMP64.h (DIST2 este o variantă mai bine elaborată a lui DIST).
Fișierele de rezultate aflate în căutare curentă trebuie să aibă extensia .NUM2, iar după terminarea căutării (cu sau fără întrerupere, la întrerupere se reia cu alt nume de fișier*), le redenumesc cu .NUM1, apoi sortatorul crescător LITUAN le reschimbă în .NUM, ceea ce înseamnă că sunt gata de cules din ele rezultatele noi pentru depozite. La RECONST sunt căutate fișierele cu .NUM2.
*Apropo de schimbarea numelui unui fișier de rezultate, fiecare fișier-sursă declanșator trebuie apelat cu o listă de parametri la argv, și se spune de exemplu ./numsimpl 100 110 /run/media/root/8TB/LPTUAN110.LPT a 1 sau ./MODPRIME 90 100 /run/media/root/12T/GIG100.TXT b 3. Primele două numere de după numele executabilului sunt josul și susul intervalului de căutare numerică pe puteri de zece, apoi vine numele depozitului numeric de la ale cărui elemente se pleacă în căutare de noutăți, în sus sau în jos (* sau /), litera a înseamnă că se păstrează numele fișierului de rezultate așa cum l-am scris în codul declanșator (/run/media/root/480G/BOHAIDER.NUM2), iar dacă este b, atunci numele devine /run/media/root/480G/BOHAIDER2.NUM2, litera b fiind preferată în DIST2.TXT pentru căutările de după întrerupere, când fișierele de reluare trebuie să difere de primele (nu am voie să anexez ceva sau, mai rău, să suprascriu un fișier de rezultate deja oprit).
Câteodată fișierele cu 2 ajung ele însele vechi și nici litera b nu mă mai ajută să dau nume noi, atunci trebuie să schimb eu manual numele-sursă, iar alteori invers, mă ajută a dacă prima dată am dat cu b. 1 sau 4 este prima cifră cu care să înceapă de jos numerele, și în DIST2.TXT diferă de 1 de multe ori după o întrerupere.
Dacă pornesc din principiu o căutare într-un depozit numeric, este cu cifra 1 de la limita de jos (eventual de la jumătate) a LPT-ului sau a GIG-ului; prima cifră diferită de 1 face parte din anormal, la întrerupere (acum nu mi se mai repornește vreun sistem pe motiv de instabilitatea setărilor de overclocking, dar am avut două pene de curent în ultimele zile - sper să nu mai fie).
Funcția care redenumește cu 2 este REN3 din GMP64.h. Mai mult, acum fiecare fișier declanșator (inclusiv FACTORSUBM-urile și VECUNSUB) trebuie să pornească la drum în două trepte. Cum adică?
La argv, penultimul parametru trebuie să fie litera a sau b de mai sus, sub c (codul ASCII mai mic decât al literei „c”), și atunci se apelează funcția PREP1 din GMP64.h, unde se face din oficiu compilarea fișierului .cc și, mai departe, se relansează acest executabil - treapta a doua -, din primul executabil ieșindu-se cu return în main după apelul lui PREP1. La a doua treaptă, litera din argv crește cu două poziții, adică se face c sau d, și dacă este d din b, se apelează REN3.
De ce două trepte? Ca dacă am ceva de schimbat în fișierul declanșator sau trebuie să-i apelez executabilul din DIST2.TXT, să nu mai stau să scriu g++ în consolă, mai salvând timp; g++-ul se scrie în PREP1. Dacă vreau să pun în funcțiune un program, este suficient să scriu numele executabilului sau să-l copiez din DIST2 și mai departe g++-ul se face din oficiu.
Comentarii
Trimiteți un comentariu