- Gaming notebook topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kormányok / autós szimulátorok topicja
- Vezetékes FEJhallgatók
- ASUS ROG Ally
- Bluetooth hangszórók
- Amlogic S905, S912 processzoros készülékek
- TCL LCD és LED TV-k
- Hobby elektronika
- Lelövi a Roccat márkanevet a Turtle Beach
Hirdetés
-
Bővíti a ROG Ally garanciáját az ASUS
ph Az egyes termékek, kártyaolvasóval kapcsolatos problámájára reagált a cég.
-
Mégis megjelenik Switch-re a Deliver Us the Moon
gp Közel négy évvel a hibrid konzolora szánt változat elkaszálása után a készítők úgy döntöttek, hogy mégis megjelenik a Switch verzió.
-
Garmin Forerunner 165 - alapozó edzés
ma Leizzadtunk a Garmin legolcsóbb amoledes futóórájával.
Új hozzászólás Aktív témák
-
T_Stark
őstag
Aztán ha megjelenik a Radeon HD7000 ezt is bas..ák a kukába?
-
Ueda
senior tag
Előbb-utóbb csak kisül belőle értékes darab, ha már ennyit kotlanak rajta.
OS : EndeavourOS KDE . . . . . . Parancs menü : https://pastebin.com/u/txt444
-
hugo chávez
aktív tag
Mintha Itanium "szagot" éreznék a levegőben...
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
Abu85
HÁZIGAZDA
válasz hugo chávez #4 üzenetére
Szóval szerinted is sikeresebb lesz, mint a Larrabee.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
mmdms
addikt
válasz hugo chávez #4 üzenetére
bocccs, asszem én voltam..
ElGuRuLt a GyoGySzErEm...VaGy CsAk FoRDíTvA VeTtEm Be?
-
Móci
addikt
Izzadtságszag az van, de hogy lesz-e mögötte valami, az jó kérdés... Ha jól értem, akkor a gpu részét kicsit kigyomlálták, és most valami 'gyorsító' szerepre szeretnék szánni ezt az x86-os csodát?
[ Szerkesztve ]
"...In a struggle to be happy and free, swimming in a primitive sea..."
-
#16939776
törölt tag
Intel bácsi akarja a piac 99%-át "lefedni" ...
Mire ez 22nm-en sorozatgyártásra kerül, addigra elavult leszCo-processzor???
Április 1.
[ Szerkesztve ]
-
hugo chávez
aktív tag
Annál talán valamivel igen, de azért még ebben sem vagyok teljesen biztos.
De legalább, ha az Itanium vonalat végképp dobná az Intel (amire, ha a Poulson is bukik, akkor szerintem elég nagy az esély), akkor így lesz egy újabb feneketlen pénznyelője.
(#6) mmdms:
Amiért ilyen becsületesen bevallottad, ezért most az egyszer elnézem.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
vanhalen
senior tag
Mint az űrállomásos faszi?
Ez most komoly: Meghirdettek egy TV-s/Netes szavazást anno, hogy mi legyen a nemzetközi űrállomás neve, ahhoz hasonlóan, mint amikor a majdani, végülis megyeri híd-ra keresztelt képződmény esetében nálunk. Volt egy csávó, valami TV-s sztár, showman vagy mifene és a "hívei" meg ő elintézték valami szavazóprogival, hogy ő nyerje meg, vagyis az ő nevét viselje az űrállomás. Végülis a Nasa kárpótlásul megígérte neki, hogy az egyik WC-t róla nevezik el odafönt. Nem tudom, így lett e, de azóta szomorú
-
dezz
nagyúr
Összefoglalva a cikkben elhangzottakat: nem lesz kis teljesítménye, de nyilván nem lesz olyan hatékony (teljesítmény/fogyasztás és teljesítmény/terület), mint a mai vezető GPU-k. Az Intel az x86/x64 kompatibilitásra próbál építeni. Kvázi azt mondják: ne törődjetek vele, hogy rosszabb, kevesebb vele a meló! Hát, ez nekem nem túl rokonszenves stratégia...
(#3) NLZ: És? A GPU-kat sem csak raszter-grafikára használják... Már PC vonalon sem, de ott vannak az eleve nem erre épített kártyák is (Tesla, stb.).
(#8) Móci: Nem a GPU részét, hiszen a mai GPU-k nagyrészt szintén vektortömbökből állnak, azaz lényegében vektorprocik, a szokásos raszter-grafikára alkalmassá tevő egységekkel kiegészítve. Itt ezeket az egységeket gyomlálták ki, mert úgysem lenne alkalmas a cucc az AMD és az Nvidia GPU-ival való versenyzésre.
-
tocsa
senior tag
Mik a legfrissebb információk a MIC architektúra magok közötti kommunikációjával kapcsolatban? A régi Larrabee tervek még gyűrű buszról (ring bus) szóltak (ami eléggé bottleneck, emiatt alkalmazták volna a binned renderinget). Jóval később egy-egy hírben láttam említést mesh összeköttetésről említést. Szóval mi most a helyzet? Ez sokkal fontosabb, minthogy mi az egyes magok adata.
Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
shabbarulez
őstag
"Ettől függetlenül nem elképzelhetetlen, hogy később lesz egy QPI összeköttetést használó verzió, melyet jóval közelebb helyezve a processzorhoz drámaian csökkenthető az adatmozgatással járó kommunikációs késleltetés. "
Nem valószínű hogy lenne benne QPI. A MIC, ahogy az előd Larrabee is egy sok magos általános célú cpu, így önmagában is működőképes, nem szükséges host cpu a működéséhez. Egy hónapja volt Európában egy HPC konferencia, ahol az egyik előadás témája egy olyan project volt, ahol 2 KNC-t raknának egy blade-re, host cpu nélkül, közvetlen hálózati csatlakozással. Így nem kell drámaian csökkenteni a host cpu-val történő adatmozgatással járó kommunikációt, mert olyan nincs is a rendszerben. [link]
-
dezz
nagyúr
Ami egy Keplert vagy GCN-t megfektet, az szerintem ezt is meg fogja fektetni. Nem a szokásos x86/x64 magokra kell gondolni, igencsak le lehetnek butítva, hogy 64db fér el belőlük egy lapkán... Talán rosszabbak is rugalmasságban és más, CPU-knak tulajdonított előnyökben, mint akár az említett architektúrák.
Mondjuk az sem mindegy, milyen memória van mellépakolva, "CPU-s" DDR3 vagy "GPU-s" GDDR5. Vélhetően az utóbbi, mert itt is kell a sávszél, a rosszabb latency árán is, amit tovább ronthat a ringbus.
-
#16939776
törölt tag
válasz TESCO-Zsömle #11 üzenetére
A Raid vezérlő cpu-ja is legyen co-processzor
A VGA és CPU "között" van ez az izé, nekem csak "bővítőkártya" lesz, amíg bele nem költözik a cpu-ba
Nem hinném hogy külön qpi-t fog kapni Desktop MB-n, maradni fog Pci-Ex sávon.
[ Szerkesztve ]
-
TESCO-Zsömle
félisten
válasz #16939776 #24 üzenetére
A RAID-vezérlő miben segíti a processzor munkáját?
Mindegy, hogy minek nevezed... Hívhatod téglának is, attól még a GPU co-processzor marad...
Az, hogy mit hiszel, lényegtelen. Itt alapvető változások mennek végbe, amik megváltoztatják a részegységek szerepét és viszonyát. Tény, hogy a PCIe iszonytatóan szűk ahhoz a direkt eléréshez képest, ami az APU-ban van. Ezzel valamit kezdeni kell... Vagy a dGPU-k szerepét kell megváltoztatni, vagy a kapcsolatot szorosabbra fűzni.
Sub-Dungeoneer lvl -57
-
#16939776
törölt tag
válasz TESCO-Zsömle #25 üzenetére
Nem a processzort terheli: adat darabolása/összeillesztése, paritás bitek kiszámítása, hibajavítás.
Értem hogy miről szól a cikk
Hogy ez elférjen a Cpu mellet, Eatx lap kell, ha meg akarjuk tartani a bővítőkártyákat is.
Qpi-vel nem fogjuk Desktop lapon látni
shabbarulez is azt írja hogy nem kell hozzá host cpu, ergo nem Co-processzor
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz shabbarulez #21 üzenetére
Ez is érdekes. Beleírtam ezt az opciót is. Valamelyik csak megtörténik. Köszi.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
TESCO-Zsömle
félisten
válasz #16939776 #26 üzenetére
Akkor az is co-processzor.
Nagyon örülök.
A dolog lényege, hogy nem kell megtartani a bővítőkártyákat. Nem mindet. Hány olyan felhasználó van, akinek nem elég az mATX alaplap 4 bővítőhelye úgy, hogy még a VGA-t is oda kell tenni? Maradjon a lap végén 2 slot és annyi. Bőven elég...
Bár -szvsz- nem dobna hátast a világ, ha végre elfelejtenénk az ATX-et... Legyen kompatibilis a lapok furatkiosztása, meg a kivezetések, de a RAM-okat igazán beforgathatnák már "szélirányba"...
Nem ragaszkodok a QPI-hez*, de a PCIe most is szűk keresztmetszet, szóval azt inkább hanyagoljuk.
* - Legyen HyperTransport.
Sub-Dungeoneer lvl -57
-
#16939776
törölt tag
válasz TESCO-Zsömle #28 üzenetére
Legyen
Nálam is mATX, és 1db vga van benne. Szóval +1 user a példádhoz. sőt 2 sata port is bőven elég a többi csak a helyet foglalja. még a tápkábeleket is méretre vágtam olyan pici a hely
A "szélirány változást", támogatom, kompaktabb, csendesebb gépeket lehetne összerakni
A többiről beszéljünk 1-2 év múlva
-
orbano
félisten
válasz TESCO-Zsömle #31 üzenetére
mondjuk nem lenne rossz, ha az összes melegedő alkatrész beférne egyetlen fémlemez alá és lehetne lapos-széles bordákat tenni léghűtésnek ,vagy egyszerűen csak vizet egy darab blokkal. de valahogy még SSF frontos sem valami hatalmas sa fantázia. talán majd ha elkezd haldokolni a PC...
A vér nem válik VAZZE!™
-
ddekany
veterán
Én ezt, hogy nem kell újra írni a programokat, nem teljesen vágom. Azt értem, hogy futnak a régi x86-os programok rajta, de mivel eddig nem volt ilyen felépítésű (nagyon sok mag, stb.) x86-os CPU, ha ki akarom aknázni egy ilyen potenciálját, nem kifejezetten erre az processzora gondolva kéne megírni a sebesség szempontjából kritikus algoritmusokat? Ha csak egy hagyományos programom van, ami annyi szálat alkalmaz ahány magot lát (de azt nem tudja hogy ezek pici buta magok, ki tudja milyen memória elérési tulajdonságokkal), az vajon mennyire fog hatékonyan futni? Egyáltalán van lehetősége programnak kontrollálni a magok közti adatmegosztást, vagy kötelezően mindent áttetszően a hardver old meg?
[ Szerkesztve ]
-
-
mikej95
aktív tag
Máig nem értem mire való ez a proci valaki PM-ben megírná?!
Azt viszont nem tudják, hogy mi nem tudjuk azt, amiről ők úgy tudják, hogy tudjuk.'
-
P.H.
senior tag
Valahol elveszlik a lényeg, ha így közelíted meg. Ezek az erősen párhuzamosíható feladatok nem fekszenek a CPU-knak, a kevésbé párhuzamosíthatóak pedig a GPU-knak. Mondok egy nagyon egyszerű példát, talán így jobban kijönnek a különbségek: van egy 1 megapixeles képed, amin a pixelek YUV színtérben vannak, ezt át kell konvertálni RGB-be (tipikus JPEG- vagy MPEG-feladat); ez a konvertálás kb. CPU SIMD 20 utasítás, kell hozzá 3 konstans és pixelenként 4 regiszter.
Egy CPU-val mit csinálsz? Írsz egy ciklust, ami lefut minden pixelre. Ezek a lefutások függetlenek egymástól (egyik pixelnek sincs köze a másikhoz), OoO is a processzorod, csak az utasításdekódolás sebessége és a ROB mérete (azaz az egyszerre on-the-fly állapotban levő utasítások száma) limitálja azt, hogy mikor kezd neki a következő ciklusnak; egy modern mikroarch 4 utasítást dekódol órajelenként, azaz 5 órajelenként indulhat a következő ciklus. A ROB gyorsan betelik, mivel egyetlen összeadás vagy szorzás tipikusan 3-6 órajel, tehát nem tudja olyan gyorsan fogadni az egymást követő utasításokat, hogy hosszabb távon tartani tudja az 5 órajelenkénti következő ciklust.
Egy GPU-val mit csinálsz? Átadod neki a 20 utasítást, megmondod, hogy futtassa le 1 milliószor, ezen az bemeneti adaton, erre a kimenetre, ekkora léptékkel. Van neki 32-512 shader processzora és hozzá egy jó nagy regiszertömbje, elkezdi a ciklusmagokat lefuttatni annyi példányban egyszerre, amennyire kapacitása van, majd ha kész az egésszel, akkor jelzi. Nincs decode, ROB, OoO; nem is kell, mert csak 20 utasításod van, amit le kell futtatni 1 milliószor: számítási teljesítményben ki van gyúrva, az utasításfeldolgozási rész kicsi, mert ugyanazon a 20 utasításon miért rágódnál el 1 milliószór?
Egy Itanium-mal mit csinálsz? In-order CPU, de van egy kisebb halom regisztere, meg egy okos utasításkészlete, ami által megmondod neki, hogy most egy olyan programrész következik, ami ciklus, de a lefutások függetlenek egymástól. Megmondod továbbá azt is neki, hogy itt kezdődik a ciklusmag kódja, emitt van a vége, ennyi a lépésköz, kell hozzá 4 regiszter és 1 milliószor kell lefuttatni (mindezt pár utasítással). Végrehajtó egységből nem sok van neki, de belül megoldja, hogy elkezd annyi ciklusmagot futtatni párhuzamosan, ahánynak az igénye csak belefér a kisebb halom regiszterébe illetve amennyinek az utasításait tudja tárolni ideiglenesen. Egy-egy szorzás vagy összeadás időigénye továbbra is néhány órajel, de mivel a végrehajtói pipeline-osak, a következő órajelben egy másik ciklus utasítását indíthatja el, így nem sérül az in-ordersége sem (mivel ez csak ciklusmagon belül szükséges, hisz megmondtad neki, hogy ez olyan ciklus, aminek lefutásai nem befolyásolják egymást). Ha kész, akkor elindul a ciklust követő következő utasítások lefuttatása, mint minden rendes CPU-nál.
Egy MIC-en mit csinálsz? In-order (~Atom) x86 magok, kevés regiszterrel és kevésbé okos utasításkészlettel: annyi (de minél több) szálra bontod a programot, amennyi még nem befolyásolja negatívan a teljesítményt, pl. egy szál egy képsort dolgoz fel, lehet ez akár példából kiindulva 1000 vagy több sor/szál is. Az OS majd elosztja a szálakat a magok között, magonként 4-et. Ha egy szorzás vagy egy összeadás időigénye 4 órajel és a végrehajtók pipelined-ek, akkor in-order magon pont jó, mert órajelenként indíthatja a CPU más-más szál utasításait úgy, hogy egy-egy szál akkor se futna le számottevően gyorsabban, ha csak ezzel az eggyel foglalkozna az adott mag (mivel a következő utasítás nagy eséllyel függ az előző eredményétől 1 szálon belül). Ha kész egy-egy szál, akkor az OS számára jelenti, hogy végzett; amikor az összes kész, akkor az van vége a feladatnak.
Ha így (és kissé egyszerűsítve) közelítjük meg, akkor már talán tisztább az, hogy mire jó (és talán az is, hogy mi mire lesz jó a jövőben):
- egy általános CPU-ra nem tervezel több 100 szálat, mert csak a bonyolultságot növeli és egy x86 mag csak 2 szálat tud futtatni; egy MIC-re ez sima ügy. Mégsem GPU: elrágódik ugyan a 20 utasításon 1 milliószor (dekódolás) külön-külön, de nincs ROB, ami betelhetne, ha elég nagy a per-thread utasítássor. Nem is Itanium, mert nem kell átírni/újrafogalmazni az egészet a független lefutású ciklus miatt, csak a szálszámot kell megnövelni, ha már eddig is többszálú volt a program (ennél azért többet kell tenni, de kb. ilyen egyszerű lépésekben).
- ha ezt vesszük példának, akkor uop-bufferrel + kb. az Itanium megoldásával, azaz utasításkészlet-bővítéssel (független ciklusok felprogramozása) tudom elképzelni azt, hogy egy jelenlegi FPU-t a jövőben lecserélnek GPU-szerű megoldásokra.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
dezz
nagyúr
Azért ne gondold, hogy ide nem kell átírni, vagy akár áttervezni a programokat, hogy valóban jól fussanak!
(#37) P.H.: "csak a szálszámot kell megnövelni, ha már eddig is többszálú volt a program (ennél azért többet kell tenni, de kb. ilyen egyszerű lépésekben)."
Ezt valahogy kevésnek érzem. Nem tudom, hány csatornás és milyen memória lesz mellette, de arra is oda kell figyelni, hogy ne "akadjanak össze" az adatok. Meg hát a példád a lehető legegyszerűbb, ritkán ennyire függetlenek és eleve elkülönülők az egyes szálakban elvégzendő műveletek.
-
orbano
félisten
Ahogy én képzelem ezt a cuccot, szeretni fogja a proginkat. nagyon kevés adattal dolgozunk elképesztően sokat, így sávszélesség gondunk nem lesz. mondjuk a szinkronizációval lehetnek gondok, most is van valamennyi starving sima i7-en, de úgyis nekiállunk újraírni a progit, az megjavítja. ezért is örültem volna, ha tudok szeretni ebből egy példányt, hogy le tudjuk a koncepciónkat ellenőrizni rajta.
A vér nem válik VAZZE!™
-
orbano
félisten
válasz TESCO-Zsömle #40 üzenetére
Akarjuk, csak még nem jöttem rá melyik a legalkalmasabb mód, meglehetősen nagy cég
A vér nem válik VAZZE!™
-
P.H.
senior tag
Mint láthatod, én nem mondtam véleményt róla, csak valóban a legegyszerűbb példán keresztül leírtam, hogy négy eltérő - nem is architektúrára, hanem - koncepcióra hogyan lehet(ne) ugyanazt a programot megtervezni. Nyilván nem mindegy, hogy milyen memória-alrendszerek vannak köréjük építve, de ez a tervezőik dolga, nem a "felhasználóké"/programozóké (lásd az előző Knights Ferry). De ötödikként tedd hozzá nyugodtan, hogy ezt Cell-en hogyan oldanád meg, ezzel is bővülne a kép és szélesedne a látótér.
Az, hogy mi ritka, az relatív (pl. asztalon "ritka" a nem SIMD vagy lebegőpontos kód, nagyítóval kell keresni az ilyeneket, ezért a Bulldozer nem feltétlenül jó választás ide; szervereknél viszont "ritka" a SIMD- vagy FP-kód, ott úgy tűnik, senki sem vitatja a teljesítményének versenyképességét ).
Semmiképp sem nevezhetném ritkának azokat a problémákat, amiért az emberek hajlandóak mélyen a zsebükbe nyúlni. Jelen esetben általánosan az elosztott számításokról - distributed computing - beszélünk: legyen az chipen belüli (multicore, GPU, GPGPU, játékok - nyilván nem véletlenül nő a shader processzorok száma az egekbe), szobányi rendszereket felölelő (pl. Cray-rendszerek) vagy a világon átívelő (BOINC), mindegyiknél ugyanaz a lényeg: amennyiben olyan algoritmusokat használnak, amelyeknél minimális a számítást végző egységek közti kommunikáció igénye egy-egy részprobléma esetén egészen a teljes megoldásáig, tehát jól osztható független részfeladatokra, addig hatékony. Amely problémákat nem lehet így megvalósítani, azoknál fel sem merül ezen eszközök használata.Az átírás megint egy érdekes kérdés: nem öntötték el a világot a GPGPU-segített programok, de szállingóznak; akik ezeket használják, azok elégedettek. Mások pedig a saját programjaik kapcsán vannak megelégedve:
"Az MIC projekt első mérföldköve a 45 nanométeres Knights Ferry kódnevű chip, ami 32 magot tartalmazott, ezeket a lapkákat tartalmazó PCI Express bővítőkártyákat az MIC projektben résztvevő Intel-partnerek, akadémiai intézetek kaphatták meg. Glenn Brook, az Oak Ridge National Laboratoryt és a University of Tennessee mérnöki-tudományos számítástechnikai erőfeszítései felett bábáskodó Joint Institute of Computational Sciences igazgatója az eseményen elmondta, a mérnökök számos alkalmazást, összesen mintegy 5 millió sornyi Fortran, C és C++ kódot ültettek át a 32 magos Knights Ferry tesztchipre, a tudományos szoftverek "portolása" egyenként egy napot vett igénybe."[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
dezz
nagyúr
Cell: első nekifutásra, pár sort beolvasni minden SPE-be, azt' mehet. Csak azt nem tudom, miért releváns ilyen egyszerű feladatnál hasonlítgatni...
"pl. asztalon "ritka" a nem SIMD vagy lebegőpontos kód, nagyítóval kell keresni az ilyeneket, ezért a Bulldozer nem feltétlenül jó választás ide"
Hmm, biztos, hogy ezt akartad írni?
"szervereknél viszont "ritka" a SIMD- vagy FP-kód, ott úgy tűnik, senki sem vitatja a teljesítményének versenyképességét"
Nos, attól függ, hogy adatbázis- vagy HPC szerver...
"amennyiben olyan algoritmusokat használnak, amelyeknél minimális a számítást végző egységek közti kommunikáció igénye egy-egy részprobléma esetén egészen a teljes megoldásáig, tehát jól osztható független részfeladatokra, addig hatékony. Amely problémákat nem lehet így megvalósítani, azoknál fel sem merül ezen eszközök használata."
Hát, adott esetben nem gond a kommunikáció...
"a mérnökök számos alkalmazást, összesen mintegy 5 millió sornyi Fortran, C és C++ kódot ültettek át"
Ó, micsoda marketing szöveg...
"a 32 magos Knights Ferry tesztchipre, a tudományos szoftverek "portolása" egyenként egy napot vett igénybe."
Mondhatta volna azt is, hogy 5 perc, csak mondjuk nem mindegy a hatékonyság...
-
P.H.
senior tag
"Cell: első nekifutásra, pár sort beolvasni minden SPE-be, azt' mehet. Csak azt nem tudom, miért releváns ilyen egyszerű feladatnál hasonlítgatni..."
Leírnád, mi történik a pár sor beolvasása után, vagy erre hogyan kellene tervezni software-t? DMA, ilyesmi?A többit összevonva: Biztos. Függ tőle? Nem adott esetben? AMD64-nél nem volt marketing? Nekik ennyi a belefektetett energia, másnak több?
Beszélgetünk és informatívan vitatkozunk, vagy csak egymás mondatait cáfoljuk?
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
MaUser
addikt
Mi a bajod a kódsorok számával? Alig találsz olyan maintenance metric-et ami nem arra épül (függványek hossza, scope hossza, stb.), akkor meg lehessen már megemlíteni egy marketing anyagban, ahol pont a portolás egyszerűségét hozzák fel...
Egyébként csak egy példa ahová ezeket ezrével lehet majd eladni: rapid prototype esetén elég gyakori, hogy adott egy program, ami "csuklóból" párhuzamosít x86-on, de a mért adatok mennyisége miatt rengeteg mérnökóra megy el szimplán várakozásra, azonban cluster kiépítése és fenntartása nem érné meg az időszakos felhasználás miatt. Ha egy ilyen kártya kijön egy-kétezer €-ból és közel automatikusan kezelni fogja az x86 kódokat, akkor alapfelszereltség lesz szinten minden k/f mérnöknél...
[ Szerkesztve ]
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
-
dezz
nagyúr
Nem volt célom különösebben vitatkozni veled.
SPE-nként: X sor beolvasása az SPE LS-ébe DMA-val (X = 1...amennyi elfér egy LS-ben/2), SPE-n belül a konverzió elindítása, közben a már átkonvertált sorok kiírása DMA-val. Term. az adatforgalmat koordinálni kell.
"Biztos."
Tehát, a PC-s szoftverek túlnyomó többsége SIMD vagy FP lenne? Ezen most egy kicsit csodálkozom.
"Függ tőle? Nem adott esetben?"
Párdon?
"AMD64-nél nem volt marketing?"
Miért lett volna? 3,5 GB main ram és 2 GB/process sokszor kevés már PC-n is. Ezen kívül kicsivel gyorsabbak is a 64 bites kódok, könnyebb rá optimalizálni (gépileg vagy manuálisan, több regiszter ugye, stb.) és modernebb az egész platform.
(#46) MaUser: Egy egész program portolása per nap tempó mellett nem hiszem, hogy nagyon belenyúltak volna a kódba, mely esetben ugye tök mindegy a hossz... A hatékonyságról meg egy szó sem esett. 'Így könnyű...'
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Gaming notebook topik
- Samsung Galaxy A54 - türelemjáték
- Kerékpárosok, bringások ide!
- Kerti grill és bográcsozó házilag (BBQ, tervek, ötletek, receptek)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Xiaomi 11 Lite 5G NE (lisa)
- Synology NAS
- Kormányok / autós szimulátorok topicja
- Vezetékes FEJhallgatók
- sziku69: Fűzzük össze a szavakat :)
- További aktív témák...
- Új GAMER PC - RTX 4060 Ti - i5 13400F/14400F - 16GB DDR4 - 500GB Nvme SSD - DLSS3!
- fehér RTX3060Ti Gamer PC Intel i5-11400F, Zotac Gaming RTX3060Ti 8GB, 16GB Corsair RAM, vízhűtés!
- ÚJ GAMER PC - RTX 4070 12GB - i5 13400F/14400F - 16GB DDR4 - 500GB Nvme SSD - 750W 80+
- Fujitsu PRIMERGY RX1330 M4 Garanciával
- Új! GAMER PC - RTX 4060 8GB - i5 10400F/11400F - 16GB DDR4 - 500GB Nvme SSD