Keresés

Új hozzászólás Aktív témák

  • ddekany

    nagyúr

    válasz Abu85 #121 üzenetére

    "A szerverpiacon még nincs akkora probléma a skálázással, mert az órajellel nagyon jól lehet játszani. Ide még legalább 2 évig lesznek fejlesztések, de idővel itt is csak APU-k lesznek, mert a skálázás itt sem biztosítható a végtelenségig."

    Miért lehet ott jobban játszani az órajellel? Amúgy meg szerveren többet lehet kezdeni az újabb és újabb magokkal is mint asztalon, mivel egy időben több felhasználót szolgálnak ki. Viszont nem tudom mit lehet kezdeni egy APU-val... nyilván attól függ mit csinál a szerver. De valahogy nem látom, hogy tömegesen ez hol hasznos szervereken. Mit csinál vele?

  • ddekany

    nagyúr

    válasz dezz #116 üzenetére

    Egyszálas optimalizáció alatt én nem is alacsony szintű szőrözésre gondoltam, hanem sokkal inkább arra, hogy sokszor a belső "API-k" olyanok, meg néha az alkalmazott adatstruktúrák is, hogy sokkal többet dolgozik a gép, mint kéne.

    A másik ami nem tudom mindenkinek világos-e, állatira más az, amikor ugyan azt a feladatot kell elvégezni egymástól függetlenül sok objektumon (tipikus kép/hang kapcsán), meg az, amikor úgy kell vakaródzni rajta, hogy egyáltalán mik azok a részek, amik egymástól függetlenek annyira, hogy egyszerre futtathatók legyenek, és persze akkor is figyelni kell, hogy mi van azokkal az adatokkal amiket közösen használnak és módosítanak (azaz, konkurens programozás). Előbbi biztosan el fog harapódzni, utóbbit meg eddig is csak ott csináltuk ahol muszáj (tipikusan, szerverekben, néhol vezérélésben).

  • ddekany

    nagyúr

    válasz Abu85 #103 üzenetére

    "Ha a programod gyors, akkor eladható, ha van gyorsabb/jobb, akkor azt veszik az emberek."

    A végkifejlet a valóságban valószínűleg az lesz, hogy a felhasználó csendben viseli, hogy némely dolgok kissé nyögvenyelős maradt, mint ezelőtt is volt, aztán kész. Amikor valami multimédiás (kép, hang) csodáról van szó, akkor brutálisat lehet kaszálni párhuzamosítással, főleg GPU-val. Meg még egy két speciális területen. Ezek jelentőségét én nem nézem le, csak a legtöbb kód nem ilyesmikről szól. Valószínűleg nem is lehetne olyan sok pluszt kinyerni belőlük több maggal. Sőt, az optimalizálatlanságuk egyáltalán nem csak abból adódik, hogy nincsenek párhuzamosítva... azaz, már eddig is (egyetlen magon) sokat lehetett volna gyorsítani rajtuk, de ez is csak módjával történik meg a valóságban, mint tudjuk. Szóval eddig sem törték magukat össze a cégek optimalizálás terén, pedig elvileg eddig is versenyelőny lett volna. És ezt mondom, hogy valószínűleg hasonlóképen módjával lesz az sokszálúság is kihasználva, ama néhány tipikus speciális területen kívül.

  • ddekany

    nagyúr

    válasz Abu85 #96 üzenetére

    "Vagy rájönnek a programozók, hogy az ingyen ebédnek vége"

    A programozónak kb mindegy, hogy fele olyan gyorsan halad a munkával vagy sem, feltéve hogy minkét esetben ugyan akkora órabért kap. Persze nem valószínű, hogy az őt alkalmazó cég ezt hajlandó lesz meglépni, hacsak nem te hajlandó vagy 2x annyit fizetni a licencért. Ergo a dolog vége lehet hogy az lesz, hogy bár sok területen párhuzamosítanak (multimédia, tömörítés... játék... őőő), a legtöbb kód marad olyan amilyen volt, aztán max. nem lesznek gyorsabb egy darabig. Az meg, hogy hány MHz-is fogunk felmenni és mikor, ki tudja... egyszer tán tök más alapon fognak működni a CPU-k, és ott lehet hogy reális lesz a 30 GHz.

  • ddekany

    nagyúr

    válasz dezz #94 üzenetére

    "A Trinity elsősorban mobil/mainstream desktop proci. Ehhez megvan a kellő "CPU-erő".

    De én a CPU számítási teljesítmény / Wattról beszéltem, nem nyers erőről.

    "Sorolnád azt a sok alkalmazást (főleg a hétköznapiakat), ami nem többszálúsítható, de igényli a minél nagyobb teljesítményt?"

    A legtöbb kód amit írunk (90%-sok százalék simán) egyszálú volt és reálisan az is marad örökre (hacsak nem tök más nyelvek lesznek mainstream-ek... maaajd, talán), mert egyszerűen nem reális erőfeszítés megkeresni benne a picike párhuzamosítható cafatokat, meg összehangolni őket. Ráadásul ha pici cafatokat tudsz csak párhuzamosítani, akkor sokszor a párhuzamosított megoldás a lassabb. (Illetve a nagyon-nagyon pici párhuzamosítható cafatokat megtalálja egy modern CPU.) Hogy aztán ezek közt ki szerint melyik üti meg a "igényli a minél nagyobb teljesítményt" követelményt... Amikor van kismillió absztrakciós réteged, sőt, meg akár magas szintű nyelved (Python, Ruby, JavaScript, stb), akkor azért van, hogy tetű lesz a program a rakás overheadtól egy modern CPU-n is, szóval a gyorsabb jobb. Amúgy pl. fordítás/értelmezés (parsing) is jellemzően olyan, hogy nem nagyon párhuzamosítható elvileg sem.

  • ddekany

    nagyúr

    válasz pakriksz #91 üzenetére

    Mikor kijött a Bulldozer, emlékeim szerint minden teszt amit láttam (PH, AnandTech meg hasonlók, nem vérpistike) lehúzta a fogyasztása miatt, és nem is kicsit. Amúgy, én csak örülök neki, ha most az ellenkezője fog bebizonyosodni.

    "És nem kell rizsázni hogy "mert nehéz" nem az, csak fejlődni kéne, nem futószalagon gyártani ugyan azt újra és írja."

    Pedig lényegesen nehezebb, mint egy magra írni. Legalábbis amíg valami nagyon forradalmi nem történik a szélesebb körben használt nyelvekkel/könyvtárakkal... Az meg nem mostanság lesz, ha lesz valaha egyáltalán.

  • ddekany

    nagyúr

    Ez a "minek gyorsabb CPU" dolog... Egyrészt, a lényeg itt inkább a számítási_teljesítmény/Watt, amiből a Bulldozer a béka segge alatt volt, így én félek, hogy itt sem lehet sok jóra számítani. Másrészt, nagyon-nagyon sok dolog nem írható át GPU-ra, szóval ez azért nem így megy, hogy majd átírnak mindent GPGPU-ra.

Új hozzászólás Aktív témák