Slo-Tech - AMD-jev najobširnejši procesor ta hip je Ryzen Threadripper W2990X, ki ima 32 jeder. Že to je zavidanja vredna številka, a AMD za letos načrtuje še zmogljivejši procesor. Po podatkih Wccftecha bomo še pred koncem leta dobili procesor, ki bo imel 64 jeder, torej bo lahko hkrati poganjal 128 niti. Procesorji AMD Ryzen Threadripper tretje generacije naj bi bili tudi združljivi z obstoječimi podnožji, tako da bodo obstoječe matične plošče (TR4) potrebovale zgolj kakšno nadgradnjo firmwara.
Seveda orjaški novinec ne bo poceni. Pričakovana cena je med 2500 in 3000 dolarji, kar pa je še vedno zelo ugodno za toliko jeder. Intelovi 18-jedrniki trenutno stanejo okrog 1800 dolarjev, torej bo AMD-jev procesor na število jeder dvakrat cenejši. Tudi W2990x s 1500 dolarji je cenejši od Intelovih procesorjev. Mimogrede, 28-jedrni Xeon stane 8000 dolarjev. Iz AMD-ja uradnih novic seveda še ni in jih tudi še lep čas ne bo. Morda kaj več izvemo na IFA 2019, zagotovo pa na CES 2020, pravijo viri blizu podjetja.
Pa bo 4 kanalni kontroler dovolj za futrat 64 jeder? Recimo avx porabi dobrih 20GB/s na jedro...
The reason why most of society hates conservatives and
loves liberals is because conservatives hurt you with
the truth and liberals comfort you with lies.
A je po 10 letih dejansko kaj napredka v paralelnem programiranju? Namreč, še vedno je omejeno na nišne področja uporabe. V smislu običnega uporabnika kje točno je viden napredek paralelizacije?
There will be chutes!
It came from the lab.
Like tears in rain. Time to die. v_1 2012-21
Počakaj, če pride glede na govorice ZEN 3 z 3 nitmi na jedro. Šele potem bodo tole PR nebesa. Potem pač bomo na bolhi prodajali odvečna jedra...
Og kje ti to? 3 niti na jedro?
Govorice od enega inženirja. Seveda uporabi...
Malo soli
Mogoče gre za FANBOY mokre želje. https://www.reddit.com/r/Amd/comments/b... Seveda INTEL ima podobno tehnologijo že v uporabi. Tako ,da izvedljivo. Če pa je vredno pa je drugo vprašanje. Mogoče 10%-30% performanse v idelani SW prijazni situaciji. Definitivno izziv za programerje.
To so najbolj divje govorice. Drugače je bolj verjetno, da bo ZEN 3 prinesel: DDR5 in mogoče 6nm ali 7nm+ definitivno. ZEN 4 pa se govori, da bo večslojni dizajn na eni rezini. Podobno, kot Intelov prihajajoči Sunny Cove. Plus 5nm proces.
The reason why most of society hates conservatives and
loves liberals is because conservatives hurt you with
the truth and liberals comfort you with lies.
A je po 10 letih dejansko kaj napredka v paralelnem programiranju? Namreč, še vedno je omejeno na nišne področja uporabe. V smislu običnega uporabnika kje točno je viden napredek paralelizacije?
Ce uporabljas Javascript potem napredka ni in ga tudi ne bo. Pa je skoz bolj popularen. Glej vse te electron appe.
Mas pa druge jezike, ki imajo boljse concurrency modele, kjer je potem tudi paralelizacija mnogo bolj trivialna.
A je po 10 letih dejansko kaj napredka v paralelnem programiranju? Namreč, še vedno je omejeno na nišne področja uporabe. V smislu običnega uporabnika kje točno je viden napredek paralelizacije?
Zakaj bi moral paralerno programirati ko pa zna operacijski sistem sekvenčno aplkikacijo poganjati paralerno na več jedrih ... skratka softwerska ali hardwerska rešitev ... Intel je 2 leti nazaj kupil start up ki ravno to dela na hardwarskem nivoju. Na večih jedrih teče enojederna aplikacija.
Obstaja pa tudi podjetje ki je na mobitelu spremenilo operacijski sistem da to funkcionalnost dobiš popolnoma softwersko ... torej bi delala na trenutni strojni opremi. Demo na youtube je prikazoval dva telefona z isto igrico pognano gor. Klasični OS je nabil CPU na 4x 1.6Ghz da je igrica tekla. Na mobitelu s modificiranim OS pa je ista igra tekla še celo hitreje - več FPS - pa CPU je tekel 4x 0.6GHz.
Princip je statistična obdelava aplikacije ... OS analizera aplikacijo in ugotovi koliko časa se bo določen del kode izvajal. In nato te dele kode spremeni v samostojne taske, ki nato tečejo na virtualnem procesorju ... neki v tem smislu ... če najdem video ga prilepim.
Mogoče gre za FANBOY mokre želje. https://www.reddit.com/r/Amd/comments/b... Seveda INTEL ima podobno tehnologijo že v uporabi. Tako ,da izvedljivo. Če pa je vredno pa je drugo vprašanje. Mogoče 10%-30% performanse v idelani SW prijazni situaciji. Definitivno izziv za programerje.
Meh. Kaj ti bo veliko niti na eno jedro ? te niti si delijo resurse in to potem ni več to. SPloh pa ko niti zabezecajo L1/L2/L3 cache in ko začnejo cache-trashing itd.
PowerPC ima jedra z veliko nitmi a tam je to z razlogom. ker je verjetnost čakanja toliko višja, je pač fajn imeti alternativo. Če se ena nit ustavi, dobi takoj priložnost naslednja itd.
Ne pade mi na pamet primer, kjer bi pod nekim resnim bremenom ( kak encoding itd) moja 2700x dala na 16T bistveno več kot na 8T.
Verjetno,d a se kje pozna, ni pa to zame tak big news.
Aja, kar se 64C TR4 tiče, pričakovano.
Lisa je rekla, da TR-3 definitivno pride. GLede na TR-2 serijo, ki že sedaj piči do 32C, je naslednji pričakovani skok 64C, nothing new there...
Upravičeni pomisleki. Plus udari te Ahmdalov zakon. Tako koj je napisal zgoraj NSAagent. Neučinkovita povratna zanka te udari tam pri 32 jedrih. Torej je za eno aplikacijo 64 jedrov z TR neumno in ni za vsakokar. Jaz pa si nadanem PR očala gor in pozabiom n zdravo kmečko logiko in se zdijo govorice o 3 way SMT ali 4 way SMTju zelo realne, ker boostajo številke.
Podobno kot danes na smarphonih in neumnih količinah Rama in procesorke moči, ki je ne noben rabi 5% časa (oziroma vstavi vsako vsakdanjo stvar z naspihjeno statistiko). Podoben problem je pri GPUjih in vrstami spomina vs hitrosti tega spomina. Samo da je napisana večja cifra na škatli. Da ne omenjamo Buldozer arhitekturere, ki je dejansko zavajanje poprošnika z 8 jedrnikom, ki to ni.
Upravičeni pomisleki. Plus udari te Ahmdalov zakon. (snip) Tako koj je napisal zgoraj NSAagent. Neučinkovita povratna zanka te udari tam pri 32 jedrih. Torej je za eno aplikacijo 64 jedrov z TR neumno in ni za vsakokar. Jaz pa si nadanem PR očala gor in pozabiom n zdravo kmečko logiko in se zdijo govorice o 3 way SMT ali 4 way SMTju zelo realne, ker boostajo številke.
Podobno kot danes na smarphonih in neumnih količinah Rama in procesorke moči, ki je ne noben rabi 5% časa (oziroma vstavi vsako vsakdanjo stvar z naspihjeno statistiko). Podoben problem je pri GPUjih in vrstami spomina vs hitrosti tega spomina. Samo da je napisana večja cifra na škatli. Da ne omenjamo Buldozer arhitekturere, ki je dejansko zavajanje poprošnika z 8 jedrnikom, ki to ni.
Kaj današnja mularija več niti ne zna dati povezave do Wikipedije, temveč mora iti za vsako jajce "video or it doesn't exist"? Očitno se staram ...
32 jeder je kar nekaj.
Amdahlov sklep tudi ni končen odgovor, kot je to med prvimi povzel Gustafson.
Tvoje razmišljanje o domnevno "neumnih količinah RAM-a" popolnoma spregleda hirearhijo pomnilnika. Ravno tako brcaš v temo, če misliš, da procesorska moč ni izkoriščena tam in takrat, ko je to potrebno. Ravno pametni telefoni (in ostale uporabniške mobilne naprave) najbolje izkoristijo vsa jedra, da lahko nekatera opravila izvedejo hitreje ali pa v istem času izvedejo več opravil, vse s ciljem zmanjšanja uporabniku vidne latence.
Čas bo, da ponovno odpreš kakšen učbenik in osvežiš svoje znanje.
Fun times ahead. Predvsem v smislu da se bo pokazalo kateri novinarji/youtuberji imajo pojma o čem govorijo in kateri samo mešajo meglo. Tale tip se je s tem videom zanesljivo umestil med drugo sorto.
Izkoristit vsa jedra, ki so na voljo, je precej enostavno, zahteva le spremembo načina razmišljanja in nekaj fundamentov, kot je npr. ieee754 zapis floating point števil. Poglejte si malo unum in posit domislice Gustafsona, nestrpno pričakujem njegov talk tu na ISC.
Poglejte si malo unum in posit domislice Gustafsona
Smo že pet let nazaj ali nekaj takega gledali, pa sam nisem nič pametnega videl. Sedaj vidim, da je uvedel še nek tip 2 in 3 teh števil, kar zna kazati, da je v praksi uporabnost teh števil obratno sorazmerna z vsakim novim tipom, ki ga uvede. Celo en primer sem videl, ko so implementirali osnovne operacije tega zapisa na strojni nivo, pa razen, da je zavzel 2-4x več prostora kot ieee754, pa še bolj požrešen je bil pri računanju, o hitrosti računanja v primerjavi s ieee754 pa raje niti ne bom.
Za ieee754 zapisom FP ne stojijo debili, kar se kaže tudi v praksi, že več kot 30 let.
Za ieee754 zapisom FP ne stojijo debili, kar se kaže tudi v praksi, že več kot 30 let.
Najboljša primerjava, ki sem jo slišal na to temo, je ascii vs unicode. Tudi za asciijem niso stali debili, le razvit je bil v nekem drugem času, drugem okolju in reševal druge probleme. Za današnjo situacijo rabimo nekaj novega, kar rešuje današnje probleme. Positi to ponujajo, na način, ki ni prehudo drugačen od tega, ki so ga ljudje navajeni. Bo pa jasno trajalo 10 let, da se zgodi prehod, tako kot je trajal prehod iz ascii v unicode.
Žal, ni ravno neka dobra, kaj šele najboljša primerjava. Prednosti unicode proti ascii so tako trivialne, da jih lahko razume praktično vsak, ki si vzame pet minut časa. Prepoznati morebitne prednosti unum proti ieee754 zapisom FP, pa ni tako trivialna. Že na wiki strani imaš poglavje, ki je namenjeno kritiki tej prezentaciji števil. Če greš prebrati še dodatno gradivo izvora teh kritik, lahko takoj vidiš pomankljivosti, ki jih Gustafson ni niti videl oziroma jih zamolči. Verjamem pa, da možakar rabi svojo pogruntavščino zaviti v celofan - beri "reševanje novih današnjhi problemov na nov način", saj mu prinaša denar.
Sicer pa boš še sam najbolje vedel koliko se dejansko uporablja ta njegova prezentacija števil v realnosti.
Sicer pa boš še sam najbolje vedel koliko se dejansko uporablja ta njegova prezentacija števil v realnosti.
Recimo intlov bfloat16 ali rikenov "scalable vector extension" za arm. Aja, pa cel deep learning svet je na 16bitih ali manj. Vse to niso positi, so pa aplikaciji primerni zapisi števil, kar je tu poanta. Redko kdo potrebuje 32bitov, še redkeje 64bitov, a nas ieee v to prisiljuje in nam dviguje stroške elektrike in niža zmogljivosti zaradi večjih potreb po memory bandwidthu. Obstaja boljši način in kdor ga res potrebuje, si ga je že privoščil.
In čez 10 let bomo brali da bo imel najnovejši procesor 6000 jeder. Vprašanje pa bo ostalo, kako jih bomo programirali efektivno. Dokler ne bodo obstajali prevajalniki, ki bodo znali iz kode avtomatsko izločiti ven paralelizem, bo vse to neuporabno ...
Dokler ne bodo obstajali prevajalniki, ki bodo znali iz kode avtomatsko izločiti ven paralelizem, bo vse to neuporabno ...
Predpogoj za te prevajalnike so podatkovne strukture, ki omogočajo paralelizem by design in konstrukti v programskih jezikih, ki jasno izpostavijo kaj je paralelno in kaj ni. Glej chapel, upc in sorodne reči.
In čez 10 let bomo brali da bo imel najnovejši procesor 6000 jeder. Vprašanje pa bo ostalo, kako jih bomo programirali efektivno. Dokler ne bodo obstajali prevajalniki, ki bodo znali iz kode avtomatsko izločiti ven paralelizem, bo vse to neuporabno ...
IA bo skril da je razbil process med 6000 jeder. Programerji pa bodo programirali, kot da pišejo za en processor.
France Rejects Genocide Accusations Against Israel in Gaza,
To accuse the Jewish state of genocide is to cross a moral threshold
::
Mi izvajamo precej simulacij (lastne izdelave), ki smo jih paralelizirali - proces se odsimulira za različne kombinacije parametrov. Odvisono od HW, ki se uporablja, se v konfiguraciji nastavi, koliko vzporednih procesov naj se izvede. Me pa pri vsem tem skrbi dostop do pomnilnika, kako vsem tem 64 ali več jedrom filati podatke.
Ni tako tragično. Chiplet design in 5nm bi lahko omogočala 128c procesorje pri neki uporabni porabi. Consumerji pa do 32 jeder. Problem bo seveda pomnilniška prepustnost in DDR5 na dveh kanalih bo super za 16 jeder, kaj več pa zahteva večji memory paralelizem. HBM oz. podobna rešitev bi lahko bil game changer, 10 let je precej časa.
Me pa pri vsem tem skrbi dostop do pomnilnika, kako vsem tem 64 ali več jedrom filati podatke.
Parameter sweep, lepo. Lastna koda, lepo. Upam da uporabljate kake tuned math libs in niste šli sami svojih math rutin pisat ;) O kakšni količini podatkov se tu pogovarjamo? Ter kje se nahajajo? Ker so pristopi rahlo drugačni. Lahko na privat, da ne smetiva teme.
Dokler ne bodo obstajali prevajalniki, ki bodo znali iz kode avtomatsko izločiti ven paralelizem, bo vse to neuporabno ...
Predpogoj za te prevajalnike so podatkovne strukture, ki omogočajo paralelizem by design in konstrukti v programskih jezikih, ki jasno izpostavijo kaj je paralelno in kaj ni. Glej chapel, upc in sorodne reči.
Ampak saj ravno to je problem. Stvar moraš napisat na novo, in posebej označiti, kaj se da paralelizirat. Kaj pa vsa koda, ki je že napisana? Zdaj si ravnokar izjavil, da bo na novo napisana koda delala hitreje, vsa obstoječa pa ne.
"Označiti, kaj se da paralelizirati" - openmp/openacc ima pragme. Samo dodaš en "komentar" pred zanko, v najslabšem primeru moraš malo premetati zanko, da se znebiš data dependency.
"Koda, ki je že napisana" - glej recimo softposit, rabiš narediti samo s/float/posit/g v tvojih c++ fajlih. Magic, enostavneje se ne da.
Kdor je zadnjih 20 let pisal kodo s plašnicami na očeh striktno single threaded, si je sam kriv. Če od te kode živi, bo pač moral najti čas in sredstva za njeno modernizacijo. Ene magične rešitve tu ni, je precej odvisno od posameznega primera, kako se tega lotit in na kakšen način.
Ene magične rešitve tu ni, je precej odvisno od posameznega primera, kako se tega lotit in na kakšen način.
Itak. Osebno sem še vedno mnenja, da se da kodo bolje paralelizirati v času načrtovanja, kakor pozneje med izvajanjem ali popravljanjem obstoječe kode. Seveda pa je težko take trditve postavljati generalno, za vse različne primere.
Sam sem mnenja, da bo naslednji večji preskok v razvoju programskih jezikov prinesla prav paralelizacija. Nekako podobno, kot se je zgodilo z uvedbo predmetno usmerjenega programiranja pred nekaj desetletji. Pri sedanjem številu jeder ta potreba še ni tako močno izražena (pustimo ob strani super računalnike in zelo specifične probleme, ki jih rešujejo), v prihodnosti pa bomo imeli v domačih računalnikih precej več jeder, kot jih bomo lahko izkoristili.
Prepoznati morebitne prednosti unum proti ieee754 zapisom FP, pa ni tako trivialna.
I beg to differ. Številke so tako enostavne, da jih še vsi gamerji tu razumejo in so jim domače.
V članku, ki si ga dal piše samo o ieee754 formatu, nič o prednosti unum formatu števil. To, da algoritme, ki sicer uporabljajo 64 bit FP, lahko pohitriš, če lahko uporabiš 32 bit in 16 bit FP, je res jasno marsikomu. Če si lahko privoščiš, lahko že na sami grafični teoretično pohitriš zadeve za 32 kratnik, če greš iz 64 bit FP na 16 FP.
