Rusijos branduolinio tyrimų centro mokslininkai prajuokino pasaulį: vietoj to, kad kurtų branduolinį ginklą, pradėjo kriptovaliutų kasybą

Na va, galvojo pasipinigaus, o dabar matyt sušaudys,, arba darbams į Siberiją

Duos dar geresni kompa ir lieps mininti, kad galetu finansuoti savo nuclear program

Antraštė ir straipsnis nieko bendro.

kazkaip abejoju ar jie ten ka nors isminino ,viskas kas susija su branduolinem bombom, nepasikeite nuo saltojo karo,speju tuose kompose sukasi windows 95 geriausiu atveju

Tu straipsnio neskaitei 12 pasauli pagal galinguma.

"2011-aisiais ... 1 petafopo galingumo superkompiuteris, kuris tuo metu tapo 12 galingiausiu kompiuteriu pasaulyje". Blogiausia, kad *flopai kaip ir nesvarbu, ne jie hash'inge groja (spec hardwaro galia išvis flopais neskaičiuojama, nes net nežino kas tie skaičiai su kableliais). Gan kvailas būdas pažaisti ir tiek, greičiausiai norėjo pasigirti, padaryt kokį testą, o ne kažką "iškasti".

Prisikasė su valdiška įranga bitkoinų, dabar nuosavom rankelėm galės atidirbti anglių kasykloj.

Šiaip tai svarbu, labai netgi – nes ar flopai, ar hešavimas, tam reikia ir galingos magistralės, ir maitinimo, ir aušinimo. FLOPSai yra išvestinis dydis, retai jis reiškia kažką konkretaus – paprastai tai yra vektorinių operacijų kompleksai, kur tuos mistinius *FLOPSus gali išspausti vienam konkrečiam uždaviniui kaip PI skaičiavimas, matricų daugyba ar pirminumo testas. Tačiau naudojant esamus FP standartus, kiekvieną elementarią operaciją su sveikaženkle ar bitų aritmetika gali paraidžiui išversti į atitinkamą FP operaciją. Visa esmė, kiek FPU leidžia išjungti klaidų kontrolę, normalizaciją ir ribinių situacijų korekcijas. Tuo labiau, jei kriptografija pati paremta kokiom elipsinėm kreivėm, diskrečiaisiais logaritmais ar pirminių skaičių faktorizacija/daugyba. Čia su FPU gali konkuruoti nebent labai specializuotas HW.

galejo koki savo 4g interneta pajungti

Priklauso nuo HW. Man dar neteko girdeti apie toki CPU, kuris skaliarines ar vektorines FP operacijas ivykdytu greiciau nei integer. Tuo tarpu GPU yra optimizuoti butent FP load'ui ir ten, priklausomai nuo situacijos, FP operacijos gali buti greitesnes. Superkompiuteriai paprastai naudoja abu komponentus, tai viskas remtusi i tai, kaip konkreciai butu implementintas mine'ingo softas.

, o man neteko girdėti apie šiuolaikinį general-purpose FPU, kuris sveikų skaičių operacijas atliktų naudodamas daugiau taktų nei identiškos architektūros general-purpose CPU. Visas overhead'as susiveda į FP duomenų paruošimą, ribinių sąlygų patikrinimą, klaidų apdorojimą ir paklaidų korekcijas – kas šiaip algoritmų vidiniuose cikluose visuomet išjungiama. Klasikinis pavyzdys: Carmack'o fast inverse square root algoritmas, kai su tuo pačiu registru pakaitom elgiamasi tai kaip su float, tai kaip su int bitų seka. Galų gale, nepamiršk, kad IEEE-754 standartas yra sugalvotas būtent taip, kad visos FP operacijos tiesiogiai išsiverstų į atitinkamas „įprastos“ two's-complement integer aritmetikos operacijas, todėl, pvz., 64 bitų FP daugyba išvartoma į 80 bitų, kur mantisės sudauginamos pagal integer daugybos taisykles, eilei leidžiant overflowint. Tai reiškia, kad visos reikalingos integer ALU schemos procesoriuje jau yra, tereikia jas panaudoti be pre- ir post-procesinimo. Ir istoriškai, jei pažiūrėsim, iš kur Pentiumuose atsirado visokie SSE ir MMX – tai yra būtent 80387 koprocesoriaus integracijos į CPU pasekmė. Pirmiausia vektorinės operacijos buvo realizuotos būtent koprocesoriuje, ir tik paskui, kai programeriai pradėjo masiškai offloadinti „įprastas“ vektorines operacijas į FPU (pvz., teksto analizės), išryškėjo motyvas jas turėti pačiame baziniame CPU op-ų rinkinyje.

Nelabai supratau, kodel tu sulyginai general purpose FPU su CPU. Istoriskai tai gal ir validu, kai FPU ejo kaip ko-procesoriai, bet siuolaikiniai CPU savo konvejeriuose naudoja ir FPU, ir ALU blokus, kaip ir turi kruvas specializuotu extension'u, kurie konceptualiai atitinka istorinius vektorinius kompiuterius, bet siai dienai viskas suintegruota (nu neskaitant isoriniu DSP/FPGA ir pan, bet cia labiau custom). Cia nera prasmes kalbeti apie visiskai generic dalykus kaip IEEE-754 standarta ar FP in general. Viskas remsis i konkrecia uArch ir kaip joje viskas implementuota, bei kokius extension'us salia standartinio ISA ji palaiko. Tarkim, geras pavyzdys butu AMD Bulldozer seimos CPU, kurie 1 FPU share'indavo tarp dvieju hardware'iniu thread'u ir parareliniam FP load'e automatiskai buvo silpnesnis uz Intel analogus pagal thread skaiciu. As nebandziau irodyti, kad visur ir visada FP ops bus letesnes uz INT, bet man dar neteko matyti nei x86'to, nei MIPS'o, nei ARM'o, kur joms reiketu maziau taktu - geriausiu atveju tiek pat, dazniausiai daugiau, bet tai dar priklauso ir nuo konkrecios instrukcijos. Tai buvo mano point'as. As nesakau, kad FPU niekada negali greiciau ar taip pat graitai atlikti algoritmus, kurie by design dirba su integer. Bet tikrai nesutinku su tuo, kad FP tipiskai yra toks pats greitas. Case by case taip, bet tikrai ne tipiniu atveju. Net SSE/AVX ir pan. extension'ai turi explicityvias komandas INT tipui. Apie ka tu rasai, tai man cia labiau panasu i labai specifines optimizacijas specifiniai geleziai, kur kompiliatorius ar programeris rankytem ASM'u su INT tipu aprasyta source/algoritma isvarto i FP ISA'a masinini koda, nes per kazkuria vieta, kazka panaudojant gaunasi greiciau.

Man dar neteko matyti tokios n-bit FP realizacijos (pvz., sudėties operacijos), kuri savyje neturėtų n-bit int aritmetikos realizacijos. FP *visada* bus lėčiau nei int, nes int veiksmas visada yra tik dalis FP veiksmo (plius konversija iš FP į int ir iš int į FP). Kurią labai nesudėtinga išjungti, tarkim, operacijos flagais. Vadinasi, jei FPU sugeba per vieną taktą atlikti, tarkim 2 (!), 64-bit sandaugas, tai jis automatiškai sugeba atlikti per tą taktą 4 shr + 2 mul + 2 add + 4 shl operacijas su 64-bit intais, ir kiekvieną iš jų – ne lėčiau nei atitinkamas generic CPU be FP. Net jeigu tas FPU būtų nelogiškai primityvus ir jame būtų įhardkodinta, kad kiekviename 64bit žodyje 11 bitų skiriama eilei, tu jam šerk visus argumentus su exp=0 ir turėsi normalią 53 bitų two's-complement int aritmetiką, kurios performansas bus lygiai toks pats kaip 64 bit CPU. Floating point operacijų overheadas yra toks nykstamai mažas, lyginant su atitinkamom Fixed point (t.y. integer), kad jei ne patys gamybos ir eksploatacijos kaštai, gaminti integer ALU. FPU tiesiog turi žymiai įvairesnį aritmetinių operacijų rinkinį ir kur kas painesnį ribinių situacijų apdorojimą – pvz., jei dalybos iš 0 atveju paprastas CPU viso labo generuoja maskable interruptą, tai FPU pagal flagus jį ne tik maskuoja/nemaskuoja, bet dar ir handlina mikrokodo lygmeniu, stabdydamas tolesnius pipelines (+inf? -inf? 0/0? underflow?...). Bet, jei įjungsi maskavimą, FPU elgsis lygiai taip pat kaip primityvus ALU – užsettins klaidos flagą ir skaičiuos tolesnius veiksmus. Iš esmės, visas int operacijas su FPU gali atlikti praktiškai tokia pat sparta (ops/ins ir ops/ticks dažniu), kaip ir su analogišku ALU. 99,9% ar panašiai. Savaime suprantama, tai bus energijos švaistymas, nes neaktyvias schemos dalis vis tiek reikia užmaitinti ir aušinti. P.S. savaime suprantama, kad GPU, sulipdytas iš tūkstančių FPU-capable schemučių, yra ir žymiai brangesnis nei iš paprastų ALU. Tokių tiesiog neapsimokėtų gaminti, jei FP operacijos nebūtų naudojamos. Bet praktiškai visi nors kiek naujesni GPU jas šiaip ar taip naudoja – nes jos ir yra viso OpenGL/OpenCL/CUDA gerumo pamatas. P.P.S. Pavyzdukas, kai visiškai identiški veiksmai tam pačiam CPU atliekami greičiau naudojant FP: https://software.intel.com/en-us/forums ... pic/605167 . O čia atsakymas iš SO su konkrečiu pavyzdžiu, kaip FPU naudojamas diskrečioje crypto: https://crypto.stackexchange.com/questi ... n-integers . Konkretūs skaičiai apie daugybas/dalybas su paaiškinimais: https://www.quora.com/In-CPUs-how-much- ... -divisions . https://stackoverflow.com/questions/255 ... n-hardware Atskirų use-case komentaras iš Intel: https://software.intel.com/en-us/forums ... pic/306267

Visiskai sutinku su tavo argumentais. Mes truputi nesusikalbejome. Tu labiau rasai apie tai, kaip veikia pats FPU is HW puses, ir i ka issivarto ISA instrukcijos mikrokodo ar tranzistoriu lygyje. As labiau is programerio perspektyvos - apie ISA ir aukstesni lygi. Mano point'as tas, kad nepaisant to fakto, jog integer operacijom hardwarinis FPU gali veikti taip pat greitai, kaip ALU, dedikuotos ISA FP instrukcijos nera vykdomos greiciau, nei analogiskos operacijos dedikuotos INT instrukcijos. Arba taip pat greitai, arba leciau, o skaliariniams tipams beveik visada leciau tipiniu atveju. Naudojant extension'us ar specifiniams algoritmams gali buti ir atvirskiai - del to as taip pat nesigincijau, bet cia reikia analizuoti konkretu atveji, o ne "in general".

Cituoju tave: Dauguma modernių CPU yra tokie. Dėl pavienių FP operacijų niekas neoptimizuoja FPU pipeline, nes jį vien įsukti kainuoja nemenkai taktų. Kita vertus, CPU optimizuojami vykdyti daug procesų vienu metu, o jų algoritmai susukti tiek, kad naudingiau turėti daug nesusijusių general-purpose registrų lokaliems kintamiesiems nei juos kažkaip grupuoti matricų daugyboms. Dar vienas faktas: FPU turi savo vidinį fiksuoto dydžio operacijų steką, į kurio vidų sudėtinga lįsti, plg. su CPU general-purpose random access steku, RAMo cache. Išvada: koks nors stream cipher, net jei jis sudarytas vien iš integer operacijų, su šiuolaikiniais FPU turėtų veikti greičiau nei su CPU registrais ir ALU. O kalba tai prasidėjo – kad bitkoinus rusai mainina ant fizikinėms simuliacijoms skirto HW. Kas, mano nuomone, yra labai logiška. Be abejo, specializuoti čipai tam tiktų labiau. Apie tai buvo kitas straipsnis Technologijose. Ten institutų fizikai verkia, kad kriptovaliutų manija žlugdo general-purpose GPU ir FPU progresą.

Tai mes griztame prie to pacio - tu apie operacijas uArch lygyje, as ISA lygyje. Sakydamas "neteko girdeti", omenyje turejau, neteko girdeti, kad asemblerine instrukcija, pavyzdziui, dvieju float'u sandaugai butu ivykdoma greiciau, nei dvieju int'u, ar kazkokia SSE/AVX2 asemblerine instrukcija float vektoriui operacijai veiktu greiciau nei int vektoriui - tik tiek. Kitaip sakant, neteko girdeti, kad identiskai, tokio pacio bitu kiekio operacijai, asm'o instrukcija FP tipui butu greitesne nei INT tipui. Del visu vidiniu dalyku sutinku. Manau sita jau issiaiskinome. O kad del pacios temos - as irgi manau, kad labai logiska. Cia kiti mane, kad nelogiska As tik nesu toks zmogus, kuris tiki universaliom taisyklem. As tikiu konkreciais case'ais ir ju kontekstais - tai, kas galioja X86'tam su visokiais SSE/AVX'ais, nebutinai galioja reference design ARM ar MIPS core'ui, ir dar viskas priklauso nuo algoritmo, jau nesnekant apie naudojamus kompiliatorius/lib'us ir pacio softo implementavima. Anyway, is esmes sutinku su viskuo, ka tu rasei, tik mes "FP greiti" skirtingai interpretavome. PS. Malonu skaityti techniskai argumentuotus Tamstos post'us.

Bent jau Intelio architektūroje, dviejų floatų sandauga FMUL arba float*int FIMUL daugybai niekuo netrukdo, nes iš esmės tai yra paprastas multipleksavimas, į kurią registro skiltį turi atsistoti kuris mantisės bitas. O pačią rezultato eilę galima apskaičiuoti lygiagrečiai, net nelaukiant mantisių sudauginimo ir pernašų susumavimo. Nėra absoliučiai jokios techninės priežasties, dėl ko aparatiškai realizuota real*int arba real*real turėtų užtrukti ilgiau nei int*int. Overheadas dėl eilės korekcijos kompensuojasi su kaupu, jeigu paeiliui vykdomos kelios FPU komandos, o registrai turi pakankamai skilčių perpildymams (80 vs. 64 arba 64 vs. 32 ar pan.).

Priklauso nuo to, kaip apibresime pasakyma "dazniausiai" Uzmetus aki i x86 ASM suvestine (tarkime http://www.agner.org/optimize/instruction_tables.pdf) as nepasakyciau, kad pagal uops/latency/throughput metrikas FP instrukcijos butu vienareiksmiskai greitesnes. Labiau priesingai. Greitai sumesti praktiniai testai ta irgi parodo: http://nicolas.limare.net/pro/notes/201 ... rit_speed/ BET, darant prielaida, kad CPU seima gerai ismanantis zmogus handcraft'ins koda ASM lygyje (arba ta padarys vendor'iaus proprietary compiler'is), atliks visus tuos isjungimus, pritaikys optimaliai tinkancias instrukcijas ir "hack'us" sprendziamai problemai - taip, visiskai tikiu ir sutinku, kad imanoma isgauti didesni greiti.