Hirdetés
- Lassan állítjuk a fát, és a hardverek is be vannak csomagolva
- Klasszikus kínai festmények ihlették a Colorful legfrissebb memóriáinak külsejét
- Ultrakompakt Key E SSD-vel jelentkezett a Silicon Power
- Mesterséges intelligenciára kihegyezett mini PC jött az ASUS műhelyéből
- ASUS blog: ExpertBook P5 notebook, a munkagép
- Milyen billentyűzetet vegyek?
- AMD GPU-k jövője - amit tudni vélünk
- Intel Core i3 / i5 / i7 4xxx "Haswell" és "Haswell Refresh / Devil's Canyon" (LGA1150)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Samsung LCD és LED TV-k
- Projektor topic
- Milyen Android TV boxot vegyek?
- SSD kibeszélő
- Milyen egeret válasszak?
- ThinkPad (NEM IdeaPad)
Új hozzászólás Aktív témák
-
#93
acsa77
tag
Blindmouse
#65
acsa77
tag
válasz
Blindmouse
#65
üzenetére
A magok drámaian növelik a fogyasztást, és minden más hozzáadott végrehajtóegység, akárhogy is hívjuk, ha kihasználják. És pont az egyik nagy gond, hogy a csíkszélesség csökkenése nem automatikusan csökkenti a fogyasztást. Az ARM félvezető-technológiát nem is fejleszt jelentős mértékben, másokra van rábízva. Legfőbb előnye, hogy sokkal jobban alkalmazkodik a meglévő végrehajtási feladatokhoz, nem üzemeltet felesleges területeket. De ez csak viszonylag kis, rövid idejű feladatok esetén működik, kliens oldalon. Hogy ezt ne tudná utolérni az Intel? És ha nem éri utol, és ráadásul az ARM ténylegesen tömegesen szerverekbe, munkaállomásokba kerül, akkor gyakorlatilag átveszi az Intel szerepét.
-
acsa77
tag
Lehet, hogy nem voltam teljesen egyértelmű. Arra gondoltam, hogy a legtöbb mai komplex rendszert véve, ha gondolatban minden gépet ARM-ra cserélnénk, elég nehéz lenne megvalósítani. Nevezhetnénk infrastruktúrának, komplett rendszernek. Az Intel a legtöbb rendszer legnagyobb részét nyújtja. Ez változhat 2 év múlva, de akkor még éppen csak megjelenik az ARM-os nagyobb teljesítményű háttér. Aki e mögé üzletileg belát, nem itt fog programozástechnikai, hardvertechnikai kérdésekről vitázni. Ráadásul 2 év múlva APU-ban is, mobil processzorokban is jobb lehet az Intel.
-
oO7
őstag
oh akkor már is le vagyok maradva az infókkal... nemrég olvastam valami ilyen kis írást a Tegra 3-ról (talán pont itt a PH!-n) és mintha az lett volna a találgatások-fejtegetések vége, hogy az igért sebességnövekedést csak az Unified Shader Model bevezetésével tudják valószínűleg biztosítani... és ott volt konkrétan megemlítve, hogy most hogyan is működik a jelenlegi Tegra 2-es - és akkor lehet hogy ez rémlett rosszul - és a többi jelenlegi mobil GPU...
de köszi a részletes felvilágosítást... komolyan élvezet olvasni az írásaid, sokat tanul belőle az ember
-
Abu85
HÁZIGAZDA
Arcfelismerést már láttam a gyártóktól. Az AMD és a Viewdle közös OpenCL-es megoldása nagyon jól működik már most. Az Intel egyik bemutatóján is mutatott egy algoritmust, ami állításuk szerint szintén jól működi, de valós idejű videóknál kell hozzá a komoly számítási teljesítmény, így a mai procikon egyelőre esélytelen. A lebutított algoritmus sokszor hibázott, de csak a részletességet vissza kellett venni, hogy fusson négymagos procin.
Elméletben jók az eredmények, de kell alá a vas. Az ARM koncepciója 2013-ról szól, addig még két év van. Minden szinten fejlődhet a dolog. Ráadásul az ARM eleve OpenCL-ben gondolkodik, és ez az a terület, ahol a GPU-k igazán kivehetik a részüket a munkából.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Van már unified shader modell pár IP-ben. A legújabb Mali, Adreno és PowerVR termékek ilyenek. A Tegra például pont nem ilyen, még a Tegra 3 sem. Amúgy ennek sok jelentősége nincs. Az API nem követeli meg ezt, így bármivel lehet versenyezni. Talán mobil szintre még előnyösebb is a hagyományos pipeline. A Tegrának biztos, mert az a rendszer klasszikus immediate render, míg a többi, elterjedtebb IP már tile-based rendert használ. A Mali és az Adreno hagyományosat, míg a PowerVR deferred megoldást.
Ha az új generációs IP-ket hasonlítjuk össze, akkor a Mali-T604 nagyon okos, egyértelműen az egyik legokosabb. Bár a nextgen Adreno és PowerVR Rouge rendszerekről még kevés az Infó, de maximum olyan okosak lesznek, mint a Mali-T604 (a PowerVR biztosnak tűnik, míg az Adreno esetében a DX támogatásra kompromisszumokat kötött a Qualcomm, de erről majd a bemutatókon többet tudunk). A sebesség/tranyóköltség mellett viszont még a különböző API-k támogatásának hiányában is értékelhetőbb megoldást lehet a Tegra 3 IGP-je. Az NVIDIA erősen játszik a Windows 8-ra, de amíg nincs itt az a rendszer, addig nem érdemes túllépni az OpenGL ES 2.0 támogatásán, mert sok extra tranyót jelent. A Mali-T604 például már túllépet, és támogatja az OpenCL 1.1-et, illetve a DX11-et is. Az NVIDIA inkább biztonságra játszik, és legyen egy rendszer még a 40 nm-re. A Windows 8-ig úgyis kész lesz a 28 nm-es Tegra 4.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
ddekany
veterán
válasz
julius666
#85
üzenetére
"kódkiegészítés lényegében nincs (van csak buta) és sorolhatnánk. Ez azonban nem hiszem hogy szükségszerű állapot"
Javítani lehet sok mindenen, heroikus befektetésekkel... de soha nem lehet azt a szintet elérni, mint statikus nyelvekkel, főleg azonos befektetéssel nem. Ha ugyanis tényleg kihasználod a dinamikusságot, akkor szükségszerűen nincsenek egyértelmű válaszok arra, hogy mi milyen típusú (osztályú), meg ha adott osztályú akkor milyen metódusai vannak. Neked is sokszor nehéz kigabalyítani, hát még egy IDE-nek aki magasabb szinten nem érti a programot, na meg nem futtathatja és nézegetheti debuggerrel. Ha meg nem használod ki a dinamikusságot, akkor inkább valami modern statikus nyelvet érdemes használni. Persze itt egy nagy buktató, hogy a statikus nyelvek világa valamiért elég nehézkesen mozgott az utóbbi évtized(ek?)ben... A korszerűbbek (pl. Digital Mars féle D vagy Scala, Kotlin, Ceylon) még szinte sehol sincsenek, főleg tooling terén, holott utóbbi lenne pont ez egyik lényeges erényük. A Java ilyen szempontból remek pozícióba van, de maga a nyelv ma már fájdalmasan elmaradott és eleve feleslegesen szószátyár, ezzel is égetve a statikus nyelveket. C# még tán a legjobb azok közt ami elterjedt, de Mono ide vagy oda, ott az MS árnyéka. Szóval legalábbis nem-Windows platformon van itt egy űr, ami kedvez a dinamikus nyelveknek, jobban mint megérdemelnék. Most ezért a szerver oldalon is a feleslegesen szadista Java és a saját műfajában elég jó Ruby ill Python közt kell választani. (Persze, visszatérve a rögös Webes valóságba, az is már csodás lenne, ha mondjuk a Python ugyan olyan mindenhol alapértelmezésben jelenlévő és bagóért hosztolható lenne, mint a PHP. Igen, a VPS ára szerencsére csökken.)
Ja, "kicsit" OFF-ok lettünk...
[ Szerkesztve ]
-
julius666
addikt
Csak kicsit furcsa, hogy míg Windows alkalmazásfejlesztés terén már rég elindult a trend a C++ (natív) leváltására C#-al (CLR), itt most megint totál natívról akarnak kezdeni.
Nem totál natívról akarnak kezdeni, ott a JavaScript.
A karbantarthatóság és IDE támogatás az ami miatt sokszor nem jó üzlet a dinamikusság.
Ebben egyetértünk, valóban siralmas a mai napig a js támogatás az IDE-kben (legalábbis amikkel eddig találkoztam, Eclipse Aptana pluginnal és Netbeans, de a VS-ről sem hallottam túl sok jót), kódkiegészítés lényegében nincs (van csak buta) és sorolhatnánk. Ez azonban nem hiszem hogy szükségszerű állapot, más dinamikus nyelvekhez (pl. python) ezek teljesen használhatóak, illetve már így is sokkal előrébb tartunk mint évekkel ezelőtt. Ez minden bizonnyal javulni fog, akár a közeljövőben már.
Karbantarthatóság/code management téren ott a CommonJS ami baromi nagy előrelépés (sajnos ez böngészővonalon nem létező dolog), illetve az ECMAScript 5 is hoz be újdonságokat ilyen szempontból. Szóval kétségtelenül vannak ilyen irányba törekvések, csak ezek nagy részét már évekkel ezelőtt meg kellett volna lépni. Sajnos most isszuk meg a levét a webszabványokat kidolgozó csoportulások inkompetenciájának meg hogy anno MS-ék meg a többi akkori nagy IT cég nem karolta fel rendesen az ügyet. Most már kínkeservesen fog csak átmenni minden apró változtatás.
A kliensoldal vastagodásához pedig csak annyit, hogy persze, az oldalak funkcióinak növekedésével meg a szirszar izgőmozgó designelemekkel/átmenetekkel meg tudnak szaladni a kódok, azonban ez még mindig egyszerű View réteg. A Modell ahová komoly karbantarthatóság kell az a szerveren marad. És nem igazán látom hogy ez megváltozna a jövőben, minden piaci szereplő a cloud meg SaaS irányba nyomul, a javascript csak megjelenítő oldalra kell. meg amúgy is komoly security problémákat vetne fel.
Ez alól egyedül a játékok (illetve esetleg képszerkesztők meg még egy-két célterület, ha normális UI reszponzivitást akarunk) a kivételek, annak nyilván a kliensél kell futnia.Na de ilyen nyelvi finomságokról kár is beszélgetni Web kapcsán, ahol is a programok 99%-át PHP-ban írják, ami nyelvtervezésileg egy hatalmas kupac inkompetencia némi káosszal nyakon öntve...
A JavaScript a rossz hírnevét pont annak köszönheti, mert hosszú éveken keresztül ezen emberek játszótere volt. Meg mert sok programozó szemében a mai napig JavaScript = valami gagyi typeless Java-klón és b*sznak megtanulni programozni benne, programoznak Java-ul. Ami működő dolog, csak nem hatékony.
-
ddekany
veterán
válasz
julius666
#83
üzenetére
"Szarrá van sandboxolva meg ellenőrizve, így talán annyira nem."
Nem is a biztonság a gondom vele, meg annyira fatális gondom nincs vele ha majd CPU architektúra független is lesz (PNaCl, LLVM). Csak kicsit furcsa, hogy míg Windows alkalmazásfejlesztés terén már rég elindult a trend a C++ (natív) leváltására C#-al (CLR), itt most megint totál natívról akarnak kezdeni. A JVM (Java, stb) és CLR (C#, stb) felfogásának közel sem csak a valamivel nagyobb biztonság az előnye... Hanem pl. automatikus memória kezelés, nincsenek pointerek, jobb interoperabilitás a mások által fejlesztett komponensekkel. Persze a (P)NaCl-en meg lehet valósítani egy JVM-szerűséget, csak nehogy az legyen, hogy ezért nem fog ilyesmi elterjedni, mert alapból nincs elég helyen telepítve, és 50 MB-t lerántatni a weboldal első meglátogatáskor meg nem vicces. (Ez kb u.a. a sztori mint desktopon, ahol is a .Net igazi felfutásához egyértelműen fontos, hogy az Windows része lett. Itt ha csak a PNaCl lesz a böngészők része alapból, de az akármilyen-VM (pl. Dalvik) nem... kétséges a kimenetel.)
"Csak komolyabb dolgokhoz (pl. komolyabb játékmotorokhoz, nagyobb üzleti rendszerekhez) alkalmatlan, de nem igazán értem ez miért akkora probléma, nem is erre találták ki, nem is próbálja senki ilyesmire használni."
Azért igencsak vastagodnak a kliens oldali rétegek is... És amúgy a dinamikus nyelvek problémái közül a sebesség csak az egyik, és sokszor nem is a lényeges gond. A karbantarthatóság és IDE támogatás az ami miatt sokszor nem jó üzlet a dinamikusság. (Na de ilyen nyelvi finomságokról kár is beszélgetni Web kapcsán, ahol is a programok 99%-át PHP-ban írják, ami nyelvtervezésileg egy hatalmas kupac inkompetencia némi káosszal nyakon öntve... Képzelem, emberek ezen nőnek fel, és a koporsóig más nem is látnak. Csak hallották, hogy van ilyen, mint Scala, meg Ruby meg Python, de azok bloatedek meg lassúak meg vááá...)
-
julius666
addikt
Ilyesmi lenne a helyes út...
bár a natív kód elég szarul hangzik
Szarrá van sandboxolva meg ellenőrizve, így talán annyira nem.
A JS-dologhoz: így már értem mire gondoltál, az nem volt tiszta hogy mi akar lenni az a más nyelv implementálós dolog (bár egyébként vannak ilyenek - coffescript és tsai, amik JS-be fordulnak - de ezeket őszintén szólva nem tartom sokra és nincs tudomásom róla hogy különösebben elterjedt lenne). A JS nem rossz dolog egyáltalán, mindaddig amíg nem akarnak vele realtime nagy számításigényű dolgokat/bazinagy rendszereket csinálni, amire klasszikusan a típusos, statikus nyelvek valók. GUI-k logikájának összedrótozására, nagy funkcionalitású API-kkal mögötte különböző rövid feladatokkal operáló (nem blokkoló) eseményvezérelt alkalmazások készítésére tökéletes, abszolút felveszi a versenyt a konkurenciájával (a Node.js pl. nem hiába annyira felkapott). Csak komolyabb dolgokhoz (pl. komolyabb játékmotorokhoz, nagyobb üzleti rendszerekhez) alkalmatlan, de nem igazán értem ez miért akkora probléma, nem is erre találták ki, nem is próbálja senki ilyesmire használni. Egyáltalán nem értem a programozói társadalom negatív hozzáállását a nyelvhez (pontosabban de, őszintén szólva engem is zavar hogy OKJ-s "webfejlesztő" kóklerek programozónak nevezik magukat azzal hogy templatekből össze tudnak dobálni valamit ami úgy-ahogy működik, de ez elsősorban nem a nyelv hibája).
A WebCL-hez: a ... valami C-szerű forráskód ... nem egy-az-egyben OpenCL (esetleg korlátozásokkal)?
-
-
ddekany
veterán
válasz
julius666
#80
üzenetére
Én meg attól tartok, hogy a megbízható beszédfelismerés nem csak számítási kapacitás kérdése, hanem AI-é is. Legalábbis nekem borzalmasan sokat segít egy szöveg (főleg egy angol szöveg) hallás utáni megértésében, hogy tudom hogy milyen szó értelmes az adott ponton (a sok hasonlóan hangzó közül).
JS dolog: "Ezt nem igazán értem."
Elég gyér egy olyan alkalmazás fejlesztésre szánt platform, amiben a legalacsonyabb szintű nyelv egy eredetileg nagyon-nagyon kicsi projektekre tervezett script nyelv. Képzeld ha Windows platformon a VB lenne a legalacsonyabb szintű nyelv amit használhatsz, és nem létezne a gépikód, amire építve létezhet a C++, Pascal, Python, meg akármi ami kell. Meg nem utolsó sorban, amire építhetsz nagy és széles körben használt könyvárakat anélkül, hogy mindenkinek aki használja 5x annyit egyen mert dinamikus nyelv. Normális platformokon van választásod.
"Egyébként ha a Google próbálkozásai sikerrel járnak és elterjed, a jövőben natív kód (illetve próbálkoznak egy köztes nyelv használatával is)"
Ilyesmi lenne a helyes út... bár a natív kód elég szarul hangzik, a köztes (Dalvik pl.?) már sokkal jobban.
-
julius666
addikt
Ilyen egyáltalán van már, ami megbízhatóan működik?
Nem, de jelenleg rendes procin elég esélytelennek tűnik az implementálása, nagy számításkapacitású GPU segítségével már sokkal reálisabb lehet kliensoldalon is.
Ettől függetlenül én is inkább azt mondom hogy ez felhőben fog menni, a Google-nek már van is rá konkrét API-ja, amit a weboldalak már felhasználhatnak tudtommal. Sajnos még messze nem tökéletes.Abba már bele sem megyek, hogy a JS nem egy olyan nyelv, amivel más nyelveket implementálni tanácsos
Ezt nem igazán értem.
Egyébként ha a Google próbálkozásai sikerrel járnak és elterjed, a jövőben natív kód (illetve próbálkoznak egy köztes nyelv használatával is) is futhat a böngészőben, nem csak javascript. -
julius666
addikt
Már vagy 10 éve kapható olyan agyhullámvezérlésű joystick, ami egy fejre rakható pántból és egy elemző egységből áll.
Link? Remélem nem valami idióta sg.hu-s szar...
Viszont az OpenCL-lel nem tudom, mi a bajod, senki sem fog nekiállni mindezeket shader-asm-ben leprogramozni minden fajta GPU-ra.
Semmi, írtam hogy bajom lenne vele?
Lehet, hogy WebCL előbb fog megjelenni, mint az...
Azt nehezen tudnám elképzelni, mivel a WebCL az javascript bindig az OpenCL-hez, nem több.
Azt nem ismerem, viszont bejönnek az Andoid vagy az iPhone 3D-s UI megoldásai...
Kár hogy csak csicsa lényegében, a lényeg ugyan úgy 2D-s (hint: navigálni 2D-ben navigálsz).
Itt most a VRML-re gondolsz?
Akár, bár én OpenGL-re gondoltam konkrétan (csak késő volt és már fáradt voltam, grafikus API-t akartam írni).
-
-
ddekany
veterán
"A hang- és gesztusfelismerést át lehet ültetni a weboldalakra is. Ezen dolgozik az ARM. Az új generációs fórummotorok esetében ez komoly lehetőségeken nyitna meg."
Diktálni fogod amit írnál? Ilyen egyáltalán van már, ami megbízhatóan működik? Meglepődnék. Elég csak megnézni a YouTube beszédfelismerős feliratozóját... pedig gondolom ők komolyan veszik ezt, meg van sok szerverük is erre.
Egyébként nszvsz kapja be az összes cég aki ilyenekkel nyomul weben, mind 3D meg ilyen-olyan CL... Esetleg előbb az alap gondokat kéne helyrerakni. Az kutyát nem érdekel pl. hogy egy egyszerű szövegszerkesztőt nem lehet csinálni HTML/JS alapon, csak össze-vissza bugos/lassú szarokat. (Igen, ismerem a TinyMCE-t/CKEditor-t, amik 2011-ben azzal kezdik, hogy aláhúzós helyesírás kikapcsolva mert különben megkavarodnak... meg Google docs-ot ami bekezdésről még nem halott, stb., szóval Word 1.0 tudásban lealázza, sebességben meg kb. a föld közepéig). De nem gond ám... elvégre a formázott szöveg felvitel csak alapfunkció, ha weboldalakat tölt fel az ember (CMS-ek, vagy akár PH fórum). A Webes 3D meg a hanga, na aaaz a fontos... Konzum idiótaság a köbön. Abba már bele sem megyek, hogy a JS nem egy olyan nyelv, amivel más nyelveket implementálni tanácsos, meg úgy általában nem teljesítmény orientált sem karbantarthatóságra kihegyezett, ergo semmi keresnivalója nincs a "szabványos" stack alján. Erre is szarik mindenki. (OK, MS próbálkozik a CLR-el, de az meg az MS+Web kliens oldalon, szóval ez sem lesz soha elterjedt...) De nem baj semmi... legalább van munka, fizet mindenki mint a katonatiszt.
-
dezz
nagyúr
válasz
julius666
#72
üzenetére
Már vagy 10 éve kapható olyan agyhullámvezérlésű joystick, ami egy fejre rakható pántból és egy elemző egységből áll. Először még nagyon primitív volt, mostanra már talán használhatóvá vált, valamennyire. Ha a PC vagy a telefon kellő kapacitást tud erre elkülöníteni, nem csak kiváltható a külső elemző egység, hanem nagyobb kapacitás is rendelkezésre állhat, olcsóbbá és hatékonyabbá téve az egészet. Persze, nem csak a számítási kapacitáson múlik a dolog. De egyéb érdekes kutatások is zajlanak ilyen téren.
Láttam, hogy te is látsz (némi) rációt a beszédfelismerésben és társaiban. Az is igaz, hogy a legjobb, ha ezeket már eleve az OS tudja, vagy ha az nem, akkor a fejlődéssel lépést tartó browserek, amihez nem a WebCL a legoptimálisabb. (Viszont az OpenCL-lel nem tudom, mi a bajod, senki sem fog nekiállni mindezeket shader-asm-ben leprogramozni minden fajta GPU-ra.
)Viszont, addig sem kell feltétlen megállnia a fejlődésnek, amíg az OS/browser/browserplugin készítők megemelik a val...kat.
Amúgy van már valamelyik okostelefon platformra OpenCL implementáció? Lehet, hogy WebCL előbb fog megjelenni, mint az...
"Egyébként ezzel a 3D-s UI-val már piszok régóta próbálkoznak, mindeddig abszolút sikertelenül."
Talán megelőzték a korukat. Előbb meg kellett várni, amíg a jónép kiismeri magát a 2D-s felületeken.
"Sőt ha megnézed határozottan megfigyelhető trend az UI-k minimalizálódása mind design, mind egyéb téren. Az érintőképernyők terjedésével ez csak folytatódni fog (lásd Win8 csempés felülete)."
Azt nem ismerem, viszont bejönnek az Andoid vagy az iPhone 3D-s UI megoldásai... Egy harmónika-szerű fotóalbum is gyorsabban és kevésbé fárasztóan végigpörgethető, mint sok kis 2D-ben kiterített képecskét nézegetni.
"Max annyira hogy ha megjelennek normális 3D-s monitorok akkor ugyanazok a 2D-s felületek kapnak valami minimális mélységet is (kb. csak a csicsa, valódi funkcionalitás nélkül)."
A zárójeles részben nem lennék annyira biztos.
"Ehhez pedig 3D-s leíró nyelv meg driver kell, semmi más, ezek eddig is rendelkezésre álltak."
Itt most a VRML-re gondolsz? Az valahogy nem jött divatba (talán túl korai volt neki, vagy nem tudom). Vagy nem platform-független megoldásokra? Azok egyre inkább "felejtősek"... Ami az OpenCL-t illeti, az elvileg platformfüggetlen, viszont a gyakorlatilag nem annyira. Az WebCL viszont az. Mint ahogy a WebGL is.
-
julius666
addikt
Hosszabb távon megjelenhet pl. a közvetlen agyak közötti kommunikáció, és lehet, hogy ehhez nem kevés asszisztencia is kel majd. Ki tudja, mit hoz a jövő...?
Ez 10 év múlva még mindig csak sci-fi lesz, ezt nyugodtan veheted készpénznek.
Addig amíg ilyesmiről realitásként beszélhetünk még le fog folyni pár programozói paradigma meg hardverarchitektúra a Dunán, erre felesleges már most felkészülni. Eleve kétlem hogy a jelenlegi architektúrák ilyesmire képesek lennének egyáltalán (pontosabban nyilván bármire képesek, csak az más kérdés milyen hatékonysággal).Hangvezéerlés, beszéd- és emóció-felismerés, tekintetkövetés, stb. stb.
Ez viszont realitás, ha elolvasod az első hozzászólásomat akkor ezt pont mint az átlaguser számára is értelmes GPU-kihasználási lehetőséget tartom.
Ez a flatness is elég unalmas már, akár OS, akár web szinten.
Unalmasnak lehet hogy unalmas, viszont nincs jobb. Egyébként ezzel a 3D-s UI-val már piszok régóta próbálkoznak, mindeddig abszolút sikertelenül. Sőt ha megnézed határozottan megfigyelhető trend az UI-k minimalizálódása mind design, mind egyéb téren. Az érintőképernyők terjedésével ez csak folytatódni fog (lásd Win8 csempés felülete). Egész egyszerűen a jelenlegi eszközeink mellett ez az optimális, illetve mi emberek sokkal könnyebben igazodunk el 2D-ben hiába 3D-s világban élünk. Ez van, nagy változásokra ilyen téren sem számítok az elkövetkezendő 10 évben. Max annyira hogy ha megjelennek normális 3D-s monitorok akkor ugyanazok a 2D-s felületek kapnak valami minimális mélységet is (kb. csak a csicsa, valódi funkcionalitás nélkül). Ehhez pedig 3D-s leíró nyelv meg driver kell, semmi más, ezek eddig is rendelkezésre álltak.
Azt nem értem, miért ne lehetne több-kevesebb WebGL és WebCL kód a lapokon.
Hol mondtam én hogy nem lehetne? Én csak annyit mondtam, az átlaguser nem fog sokat belőle profitálni, mert a játékokon meg képfiltereken kívül nem lesz normális felhasználási terület a számára. Hétköznapi feladatoknál (e-mail, hírolvasás, közösségi háló) egyszerűen nincs rá szükség.
Persze be lehet tenni trükkösebb transition-öket, animációkat meg ilyesmiket user input eventekhez, amit aztán ki lehet dobni GPU-ra, ami gyorsabban/hatékonyabban számolja ki a nagyszámú lebegőpontos műveletet, de ha már a fogyasztáson skótoskodunk, akkor lehet egyszerűbb lenne ezeket eleve mellőzni. Meg nem mellesleg ezek nem fogják jobbá tenni az user életét, ezek jellemzően 10 percig mókásak, utána egyre inkább zavaróak.
-
dezz
nagyúr
válasz
julius666
#64
üzenetére
Hosszabb távon megjelenhet pl. a közvetlen agyak közötti kommunikáció, és lehet, hogy ehhez nem kevés asszisztencia is kel majd. Ki tudja, mit hoz a jövő...?
Rövid távon is sokmindent el lehet képzelni. Valószínű előbb-utóbb visszaszorul pl. a billentyűzet használata (és majd az egéré is). Hangvezéerlés, beszéd- és emóció-felismerés, tekintetkövetés, stb. stb.
Ez a flatness is elég unalmas már, akár OS, akár web szinten.
"Pl. azért, mert egy használhatóbb beszédfelismerő/mintafelismerő forráskódja sok(tíz)ezer sor."
Jó, persze, én sem úgy értettem, hogy az ilyen nehézsúlyú dolgok mind 1-1 adott weblap kódjában lennének. Azt nem értem, miért ne lehetne több-kevesebb WebGL és WebCL kód a lapokon.
(#65) Blindmouse: Mindketten tudjuk, hogy ez egy szintetikus teszt, ami messze nem mond el mindent.
(#70) Zeratul: Nem hiszen, hogy ez lett volna a cél, ahhoz túl gyenge a PPE, mint normál CPU mag. Inkább egyfajta co-procinak szánták egy nagyteljesítményű hagyományos CPU mellé, már ami az IBM-et illeti. Pl. a Roadrunner is eléggé ott van még a szeren, és van egy pár kistestvére is. A projekt fő szponzora, a Sony a maga részéről eleve a PS3-ba szánta, a Toshiba pedig TV-kbe, médiaplayerekbe, stb.
[ Szerkesztve ]
-
#70
Zeratul
addikt
Blindmouse
#69
Zeratul
addikt
válasz
Blindmouse
#69
üzenetére
A Cellt az X86 és az Itanium ellen szánták, ahhoz képest a konzolban landolni nem egy óriási karrier.
[ Szerkesztve ]
-
#69
Blindmouse
senior tag
Blindmouse
senior tag
Szűklátókörűség. Mondhatnám, hogy RISC, meg újra kell tanulni programozni, mostmár úgy ahogy eleve kellett volna, de felesleges. Arra a csodás Cisc-re ami olyan sokat tud fordítóprogramot nem tudnak írni, de csak dobáljuk bene az SSE40 meg többi utasítást, és amire felhozza a memóriából a kódot, addigra az ARM kiköpte a végeredményt a Thumb-jával. Ha meg elágazás lenne akkor x86 lehúzza a wc-n a 30 lépcsős pipeline-ban mindent, arm meg vállat von, és számolgat tovább, semmibevéve az eredményt. Folytathatnám a kontextusváltással meg hasonlókkal, de látom mindenki write only üzemmódban van.
Ja elvérzett a Cell, az a pármillió eladptt PS3 csak kerekítési hiba a bevételi oldalon...
[ Szerkesztve ]
3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace
-
#67
julius666
addikt
Blindmouse
#65
julius666
addikt
válasz
Blindmouse
#65
üzenetére
Egyszerűen nincs értelme arról vitatkozni, hogy számítási teljesítményben mikor hagyja le az x86-ot. Ha kevés a teljesítmény, teszünk még oda magot, kész
Ez feladatfüggő mennyire használható módszer. Ha szálakba/processzekbe jól szétbontható a feladat ami miatt szükséged van rá, teljesen jó, és ilyen területeken az ARM könnyen lekörözheti az x86-ot. Onnantól fogva viszont hogy egy szálon kell magas számítási teljesítmény, dobálhatod mellé a magokat.
-
#66
Zeratul
addikt
Blindmouse
#31
Zeratul
addikt
válasz
Blindmouse
#31
üzenetére
Igaz is lehetne a clock to clock teljesítménye megegyezne az ARMnak és az X86nak, de utóbbi jóval többet tud és többet is zabál.
-
#65
Blindmouse
senior tag
acsa77
#40
Blindmouse
senior tag
acsa77: szerverek, meg átfordítani... régóta minden .Net-be meg Javába van megírva, Java már fut ARM-en, silverlight is, szóval nagyon nehéz lesz átfordítani mindent...
Egyébként az ARM marketingje épp az ellenkezőjét állítja mint amit mondasz:
A15 " combined with low power consumption", nem kellene hülyíteni a népet. Az intel meg addig kiad egy új architechtúrát, ami 10%-al gyorsabb lesz, ARM meg megduplázza a magok számát. Szerinted?lkandris : ARM != Android. Ha meg linuxra szerinted nincs fordító (gcc) akkor nem tudok segíteni.
dezz: Dhrystone MIPS. Mondj jobbat, hogy hasonlítsunk össze egy Risc-et egy CISC-el.
Abu85 : A Ph-t csak azért nem gyorsítja a GPU, mert ráférne egy új motor a RIOS-ra. Pl mobil browser támogatással...
Egyszerűen nincs értelme arról vitatkozni, hogy számítási teljesítményben mikor hagyja le az x86-ot. Ha kevés a teljesítmény, teszünk még oda magot, kész, ha elemről megy, lekapcsoljuk amikor nem használjuk. Eléggé meggyőző tud lenni, ha látsz egy olyan rendszert, amiben nincs akku, elem stb... kihúzod a tápot, és utánna még fél percig megy a rendszer kisebb kondikról mint ami egy PC tápegységben van.
3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace
-
julius666
addikt
Miből gondolod, hogy a jövőben emailen és chaten tartja majd a kapcsolatot egymással az átlagember?
Totál lényegtelen, érted mire gondoltam. Vagy szerinted fraktálokban fogunk 10 év múlva kommunikálni és azok megjelenítéséhez kell a kapacitás?
Azt sem értem, miért akarod mindenáron az OS-re vagy a browserre bízni az egészet?
Pl. azért, mert egy használhatóbb beszédfelismerő/mintafelismerő forráskódja sok(tíz)ezer sor. Már a beparse-olása is beszarás lenne. Meg nem látom értelmét hogy egy totál generikus feladathoz most minden oldal külön postáza le ugyan azt a rahedli kódot. Meg nem mellesleg oprendszerbe/driverbe építve akár le lehetne hardver-közelibben is kódolni a nagyobb teljesítmény érdekében.
A webes platform népszerűségének egyik oka amúgy is a könnyűsúlyúsága, hogy gyors implementációjú API-kból pikk-pakk össze lehet legózni egész komoly dolgokat egy magas szintű nyelven.
-
-
dezz
nagyúr
válasz
julius666
#60
üzenetére
Miből gondolod, hogy a jövőben emailen és chaten tartja majd a kapcsolatot egymással az átlagember?
A 3D-hez nem feltétlen kell (attól függ...), de az animáláshoz és az interakcióhoz nem árt.
Azt sem értem, miért akarod mindenáron az OS-re vagy a browserre bízni az egészet? Sokkal rugalmasabb és fejleszthetőbb, ha a kód nagy részt az oldallal töltődik be.
Az #58-ba beszerkesztettem a választ az #57-re.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz
julius666
#59
üzenetére
Már hogyne lenne köze. A PH-t hogyan tudod gyorsítani GPU-val? Nem sok ilyen tartalom van rajta. A HTML5-ön belül viszont számos olyan tartalmat használhatsz, ami GPU-val gyorsítható.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
julius666
addikt
Éppenséggel a Direct2D és a DirectDraw gyorsítás pont, hogy általánosan előnyös a fogyasztásban.
Persze, ezt említettem én is.
Minél több HTML5-ös oldal lesz, annál kevesebb fogyasztást fog igényelni azok megjelenítése, ha azokat GPU-val gyorsítod
Továbbra sincs semmi köze a HTML5-nek a hardveres gyorsításhoz, már párszor leírtam. Élmény veled vitatkozni.
-
dezz
nagyúr
válasz
julius666
#55
üzenetére
Szerinted 10 év múlva is ilyen flat (szöveg+pár kép) lesz a net?
(#57): "a CPU pedig önmagában jellemzően kevesebbet zabál adott idő alatt"
Ez csak akkor igaz, ha egy sokszoros peak FLOPS teljesítményű GPU hasonlítasz egy CPU-val. Viszont adott fogyasztás mellett is többszörös peak FLOPS teljesítményű a GPU. A többi már csak azon múlik, hogy az adott feladat mennyire fekszik a GPU-nak, azaz mennyit lehet kihasználni a peakből a gyakorlatban. Ebben nagyon sokat fejlődtek a GPU-k az elmúlt években és ma is nagy léptekkel halad a dolog.
"A jelenlegi GPU-gyorsított enkóderek mindenesetre nagyon ganék."
Elsősorban a sebességre mentek rá, de azt hiszem, létezik profi, minőségi megoldás is.
[ Szerkesztve ]
-
julius666
addikt
Most hirtelen csak ezt találtam, 2008-as, de olyan nagyot nem javult a helyzet azóta: [link]
Ha jól értem, azért tartod túlspilázottnak, mert nem tudod elképzelni, mire is lehetne használni.
Már hogyne tudnám elképzelni. Olyat nem tudok elképzelni amiből az átlaguser jelentősen profitálna. Pontosabban de, de csak 1-1 területen (pl. az említett webes képszerkesztők).
Szerintem ez tévedés.
Szerintem meg nem.
Láttam rendes teszteket (nem a kamu megrendelt marketinganyagokat) és ~ugyanazon a minőségen az x264 pl. gyorsabb/közel ugyanolyan gyors volt mint a hardveres megoldások. Csak mellette sokkal jobban skálázható többek közt.FLOPS/W alapon nagyon nem így van!
És ki nem szarja le a FLOPS/W értéket? A Flops az csak egy szám, e-pénisz.
Az számít, tömörítésnél azonos minőségű tömörített kimenet mellett melyik zabál kevesebbet: mivel közel azonos idő alatt végeznek, a CPU pedig önmagában jellemzően kevesebbet zabál adott idő alatt, szerintem nem kell matematika professzornak lenni ahhoz hogy kitaláljuk összességében melyik a nyerő.Ezt kifejtenéd bővebben? Szerintem ez csak a korábbi GPU generációkra igaz, amiket megfektettek a feltételes ugrások. A maiak egyre jobban boldogulnak vele.
Igen, illetve a nagy latency sem vált az előnyükre (nyilván ez egyre csökken, de még továbbra sem az igazi), nehézkes threading modell, meg még vannak problémák.
Bizonyos részeire alkalmas lenne (pl. mozgásvektorok keresése), bizonyos részeire gyakorlatilag alkalmatlan (pl. entropy coding).
A jelenlegi GPU-gyorsított enkóderek mindenesetre nagyon ganék.Azt tudom hogy régebben az x264 fejlesztői nagyon kacsingattak a dolog felé, de az eredmény egyértelműen nem azóta is. GSOC-ra évek óta ki van írva a mozgásvektor-keresés GPU-gyorsítottra megírása, mindeddig sikertelenül.
-
Abu85
HÁZIGAZDA
válasz
julius666
#55
üzenetére
Pont erről beszél az ARM is. A számításigényes feladatok minek terheljék a CPU-t, amikor a GPU kisebb erőforrásigényből megoldja, és ezzel még akkuidőt is nyertél.
Éppenséggel a Direct2D és a DirectDraw gyorsítás pont, hogy általánosan előnyös a fogyasztásban. Ez is kihasználható már pár oldalon. Minél több HTML5-ös oldal lesz, annál kevesebb fogyasztást fog igényelni azok megjelenítése, ha azokat GPU-val gyorsítod.
Az ARM víziója szerint az eszközöd állandóan a netre csatlakozik, vagyis azok a programok, amiket jelenleg még külön böngésző nélkül futtatsz átkerülnek a webre. A webalapú programok jelentik a vállalat víziójában a jövőt. Minél jobban el kell osztani a terhelést a SoC-on belül, egy APU jó kihasználásával üzemidőt nyersz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
julius666
addikt
Dehogynem alkalmas rá. A Youtubeon a videót ki nézi teljesen procival?
A videólejátszás gyorsítására igen, alkalmas. Ugyanúgy alkalmas a canvasos/WebGL-es animációk gyorsítására, értelemszerűen. De ennyi, és ehhez nem kell OpenCL/WebCL.
A WebCL másra kell, például a javascript helyébe léphet, az ARM szerinte erre nagy esély van.
Dehogy válthatja. Ez a kijelentés önmagában is nevetséges, mivel javascriptből kezeled az egész WebCL-es mizériát. Ha valami válthatná a javascriptet, az max a Chrome-féle natív kliens lehetne, amin natúr C-ből/C++ból fordított bináris kódokat lehet futtatni.
Itt csupán arról van szó, hogy ki lehet számításigényes feladatokat dobni a WebCL-motornak javascriptből (amiről már hsz-ek óta beszélek).
Ez nagyon klassz és hasznos, de a PH! ettől nem fog hamarabb betölteni, sem PH!-zás közben kevesebbet enni a vas fogyasztásban (nyilván mindenki azt helyettesít be oldalnak amit akar, az átlaguserek által naponta látogatott oldalakról beszélünk itt). Márpedig mindenki ezt várja tőle, majd "minden a GPU-n fut mer' az gyorsabb", a marketing is ezt tolja és én már nagyon unom.
Webalapú képszerkesztőket (a számításigényes dolgokat kidobva GPU-ra, ugye az pont alkalmas a "sok adatot ugyanúgy manipulálunk párhuzamosan" jellegű feladatokra) meg nagyon szép demókat lehet vele összepakolni, klassz fizikai számításokat végezni ami eddig esélytelen lett volna, de ennyi. Ebből az átlaguser max. a fotószerkesztőt ha látja.
-
#54
dezz
nagyúr
Blindmouse
#31
dezz
nagyúr
válasz
Blindmouse
#31
üzenetére
Mint ha csak a nyers MIPS számítana...
Egyátalán, hogy lett mérve? SIMD benne volt?(#32) Zso2: Ha Atomot írt volna (aminél a Brazos csak úgy 20-30%-kal gyorsabb, mag-mag), akkor is csodálkoznék. De lehet, hogy csak én vagyok lemaradva.
(#40) acsa77: "az Intel ellen az Intel területén"
Éppenséggel a GPU-k nagyon nem az Intel területe, márpedig az ARM is "APU" és heterogén programozás irányba tart. Mert a klasszikus CPU jellegéből adódóan kevés az igazán számításigényes feladatokra.
(#41) lkandris: Az Android ugye nagyrészt egy UI + Java környezet egy Linux kernel fölött, már ha jól vettem ki (túl sokat még nem foglalkoztam vele). Miért ne lehetne megoldani pl. egy fordítást? Mi hiányzik hozzá, amit nem lehet app-ként megvalósítani? Illetve nem tudom, van-e lehetőség hozzányúlni az alatta lévő kernelhez.
(#42) Youri: Mint pl.?
(#47) julius666: Ha jól értem, azért tartod túlspilázottnak, mert nem tudod elképzelni, mire is lehetne használni. De akkor miért nem kérdezed meg, hogy hé gyerekek, mire lehet ezt használni?
(#48): "Értsd: ugyanazon minőség/bitráta arány mellett a CPU-s kódolás gyorsabb és így energia-hatékonyabb is"
Szerintem ez tévedés.
"(CPU-k jellemzően kevesebbet esznek a GPU-knál)."
FLOPS/W alapon nagyon nem így van!
"A GPU-k architektúrája egyszerűen nem ideális a videókodolási folyamat lépéseinek többségére."
Ezt kifejtenéd bővebben? Szerintem ez csak a korábbi GPU generációkra igaz, amiket megfektettek a feltételes ugrások. A maiak egyre jobban boldogulnak vele.
-
Abu85
HÁZIGAZDA
válasz
julius666
#52
üzenetére
Dehogynem alkalmas rá. A Youtubeon a videót ki nézi teljesen procival? Sokkal többet fogyasztana, mint a GPU-k erre felkészített feldolgozómotorjával.
GPU-val még post-processre is van lehetőség, ha szeretnéd. Ezt már ma is ki tudod használni, nem a jövő webtartalma, és az akkuidőben durván meg fog látszani a különbség.A WebCL másra kell, például a javascript helyébe léphet, az ARM szerint erre nagy esély van (az akkuidő miatt a javascript nem kellemes jelenség az netes tartalomban, de jelenleg nincs alternatíva). Képzelj el például egy webes, fejlett fényképszerkesztőt.
A Nokia már kísérletezik a WebCL-lel. [link] - Az FF6-hoz tölthető egy kiterjesztés, amivel már bárki dolgozgathat.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
julius666
addikt
A hang- és gesztusfelismerést át lehet ültetni a weboldalakra is.
Csak nem a weblap motorja fogja feldolgozni a hangjeleket/egyebeket. Az már majd a feldolgozott anyagot (szöveg/gesztusfelismerésnél kész eventek) készen kapja, a feldolgozást a driver/oprendszer végzi, OpenCL-el/natív kóddal/akármivel amiben megírták. Tehát itt nem fog a WebCL egy büdös betűt sem csinálni.
Az IGP energiatakarékosabban dolgozza fel a webes tartalmakat.
Mi az hogy az IGP feldolgoz webes tartalmat? Az IGP nem dolgoz fel webes tartalmat, mivel nem alkalmas rá. Láncfűrésszel nem tudod kifesteni a lakást hiába nagy a teljesítménye.
Az IGP (vagy mondjunk inkább GPU-t) az gyönyörűen megcsinálja a layoutot meg a kirajzolást, de ehhez nem kell sem OpenCL, sem WebCL. Ez működött eddig is.DOM nodeokat kezelni/felépíteni, javascriptet futtatni nem fogsz GPU-n, az hétszáz.
-
Abu85
HÁZIGAZDA
válasz
julius666
#50
üzenetére
A hang- és gesztusfelismerést át lehet ültetni a weboldalakra is. Ezen dolgozik az ARM. Az új generációs fórummotorok esetében ez komoly lehetőségeken nyitna meg. Természetesen ennek részesei leszünk PC-n is, hiszen szabványszinten ez az egész átkarolja az összes terméket. A CPU tehermentesítését pedig a mobil piacon egyértelműen sürgetni kell. Az IGP energiatakarékosabban dolgozza fel a webes tartalmakat. Ez már most kimutatható, később a szabványok finomodásával jobb lesz. Mobil terméknék az üzemidő szempontjából nem mindegy, hogy a CPU, vagy az IGP lesz túráztatva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
julius666
addikt
A CPU csak kismértékben határozza azután meg az internetes megjelenítés sebességét. Mint "Javascript leváltó" a WebCL ebben komolyan benne lesz. Legalábbis az ARM szerint.
Aha.
A WebCL az az OpenCL webes megfelelője, hasonlóan a WebGL <-> OpenGL-hez (gondolom hasonló butításokkal és korlátozásokkal). Pont ugyanannyit fog tudni (pontosabban csak még kevesebbet), mint az OpenCL. Tehát bizonyos feladatokat, amik alkalmasak rá (a GPU hatékonyan el tudja végezni őket, azaz kb. jól párhuzamosítható számítási feladatok), ki lehet vele zavarni GPU-ra. Az átlaguser szempontjából ez totál irreleváns, mert ő (játékokon kívül) semmi olyat nem használ ahol ilyesmire szükség lenne. Hogy a búbánatba segítene a WebCL ott ahol az OpenCL sem tudott? Nem azt mondom hogy semmi értelme ezeknek a dolgoknak, de a professzionális szakterületeken kívül messze nem lesz ez akkora durranás mint beharangozzátok. A cikkben említett területek az elsők ahol a játékokon kívül is látom valamiféle értelmét.
Az oldalrender hardveres gyorsításához meg eddig sem kellett OpenCL.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz
julius666
#47
üzenetére
WebCL. Erről is beszélt az ARM. Az okostelefonok proci része erősödik ugyan, de nagyon messze van a PC-s szinttől. A WebCL-lel ez a probléma is megoldódik. Úgy gondolják, hogy 2013-tól már elterjednek azok a webes szabványos, amelyek főleg a GPU-t terhelik. A CPU csak kismértékben határozza azután meg az internetes megjelenítés sebességét. Mint "Javascript leváltó" a WebCL ebben komolyan benne lesz. Legalábbis az ARM szerint.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
julius666
addikt
Megoldani meg lehet, de hatékonyságban elmarad a klasszikus CPU-s megoldásokétól. Értsd: ugyanazon minőség/bitráta arány mellett a CPU-s kódolás gyorsabb és így energia-hatékonyabb is (CPU-k jellemzően kevesebbet esznek a GPU-knál). A GPU-k architektúrája egyszerűen nem ideális a videókodolási folyamat lépéseinek többségére.
Tehát CPU-s "szoftveres" tömörítők >>> GPU-s "hardveres" tömörítők. A marketingnek ne tessék felülni.
-
julius666
addikt
Ok egyébként végre egy felhasználási terület ahol a szvsz messze túlspilázott heterogén programozásnak végre az átlaguser is hasznát fogja látni.
Ugyanis mindenki várja itt mint a messiást, de professzionális alkalmazásokon meg játékokon (fizika, újfajta effektek, raytracing elemek beépítése a raszteres motorokba) kívül még mindig nem látom hol fog ez áttörést hozni. -
vanhalen
senior tag
"(Minden esetre én is érdeklődve várom, mit fog ez tudni Win8 + Office terén... Égés lesz vagy ellenkezőleg?)" Nemrégiben demózták Win8 (asszem alfa) + Office teljesítményét egy előadáson pár hónapja. Nem emlékszem, hol lehet a video, de ha keresel, megtalálod. Teljesen elfogadható sebességűnek tűnt (nekem) és még lényegében kész sincs.
-
lkandris
tag
Ha nem is a kódolás felé kacsintgatnak az emberek, egyre többen szerkesztik meg saját kis videójukat maguknak az emberek amiben ugye nagy szerepe van a youtube-nak. Nem vagyok benne biztos, hogy belátható időn belül piacra kerülne valami életképes alternatíva mobilplatformon (habár itt a tegra, a gpu kódolás nem megoldhatatlan). Ki tudja.
Viszont irodai szinten igazad van.
[ Szerkesztve ]
-
ddekany
veterán
Mondjuk amit említettél, az csak programozóknak kell, igen szűk réteg. Ráadásul általában a jó egyszálas CPU teljesítmény a fontos ott, abban meg nem valószínű az Intel trónfosztása. (Minden esetre én is érdeklődve várom, mit fog ez tudni Win8 + Office terén... Égés lesz vagy ellenkezőleg?)
-
lkandris
tag
-
#40
acsa77
tag
Blindmouse
#31
acsa77
tag
válasz
Blindmouse
#31
üzenetére
Ez csak azt mutatja, hogy egy meglehetősen régi, megjelenésekor is meglehetősen rossz hatásfokú architektúrát majd jövőre utolér egy új. Egy olyan maximális órajelen, mely nem mobil eszközökbe megy. (Az ARM úgy marketingel, hogy "csak" a fogyasztás a gát - pont a legfontosabb terület, ami nagyon lassan fejlődik.) És addig még sok víz folyik le a Dunán. És hiába szánják szerverekbe is a processzort, nem fog egy komplett iparág hipp-hopp átfordítani mindent egy meglehetősen másképp működő, más hátterű architektúrára, melynek gyors fejlődése és átalakulása pont gátja még a terjedésének. Majd ha az ARM jövőképe beválik, akkor tényleg lesz esélye az Intel ellen az Intel területén. Persze addig, azaz 2-3 évig, az Intel ne fejlesszen semmit...
-
#39
Plazmacucci
félisten
Egon
#38
-
Abu85
HÁZIGAZDA
válasz
julius666
#35
üzenetére
Pontosa ezt emelték ki az előadáson, hogy a GPU és a CPU heterogén módon történő kihasználásával ez lehetségessé válik. Most ezt hiába tudod megcsinálni elméletben, a gyakorlatban nem fog működni, mert nincs meg a teljesítmény.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
julius666
addikt
A felhasználói interfészen belül az innovációt az OpenCL felület szolgáltatná, amelynek segítségével lehetővé válna számos új vezérlési forma, mint például a hang- és a gesztusfelismerés, illetve a kiterjesztett valóság.
Mi köze van az UI-nak az OpenCL-hez? Mert nagyon mást nem látok hogy lehetővé teszi a GPU-n számítást nagy a jól párhuzamosítható, GPU-n számítható feladatok terén, amivel esetleg lehetne hangfelismerést / gesztusfelismerést / mintafelismerést a kamera képéből a GPU-n is számítani...
[ Szerkesztve ]
-
Ultraphone mikor lesz?
Tényleg, azt tudja valaki, hogy a Li-Poly aksikat miért nem gyártják már? 6310i-m még mindig elmegy 5-6 napot Anno 7-8at is kibírt kaja nélkül.A Harry Potter film egy Die Hard koppintás. A főhős éjnek évadján egy toronyban rohangál össze-vissza, és próbálja elkerülni Alan Rickmant.
-
Zso2
őstag
Nem ,ez inkább + hsz volt.. semmi bajom az ARM-al, ennyire nem vagyok Intel párti,hogy mindenhova Intel procit szeretnék
. Inkább a mobiltelók kihalására céloztam, mert ezek már nem telefonok, hanem inkább zsebpc-k amiken lehet telefonálni is
..de te meg ahogy látom ráugrottál a Brazost cikizőre egyből..[ Szerkesztve ]
Adelante ALONSO - Forza Ferrari | BF3-- satazso | Intel Core + Windows = Jaguar, behúzott kézifékkel.
-
#31
Blindmouse
senior tag
acsa77
#22
Blindmouse
senior tag
Váó. Tudnám ennyi hülyeséget honnan szedtél össze.
Wikipedia:
ARM Cortex-A15 (Quad Core) 35,000 MIPS at 2.5 GHz
AMD Phenom II X4 940 Black Edition 42,820 MIPS at 3.0 GHz
oszd le a Phenom órajelét, esetleg a magszámát is.
Fojtatnám, de munkába kell mennem, ARM-re programot írni...3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace
-
ddekany
veterán
"Win8-nál meg az alkalmazások túlnyomó része probléma nélkül futni fog tetszőleges hardveren merthogy silverlight..."
Hogy az MS esetleg sok mindent átír .Net-re a Win8-ba beépített alkalmazások közül, az ilyen szempontból szinte mindegy, mert ha ők valóban rendesen támogatni fogják az ARM-et, akkor ami nem .Net azt úgyis kénytelen újrafordítani az ARM-is Win8-hoz. A többieknek meg nem lesz .Net-es átirata a büdös életben az eleve nem úgy fejlesztett programokból, és ezen Win8 nem segít. Szóval marad nekik az újrafordítás... -
#29
dezz
nagyúr
Don't Panic
#1
dezz
nagyúr
válasz
Don't Panic
#1
üzenetére
Már évekkel ezelőtt lehetett hallani bizonyos szuperaksikról, többszörös kapacitással, de sehol semmi... Pedig szupertelóhoz szuperaksi dukál!
(#2) Helmoras: Már van olyan, de úgy látszik, alattomos módon előre ki akarják spórolni!
(#7) Krugszvele: Pl. a S.-E. Xperia X10 Mini-Pro kihúzható mini-billentyűzetén egész jól lehet írni. (Kár, hogy ez egy eléggé egyedi megoldás, jó lenne, ha elterjedne és jóval több típusból lenne ilyen változat.) De vannak B.T.-s billentyűzetek is (bár ahhoz nem árt egy asztal is).
(#12) Zso2: Ezt ugye most nem azért írtad, mert nem Intel proci van benne?
(#15) Tigerclaw: Miért baj az, ha egy olyan eszköz, amit az ember még a wc-re is magával visz, egyre többet tud? Nyilván nem fogja teljesen kiváltani a laptopot, de pl. egy 480x800-as képernyőn is igen sokmindent lehet csinálni.
A videotelefonálás már nem újdonság, pár telón direkt emiatt van előrefelé is egy kamera. (Csak mondjuk ez még sehol sincs benne a korlátlan adatforgalomban.)
(#16) Blindmouse: "már az A15 állva hagyja a csodálatos Brazost teljesítményben"
Erről valami forrás? Ugye nem csak a magszámból és a frekiből indultál ki?
(#24) Youri: Elsődleges internetező cucc.
[ Szerkesztve ]
-
#26
Angel1981
veterán
Krugszvele
#7
Angel1981
veterán
válasz
Krugszvele
#7
üzenetére
+1
Hogy váltana már ki egy laptopot, amin sokan komolyan dolgoznak?
Ugyan már! -
#25
Krugszvele
senior tag
Blindmouse
#16
Krugszvele
senior tag
válasz
Blindmouse
#16
üzenetére
Dokkoló eddig eszembe se jutott: ez megoldja a töltés, a kijelző és a beviteli eszközök problémáját is!
Na, majd kiforrja magát.
-
domi007
őstag
Azért ennek egy része már nem jövőkép, pl. 1080p videó felvétel és visszajátszás HDMI-n (Optimus 2x, Sensation stb.)
"̶d̶e̶ ̶a̶ ̶t̶u̶d̶o̶m̶á̶n̶y̶ ̶m̶a̶i̶ ̶á̶l̶l̶á̶s̶a̶ ̶s̶z̶e̶r̶i̶n̶t̶ ̶a̶z̶ ̶i̶p̶a̶r̶i̶ ̶m̶é̶r̶e̶t̶e̶k̶b̶e̶n̶ ̶i̶s̶ ̶h̶a̶s̶z̶n̶á̶l̶h̶a̶t̶ó̶ ̶S̶H̶A̶1̶ ̶c̶o̶l̶l̶i̶s̶i̶o̶n̶t̶ ̶g̶e̶n̶e̶r̶á̶l̶ó̶ ̶e̶s̶z̶k̶ö̶z̶..." - 2017. február 23. óta már létezik
-
acsa77
tag
válasz
Alchemist
#20
üzenetére
Az "egyszerűt" nehéz megfogalmazni. Én az előbb pont az egyszerűeknél említettem a GPU-t, ahol ugye többszörös teljesítménynövekedésnek örülnek sokan. A bonyolult pont az, amikor intelligensebb szolgáltatásokra van szükség, amiket pont egy hordozható készüléktől is várunk.
De van olyan másik értelmezése az egyszerű folyamatnak, amikor sima irodai munkában fordul elő nem ritkán, hogy igen nagy x86-teljesítményt igényel. És sem ARM-jellegű sem GPU-jellegű processzorokon nem programozható. Pl. egy kis helyi, kicsit bonyolult adatértelmezés, aminek kattintásra kell mennie.
Az persze más kérdés, hogy a szórakozásra és esztétikára szánt multimédiás szolgáltatások mennyire hajtják a fejlődést és alakítják át az ipart, és hogy mennyire alkalmazkodnak hozzá a platformok (az ARM nagyon). De ez hasonlít arra, amikor a játékipar is hajtotta a fejlődést a gyakran újrainduló termékciklusokkal stb., miközben önmagában szinte teljesen haszontalan volt. Mint a multimédia is jelentős részben. Mondom ezt úgy, hogy mindkettőt élvezem én is, de nem dőlne össze a világ, ha hirtelen nem lennének.
-
#21
T-bag
tag
Blindmouse
#16
T-bag
tag
válasz
Blindmouse
#16
üzenetére
Brazos APU, A15 csak CPU szóval elég állatság amit írtál.
-
Alchemist
addikt
Biztosan lesznek olyan jelentős fejlesztések, amelyek optimalizációval együtt is csúcsra járatják a legnagyobb teljesítményű procikat... viszont az egyszerűbb feladatok simán mennek majd az ARM-on is.
Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
#18
acsa77
tag
Blindmouse
#16
acsa77
tag
válasz
Blindmouse
#16
üzenetére
Ha gameover, akkor szerveroldal megszűnése miatt az ARM-nak is gameover 99%-ban. De ügyféloldalról is gameover az IT-munka 90%-nak, akár folyamatos, akár pillanatnyi CPU-terhelésről van szó (válaszidő...). Meg temetik az eredeti GPU-kat is - akkor az egyszerűsített számítások is mehetnek a kukába. És azért teljesítmény/W ill. teljesítmény/mag terén nem éppen fényes az ARM, és még most sem elég gyors egy x86-mag (vagy bármilyen hasonlóan rugalmas CPU). Az AMD-t is ezért ekézik még most is, ezen múlik a túlélése, hogy pl. bővülhessen a szerverpiacon. Az ARM-platformok "csak" kiegészítői az x86-nak, egyfajta ügyes kezei, akár szerveren, akár PC-n mennek a fő folyamatok. Tehát szintén nélkülözhetetlenné váltak.
És ha nő középtávon az AI-igény, akkor sem valószínű, hogy elhagyhatók a nagy teljesítményű, rugalmas magok, mint az x86. Vagy az ARM is lényegében x86-hoz hasonlóvá válik. Akkor persze mindegy, mi lesz a neve. De addigra az Intel sem lesz hülye, hogy kihagyja a fejlődést a mobil szintekre.
-
Srodney
senior tag
tök jó hogy mire lesznek képesek a telefonok,de belerondít a jövőképbe az a tény hogy ezek csak úgy lesznek gazdaságosak,mármint az előállításuk gazdaságos,ha jelentősen csökkentik az élettartamukat és újat és újat vásárolunk...a tervezett elavulás egyre nagyobb...
[ Szerkesztve ]
-
#16
Blindmouse
senior tag
Blindmouse
senior tag
Fogyasztás -> órajelkapuzás, maglekapcsolás
Teljesítmény -> már az A15 állva hagyja a csodálatos Brazost teljesítményben, és az egész platform töredékét fogyasztja mint az AMD proci
Akku -> fejlődik az, csak nem az android gagyifonoknak (lásd apple)
Kijelzőméret-> dokkolóÉn mindig is mondom, Game over x86.
3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace
-
Tigerclaw
nagyúr
Remélem nem így lesz. Szerintem a telefonoknak továbbra is a kommunikációról kellene szólnia, nem arról, hogy minden létező számítástechnikai és multimédiás kütyüt megpróbálnak belesűríteni.
Elmehetnének pl. a videotelefonálás irányába, sőt abból később csinálhatnának 3D videotelefont is (persze a szemüveg nélküli verziót. Ez javítaná a kommunikációt, de ehelyett házimozit és hasonlókat próbálnak csinálni a telefonból és lassan 5 inches lesz a kijelző, mert sehogy nem lehet rajta rendesen netezni és hasonló dolgokat csinálni. Persze a világ végén vészhelyzetben megfelel sok mindenre, de ha a tablet is egy nagy kompromisszum, akkor ezekre mit lehet mondani?
Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.
-
Zso2
őstag
Magyarul , ezek már nem telefonok, hanem zsebben hordozható agyzsugorítók, vagy a 12mp-ről még valami nagyobb kategóriás fényképezőgép jut eszembe...
Tényleg a telefon kifejezés már nem is illik rá,mert az a legkevesebb amit tud. Szerintem inkább nanonettop legyen[ Szerkesztve ]
Adelante ALONSO - Forza Ferrari | BF3-- satazso | Intel Core + Windows = Jaguar, behúzott kézifékkel.
-
oO7
őstag
valszeg igen, arról van szó, hogy a "hagyományos" x86 -os procikkal megegyező (vagy jobb) teljesítményt és fogyasztást tud majd produkálni az ARM -es proci...
Win8 -nál meg az alkalmazások túlnyomó része probléma nélkül futni fog tetszőleges hardveren merthogy silverlight... a natív alkalmazásoknál meg ideális esetben csak egy recompile oszt annyi... -
ddekany
veterán
Hagyományos laptop kiváltása tömegesen érdekes attrakció lenne azért. Eleve Android mint OS Windows helyet... azt hiszem nem kicsit fogná vissza a térhódítás. Ha meg Win8, és rendes Office, stb, akkor labdába rúg ez mondjuk egy Brazos C50 súlycsoportban (9W, stb) sebességben? Meglepődnék, de amúgy nem tudom... (Persze a legtöbb Win-es alkalmazásnak nem lesz egyhamar ARM-ra fordított változata, és innentől kezdve lehet, hogy nem is jobb mint az Android...)
[ Szerkesztve ]
-
#8
oO7
őstag
Krugszvele
#7
oO7
őstag
válasz
Krugszvele
#7
üzenetére
ez most ám csak egy processzor... és az "enough compute power to replace your laptop" az arra vonatkozik, hogy a "hagyományos" lapptopokat (processzorokat) teljes mértékben ki tudja majd váltani... de itt szó nincs arról, hogy egy mobiltelefon akarná kiváltani a notikat...
-
#7
Krugszvele
senior tag
Krugszvele
senior tag
A három legnagyobb probléma nem oldódik meg:
- akkumulátoros üzemidő
- kijelző mérete
- adatbevitel egyszerűségeEgy blogbejegyzést is siralmas megírni mobilon, akkor dolgozni hogy lehetne rajta? Egy excel táblát megnyitni és megkeresni benne valamit... nehéz.
-
#6
zsirfecske
addikt
zsirfecske
addikt
28 nm, négy Cortex-A15 és Mali-T604 gpu? atyaég, egy jó hdmi-vel a win8 tablet nekem jöhet is. dokkolva akár munkára is. töredék fogyasztás és súly egy notihoz képest. kell, na.
-
#5
Don't Panic
senior tag
jimmy399
#4
Don't Panic
senior tag
-
jimmy399
senior tag
Hm, szerintem ha nem fejlesztenek a gyártók, akkor lassan ismét táskányi méretű akkumulátorok kellenek ahhoz, hogy kihúzzanak 3-4 napto is töltés nélkül... CSak az nem vicces, hogy a hátunkon van egy egész hátizsák, hogy életben tartsa a telót... Lassan feltalálhatnák a mini atomerőművet, ami alatt többször kellene cserélni a telót, mint akksit xD
[ Szerkesztve ]
--- N/A ---
-
#2
Helmoras
őstag
Don't Panic
#1
Helmoras
őstag
válasz
Don't Panic
#1
üzenetére
+1, illetve én örülnék adott esetben a "vezeték nélkül küldje a tv re a képet" technológiának is
-
#1
Don't Panic
senior tag
Don't Panic
senior tag
klassz de valami új akkumulátoros technológiát is mellé csaphatnának ha már ennyire super ez a FÓÓÓN!
.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Hogy az MS esetleg sok mindent átír .Net-re a Win8-ba beépített alkalmazások közül, az ilyen szempontból szinte mindegy, mert ha ők valóban rendesen támogatni fogják az ARM-et, akkor ami nem .Net azt úgyis kénytelen újrafordítani az ARM-is Win8-hoz. A többieknek meg nem lesz .Net-es átirata a büdös életben az eleve nem úgy fejlesztett programokból, és ezen Win8 nem segít. Szóval marad nekik az újrafordítás...
Új hozzászólás Aktív témák
Hirdetés
ph A vállalat 2013-ra ígéri az okostelefonok új generációját, más néven a „szupertelefonokat”.
- DIGI Mobil
- Mikrotik routerek
- Drive! - Az utolsó gurulás idén a Quadrifoglio-val
- Milyen billentyűzetet vegyek?
- Digitális Állampolgárság Program
- AMD GPU-k jövője - amit tudni vélünk
- EA Sports WRC '23
- Kertészet, mezőgazdaság topik
- PlayStation 5
- Garmin Fenix 7 és 7S - profi sport megszokásból
- További aktív témák...
- BESZÁMÍTÁS! AMD Ryzen 9 7900X 12mag 24szál processzor garanciával hibátlan működéssel
- BESZÁMÍTÁS! Intel Core i9 13900KF 24mag 32szál processzor garanciával hibátlan működéssel
- BESZÁMÍTÁS! Intel Core i7 13700K 16mag 24szál processzor garanciával hibátlan működéssel
- AMD Ryzen 5 7600 (3.8-5.1 GHz, 6 mag, 12 szál, 65 W)
- Intel Core i7-8700K 6-Core 3.7GHz LGA1151 (12M Cache, up to 4.70 GHz) Processzor!
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest