Hirdetés
- Azonnali alaplapos kérdések órája
- Fixált kábelekkel jönnek a SilverStone legfrissebb, ATX 3.1-es tápjai
- Milyen egeret válasszak?
- Milyen processzort vegyek?
- OLED TV topic
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Androidos tablet topic
- Annyira örül az SNES öregedésének Super Mario, hogy idővel nagyobbat ugrik
- Bemutatta az RTX PRO generációt az NVIDIA
- Sony MILC fényképezőgépcsalád
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
julius666
#107
üzenetére
A HSA az nem egy extra réteg lesz. Ma az OpenCL-t minden gyártó úgy támogatja, hogy a GPU ISA előtt van egy vISA. Mindenkinek más. Ez ezért kell, mert a GPU lényege a skálázás. Ezt már az ISA és a memóriamodell szintjén beletervezik. Ergo 3-4-5 évente mindenki lecseréli a GPU ISA-t és memóriamodellt egy újra, hogy jobb legyen a skálázás. Erre van a vISA a GPU-k előtt. A HSA ötlete, hogy ne legyen minden gyártónak külön vISA-ja, hanem mindenki használjon egy közöst, ami a HSAIL. Ezzel erre a vISA-ra is lehetne direkten alkalmazást írni, és akkor teljesen kizárható a driver stb. Akik beléptek ebbe az alapítványba azok a cégek eldöntötték, hogy a jövőben közös HSAIL-t használják majd a saját vISA-juk helyett. Ez jelentősen egyszerűsíti majd a munkát, és az alkalmazás teljesítményének portolhatóságát. Vannak már webinarik is egy ideje. A fejlesztők a HSA alapítvány oldalán jelentkezhetnek erre. A HSA Bolttal már mutatták, hogy majdnem el lehet érni az OpenCL-C sebességet, és eközben rövidebb a kód, mintha C-ben írnád párhuzamosítás nélkül. Ezért nőtt háromszorosára az érdeklődés a HSA iránt fél év alatt. A gyártók látják a fizika problémáit, míg a programozók is lassan rájönnek, hogy itt a gyártók most tényleg nem viccelnek, és valóban nem tudják növelni a teljesítményt a megszokott úton. Nyilván a programozók miatt történik ez a HSA, hogy egyszerűbb legyen a dolguk. Sosem lesz közös fizikai ISA a GPU-knál, mert nem fognak működni a rendszerek, de a vISA-t közösre lehet rakni.
A Windows 8-ban már per engine reset van. Ha lefagy az alkalmazás, akkor nem omlik össze az OS, hanem újraindul az engine. Ezt az MS szándékosan fejlesztette ilyenre a WDDM 1.2-ben, nyilván ők is átgondolták, hogy C++ AMP mellett ez gond lenne, de így tulajdonképpen akkor sem lesz baja az OS-nek, ha egy GPU-s alkalmazás áll le. Ettől persze bármikor lefagyhat az OS, de ennek lesz nem nagyobb az esélye GPU-s alkalmazás mellett.
-
ddekany
veterán
válasz
agressiv
#108
üzenetére
Amennyiben desktopon az olyan feladatok nem számítanak... Persze most is 99%-ban elvagyunk azzal ami van, mert legfőbb alkalmazásokat (videó lejátszás és 3D) lefedték célhardverrel. Kérdés, hogy mikor már szabadon programozhatóbb lesz a GPU-jellegű vagy csak nagyon-sok-magos vas, megjelenik-e pár új alkalmazás ami széles körben elterjed. Pl. lehet, hogy 15 év múlva természetesnek fogjuk venni, hogy a videó-telefonálásnál ki lehet üttetni a hátteret, vagy hogy szóval és mozdulatokkal megbízhatóan lehet távvezérelni a gépet, vagy hogy sokkal jobb a játékokban a fizika.
-
julius666
addikt
a HSA ép ezt fogja kiküszöbölni, hogy ne kelljen minden GPU fajtára kézzel optimalizálni, hanem 1x megírják és utána csak lefordul és kész.
Az OpenCL-ben már most is is 1× megírják és kész, fut mindenen. Ha meg arra gondolsz, hogy optimalizálni kell a kódot és ezért külön architektúrákra mást írni, ezen a téren a HSA kétlem hogy sok előnyt hozna, ugyanúgy különböző architektúrákról beszélünk, csak lesz valami elvárt minimum illetve föléjük húzva egy viszonylag alacsony szintű közös réteg.
A GPGPU azért nem terjed olyan baromi gyorsan mert elég macerás (ergo drága) rá kódot írni, a processzor és a GPU közti szinkronizálás, vagy akár GPU-n belül annyira lassú és vacakolós, hogy jóformán azalatt a processzor sokszor elvégezné maga a melót (cserébe viszont az összfogyasztást esélyes hogy alaposan megdobja a dolgozó GPU), illetve a driverek sem mindig százasok. Ha a CPU-n van valami gebasz az alkalmazásban akkor max az alkalmazás zakózik egyet, ha a GPU-n akkor esélyes hogy akár az egész oprendszer (kékhalál). Debugolni meg szintén nem a legjobb GPU-n.
És akkor nem is lehet a "hétköznapi" alkalmazások legnagyobb részénél a grafikus felületen kívül mit kidobni GPU-ra.
-
ddekany
veterán
"a nagy igényű programoknak pedig olyan 90%-a képes kihasználni a több processzormagot"
Mit értesz nagy igényű alatt? Ami szerveroldali (pl. egy adatbázis kezelő), már csak azért is ezer éve kihasználja, mert egyszerre több kliens nyúzza. Viszont itt kliens oldalon futó cuccoknál akarják kihasználni a sok magot (mobil telefon). Ami ott jól párhuzamosítható, az azt gondolnám jellemzően olyan feladat, ami egy GPGPU-nak is fekszik. Tehát most vagy találni akarnak még más több szálra bontható feladatokat, pont azokat a feladatokat akarják pár tucat teljes értékű x86 maggal ledarálni, még több tucat korlátozott tudású CU (vagy ahogy épp hívják) helyett. Csak akkor nem mernék rá sokban fogadni, hogy nem sülnek fel ezzel Intelék (mert tudnak ők olyat is...) az AMD specializáltabb megoldásával szemben.
"a gpgpu révén nyújtható gyorsítást egy rövid wikipedia oldalon felsorolható mennyiségű program támogatja"
Most még...
-
Pikari
addikt
én nemtom hogy mire gondolsz, de kb 20 évre visszamenőleg az összes program threadelt, a nagy igényű programoknak pedig olyan 90%-a képes kihasználni a több processzormagot. a gpgpu révén nyújtható gyorsítást egy rövid wikipedia oldalon felsorolható mennyiségű program támogatja, ami az összes programok kb 1 tízezreléke SE. az asszimetrikus MP egy halott koncepció, sosem fog felfutni, ez egy téveszme, amit a laikusokkal szopatnak fel.
-
Pikari
addikt
nem kizárólag az objektumokról, mint fogalomról beszéltem. a magas szintű nyelv mindig nagy overhead. ezzel persze nem azt mondom, hogy írjon mindenki mindent assemblyben, mert ki a franc akarja már azzal szopatni magát, ha nem muszáj? tessék mindent C/C++-ban írni, kinek mi a szimpatikus, de *ésszel*.
-
ddekany
veterán
És ez az ígéret még rosszabb, mert ha elérkezett volna a 10 MHz-s CPU-k korszaka akkor abból profitáltak volna a meglévő szoftverek. Most ha még tudnak is olcsón rengeteg-magos CPU-kat gyártani 10 év múlva, akkor is kérdés, hogy mi és hogyan fogja ezt kihasználni... ill. hogy ez hogyan fog viszonyulni a GPGPU-s dolgokhoz (OpenCL, C++ AMP, és persze HSA), amik már most kezdenek felfutni, és lenyúlják a jól párhuzamosítható feladatokat az x86-os CPU-k elől. Mondjuk lehet, hogy Intelnél pont az utóbbiakat fogják megvalósítani ezeken, de akkor lesz olyan hatékony, mint a specializáltabb hardver?
-
Srodney
senior tag
gyorsan átfutottam a hsz-eket de senki nem írta még hogy volt már az intelnek 2000ben egy ígérete, méghozzá hogy 10 éven belül elérik a 10ghz-es órajelet a procik...ez nem jött be....íme egy újabb ígéret...
hamarabb változik a világ ahhoz,hogy az intel ilyen "10év"-es ígéretekkel álljon elő....szerintem!
-
azopi74
addikt
"64 bittel meg már akkora bazni nagy memóriateret kapsz, hogy nincs értelme nagyobbnak."
Arról nem is szólva, hogy valójában 64 bites CPU-k sincsenek még a láthatáron sem, amikkel amúgy elméletileg 16 exabyte-ot lehetne lapozás-mentesen megcímezni, ami több, mint elég lesz a közeljövőben
Úgyhogy először a valódi 64 bites CPU-k fognak jönni, a 128 bit a nagyon távoli jövő zenéje.... -
ddekany
veterán
Ezzel a sok magosítással meg arra tippelnék az lesz, hogy marad grafika/képfelismerés/hangfelismerés terén, meg egy-két ilyen speciális dologra, és kész... A többi kódra meg azt mondjuk, hogy elég gyors az már most is...
Aztán majd egyszer talán nő tovább az órajel is, ha átállnak valami tök más megvalósításra mint ami most van (más anyagok, akár más elven működő kapuk). -
ddekany
veterán
A 64 bitre átállás hajóereje az volt, hogy megszűnik az alkalmazásonként 4G-s (ill. OS-től függően akár csak 2-3G-s) memória korlát. (Tudom, elvileg lehet lapozgatni, de az komplikálja a programozást, nem reális megoldás általában.) Lehet még találni példákat, ahol valamivel gyorsabb, mert nagyobb adagokban tudod dobálni az adatokat, de csak amiatt szvsz a kutya sem fektetett volna bele az átállásba. 64 bittel meg már akkora bazni nagy memóriateret kapsz, hogy nincs értelme nagyobbnak.
-
azopi74
addikt
A mai ún. 64 bites x86-os CPU-kkal, amik valójában 48 (40+8 - AMD) vagy 42 (Intel) bitesek, meg lehet címezni 256 TByte RAM-ot, ami még egy ideig szvsz elég lesz még a csúcs-szerverekben is
Addig is csak tranzisztorpocsékolás lenne a 128 bit. Tudom, más "elméleti" előnye is lenne a váltásnak, de azok tényleg csak elméletiek, és eltörpülnének a tranyószám növekedés miatti hátrányok mellett....
Inkább a párhuzamos utasítás-végrehajtásra és a heterogén rendszerekre kellene rágyúrni a közeljövőben. Na meg az igazi" 64 bitre. -
-
azopi74
addikt
"(szerintem kb 4-5 év a jelenlegi tendenciákat figyelembe véve)"
Bár rendkívül tudománytalan megközelítés mindig a jelenlegi tendenciákat extrapolálni a jövőre nézve.
Ma például az ezredfordulón érvényes folyamatokat extrapolálva 1 magos CPU-k ketyegnének az eszközökben, de 2-3 THz-en, és 128 vagy 256 bitesek lennének -
#84
azopi74
addikt
cipofuzo87
#82
azopi74
addikt
válasz
cipofuzo87
#82
üzenetére
"Hülyeség a sok mag, az egyszálú teljesítményre kell helyezni a hangsúlyt, ahogy az apple is teszi. A tablet médiafogyasztó eszköz, és a felhasználói felületek pedig egyszálúak."
Nem a sok mag a hülyeség, hanem ez a rendkívül szakértő, jövőbe mutató hozzáállás :- )...
-
#82
cipofuzo87
tag
cipofuzo87
tag
Hülyeség a sok mag, az egyszálú teljesítményre kell helyezni a hangsúlyt, ahogy az apple is teszi. A tablet médiafogyasztó eszköz, és a felhasználói felületek pedig egyszálúak.
-
kb minden nap leírja valaki, hogy milyen fontos (lenne már végre) a szoftvereket többszálúra optimalizálni. a másik oldalon meg reklámozza mindenki, hogy milyen fasza többszálú programja, processzora van.
ha olyan egyszerű lenne (vagy sok esetben egyáltalán kivitelezhető lenne) többszálú programokat írni, akkor már kb 10 éve így működne minden, de még mindig csak a beszélgetés megy róla...
-
#95904256
törölt tag
Nem tudok túl sokat mondani a fordítás körülményeiről. A kódrészlet az FFTW-ből származik. De a "Fastest Fourier Transform in the West" szlogennel hírdetik magukat, így gondolom törekedtek némi optimalizációra...
"Az meg hogy atomon biztos van különbség... lehet, főleg mert ne in-orderre számít manapság egy x86-os compiler. Aztán persze csak akkor tudjuk ezt meg, ha ki is próbálod."
Kellő tapasztalattal, próba nélkül is megmondható...
-
-
ddekany
veterán
válasz
#95904256
#76
üzenetére
Ja, az [ESP+40] írását sikerült átsiklanom... Amúgy nem tudom miért nem egyszerűsítette tovább a compiler ezt, mert ez pont egy mechanikus feladat, meg kellően "lokális" is. Optimalizáció kapcsolókkal mi volt?
Az meg hogy atomon biztos van különbség... lehet, főleg mert ne in-orderre számít manapság egy x86-os compiler. Aztán persze csak akkor tudjuk ezt meg, ha ki is próbálod.
-
#95904256
törölt tag
Hm... Nem kell találgatni a fenti kódrésszel kapcsolatban. Ha érdekel, szívesen megmondom, hogy melyik sor mit csinál és hol vannak függőségek. Az [ESP+40]-en kersztüli értékcsere elhagyása miatt egyértelműen gyorsabb a második kód Atom-on ( in-order ). Egyébként out-of-order szempontból a MOV ESI,[ESP+68h] / LEA EAX,[ESI+EBX*8] / MOV ESI,[ESP+5Ch] / MOVSS XMM0,[ESI] kódrészletre érdemes figyelni. A második kóban nincs benne ez az ESI regiszteres függőség, mégsem gyorsabb... Óó...
-
ddekany
veterán
válasz
#95904256
#74
üzenetére
"Mit értesz az alatt, hogy jobban átrendezhető?"
Hogy kevesebb függőség van az utasítások közt, tehát az OoO esetleg többet tud belőle kihozni.
"Kettővel kevesebb utasítás, ennek ellenére a futásidő mégis ugyanaz."
Ennyi alapján elég nehéz ezt kitalálni, hogy mi miért hogy... Pl. a compiler kódjában van egy `mov eax,[esp+40h]`, aminek a tiedben nincs megfelelője, ill. itt még nem látszik miért kellett az (talán lejjebb használja). Nyilván az sem mindegy, hogy milyen optimalizációra volt állítva a fordító (és most feltételezem, hogy az GCC vagy VC volt, tehát valami fejlettebb). A futási sebességnél meg lehet, hogy a memória elérések dominálnak. Meg persze ki kellene próbálni atomon, hogy kiderüljön, ott lassabb-e a compileré (elképzelhető, elvégre nem arra van optimalizálva, főleg mert x86 vonalon már rég nem volt in-ordre semmi).
-
#95904256
törölt tag
Mit értesz az alatt, hogy jobban átrendezhető? Itt ugye arról beszélünk, hogy pl. egyes helyzetekben a fordító generál egy 5 soros kódot ahelyett amiből kettő kihagyható lett volna.
Ezt például most ollóztam ki egy disassemblált kódból:
mov ebx,[esp+44h]
mov esi,[esp+68h]
mov ebp,[esp+54h]
mov edi,[esp+58h]
lea eax,[esi+ebx*8]
mov esi,[esp+5Ch]
mov [esp+40h],ebp
mov ebx,[esp+50h]
mov ebp,eax
mov eax,[esp+40h]
movss xmm0,[esi]Valószínűleg nem vagyok annyira sokat csiszolt, mint a fordító, de így egyszerűbb:
mov ebx,[esp+44h]
mov ebp,[esp+68h]
mov eax,[esp+54h]
mov edi,[esp+58h]
lea ebp,[ebp+ebx*8]
mov esi,[esp+5Ch]
mov [esp+40h],eax
mov ebx,[esp+50h]
movss xmm0,[esi]Kettővel kevesebb utasítás, ennek ellenére a futásidő mégis ugyanaz.
-
ddekany
veterán
válasz
#95904256
#70
üzenetére
A tudása limitált, de egy emberéhez képest? A compiler feladatai közé tartozik, hogy a valóban felesleges cifraságokat kiejtse... valószínűleg egy sokat csiszolt fordító jobban is csinálja ezt, mint egy ember, aki nem valami ritka zseni. Az már inkább van, hogy nyelv szemantikájának szigorú megőrzése, ami nem fekszik teljesen a CPU világnézetére, generál plusz kódot. Csak arra voltam kíváncsi, hogy ezek miért jobban átrendezhetőek (OoO) mint mondjuk egy ASM-ben (vagy csak C-ben?) írt kód, hátha van valami konkrétum, vagy teszt erre.
Az OoO jelentése amúgy annyi, hogy nem feltétlenül abban a sorrendben potyogtatod az utasításokat a végrehajtóba, mint ahogy a kódban szerepelnek, hanem amennyire a függőségeik engedik, átrendezheted őket. Branch predictionnak és társainak anélkül is van szerepe, mert nem akarsz buborékokat a pipeline-ban in-ordernél sem.
-
-
#95904256
törölt tag
Igen. Mivel a fordító programoknak is limitált a tudása, így egyes helyzetekben némiképp cifrára sikerül a kimeneti kód. Ez "cifraság" a szükségesnél több utasítást jelent, aminek a hatása az out-of-order végrehajtás miatt nem jelentkezik a futásidőben. Megjegyzés: out-of-order végrehajtás -> register renaming, branch prediction, spekulatív végrehajtás, több utasítás párhuzamos futtatása, stb...
-
ddekany
veterán
Ha valami komplexebb dolgot írsz, mondjuk C-ben (de lehetne akár ASM is - lényeg, hogy nincs objektum orientáltság támogatás), akkor általános tendencia, hogy elkezdesz valami könyvtárat ad-hoc módon kifejleszteni, ami lényegében az objektumokat szimulálja... csak bénábban...
-
ddekany
veterán
"Ez nem tanulás vagy akarat kérdése."
Persze azért van, hogy annak is kérdése. Csak amiről még a jellemzően laikus megmondó emberek nem tudnak, hogy ha az ember meg is tanulta "hogyan kell", akkor is lényegesen időigényesebb lehet a párhuzamos (és főleg a konkurens jelleggel bíró) változat elkészítése. A programozót ez nem érdekli, amennyiben a megrendelőt/főnököt sem érdekli, hogy - mondjuk - 2x annyi ideig készül a cucc, és az órabér ugyanannyi maradt...
-
ddekany
veterán
Nem programozok C#-ban, nem igazán ismerem, de 99.9% vagyok benne, hogy ugyanúgy mint Java-ban, meg kb. minden statikus JVM nyelvben, technikailag általában nem objektum egy integer. Az, hogy hívhatod egy int metódusait magas szintű nyelven, önmagában nem igényli, hogy az futásidőben is objektum legyen. Ha olyan típusú változóba rakod ami nem "int"-nek van deklarálva (hanem "int?"-nek, Object-nek, stb.), na akkor lesz belőle objektum.
-
cucka
addikt
válasz
#95904256
#32
üzenetére
Muszáj lesz megtanulni több szálra programozni.
Az a baj, hogy nagyon sok olyan feladat van, amely nem igazán párhuzamosítható. Ez nem tanulás vagy akarat kérdése.(#43) ---Lasali---
Szóval itt az egész programozással kapcsolatos gondolkodás módot újra kéne gondolni, kötelezővé tenni a több magos optimalizációt a kódban, mint a programkód tagolást.
Olyan fogalom nem létezik, hogy több magos optimalizáció. Vagy párhuzamosan futtatható kódot írsz, vagy pedig nem. Ez tervezési kérdés, nem úgy működik, hogy megírod az egyszálú kódot, aztán némi plusz idő ráfordításával abból pikk-pakk többszálú kód lesz.Valamint a fordító programokat és nyelveket is kihegyezni erre, hogy minél egyszerűbben lehessen több szálasan programozni.
Minden fontos programozási nyelv támogatja ezt.Pár éve az egyetemen még csak kérdő ív formájában beszéltek arról
Nem tudom, melyik egyetemre jártál, de az ELTÉn már 10 éve is kötlező tárgy volt ez. -
Zeratul
addikt
válasz
#95904256
#62
üzenetére
Dinnye felépítésű CPUnál az OoO egység és bonyolult feladatütemezés eleve kiesik mert baromi sok helyet foglalna. Bulldozernél is legnagyobb problémát az okozta aminek előny kellett volna hoznia. Egy feladatütemező látja ez a modul két szálát és biza kevés annak 4 utasítás/órajel teljesítménye. Steamrollernél nem véletlen a megkettőzött feladatütemező.
-
#95904256
törölt tag
"...két egész szám szimpla összeadás nem 1-2 órajel, nem tudom pontosan mennyi, de legalább a 10x-nek veszem..."
"...a fordító mivel mindent objektumként kezel, a matematikai műveletek sebességét rendesen hazavágja. Tehát a többszálú programozással azt a sebességet próbáljuk meg visszaszerezni, amit a fordító elvesz..."
Ez csak egy hiedelem. Egyrészt a mai fordítók nagyon hatékony kódot készítenek, másfelől a CPU-ban lévő out-of-order végrehajtás sokmindent elrejt. Egy normálisan megírt, egy szálra íródott programnál, a "fordítási veszteség" max. 1-2%.
-
Pikari
addikt
bizony. gépi-kód szinten nincs objektum. regiszterek vannak, memóriacímek, meg utasítások. nincs magas szintű asshatery sehol, azok csak egy programozási elv reprezentálódásai, kizárólag magas szinten léteznek. aki ezek mentén gondolkozik, az ritkán tud gyors kódot írni eleve.
-
borg25
senior tag
Úgy jön ide, hogy elvileg azért kell a többszálú programozás, hogy ki lehessen használni a 4, 8, 48… mag előnyeit. Csak épp előtte a fordító mivel mindent objektumként kezel, a matematikai műveletek sebességét rendesen hazavágja. Tehát VB.NET, C# alatt a többszálú programozással azt a sebességet próbáljuk meg visszaszerezni, amit a fordító elvesz.
Oké van az a pont, vannak olyan számítások ahol már nem lehet assemblyvel se további sebességet nyerni, és jól jön a párhuzamosság ezt elismerem. De valahogy most úgy látom, hogy olyan a helyzet, mintha a C64-es korszakba nem azt mondták volna, hogy a lassú az interpreteres basic-et úgy gyorsítják fel, hogy lefordítják a kódot, vagy eleve assemblyben írják meg az egészet ahogy az történt, hanem akkor a C64ekből összefűznek egy gridet és majd annak nagyobb lesz a számítási kapacitása, és nem baj, hogy a módszer miatt lassú az egész, azt a számítási kapacitás ellensúlyozza.
A C++-nak tényleg az objektumorientáltság az egyik legnagyobb előnye, de ettől az alap adattípusok még nem objektumok, egy 32bites egész szám 4 byte egy memória címen lehetőleg 4-re igazítva. VB.NET-re és C#-ra ez már tudtommal nem mondható el. (Legalábbis a M$ mondja azt, hogy nála minden objektum, ezért is lehet egy számot könnyedén stringre alakítani a .ToString metódussal, és hogy a VB.NET és a C# ugyanarra a köztes nyelvre fordul, sebesség szempontjából mindegy miben kódolsz.) -
ddekany
veterán
válasz
julius666
#44
üzenetére
"Itt most persze megpróbálják eladni azt hogy ez egy új probléma, közben nem, a tudományos számításoknál, grid rendszereknél pl. rég megoldott kérdések ezek."
A tudományos számítások eléggé speciális terület, és ha jól sejtem a mostani GPGPU-s csodák is ott domborítanak, attól a néhány tipikus grafikai/képfelismerős/stb feladattól eltekintve. Az, hogy az összes többi kódot hogyan fogod párhuzamosítani, tudtommal nem eldőlt kérdés.
Említed a data-flow nyelveket, amik gondolom lényegében egyenértékűek a tisztán funkcionális nyelvekkel (pl. Haskel). Ezeknek a hívei emlegetik, hogy ezek az elfeledett nyelvek reneszánszukat fogják élni a sokmagos (és akár a heterogén) korszakban, de mint írtam, kétségeim vannak. Egyik dolog, hogy vajon mennyire lesznek ezek hatékonyak szokványos kód esetén (tehát nem valami grafikai számításnál), a másik, hogy vajon mennyire lesznek ezek emészthetőek a fejlesztők agyának. Én még nem tudtam eldönteni, hogy simán a rutin hiánya miatt érzem ezeket rohad nehéznek, vagy mert annyira buta vagyok. Esetleg, hogy nem vagyok zsigerileg matematikus. Majd még ahogy életem engedi, próbálkozok...
-
ddekany
veterán
"Ma a Visual Studiok egy köztes nyelvre fordítanak, mindent objektumként kezelnek, és két egész szám szimpla összeadás nem 1-2 órajel, nem tudom pontosan mennyi, de legalább a 10x-nek veszem."
Valószínűleg C#-nál 1-2 órajel... A szokványos numerikus típusok ált. nem objektumok, a CIL kódot meg gépi kódra fordítja a JIT. Mellékesen egy modern C++ programban is jobbára "minden objektum", mondjuk annyi eltéréssel, hogy lehet a stack-ban is egy objektum, nem csak heap-ben, na meg hogy a collectionoknak (vektorok és társaik) van specializált változata primitív típusok tárolására, tehát nem kell őket objektumokba csomagolni. C#-nak nem tudom van-e ilyen képessége, Java-nak nincs, de pl. a Scala-nak (ami JVM-es nyelv) van.De hogy jön ez az egész ide, a sok mag kihasználásához? Az tök másról szól. Magas szintű nyelvek is tudnak olyat, sőt, pont azok közt lehet erre kihegyezetteket találni (Clojure, Erlang, stb.).
-
gyurielf2
csendes tag
-
borg25
senior tag
Programozó szempontjából a min a kérdés. Koca programozó vagyok, még C64-en tanultam meg assemblyben programozni, PC-n még kacérkodtam vele, de nem igazán alkalmazom, pedig megérné…. de ma már Windows alatt cefetül kevés programozási nyelv támogatja. Amit ismerek az a Borland és Visual C++ natív programkódja. Egyik nem annyira elterjedt, a másikban pedig számomra cefetül nehéz Windows-ra programozni (Megszoktam a VB egyszerűségét
). Maradt a VB.NET, és a C# amiben egyszerűen és könnyen össze tudok dobni egy programot, cserébe minden objektum.
Lehet azt mondani, hogy legyen 48 mag, meg hogy a programozok tanuljanak meg rendesen programozni, de könyörgöm: A régi programozási nyelveken amik még ismerték az assemblyt egy összeadás ADD EAX, [ES:0x1200] vagy FADD ST, ST(7) formátumú volt. Ezt a CPU 1-2 órajel alatt megoldotta, nem kellett assemblybe nagyon lemenni, hogy gyors kódot kapjon az ember. Ma a Visual Studiok egy köztes nyelvre fordítanak, mindent objektumként kezelnek, és két egész szám szimpla összeadás nem 1-2 órajel, nem tudom pontosan mennyi, de legalább a 10x-nek veszem. Nem tudom Javaban pontosan hogy van, de az is tudtommal virtuális gépen fut, az is mindent objektumként kezel…
Szóval ha programoznom kell, akkor választhatok az egyszerűen lassú programot írni, és a nehezen gyorsat közt :S Köztes út nincs, és az se megoldható, hogy a felületet itt írom meg a számítást pedig ott
Szóval a jó hardver helyett, előbb egy jobb programozási környezet kéne (nekem) aminél egy szálból is kényelmesen ki tudom sajtolni a maximumot. Ha bárki nem ért velem egyet, az szóljon, mondtam nem vagyok profi programozó, magamtól tanultam, nem programozóin végeztem. Szívese hallanék arról, hogy milyen programozási nyelvet ajánlanátok amin könnyű programozással el lehet érni a teljesítményt.
De addig, míg a M$ által nyomott programnyelvek lassú kódot fordítanak, ne a programozókat ócsároljuk, hogy nem hajlandóak párhuzamosan programozni, pedig 7 éve ott a mindenki számára elérhető többmagos CPU (Lsd: Pentum D széria 2005-ből) -
Abu85
HÁZIGAZDA
válasz
julius666
#46
üzenetére
Én is ezeket mondanám mobilban. Illetve a multimédiás programok egy része.
Azt kétlem, hogy ezek átkerülnének dedikált hardverre. A fixfunkciós eszközök jók egy bizonyos határig, de a nagyon számításigényes feladatokra már nem jók. A képfelismerés tipikusan ilyen. Azt meg lehet csinálni, hogy szeleteled a képet mozaikokra és azokon mész át több fixfunkciós hardverrel, de akkor meg a lapka elég nagy része egy olyan célhardverből áll, ami másra nem használható. Távolról sem mondom, hogy a fixfunkciós eszközöknek nincs értelme, csak ezeknek is megvannak a maguk korlátjai. Valamit megéri ezekkel csinálni, míg valamit nem. -
julius666
addikt
Feladatfüggő le lehet-e "kezelni". Gustafson törvénye egyáltalán nem olyan univerzális.
Gustafson's Law (also known as Gustafson-Barsis' law) is a law in computer science which says that computations involving arbitrarily large data sets can be efficiently parallelized.
Ilyenek mobil eszközökön a grafikai számítások. Tudsz még hasonló feladatot mondani amire mobilon szükség lehet? Képfelismerés, hangfelismerés esetleg, de a fejemet merném tenni rá, ezek a jövőben dedikált hardvert fognak kapni, ergo kiesnek a képből.
-
Abu85
HÁZIGAZDA
válasz
julius666
#44
üzenetére
Amdahl törvényét lehet kezelni a programozási szokások drasztikus módosításával. A Gustafson-Barsis törvény, pont az ellentettjét mondja az Amdahl törvénynek. Ergo a Dennard-féle skálázási szabállyal ellentétben ez a gond sokkal könnyebben kezelhető. Lehet dobálózni persze a mérnökök felé, hogy hülyeség amit csinálnak, de ettől a fizika törvényei nem változnak meg.
(#38) ddekany: Szerintem senki sem látja teljesen tisztán, hogy mi lesz. Nyilván a mérnök szeme előtt az lebeg, hogy skálázni kell az új generációs termékek teljesítményét, és ez a hagyományos módon már nem megy. Nyilván a mai zöld világban a vezetőség meg sem akarja hallani, hogy a TDP keretet meg kellene duplázni, szóval marad a párhuzamos feldolgozás. A programozó oldaláról pedig felmerül a hogyan kérdés, mert ők meg a megszokott dolgokon nem szeretnek változtatni.
Ami egyelőre biztos, hogy a Dennard-féle skálázási szabálynak vége, vagyis nem lehet más irányt választani a hardver tervezésénél, mint a termékbe betervezett pJ/FLOP mutató mérséklését. Aztán, hogy ezután mi lesz az kérdés. -
julius666
addikt
Igazából ilyen dataflow nyelvek amik direkt a párhuzamosságra mennek rá (a klasszikus imperatív nyelvekkel szemben nem kell gondolkozni azon mit lehetne külön szálakba szervezni, mert a struktúrából adja magát a párhuzamosság) ősidők óta léteznek. Itt most persze megpróbálják eladni azt hogy ez egy új probléma, közben nem, a tudományos számításoknál, grid rendszereknél pl. rég megoldott kérdések ezek.
Aztán az sem bizonyított, hogy a sok pici párhuzamosíthat cafat kinyerése a sok frok-join overhead-je nem üti agyon az egészet.
Itt van a kutya elásva. Többszálú programozás esetén a "szűk keresztmetszet" a szálak szinkronizálása Jól párhuzamosítható feladatoknál ugye ez nem jelent problémát, mivel ritka, rosszul párhuzamosíthatóknál igen.
Sok apró feladatot ki lehet dobálni külön szálakba, de az általad említett "fork-join overhead" nagyobb lesz mint maga a számítási feladat elvégzése volt.Arról nem is beszélve, hogy a rahedli szálat valahogy managelni is kell, ez néha még asztali gépen is probléma tud lenni (bizonyos szál felett szépen "bedugul" a rendszer és jelentősen esik a teljesítmény), nem hogy mobilon, ahol még a fogyasztás is számít.
És akkor nem is lehet végtelenségig többszálúsítani semmilyen feladatot. Tök jól hangzik a "Dennard skálázási szabályának hanyatlása", de akkor én meg mondom Amdahl törvényét, ami még univerzálisabb.
Őszintén szólva mobilon a grafikus jellegű feladatokon kívül nem nagyon látom mit lehetne durván többszálúsítani, az meg már most is ugye "többszálúsítva" van, mert külön segédprocesszoron (GPU) fut. Esetleg a játékok fizikáját, de aztán kész.
-
#43
---Lasali---
Közösségépítő
sampe
#21
---Lasali---
Közösségépítő
Francba, én is ezt akartam belinkelni.
De amúgy mai napig azt tapasztalom hogy a fejlesztők többsége nem tud többszálasan programozni.. asztali prociknál is pl ott van a bulldozer-vishera, látható hogy ahol szépen többszálasan hatékonyan dolgoznak, ott utolérik vagy még gyorsabbak is az i7 nél, de mindenhol máshol bukta.. nyer a még erős single processokra tervezett intel proci..
Szóval itt az egész programozással kapcsolatos gondolkodás módot újra kéne gondolni, kötelezővé tenni a több magos optimalizációt a kódban, mint a programkód tagolást.
Valamint a fordító programokat és nyelveket is kihegyezni erre, hogy minél egyszerűbben lehessen több szálasan programozni.
Pár éve az egyetemen még csak kérdő ív formájában beszéltek arról hogy van-e igény erre.. hát ezt nem kérdő ív formájában kellett volna kérdezgetni, hanem mivelhogy erről fog szólni az informatika, azonnal bepakolni a tantervbe.. -
mrhitoshi
veterán
Épkézláb fejlesztésnek tűnik, de mégis életképtelen. A HSA-ba nyomják ezerrel a pénzt, ráadásul olyan cégek vannak már most is benne, mint a Qualcomm, nem hinném hogy az Intel megoldása lenne a nyerő, már csak azért is mert az ultramobil/mobil szegmensben nem versenyképes az Intel, ezzel meg végképp árral szemben megy.
Szóval ha van pénzük, már pedig van, akkor elhülyéskednek még egy ideig ezzel a gondolattal, meg az x86-tal, de sokáig nem lehet az árral szemben úszni.
Viszont a non Low end kategóriákban lehet nyerő lesz ez az ötlet, mert nem nagy a konkurencia. -
ddekany
veterán
Nagyon kíváncsi leszek rá, hogy ezt mennyire tudják majd kihasználni a programok, meg hogy hogy a fenébe... Vannak feladatok, amikről ismert hogy jól párhuzamosíthatóak, azaz könnyen fel tudom bontani a feladatot tetszőleges számú egyforma alfeladatra (tipikusan grafikai területen, de nem csak), ezekre vannak is speciális eszközök (OpenCL, amire lehetne építeni valami magasabb szintűeket) de a többivel mi lesz? A sok "szokványos" programrésszel? Valószínűleg lehet automatizáltan pici kis párhuzamosítható részeket találni az alkalmazásokban, ha szigorúan funkcionális stílusban írod őket (kb. Haskell, talán valamilyen LISP...), de hogy nem állunk át ilyenekre 10 éven belül, az biztos. Igazából az sem bizonyított, hogy valaha gyakorlatilag értelmes lenne egy ilyen átállás... Van egy szubkultúrája ezeknek, ahol esküsznek, hogy miután beletanult az ember, nem is robban le a feje a legegyszerűbb feladatoktól is. Aztán ki tudja mi az igazság. Én amennyit ilyenekkel vacakoltam, nem láttam bizonyítottnak, hogy ez emberi lényeknek való minden feladat esetén. Aztán az sem bizonyított, hogy a sok pici párhuzamosíthat cafat kinyerése a sok frok-join overhead-je nem üti agyon az egészet.
-
siti
őstag
válasz
#95904256
#32
üzenetére
volt régen egy cikk az inteltől, amikor kihozta az első kétmagos desktop procikat (E2140 1.6GHz és E2160 1.8GHz), miközben a p4-ek bőven túl voltak a 3GHz-en, azt mondták, hogy a frekvenciákat nem lehet tovább növelni, túl komplikált és hogy a több mag a jövő és ezekhez elég az alacsonyabb órajel is. Ha most belenézek a gépbe, akkor ez az alap i3 itt pörög 3.3GHz-en, mert hát, izé, kell az is, mert elég sok program még mindig csak egy szálon dolgozik, pedig azóta eltelt 5 év. és most ott tartunk, hogy valahogy rá kéne venni a GPU-t is, hogy ha már nem háromszögeket számol, akkor besegítsen az excel makró futtatásba, mert vagy a magok, vagy freki, de valahogy nem elég hogy a HD film ne szaggason
-
#36
Pálin(t)ka
tag
Pálin(t)ka
tag
huuuu...*_* hát várjuk.
-
Silenzio
addikt
Az uccsó előtti bekezdést támogatom. Már csak az a kérdés, mekkora terület kell egy ilyen processzornak? Egyelőre a fogyasztás mellett ez a legnagyobb gond. Azt is leszarja jelenleg mindenki az okostelefonok piacán, majd rájönnek, mekkora szívás, ha fél nap alatt lemerül a csúcskütyü.
Na de mi van akkor, ha már akkora a lapka területe, hogy fizikailag nem tud megfelelő késleltetéssel kapcsolatot létesíteni a magok közt? -
Sundesz
addikt
Engem ez a kijelentés kicsit arra emlékeztet, amikor az Intel a 2000-es évek elején 10+ Ghz-es processzorokat vízionált, aztán rájöttek, hogy a P4-nek aztán hiába emelik az órajelét, mert xar. Szóval én szkeptikus vagyok abban a tekintetben, hogy a magszámok emelése lenne az egyértelmű jövő.
-
#95904256
törölt tag
Muszáj lesz megtanulni több szálra programozni. Az egyértelmű, hogy az órajel a fizikai korlátokat döngeti, így ez az út tovább már nem járható. Ideje másik zsákutcát keresni.
Szvsz. az órajel csökkentése új lehetőségeket is teremt. A mérnökök meg fogják találni, hogy mely áramköröket érdemes az adott TDP limiten belül többszörös órajelen üzemeltetni, ugyanis a gyártástechnológia ezt megengedi! Pl. az is lehetséges, hogy a jövőben egyetlen nagy cache lesz a sok processzormag mellett. Az alacsony órajelen ketyegő magokat képes lesz kiszolgálni egy magasabb órajelen ketyegő cache. Ez pl. feleslegessé tenné a processzoron belüli energiazabáló cache-koherencia logikát. stb... lehet ötletelni.
-
cucka
addikt
Az derék dolog, hogy bele fognak zsúfolni 48 magot egy mobil eszközökhöz fejlesztett alacsony fogyasztású cpu-ba. A fontos kérdés viszont az, hogy vajon ki fog erre szoftvert fejleszteni? Vagy egyáltalán melyek azok a feladatok, amelyeket mobil eszközökkel oldunk meg és ennyire masszívan párhuzamosíthatóak?
A párhuzamos programozás az nem egyszerű dolog, különösen desktop/mobil alkalmazásoknál. -
Ruuwa
tag
A HSA és az intel jelen ötlete nem egy és ugyan az? A HSA azt mondja, hogy legyen néhány bonyolult mag, és rengeteg kicsi egyszerű. Az Intel azt mondja, legyen sok közepesen egyszerű mag. Gyakorlatilag azon megy az ötletelés, hogy milyen arányba legyenek egyszerűbb/bonyolultabb magok az adott lapkában. Nekem ez jön le az egészből. Ezért például az eljövendő HSA-s fejlesztőkörnyezeteknek nem jelent majd különösebb nehézséget az Intel megoldásaihoz alkalmazkodni, hiszen ugyan azzal a szemlélettel kell majd a programot írni, "csak" a fordító lesz más. Vagy ennél azért nagyobb a két megközelítés között a különbség?
-
sampe
aktív tag
48 mag, 10 éven belül? UGYAN!
A barátok közt már 64 magos processzorral
rendelkezik, már MOST!Elnézést az offért!
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
CYBERIA
őstag
Pont az a lényeg, hogy a programnak fel KELL lennie készítve a többszálú futásra, ha nincs akkor hiába tüntetsz el előle magokat, meg hiába is teszel hozzá.
Amire te gondolsz, az azért nem működik, mert nem az történne hogy kétszer gyorsabbá válna a számítás, hanem ugyanazt kétszer számolná ki. -
#22145024
törölt tag
A felhasználói programok (excl. games) ma mennyire használják ki jól az x86-os hardvereket? Lehetne mondjuk 3-10x olyan hatékonyan is futtatni ugyanazt, ha a jelenleginél "normálisabban" írnák meg a kódot? Vagy már eleve túl vannak a mindent brute force-ból megoldani dolgon?
-
=WiNTeR=
senior tag
Lehet hülye kérdés, de olyat nem lehet csinálni, hogy mondjuk egy ténylegesen 8 magos processzort a rendszer 4 magként lásson, pedig valójában amit a rendszer magonként egynek lát, az ténylegesen 2 mag legyen, így dupla számítási teljesítmény lenne, és még a programnak se kéne támogatnia a 4+ szálakat.
-
pakriksz
őstag
"nem tudják megoldani azt, hogy 8 mag felett legyen jelentős haszon a + magokból"
hát ha megnézel egy amd fx procis tesztet, akkor már látható hogy többségében 2 mag fölött sem... de 4 mag fölött ritka mint a fehér holló ha valami profitál belőle desktopon és ez nem igazán akar változni. Már jó pár éve vannak 4 magos procik és még mindig ugyan az megy mint a megjelenésükkor "majd ki lesz használva néhány év múlva". Pl a játékoknál a directx a legnagyobb korlátozó tényező a többszálasításban.
Szerveren persze más a helyzet. -
DrJános
aktív tag
Hát szerintem most Inteléknél valaki valamit nagyon elszámolt.
Ha Asztali környezetben több Gigás OS-nél (és az ultramobil eszközökhöz képest nagy méretű programoknál) nem tudják megoldani azt, hogy 8 mag felett legyen jelentős haszon a + magokból, akkor ezt pont az ultramobil eszközöknél fogják tudni megoldani ahol pár megás /pár száz megás programokkal /OS-ekkel dolgoznak?
Szerintem nem túl valószínű, hogy ami asztalon nem működik az pont működni fog az ultramobil eszközökben, főleg mivel ezek egyre inkább átveszik a PC-k helyét. Ma már (és főleg a jövőben) nem elég az ha "buta" rendszereket hoznak össze. Azzal már nem lehet eladni őket, hogy egyszerűen kicsik, csak azzal lehet eladni őket, hogy egyre inkább tudják azt mint egy "behemót" PC.
Ez csak az én véleményem, lehet hogy nincs igazam, de én így érzek ezzel kapcsolatban
-
Hokoyumi
tag
érdekes lesz, kíváncsi vagyok mit hoz a jövő
az intel ezzel totál ellene megy a hsa alapítványnak
HA marad is a 48 magvas mobiltelefon prociban az x86 és a fejlesztők valóban 48 magra optimalizálnak a szoftver még amd-n sem fog futni normálisan, de ugyan ez lesz fordítva
magonként lesz 800mhz ez a proci? -
#16939776
törölt tag
Ezt már korábban is foglalkoztatok, csak más szerző tollából:[link]
Jó cikk, korábban már volt szerencsém hozzá.
On: Ebben mekkora lehetőség van? tudtommal már most sokkal "energia hatékonyabb" egy GPU-val számoltatni mint CPU-val.
Nekem ez kicsit elkeseredett harcnak ígérkezik a (ultra)mobil szegmens "meghódítására"Az viszont örvendetes hogy lesz egy csomó programozó aki rá lesz kényszerítve hogy jól párhuzamosítható kódot írjanak. Ugye Intel bácsi mögött elég sok pénz van
-
#3
SkyLine3000
addikt
SkyLine3000
addikt
Kevés lesz az...
-
P.H.
senior tag
Intel’s Near-Threshold Voltage Computing and Applications
Alacsonyabb csíkszélességen, több tranzisztorral kisebb energiaigény. Átmeneti megoldásként annak, akinek gyártástechnológiai előnye van, mindenesetre jó lesz.
(#33) Sundesz
). Maradt a VB.NET, és a C# amiben egyszerűen és könnyen össze tudok dobni egy programot, cserébe minden objektum.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
ph A vállalat tíz éven belül 48 processzormagot helyezne el az okostelefonokba.
- Elemlámpa, zseblámpa
- Azonnali alaplapos kérdések órája
- Fixált kábelekkel jönnek a SilverStone legfrissebb, ATX 3.1-es tápjai
- Milyen egeret válasszak?
- Linux haladóknak
- Milyen processzort vegyek?
- OLED TV topic
- ASUS routerek
- Autós topik
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- További aktív témák...
- BESZÁMÍTÁS! Gigabyte B760M i5 14600KF 32GB DDR4 1TB SSD RTX 3080 10GB GDDR6X CM MasterBox MB500 850W
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASUS ROG MAXIMUS Z790 EXTREME alaplap garanciával hibátlan működéssel
- LG 27GN800P - 27" IPS - 2560x1440 - 144 hz 1ms - NVIDIA G-Sync - AMD FreeSync - HDR 10
- Csere-Beszámítás! RTX Számítógép játékra! I7 10700 / RTX 3060Ti / 32GB DDR4 / 500GB SSD
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest