- Asztrofotózás
- Milyen TV-t vegyek?
- Már elstartolt az AMD nyári játékpromóciója
- Mikrofon topic
- Fejhallgató erősítő és DAC topik
- Projektor topic
- Milyen széket vegyek?
- Apple notebookok
- HiFi műszaki szemmel - sztereó hangrendszerek
- Intel Core i3 / i5 / i7 / i9 10xxx "Comet Lake" és i3 / i5 / i7 / i9 11xxx "Rocket Lake" (LGA1200)
Hirdetés
-
Mesterportrékkal érkezett a Honor 200 Pro
ma A Honor AI a Studio Harcourt módszerén edzett, a Pro mellett befutott a Honor 200 is.
-
Computex 2024: Kingston mindenhol
ph A mesterséges intelligencia futtatásához sok RAM kell – és ez nem kerüli el a Kingston figyelmét sem.
-
Nem lesz soulslike játék a Phantom Blade Zero
gp A készítők egy pár mondatos kérdezz-felelekkel tisztáztak néhány dolgot a játékkal kapcsolatban.
Új hozzászólás Aktív témák
-
MZperX75
addikt
válasz
attiLANte
#97
üzenetére
Jaja
Ahány rendszer annyi fogyasztás,a APU az belőle csak 1 tétel,a perifériák sokat számítanak.1.Táp hatásfoka? paneltáp-FSP vagy moduláris kis terhelésnél rengeteg lehet,E-350brazosnál mértem annyit veszteséget csak a tápon ,mint a lap+cpu+vga fogyasztása pluszban.(44W idle load 55-57W) pedig paneltáppal csak (19.6W volt load 29.6W) ugyan az a rendszer csak más táppal az egyik 95%-os hatásfokú a másik 80-at sem értel el.
2. SDD-t teszel HDD-helyett(HDD 8-10W plusz SSD 1-2 W)
3.Lap is fogyaszthat jóval többet ,látom linkeid közötti lapok mellett is volt 2-5W különbség,de akár lehet 10W-is.
4.+ventilátorok is megehetnek 5-10W-ot nálam 3 venti akár 8W-al is többet ehet fordulatszám függvényébenA tesztek amit linkeltél mind hitelesek lehetnek.
Most A8-3820-am van "szar" táppal nálam 43W idle 100W load kb 10-12W-al több mint a tesztben az a lapon és tápon +3 ventin eloszlik az a plusz néhány W. alulfeszelve sem megy lejjebb sokkal 38W alá.
De nekem nem ér meg +10-15ezret egy jó táp ,mert nem hozza vissza az árát csak jó bő 5-10-15év alatt.[ Szerkesztve ]
-
attiLANte
tag
válasz
MZperX75
#101
üzenetére
"Ahány rendszer annyi fogyasztás,a APU az belőle csak 1 tétel,a perifériák sokat számítanak."
Így van. Ezért kell körültekintőnek lenni.
Sajnos sokan elfelejtik (vagy nincsenek tisztában vele), hogy néha nem elég ránézni egy szép, színes ábrára: az igazság a részletekben bújik meg (mérési módszer, eszközök, tesztkörnyezet, stb.). Nem árt egy kicsit elemezgetni az eredményeket, összevetni más mérésekkel, és nem kőbe vésett értékként tekinteni rájuk (még ha látszólag kedvünkre valók is) - vagy legalább alaposan elolvasni a cikket, amiben a szerző jó esetben felhívja a figyelmet ezekre a dolgokra... -
lenox
veterán
válasz
atti_2010
#98
üzenetére
Hat a valosagban meg idleben 1-2 watt a kulonbseg alaplaptol fuggoen egyik vagy masik iranyban, hd filmlejatszasban meg inkabb az intel fogyaszt kevesebbet. Meg a ph-n is van 12 wattal kisebb erteket ado meres, de amugy 19 wattal kisebb fogyasztasu lap is van, es mint irtam ezek meg mind z77-esek. De amugy meg az ASUS P8Z77-V Premium meg tobbet fogyaszt 11 wattal. Miert nem terjeszted inkabb azt? Az intel 'cpu' 26 wattal tobbet fogyaszt idleben. Az mar majdnem dupla annyi. Nem hangzik jobban?
-
atti_2010
nagyúr
Annyira nem érdekel a LOAD fogyasztás mivel játékokban úgy 15W fogyaszt többet a Trinity de alul feszelve már csak 5W, viszont az IGP ami nekem fontos 3x erősebb mint az Intelben.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
MZperX75
addikt
Én a teszteken nem ezt látom
Gondolom a PH-n jól válogatott dolgokkal tesztelték mind két platformot...
nem hiszek a részrehajlásban...Egyébként ebből mire szeretnél kilukadni? Én csak annyit látok ebből,hogy AMD-nek FM2-es cuccai versenyképesek fogyasztásban is az Intel hasonló árú APU -jaival,IGP-ben meg verhetetlenek az AMD APU-k.
-
lenox
veterán
válasz
atti_2010
#105
üzenetére
Meg ugyanannyi penzert 2-szer annyi magot is kapsz a megfelelo esetben. Mindig ezt mondom, hogy nem eleg olyanra hivatkozni, ami teljesen egyertelmu? Amikor mar a ph is leirja, hogy ja, ez egy sokat fogyaszto lap, akkor mar talan felesleges a fogyasztasra mutogatni.
#106:
Gondolom a PH-n jól válogatott dolgokkal tesztelték mind két platformot...
nem hiszek a részrehajlásban...Az hivatkozott teszteknel kiderul a forumbol, hogy mit miert teszteltek, a reszrehajlasrol meg szerintem tobbfele velemeny is van, nyilvan lehet neked is.
-
stratova
veterán
válasz
attiLANte
#97
üzenetére
Érthető a felvetésed az alaplapok miatt, de atti_2010 magyarázata is. Ahol a CPU-t terhelik Intel a nyerő, ahol a GPU-t AMD, emiatt lehet üresjáratban és filmezés alatt jobb - itt még abból is adódhat eltérés, mely anyagok GPU-s gyorsítását támogatja egy-egy APU - CPU intenzív résznél pedig (pláne gyári értékek mellett) gyengébb AMD teljesítmény/fogyasztásban.
Az általad linkelt oldalról itt az üresjárat.
Ami az egy szálas fogyasztást illeti:The CPUs are loaded by running the 64-bit version of LinX 0.6.4-AVX utility. Moreover, we enabled Turbo mode and all power-saving technologies to correctly measure computer's power draw in idle mode: C1E, C6, Enhanced Intel SpeedStep and AMD Cool’n’Quiet.
AMD a Turbo-nál "kvázi keményen túlfeszeli" a CPU-t, jóval kevesebbel is megy a példányok többsége azon az órajelen. De már A10-5700 sem feltétlenül kap olyan nagy feszültséget azonos órajelhez, mint 5800K; ennek következtében már javul a CPU teljesítmény/fogyasztás értéke.
Intel alacsony fogyasztásához nagyban hozzájárul, hogy egy szálra vetítve c2c nagyon erős, így nem igényel jó teljesítményhez eszement órajelet. Ebből következik, az igen alacsony magfeszültség.
Főként hírekben általában érezhető, pár szerző tollából pozitív vagy negatív sugallat egyik vagy másik gyártó vonatkozásában; de általánosságban elmondható, hogy tesztelésnél szvsz korrektségre törekednek.
[ Szerkesztve ]
-
atti_2010
nagyúr
válasz
stratova
#109
üzenetére
Nem is értem miért kellett bohóckodniuk ezzel a turbóval ugyanis csak megkeveri a történetet különösebb előnyök nélkül, valóban rettenetesen tulfeszeli az APU-t pontosan 1,4V -ra ami jókora fogyasztástöbbletet hoz magával de ha az ember kikapcsolja 1,3V -ra állítja a feszültséget és mind a 4 magot 4200 Mhz-re húzza többet nyer mint a turbón amit amúgy összevissza kapcsolgat és még kevesebbet is fogyaszt úgy 15W -al.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
stratova
veterán
válasz
atti_2010
#110
üzenetére
Én inkább azt nem értem teljesen, miért kellett AMD-nek gyárilag ekkora turbo-feszültség. Nyilván nem látunk bele, milyen feltételeknek kell megfeleljen náluk egy lapka, max. leteszteljük az általunk elérhető programokban és felhasznált alkalmazásokkal.
Viszont Xbitlabs szerintem jól tesztelt. A legtöbb felhasználó alapbeállítással használja a processzorát, ahol ezek a funkciók engedélyezettek. A fenti hozzászólásomat elsősorban magyarázatnak szántam.Intel jó procit ajánl, out of the box, csak megkéri az árát. Azaz alapon elég jó a teljesítmény és a fogyasztás s kb.elég neki a gyári hűtő, bár láttam én már Ivy i3 tulajt a hűtős témában, mert hangos neki a gyári; de AMD is egy helikopter. Szvsz mindkét hűtő eléggé komolytalan csak AMD-nél out of the box nagyobb hőt kell legyűrnie.
Mérlegelni kell kinek mire van szüksége és több pénzt vagy inkább időt (finomhangolásra) áldoz rá.
Richland legalább jó irányba mozdult el az RCM fejlesztésével, lehet hogy szinte ua. lapka mint Trinity, de gyári körülmények között javulást hoz és a notebook vásárlóknál még kisebb réteg tuningol, mint az asztali PC tulajdonosok között (ebbe beleértem a gyári órajelek megtartása mellett végzett feszültségcsökkentést is, ami az én kis ősvasamnál energiatakarékos módban 0,2 V-ot jelent és ennek hatására automatikusan lekapcsolódó ventilátorral hálálja meg, így éjszaka sem zavar a noti).
Llanoban még hihetetlen tartalékokat hagytak (a mobilban végképp), és nem túl versenyképes órajellel engedték útnak.[ Szerkesztve ]
-
apatyas
Korrektor
válasz
atti_2010
#81
üzenetére
A konzolos APU-kban nem modulos processzor van (Jaguar), tehát emiatt nem lesz jobb. De legalább sok kisebb teljesítményű magja van, tehát jobban kell a szálakra bontást erőltetni. A gaming evolved programban viszont megkövetelhetik a modulos rendszerek jobb támogatását.
#45: az imént említett Jaguáros Kabini apu (tudom nem pont ugyanaz a kiépítés mint a konzolban) GCN rendszerű, megelőzi jópár hónappal a Kaverit tehát az lesz az első GCN APU. Lehet hogy csak a neveket kavartad, nem tudom.Abu, a konzolos rendelések kiszolgálása hátráltathatja a nekünk szánt Kabinik szállítását? Ugyanazon a technológián készülnek ugye?
Szerk: és mivel a konzolok a küszöbön vannak, feltételezem hogy a Kabini jól működik, de esetleg a Kaverivel még lehetnek gubancok főleg kihozatalban. Ne legyen igazam de volt már ilyenre példa, s ha jól emlékszem változik a technológia.
még offabb: iszonyat hülye a névválasztás[ Szerkesztve ]
pezo77 #5 2017.12.14. 13:29 Hmm. És ez az e-hajó akkor hol is tud kikötni? Az e-bay -ben? ;)
-
atti_2010
nagyúr
Valószínű hogy azért tolták el a HD 8xxx megjelenését is hogy ne foglalja a gyártósorokat, bár elég bonyolult mert a múltkor azt nyilatkozták hogy a továbbiakban a TMSC -vel dolgoznak nem tudom ez pontosan mit takar de most lehet szükségük lenne mindkét bérgyártóra.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
dezz
nagyúr
"De legalább sok kisebb teljesítményű magja van, tehát jobban kell a szálakra bontást erőltetni. A gaming evolved programban viszont megkövetelhetik a modulos rendszerek jobb támogatását."
Az első automatikusan kikényszeríti a másodikat is szerintem. Az FX-ek fő hátránya jelenleg azoknak a programoknak a viszonylag kis száma (főleg ami a játékokat illeti), amik 8 párhuzamos szálon is tudnak dolgozni.
Megjegyzem, ez a sok, de nem túl erős mag nem afféle AMD agyrém, az egész ipar erre megy, mert így alacsony fogyasztás mellett lehet növelni a teljesítményt. (Jó, az FX-ek nem az alacsony fogyasztásról híresek, de az más kérdés. A Steamrollerrel amúgy sokat javul majd a telj./fogy. arány.)
(#86) lenox: "A cimzes az tul sokat nem szamit. Annyira jo, hogy valamennyit konnyit a programozason."
Azért annyit mégiscsak, hogy nem kell másolgatni a két memóriaterület között, hanem simán átadható az adatra mutató pointer a CPU és a GPU között, ott helyben elkezdhetnek dolgozni az adattal. (Ennek a HSA-val lesz igazán nagy jelentősége, ahol pillanatok alatt el lehet indítani egy GPU-s "taszkot". Illetve, nem tudom, hogy most lehetséges-e olyan, hogy már fut egy feladat GPU-n és vár az adatra, és amikor megjön, azonnal ráveti magát - vagy mindig újra kell indítani előlről.)
[ Szerkesztve ]
-
P.H.
senior tag
"A cimzes az tul sokat nem szamit": a címzés számít a legtöbbet. Itt röviden leírtam, hogy mit segít az "egységes CPU-GPU címtér", le lehet bővebben is:
Bármely modern OS a programonkénti memóriát lapokban (jellemzően 4 KB) kezeli: ha a program lefoglal mondjuk 2 MB memóriát egy malloc( ) hívással egyben, az 512 db lapot jelent, amelyek a fizikai memóriában teljesen szétszórva vannak, az adott program virtuális memóriájában viszont folyamatos memóriaterületet jelentenek (a CR3 által mutatott táblázat által), pl. egyetlen pointerrel akár byte-ról byte-ra végig tud a CPU sétálni rajta, ha ismeri a kezdőcímet, mert minden hozzáférésnél a CPU-hardware (a.k.a. TLB) automatikusan elintézi a fordítást a fizikai címre.
Ebből a 2 MB = 512 db 4KB-os lapból viszont a CPU-n kívül más eszköz - pl. a GPU - annyit lát, hogy van 512 db különálló 4 KB-os RAM-terület, amelyekhez külön kell hozzáférni, nem folytonos. Ennek feloldására szolgálnak különböző technológiák:
- AMD processzorokban a GART:
"The GART is a system facility that performs physical-to-physical translation of memory addresses within a graphics aperture. The GART was defined to allow complex graphical objects, such as texture maps, to appear to a graphics co-processor as if they were located in contiguous pages of memory, even though they are actually scattered across randomly allocated pages by most operating systems. The GART translates all accesses to the graphics aperture, including loads and stores executed by the host CPU as well as memory reads and writes performed by I/O devices. Only accesses whose system physical addresses are within the GART aperture are translated; however, the results of the translation can be any system physical address."
- az AMD rendszerekben az ezt leváltó IOMMU, amely a CPU által kezelt processzenkénti laptáblázatokat chipset szinten elérhetővé teszi, azaz minden I/O eszköz ezen címfordításon keresztül férhet a RAM-hoz, gyorsabban és biztonságosabban (azaz akár /process bontásban), mint a korábbi megoldás
- ha továbbá magába az integrált GPU-ba van beépítve olyan TLB, azaz címfordítási mechanizmus, mint ami eddig a CPU-magok sajátja volt, akkor még rövidebb ez az út; persze ekkor az IGP CPU-specifikus lesz. Ezt az utat látjuk ma: a GCN AMD64-specifikus, az nVidia megoldása ARMv8-specifikus.Ehhez vegyük még hozzá, hogy utóbbi két esetben nem kell 'pinned memory', azaz CPU-programozásnál megszokott módon nem kell kézzel (akár memóriafoglalási paraméterekkel, akár utólagos trükkökkel) gondoskodni arról, hogy a GPU által hozzáfért memóriaterület valóban le legyen foglalva, továbbá biztosan éppen a RAM-ban legyen és ne a HDD-n.
A HSA software-es réteg, pont ezt a CPU-specifikusságot tünteti el programozói szempontból, azaz nem csak "valamennyit konnyit a programozason", hanem gyorsabbá is teszi az adott programot a beépített specifikus hardware-es megoldások használata mellett és egyszerűbbé a programozást.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
lenox
veterán
Azért annyit mégiscsak, hogy nem kell másolgatni a két memóriaterület között
Attol, hogy valaminek mas cime van, ha a cpu eri el, es mas ha a gpu meg nem kell masolni.
#115: Legyszi mondj egy peldat olyan feladatra, amit kozos virtualis cimterrel gyorsan lehet megoldani, ellenben zero copy bufferekkel lassu lenne, es gyakorlati haszna is van.
-
dezz
nagyúr
Na hát ezt mindig is tudni akartam, csak sosem volt időm utánanézni.
Köszi, hogy leírtad! (Csak esetleg zárójelben odatehetted volna, hogy az idézetek Lenoxtól származnak.)(#116) lenox: Hmm, ilyen van? Azt hittem, egy adott fizikai memóriaterülethez nem férhetnek hozzá mindketten szabadon, hanem egymáson keresztül. Most nyilván nem a system RAM/VRAM kettősségre gondolok, de az IGP-nek is ki van jelölve jelenleg egy terület, ami az ő rendelkezésére van bocsátva, mint kvázi VRAM. (Mondjuk eddig azt hittem, hogy ez egy bizonyos fizikai címtől és másik címig érő terület, de ha jól értem, amit P.H. írt a GART-ra vonatkozólag, ez valójában "be van keverve" a CPU területét képező lapok közé.) Ha esetleg közvetlenül hozzáférhet a CPU bármely laphoz (hogyan?), honnan tudja, hogy az a lap a GPU számára milyen címeket takar vagy jelent?
Amúgy szerintem nagyon nem mindegy, hogy valamit csak kacifántosan vagy egyszerűen lehet leprogramozni. Most már azért egyre többen érdeklődnek a GPGPU téma iránt (már a teljesítményigényesebb alkalmazások készítői közül), de a legtöbben nem hajlandóak ezt túlbonyolítani. Másrészt ez a közös címtér valószínűleg szükséges az egyéb HSA-funkcionalitás megvalósításához is, ami viszont már kimondottan gyorsítja pl. a GPU-s feladatindítást.
[ Szerkesztve ]
-
lenox
veterán
Ha esetleg közvetlenül hozzáférhet a CPU bármely laphoz (hogyan?), honnan tudja, hogy az a lap a GPU számára milyen címeket takar vagy jelent?
Pont ezt mondom, hogy nem sokat szamit a kozos cimter, mert nem kell tudja a cpu, hogy a gpu hogyan hivetkozik egy adott mem objektumra, csak annyit, hogy amikor be van hozza mappelve, akkor milyen (virtualis) cimen eri el. Ugyanigy a gpu-t se kell erdekelje, hogy a cpu milyen cimen hasznalta. Ettol meg ugyanugy nem kell copyzni, ugyanugy meg lehet oldani problemakat. A cimforditasok meg automatikusan megtortennek, anelkul, hogy a szoftvernek tudnia kene rola.
-
P.H.
senior tag
Egyrész nem érzem feladatomnak, hogy másvalakik által kitalált technológiák létjogosultságát bizonygassam, ezt megteszi vagy cáfolja majd az idő.
Másrészt egy technikai leírásnál ne legyen vádolva a leíró (akárcsak burkoltan is) elfogultsággal, mert ez informatív jellegű. Ha nem lát benne fantáziát valaki, attól még technológiailag ez a háttere, és más láthat.Amúgy fordítsuk meg a kérdést, a jelenlegi ismeretek birtokában: Legyszi mondj egy peldat olyan feladatra, amit kozos virtualis cimterrel lassan lehet megoldani, ellenben zero copy bufferekkel gyors lenne, es gyakorlati haszna is van.
#120 "A cimforditasok meg automatikusan megtortennek, anelkul, hogy a szoftvernek tudnia kene rola."
Hogyan?[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
lenox
veterán
Nem ertem, allitottal valamit, de nem erzed feladatodnak, hogy alatamaszd?
Az gondolom vilagos, hogy egy technologianak nem egyfajta celja lehet, szoval attol meg, hogy szerintem a kozos cimtertol nem fognak felgyorsulni a jatekok, attol meg szerintem is lehet mas gyakorlati haszna.
Amúgy fordítsuk meg a kérdést
Ez nem igy mukodik, te azt allitottad, hogy virtualis cimterrel gyorsabb lesz, en meg azt, hogy nem. Nem allitottam olyat, hogy lassabb lesz, csak hogy nem gyorsabb. Ilyenre, hogy nem gyorsabb barmelyik gpu gyorsitott kepfeldolgozas jo pelda lehet. En kertelek elobb, megis en tettem eleget hamarabb a te keresednek, ugyhogy az illendoseg mindenkepp azt kivanja, hogy te is tegyel eleget az enyemnek...
#120 "A cimforditasok meg automatikusan megtortennek, anelkul, hogy a szoftvernek tudnia kene rola."
Hogyan?Az attol fugg. De linkeltel is a temaban doksit meg sajat hozzaszolasodra is hivatkoztal, szoval mire is vagy kivancsi tulajdonkeppen?
-
P.H.
senior tag
Hasonló mérkőzéseket lejátszottál Abu-val és dezz-zel is. Kettő hozzászólásváltáson vagyunk túl, és ez alatt jutottál el oda, hogy illendő lenne nekem bizonyítanom egy még meg sem jelent technológiáról, hogy az gyorsabb, mint a jelenlegiek. Itt a fórumon sokszor lehet olvasni, hogy a programozók így-úgy lusták, nem optimalizálnak, nincsenek tisztában a lehetőségekkel, stb. Amikor ezeket olvasom, hogy egy aktív programozót kell győzködni arról, hogy egy újabb technológia jobb és egyszerűbb is lesz, példákat kellene felhozni ehhez, akkor úgy érzem, hogy igazuk van.
De ennek is megvan a miértje. Ilyen mondatok mellett, hogy "A cimforditasok meg automatikusan megtortennek, anelkul, hogy a szoftvernek tudnia kene rola." értelmetlen beszélni arról, hogy ez milyen "költséggel" jár, milyen erőforrásokat emészt fel most és milyeneket egy új technológiával, mert ez ugye nem a programozó dolga, kezeit széttárja és szemét behunyja. Ezért kérdeztem rá a "Hogyan?"-nal. Ha pedig elfogadod, hogy ezt meg is válaszoltam a korábbi hozzászólásomban, akkor azt is el kell fogadnod, amit ott leírtam.
4. éve futtatok GPU-mon 24/7-ben valamilyen GPGPU-programot. Bárki leült a gépem elé, a legenyhébb vélemény az volt róla, hogy "én képes vagyok egy gyors gépet is szinte használhatatlanra lassítani", a legdurvább az, hogy "köszi, de a telefonomon is gyorsabb netezni". Dual Opteron rendszerről beszélünk. 4. éve követem aktívan figyelemmel azt, hogy mikor fog megjelenni olyan megoldás, amelynél - azt az egységet számolásra használva, amely a képmegjelenítésért is felel - GPGPU mellett megfelelően működik a videolejátszás és nem akadozik a desktop, hogy ne kelljen kézzel váltani, hogy mit csináljon éppen a GPU; erre még egy GDDR5-ös HD7750 sem képes. Tehát nem 10-20% gyorsulásokat keresek ilyenkor, hanem egy használható rendszert akarok látni; és az ebbe az irányba tett lépéseket - a miért-jükkel és hogyan-ukkal együtt - le is fogom írni mindig.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
lenox
veterán
Szerintem nem voltak hasonloak, csak a feluletes szemlelonek. De szerintem ennek csak akkor van jelentosege, ha azon gondolkozik valaki, hogy hogyan lehetne velem kotozkodnie szakmai tema helyett.
Ne keverjuk ossze a dolgokat. Azt mondtam, hogy nem lesz gyorsabb a jatek, ellenben konnyebb lesz programozni. Nem mondtam, hogy nem lesz jobb, azt sem mondtam, nem lesz hasznos, es mas szempontokat sem emlitettem, ellenben te ugy latszik, hogy ugy kivansz vitatkozni, hogy ilyeneket nekem tulajdonitasz. Nyilvan tobb dimenzioja van a dolognak, ezt mar irtam feljebb is, de efolott elsiklasz, gondolom valami cellal. Persze tobb helyen szerepel a hozzaszolasodban, hogy es gyorsabb lesz. Ha en azt irom, hogy nem lesz gyorsabb, te meg azt, hogy gyorsabb lesz, ez velemenykulonbseg, ra lehet kerdezni, hogy milyen gyakorlati feladat megoldasa lesz gyorsabb szerinted, nem? Eleg fura valasz erre, hogy te nem tudhatod, mert meg meg sem jelent. Akkor miert allitod, hogy gyorsabb?
De ennek is megvan a miértje. Ilyen mondatok mellett, hogy "A cimforditasok meg automatikusan megtortennek, anelkul, hogy a szoftvernek tudnia kene rola." értelmetlen beszélni arról, hogy ez milyen "költséggel" jár, milyen erőforrásokat emészt fel most és milyeneket egy új technológiával, mert ez ugye nem a programozó dolga, kezeit széttárja és szemét behunyja. Ezért kérdeztem rá a "Hogyan?"-nal. Ha pedig elfogadod, hogy ezt meg is válaszoltam a korábbi hozzászólásomban, akkor azt is el kell fogadnod, amit ott leírtam.
Igen, bevallom, ezt direkt tettem be teszt cellal, hogy tenyleg mindenbe belekotsz-e, ezt ugyanis te irtad, hogy 'nincs a szoftverek felől jelentősége', szoval most magaddal vitatkozol. Szerintem azzal, hogy egy provokativ kerdesedre visszairanyitottalak a sajat iromanyodra nem fogadtam el semmit, csak probaltam kikerulni egy felesleges szalat, de ugy latszik hiaba.
En kb. 10 eve gpgpuzok, nekem is vannak preferenciam, hogy mi segitene legjobban, es mi kevesbe, nyilvan nem oldok meg mindenfele feladatot, csak amik nalam felmerulnek, azokhoz nekem nem olyan fontos a kozos cimter. Masnak lehet mas a preferenciaja.
#125 Igen, mondjuk toled latni ezt az azert fura
.[ Szerkesztve ]
-
PROHARDVER!
Akkor az OFF-ból itt és most legyen elég! Ez különösen az újabb lavinát elindító lenox számára egy figyelmeztetés, akinek már nem az az első hasonló, szándékos provokációval megfűszerezett esete! Az eszmecserét valamelyik erre dedikált topikban, vagy privát üzenet formájában tessék folytatni!
-
lenox
veterán
Zero copy.
OpenCL Programming Guide. Szerintem az egesz erdekes...
Gondolom a PH-n jól válogatott dolgokkal tesztelték mind két platformot...
Köszi, hogy leírtad! (Csak esetleg zárójelben odatehetted volna, hogy az idézetek Lenoxtól származnak.)
Új hozzászólás Aktív témák
ph A Trinity leváltójának szánt fejlesztés elsősorban a szoftverekre és a hatékonyságra helyezi a hangsúlyt.
- Intel Core i5-10400F processzor I Dobozos I 2024.10.01-ig érvényes Garancia
- AMD Ryzen 5 5600X BOX - Új, bontatlan, 3 év garancia - Eladó! 48.000.-
- Intel Core i7-11700K processzor I Gyári, dobozos
- Beszámítás! Intel Core i7 8700K 6mag 12szál processzor garanciával hibátlan működéssel
- Garanciális Ryzen 7 5800x3d Processzor