Progresul hardware, episodul 65: Progrese hard-algoritmice de toamnă (septembrie 2018)
24 septembrie: Am pus acasă un nou portabil de 2 TB la XPOWER, și de acolo l-am mutat pe cel de 1 TB la Aorus, așa că în total XPOWER-ul are 1 TB de spațiu în plus, iar Aorusul încă unul (983.4 GB utilizabili, de fapt; de curând am mai făcut niște reforme algoritmice și am descoperit niște lucruri interesante despre spațiul real utilizabil).
În următoarele luni s-ar putea ca EKWB-ul să lanseze un waterblock Velocity și pentru Threadrippere, așa că pentru 2018-2019 am în vedere, pe lângă alte două HDD-uri noi de câte 10 TB (la XPOWER, cu rocadă către Aorus și Threadripper) plus măcar un NVME PCI-E nou de 1 TB pentru Threadripper, și un astfel de nou waterblock, tot pentru Threadripper, după ce va să apară. Progresul hardware trebuie să continue, împreună cu cel numeric și cel algoritmic, iar banii să devină mai mulți lună de lună, de aici încolo, pentru cumpărăturile de hardware și pentru alte lucruri necesare sau bune, inclusiv plata la timp a datoriilor pe care le-am făcut pentru acest progres.
Am reușit ceva și cu paralelizarea OMP (pentru CARONTE și chiar la NUMSIMPL în sus, deși apoi vedeam că a devenit mică rata de scriere de rezultate și aici, pe când la NUMSIMPL în jos, MODPRIME sus-jos și MODIFSUM în sus paralelizarea nu mai corupe datele numerice, dar viteza este chiar sub cea secvențială, nu știu de ce). Am încercat și cu schedule(static) și (dynamic) + (guided) la pragma omp parallel for-uri. La MODIFSUM în jos tot nu am reușit să scap de coruperea de numere, dar nici viteza nu este una bună. Pe la FACTORSUBM încă nu am încercat în noua formă, mai temeinică și recent cunoscută, care să nu strice numere (folosirea de mpz_t nou declarat, inițializat și apoi șters), dar ar fi destulă încărcare în plus pe-acolo (Overhead) și nici nu știu dacă aș reuși algoritmic, cum nu am reușit ieri la MODIFSUM în jos.
Dar măcar avem CARONTELE și chiar NUMSIMPL în sus.
Ce am mai făcut aste zile: am optimizat RECONST-ul ca să pună în partea de sus a fișierelor de audit numeric DIST.TXT, DIST2.TXT, DIST3.TXT și REC.sh acele programe (și fișiere cu rezultate, în primul rând, pentru DIST.TXT) care au urcat cele mai multe unități de mărime zecimală*, iar cele cu .NUM2-uri care au progresat mai puțin să stea jos.
*Adică grupe de număr de cifre, în baza 10. De exemplu, dacă avem /GHIDALS.NUM2 și el a început cu numere de 161 de cifre, iar la apelul de RECONST are numere de 174 de cifre, înseamnă că a urcat treisprezece unități zecimale, și la rândul lor și aceste unități sunt sub-zecimalizate: dacă numerele de 161 de cifre aveau prima cifră 3**, iar cele de 174 o au 8, atunci avem 13 unități cu parte întreagă inferioară din 8/3, anume 13 cu 2.
**În medie, așa cum sunt verificate în funcția DIST2() din /GMP64.h. La partea de început a fișierului se parcurg primele 240 de numere, dar fișierul trebuie să aibă minim 108000 de caractere, și se face media primei lor cifre. Se iau apoi ultimele 108000 de caractere de la sfârșitul fișierului și se parcurg și de acolo alte 240 de numere (fără primul, dacă este trunchiat de cursarea la PP-108000, unde PP este dimensiunea curentă totală a fișierului, și de asemenea se taie ultimul număr citit, dacă s-a ajuns prea aproape de dimensiunea totală citită, pentru suspiciuni de trunchiere a numărului, astfel ca să fim siguri că numerele sunt complete; algoritmul este în continuare perfectibil, pot fi sub 240 de numere în ambele cazuri, dar din câte sunt, și de preferință complete, se face media primei cifre).
Am mai umblat la CIRCE.h, headerul lui CIRCENTE.cc, care să-mi citească spațiul liber total de pe discurile din calculatorul curent (sunt 5, cu Veritonul chiar șase...), spațiul liber cel mai mare de pe un disc, ca acolo să se scrie segmentele fișierelor prea mari pentru memoria calculatorului, capacitatea utilizabilă a fiecărui disc în parte (suma lor fiind spațiul total utilizabil din mașinăria respectivă) și totalul spațiului liber curent folosibil, plus procentul acestuia și cel al spațiului ocupat, suma lor fiind 100 și ele fiind raportate la spațiul UTILIZABIL.
Care spațiu utilizabil este mai mic decât capacitatea nominală (comercială) a fiecărui hard disk, NVME, SSD SATA-3, USB-ul de 61 de GB de la Aorus; formatarea Linux Ext4 răpește din spațiu la fiecare, de exemplu la cele două hard diskuri de 14 TB (poate că în 2019 vine și al treilea) sunt folosibili 13889 de GB zecimali din fiecare, nu 14000, iar la cele patru de 12 TB (hai cu 2019 la mai mare...) sunt cam 11904 folosibili la fiecare, s-ar spune că pentru fiecare 2 TB de spațiu se scad aproape 16 GB pentru ext4, dar scăderea asta este și pe la portabilul de 1 TB sau SSD-ul SATA3 de 1 TB, pe când la cele două portabile de 2 TB, pesemne, se scad vreo 32; la unul de 4 TB am văzut vreo 64 scăzuți sau 3936 desponibili, dar tot cam așa cu 7936 la 8 TB.
Am făcut un calcul amănunțit pentru discurile care totalizau nominal, împreună, 181329 sau 181330 de GB zecimali (fără Hitachi-ul de 1 TB al Veritonului, acum partiționat și el în 513 GB pentru Windows și alți 400 și ceva pentru Arch Linux, plus vreo 100 de MB (ce puțin) pentru boot loader-ul NTFS al Windows-ului, cel de FAT pentru Arch Linux fiind pe un stick USB), cu ajutorul noilor date pe care le dădea CIRCENTELE, și am văzut că totalul folosibil, scăzând și de aici gigabaiții specifici ocupați de cele cinci Arch Linuxuri, era de „doar” 179625 de GB zecimali, ca atare mi-am luat al doilea portabil de 2 TB acum (din care și el cu 1967 de GB...), al treilea portabil în general, cu tot cu cel de 1 TB pus la Aorus, încât acum sunt două Maxtor-uri (Seagate, atenție) de câte 2 TB și un A-DATA de 1 TB, ca hard diskuri portabile legate prin USB de unitatea centrală implicată - primul Maxtor la Threadripper, al doilea la XPOWER (unde săptămâna viitoare trebuie să montez cu multă atenție un waterblock Velocity și să văd de tuburi și de lichid) și A-DATA-ul la Aorus, iar spațiul total folosibil la cele cinci calculatoare asamblate este peste 180000 de GB cu adevărat, acum; 181592 ar fi, și cu încă două de câte 10 TB (9920 + 9920) până în 2019 (poate până la 31 decembrie, cu bani mai mulți câștigați în ultimul trimestru din 2018, și cu tot cu eventualul waterblock Velocity nou pentru Threadripper, care încă nu se vede anunțat pe la EKWB), țintesc să trec și de cel de 200000 de GB folosibili la numere, chiar peste gigabaiții separați ocupați în mod specific de cele cinci sisteme Arch Linux (ăștia nu sunt foarte mulți, ce-i drept). Plus ceea ce este la Veriton.
La Veriton, categoric NU este loc de GIG-uri, nici măcar de GIG52.TXT; aș putea totuși să extrag din GIG52, la un moment dat, acele numere care au cel mai mare divizor impar mai mic decât 2 la puterea 64 și să fac din ele un fișier, ca un mini-GIG, și din ele să caut numere prin înmulțiri și împărțiri cu factori de legătură, în regim NUMSIMPL/MODPRIM/MODIFSUM. Asta înseamnă să pun acel mini-GIG pe discul de 500 de GB aflat acum la SLI PLUS, calculatorul unde stă și GIG52.TXT, și să-l mut puțin la Veriton numai cât să copiez de pe el pe Hitachi acel mini-GIG, apoi 500GB înapoi la SLI PLUS... sau chiar și mai și, de oriunde în SLI PLUS ar fi mini-GIG-ul, să nu scot niciun disc din SLI PLUS, dar mini-GIG-ul să îl trimit la Veriton prin TeamViewer (...și dacă are prea mulți GB? Ar dura mult; aș putea să folosesc fugitiv MARG-ul de 1 TB de la Aorus, detașabil imediat prin USB, deși și de acolo am văzut copieri care durau mult, apoi înapoi cu el la Aorus).
Totuși numerele cu cel mai mare divizor impar încadrabil în 64 de biți fără semn (asta înseamnă mai mic decât 2 la 64) nu pot fi foarte, foarte multe, și majoritatea lor incontestabilă sub 30 de cifre, puține mai mari, așa cum îmi amintesc din anul 2010. Cele mai mari pot fi între 30 și 40 de cifre, al nouălea număr perfect și acoliții lui abundențiali, de exemplu, el având 37 de cifre și divizorul său impar fiind cu 1 mai mic decât 2 la puterea 61; dar majoritatea sub 30, chiar sub 25 de cifre. Acum GIG52.TXT are ceva mai mult de 1100 de GB zecimali, dar majoritatea lui cantitativă este peste 35-40 de cifre, adică tocmai dincolo de limitele majorității numerelor cu divizor impar mic.
Mini-GIG-ul (posibil GIGM.TXT) nu poate avea jumătate de TB, incontestabil, și posibil să nu facă nici măcar 100 de GB, ar încăpea în mod sigur la Veriton pe Hitachi. Sigur, ar fi o submulțime a numerelor din SLI PLUS, dar acolo sunt mai de interes, la GIG52, tot numerele mai mari, între 40 și 52 de cifre, poate mai găsesc ceva nou de fond 1 (deși din nefericire sunt atât de slabe speranțe, noutățile de fond 1 lipsind de ceva vreme chiar și de pe la GIG70, chiar 80 - astea două sunt la XPOWER). Dar poate că mai găsesc noutăți și la 40-52 de cifre, și dedesubt. Trebuie să insist și să rafinez căutările, plus extindere de câmp de numere prime și de puteri de apariție ale lor. Pentru moment, forța hardware din casă ESTE una mare pentru numere, dar sufletul meu caută mai departe mai binele, de aici și nevoia unor bani mai mulți pentru alte viitoare îmbunătățiri, și am tot văzut cum mai este loc de îmbunătățiri și în codul algoritmic.
O posibilă cale pentru îmbunătățire și în carieră (cea cu banii) este să caut să țin ceva mai aproape cu colegii.
De asemenea, tot la CIRCENTE, fișierele mari se scriu în segmente potrivite de la sfârșit către început, discul cu cel mai mult spațiu liber este acum depistat automat mai sus, la începutul programului, trunchierea fișierelor mari făcându-se acum progresiv, pentru fiecare fișier tăindu-se dinspre sfârșit segment cu segment, pe măsură ce este scris noul segment, așa că nu se mai așteaptă, pentru un fișier de 700 de miliarde de octeți, ca ultimele 590 de miliarde de octeți să fie întâi scrise în locul spațios, ca abia apoi fișierul să fie trunchiat la 110 miliarde; pragurile segmentelor noi sunt, dinspre sfârșit spre început, la 700 de miliarde, 40 fiind pentru primul segment, apoi la 660, cu 110 în următorul*, la 550 tot cu 110, la 440, 330 și 220, primele 110 find dimensiunea finală a fișierului de origine.
Dar trunchierea progresivă a fișierului original face ca, de exemplu, când primele 589 de miliarde din 590 ale segmentelor sunt deja gata, vechiul fișier să mai ocupe doar 220 de miliarde de octeți în calculator, în loc de toate 700 (cu trunchiere apoi, când 590 de mai sus este gata; oricum trunchierea originii la 110 se face când restul de 590 sunt puse deoparte), astfel că din mers se salvează spațiu liber în plus pe calculator.
De asemenea, ar mai trebui ca, periodic, pe timpul CIRCENTELUI, să re-verific care mai este acum discul mai spațios, ca să pun următoarele segmente acolo (din următorul fișier mare sau chiar din cel curent, mai cu seamă dacă spațiul discului spațios deja ales a scăzut sub un anume prag; și să fie ales următorul cel mai spațios disc rămas, dacă alesul curent a pierdut această calitate, cu atât mai urgent dacă spațiul lui a ajuns sub un prag de alarmă).
*Nu sunt neapărat fix 110 miliarde** de octeți pe segment sau în ce rămâne din fișierul original, chiar făcând abstracție de cazul segmentului de la sfârșit, considerat oricum a se încadra sub 110 miliarde; oricare segment neterminal și fișierul original rămân cu dimensiuni diferite de fix 110 miliarde de octeți, atunci când dimensiunea asta fixă presupune trunchierea unui număr. Dacă în fișierul respectiv, original sau segment, la poziția 110000000000 se termină abia 59 de cifre dintr-un număr de 95 de cifre, atunci numărul este păstrat până la capăt și dimensiunea fișierului va fi 110000000036.
**Valoarea asta ține seama de memoria de 128 de GB, cu posibilitatea ca în unele cazuri programul care va sorta crescător fișierul să folosească chiar niște octeți în plus față de dimensiunea fișierului, deși de obicei la LITUAN sunt mai puțini GB decât în dimensiunea fișierului, tocmai pentru că mepezetelele sunt stocate economic în memorie, dar mai apar excepții; și atunci, o memorie ocupată cu peste 110 miliarde de octeți atentează serios la capacitatea totală de memorie a calculatorului. La SLI PLUS, memoria este pe jumătate (64), și acolo mai apare un fenomen interesant - la sortarea numerelor cu mai puține cifre, sub 40 de exemplu, în memorie la LITUAN se ocupă serios mai mulți GB decât dimensiunea pe disc a zonei numerice loate în seamă, așa încât la CIRCENTE dimensiunea rației trebuie făcută chiar ceva mai mică în raport cu 64 de GB, față de cum este 110 miliarde sub 128 de GB - de pildă 40 sau chiar 35 ori 30 de miliarde (chiar și mai jos, excepțional) față de 64 de GB, o proporție de scădere care evident nu este aceeași ca la 110 miliarde cu 128 de GB. La numere diferite, abordări diferite.
Verificarea aceea cu spațiul la circentizare se poate face după terminarea segmentării unui fișier mare, de pildă. Dacă pe timpul segmentării discul ales a ajuns la spațiul zero, măcar se verifică dimensiunea noilor segmente, și dacă se ajunge la vreun zero sau la dimensiune finală de segment mai mică decât cea așteptată, chiar și nenulă, atunci, în algoritmul curent de circentizare, nu se mai trunchiază fișierul de origine, incident care înainte a apărut de câteva ori și s-a lăsat cu supărare.
Și dacă discul curent nu mai este cel mai spațios, sau mai degrabă când a ajuns cu spațiul cam mic, să se mute circentizarea pe discul cel mai spațios rămas acum, cu segmentele unui nou fișier mare, fără amestecarea locurilor segmentelor unui același fișier mare. Alt lucru interesant este să se verifice la începtul lucrului cu fiecare fișier mare dacă spațiul de pe discul curent ales ca spațios nu a ajuns cumva mai mic decât dimensiunea marelui fișier MINUS rația cu care el va rămâne (anume 590 din cele 700 de miliarde de mai sus, sau spațiul segmentelor), și dacă este mai mic spațiul, atunci să se aleagă adevăratul cel mai spațios disc de acum, pentru fișierul unde trebuie început lucrul (și cu următoarele, dacă mai încap).
În următoarele luni s-ar putea ca EKWB-ul să lanseze un waterblock Velocity și pentru Threadrippere, așa că pentru 2018-2019 am în vedere, pe lângă alte două HDD-uri noi de câte 10 TB (la XPOWER, cu rocadă către Aorus și Threadripper) plus măcar un NVME PCI-E nou de 1 TB pentru Threadripper, și un astfel de nou waterblock, tot pentru Threadripper, după ce va să apară. Progresul hardware trebuie să continue, împreună cu cel numeric și cel algoritmic, iar banii să devină mai mulți lună de lună, de aici încolo, pentru cumpărăturile de hardware și pentru alte lucruri necesare sau bune, inclusiv plata la timp a datoriilor pe care le-am făcut pentru acest progres.
Am reușit ceva și cu paralelizarea OMP (pentru CARONTE și chiar la NUMSIMPL în sus, deși apoi vedeam că a devenit mică rata de scriere de rezultate și aici, pe când la NUMSIMPL în jos, MODPRIME sus-jos și MODIFSUM în sus paralelizarea nu mai corupe datele numerice, dar viteza este chiar sub cea secvențială, nu știu de ce). Am încercat și cu schedule(static) și (dynamic) + (guided) la pragma omp parallel for-uri. La MODIFSUM în jos tot nu am reușit să scap de coruperea de numere, dar nici viteza nu este una bună. Pe la FACTORSUBM încă nu am încercat în noua formă, mai temeinică și recent cunoscută, care să nu strice numere (folosirea de mpz_t nou declarat, inițializat și apoi șters), dar ar fi destulă încărcare în plus pe-acolo (Overhead) și nici nu știu dacă aș reuși algoritmic, cum nu am reușit ieri la MODIFSUM în jos.
Dar măcar avem CARONTELE și chiar NUMSIMPL în sus.
Ce am mai făcut aste zile: am optimizat RECONST-ul ca să pună în partea de sus a fișierelor de audit numeric DIST.TXT, DIST2.TXT, DIST3.TXT și REC.sh acele programe (și fișiere cu rezultate, în primul rând, pentru DIST.TXT) care au urcat cele mai multe unități de mărime zecimală*, iar cele cu .NUM2-uri care au progresat mai puțin să stea jos.
*Adică grupe de număr de cifre, în baza 10. De exemplu, dacă avem /GHIDALS.NUM2 și el a început cu numere de 161 de cifre, iar la apelul de RECONST are numere de 174 de cifre, înseamnă că a urcat treisprezece unități zecimale, și la rândul lor și aceste unități sunt sub-zecimalizate: dacă numerele de 161 de cifre aveau prima cifră 3**, iar cele de 174 o au 8, atunci avem 13 unități cu parte întreagă inferioară din 8/3, anume 13 cu 2.
**În medie, așa cum sunt verificate în funcția DIST2() din /GMP64.h. La partea de început a fișierului se parcurg primele 240 de numere, dar fișierul trebuie să aibă minim 108000 de caractere, și se face media primei lor cifre. Se iau apoi ultimele 108000 de caractere de la sfârșitul fișierului și se parcurg și de acolo alte 240 de numere (fără primul, dacă este trunchiat de cursarea la PP-108000, unde PP este dimensiunea curentă totală a fișierului, și de asemenea se taie ultimul număr citit, dacă s-a ajuns prea aproape de dimensiunea totală citită, pentru suspiciuni de trunchiere a numărului, astfel ca să fim siguri că numerele sunt complete; algoritmul este în continuare perfectibil, pot fi sub 240 de numere în ambele cazuri, dar din câte sunt, și de preferință complete, se face media primei cifre).
Am mai umblat la CIRCE.h, headerul lui CIRCENTE.cc, care să-mi citească spațiul liber total de pe discurile din calculatorul curent (sunt 5, cu Veritonul chiar șase...), spațiul liber cel mai mare de pe un disc, ca acolo să se scrie segmentele fișierelor prea mari pentru memoria calculatorului, capacitatea utilizabilă a fiecărui disc în parte (suma lor fiind spațiul total utilizabil din mașinăria respectivă) și totalul spațiului liber curent folosibil, plus procentul acestuia și cel al spațiului ocupat, suma lor fiind 100 și ele fiind raportate la spațiul UTILIZABIL.
Care spațiu utilizabil este mai mic decât capacitatea nominală (comercială) a fiecărui hard disk, NVME, SSD SATA-3, USB-ul de 61 de GB de la Aorus; formatarea Linux Ext4 răpește din spațiu la fiecare, de exemplu la cele două hard diskuri de 14 TB (poate că în 2019 vine și al treilea) sunt folosibili 13889 de GB zecimali din fiecare, nu 14000, iar la cele patru de 12 TB (hai cu 2019 la mai mare...) sunt cam 11904 folosibili la fiecare, s-ar spune că pentru fiecare 2 TB de spațiu se scad aproape 16 GB pentru ext4, dar scăderea asta este și pe la portabilul de 1 TB sau SSD-ul SATA3 de 1 TB, pe când la cele două portabile de 2 TB, pesemne, se scad vreo 32; la unul de 4 TB am văzut vreo 64 scăzuți sau 3936 desponibili, dar tot cam așa cu 7936 la 8 TB.
Am făcut un calcul amănunțit pentru discurile care totalizau nominal, împreună, 181329 sau 181330 de GB zecimali (fără Hitachi-ul de 1 TB al Veritonului, acum partiționat și el în 513 GB pentru Windows și alți 400 și ceva pentru Arch Linux, plus vreo 100 de MB (ce puțin) pentru boot loader-ul NTFS al Windows-ului, cel de FAT pentru Arch Linux fiind pe un stick USB), cu ajutorul noilor date pe care le dădea CIRCENTELE, și am văzut că totalul folosibil, scăzând și de aici gigabaiții specifici ocupați de cele cinci Arch Linuxuri, era de „doar” 179625 de GB zecimali, ca atare mi-am luat al doilea portabil de 2 TB acum (din care și el cu 1967 de GB...), al treilea portabil în general, cu tot cu cel de 1 TB pus la Aorus, încât acum sunt două Maxtor-uri (Seagate, atenție) de câte 2 TB și un A-DATA de 1 TB, ca hard diskuri portabile legate prin USB de unitatea centrală implicată - primul Maxtor la Threadripper, al doilea la XPOWER (unde săptămâna viitoare trebuie să montez cu multă atenție un waterblock Velocity și să văd de tuburi și de lichid) și A-DATA-ul la Aorus, iar spațiul total folosibil la cele cinci calculatoare asamblate este peste 180000 de GB cu adevărat, acum; 181592 ar fi, și cu încă două de câte 10 TB (9920 + 9920) până în 2019 (poate până la 31 decembrie, cu bani mai mulți câștigați în ultimul trimestru din 2018, și cu tot cu eventualul waterblock Velocity nou pentru Threadripper, care încă nu se vede anunțat pe la EKWB), țintesc să trec și de cel de 200000 de GB folosibili la numere, chiar peste gigabaiții separați ocupați în mod specific de cele cinci sisteme Arch Linux (ăștia nu sunt foarte mulți, ce-i drept). Plus ceea ce este la Veriton.
La Veriton, categoric NU este loc de GIG-uri, nici măcar de GIG52.TXT; aș putea totuși să extrag din GIG52, la un moment dat, acele numere care au cel mai mare divizor impar mai mic decât 2 la puterea 64 și să fac din ele un fișier, ca un mini-GIG, și din ele să caut numere prin înmulțiri și împărțiri cu factori de legătură, în regim NUMSIMPL/MODPRIM/MODIFSUM. Asta înseamnă să pun acel mini-GIG pe discul de 500 de GB aflat acum la SLI PLUS, calculatorul unde stă și GIG52.TXT, și să-l mut puțin la Veriton numai cât să copiez de pe el pe Hitachi acel mini-GIG, apoi 500GB înapoi la SLI PLUS... sau chiar și mai și, de oriunde în SLI PLUS ar fi mini-GIG-ul, să nu scot niciun disc din SLI PLUS, dar mini-GIG-ul să îl trimit la Veriton prin TeamViewer (...și dacă are prea mulți GB? Ar dura mult; aș putea să folosesc fugitiv MARG-ul de 1 TB de la Aorus, detașabil imediat prin USB, deși și de acolo am văzut copieri care durau mult, apoi înapoi cu el la Aorus).
Totuși numerele cu cel mai mare divizor impar încadrabil în 64 de biți fără semn (asta înseamnă mai mic decât 2 la 64) nu pot fi foarte, foarte multe, și majoritatea lor incontestabilă sub 30 de cifre, puține mai mari, așa cum îmi amintesc din anul 2010. Cele mai mari pot fi între 30 și 40 de cifre, al nouălea număr perfect și acoliții lui abundențiali, de exemplu, el având 37 de cifre și divizorul său impar fiind cu 1 mai mic decât 2 la puterea 61; dar majoritatea sub 30, chiar sub 25 de cifre. Acum GIG52.TXT are ceva mai mult de 1100 de GB zecimali, dar majoritatea lui cantitativă este peste 35-40 de cifre, adică tocmai dincolo de limitele majorității numerelor cu divizor impar mic.
Mini-GIG-ul (posibil GIGM.TXT) nu poate avea jumătate de TB, incontestabil, și posibil să nu facă nici măcar 100 de GB, ar încăpea în mod sigur la Veriton pe Hitachi. Sigur, ar fi o submulțime a numerelor din SLI PLUS, dar acolo sunt mai de interes, la GIG52, tot numerele mai mari, între 40 și 52 de cifre, poate mai găsesc ceva nou de fond 1 (deși din nefericire sunt atât de slabe speranțe, noutățile de fond 1 lipsind de ceva vreme chiar și de pe la GIG70, chiar 80 - astea două sunt la XPOWER). Dar poate că mai găsesc noutăți și la 40-52 de cifre, și dedesubt. Trebuie să insist și să rafinez căutările, plus extindere de câmp de numere prime și de puteri de apariție ale lor. Pentru moment, forța hardware din casă ESTE una mare pentru numere, dar sufletul meu caută mai departe mai binele, de aici și nevoia unor bani mai mulți pentru alte viitoare îmbunătățiri, și am tot văzut cum mai este loc de îmbunătățiri și în codul algoritmic.
O posibilă cale pentru îmbunătățire și în carieră (cea cu banii) este să caut să țin ceva mai aproape cu colegii.
De asemenea, tot la CIRCENTE, fișierele mari se scriu în segmente potrivite de la sfârșit către început, discul cu cel mai mult spațiu liber este acum depistat automat mai sus, la începutul programului, trunchierea fișierelor mari făcându-se acum progresiv, pentru fiecare fișier tăindu-se dinspre sfârșit segment cu segment, pe măsură ce este scris noul segment, așa că nu se mai așteaptă, pentru un fișier de 700 de miliarde de octeți, ca ultimele 590 de miliarde de octeți să fie întâi scrise în locul spațios, ca abia apoi fișierul să fie trunchiat la 110 miliarde; pragurile segmentelor noi sunt, dinspre sfârșit spre început, la 700 de miliarde, 40 fiind pentru primul segment, apoi la 660, cu 110 în următorul*, la 550 tot cu 110, la 440, 330 și 220, primele 110 find dimensiunea finală a fișierului de origine.
Dar trunchierea progresivă a fișierului original face ca, de exemplu, când primele 589 de miliarde din 590 ale segmentelor sunt deja gata, vechiul fișier să mai ocupe doar 220 de miliarde de octeți în calculator, în loc de toate 700 (cu trunchiere apoi, când 590 de mai sus este gata; oricum trunchierea originii la 110 se face când restul de 590 sunt puse deoparte), astfel că din mers se salvează spațiu liber în plus pe calculator.
De asemenea, ar mai trebui ca, periodic, pe timpul CIRCENTELUI, să re-verific care mai este acum discul mai spațios, ca să pun următoarele segmente acolo (din următorul fișier mare sau chiar din cel curent, mai cu seamă dacă spațiul discului spațios deja ales a scăzut sub un anume prag; și să fie ales următorul cel mai spațios disc rămas, dacă alesul curent a pierdut această calitate, cu atât mai urgent dacă spațiul lui a ajuns sub un prag de alarmă).
*Nu sunt neapărat fix 110 miliarde** de octeți pe segment sau în ce rămâne din fișierul original, chiar făcând abstracție de cazul segmentului de la sfârșit, considerat oricum a se încadra sub 110 miliarde; oricare segment neterminal și fișierul original rămân cu dimensiuni diferite de fix 110 miliarde de octeți, atunci când dimensiunea asta fixă presupune trunchierea unui număr. Dacă în fișierul respectiv, original sau segment, la poziția 110000000000 se termină abia 59 de cifre dintr-un număr de 95 de cifre, atunci numărul este păstrat până la capăt și dimensiunea fișierului va fi 110000000036.
**Valoarea asta ține seama de memoria de 128 de GB, cu posibilitatea ca în unele cazuri programul care va sorta crescător fișierul să folosească chiar niște octeți în plus față de dimensiunea fișierului, deși de obicei la LITUAN sunt mai puțini GB decât în dimensiunea fișierului, tocmai pentru că mepezetelele sunt stocate economic în memorie, dar mai apar excepții; și atunci, o memorie ocupată cu peste 110 miliarde de octeți atentează serios la capacitatea totală de memorie a calculatorului. La SLI PLUS, memoria este pe jumătate (64), și acolo mai apare un fenomen interesant - la sortarea numerelor cu mai puține cifre, sub 40 de exemplu, în memorie la LITUAN se ocupă serios mai mulți GB decât dimensiunea pe disc a zonei numerice loate în seamă, așa încât la CIRCENTE dimensiunea rației trebuie făcută chiar ceva mai mică în raport cu 64 de GB, față de cum este 110 miliarde sub 128 de GB - de pildă 40 sau chiar 35 ori 30 de miliarde (chiar și mai jos, excepțional) față de 64 de GB, o proporție de scădere care evident nu este aceeași ca la 110 miliarde cu 128 de GB. La numere diferite, abordări diferite.
Verificarea aceea cu spațiul la circentizare se poate face după terminarea segmentării unui fișier mare, de pildă. Dacă pe timpul segmentării discul ales a ajuns la spațiul zero, măcar se verifică dimensiunea noilor segmente, și dacă se ajunge la vreun zero sau la dimensiune finală de segment mai mică decât cea așteptată, chiar și nenulă, atunci, în algoritmul curent de circentizare, nu se mai trunchiază fișierul de origine, incident care înainte a apărut de câteva ori și s-a lăsat cu supărare.
Și dacă discul curent nu mai este cel mai spațios, sau mai degrabă când a ajuns cu spațiul cam mic, să se mute circentizarea pe discul cel mai spațios rămas acum, cu segmentele unui nou fișier mare, fără amestecarea locurilor segmentelor unui același fișier mare. Alt lucru interesant este să se verifice la începtul lucrului cu fiecare fișier mare dacă spațiul de pe discul curent ales ca spațios nu a ajuns cumva mai mic decât dimensiunea marelui fișier MINUS rația cu care el va rămâne (anume 590 din cele 700 de miliarde de mai sus, sau spațiul segmentelor), și dacă este mai mic spațiul, atunci să se aleagă adevăratul cel mai spațios disc de acum, pentru fișierul unde trebuie început lucrul (și cu următoarele, dacă mai încap).
Comentarii
Trimiteți un comentariu