Aztán ha megjelenik a Radeon HD7000 ezt is bas..ák a kukába?

Előbb-utóbb csak kisül belőle értékes darab, ha már ennyit kotlanak rajta.

"Ha kétmillióan is mondják a butaságot, az attól még butaság marad."

Épp ez a lényeg, hogy nem GPU-ként versenyeztetik, hanem a szerverekbe szánják.

Mintha Itanium "szagot" éreznék a levegőben...

Szóval szerinted is sikeresebb lesz, mint a Larrabee.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

bocccs, asszem én voltam..

ElGuRuLt a GyoGySzErEm...VaGy CsAk FoRDíTvA VeTtEm Be?

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 ]

"I see the diamonds, but you only see the rock"

Intel bácsi akarja a piac 99%-át "lefedni" ...
Mire ez 22nm-en sorozatgyártásra kerül, addigra elavult lesz

Co-processzor???

Április 1.

[ Szerkesztve ]

Az élet értelme:42 igen. Csupa páros szám, nem véletlenül:)

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 ]

Co-processzor???

A GPU talán nem az?

Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.

hogy lehet az ember fia (cége) olyan Intel partner, hogy kapjon ebből megjelenés előtt mintát?

A vér nem válik VAZZE!™

Az is elég, ha a Nasa Wc-pucolója vagy Állítólag náluk már a budiöblítést is ilyen MIC-ek vezérlik, csak minket hülyítenek az elavult technológiájukkal újként beharangozva hehe

[ Szerkesztve ]

A tudomány tegnap délutáni állása/tyúkhúr elmélet szerint igazán művelt csak az lehet, akin végigment egy nehézeke, tehát: Ha nem rendelkezel az említett képesítéssel: NE OKOSKODJ!:)

De az a wc minimum valamelyik űrhajón legyen.

"I see the diamonds, but you only see the rock"

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ú

A tudomány tegnap délutáni állása/tyúkhúr elmélet szerint igazán művelt csak az lehet, akin végigment egy nehézeke, tehát: Ha nem rendelkezel az említett képesítéssel: NE OKOSKODJ!:)

Ö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.

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.

Clevo P180HM: 18.4", GTX560M SLI, i7 2670QM, 12GB 1600MHz RAM, 750GB 16MB HDD

Semmi. Az Intel hallgatott erről. Valószínű, hogy marad a gyűrűs busz.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

azért vannak olyan masszívan párhuzamosítható algoritmusok, amik koncepció szintjén is megfektetnek egy GPU-t. én úgy várom már ezt a sz*rt mint a messiást

A vér nem válik VAZZE!™

Írj az Intelnek. Közelebbit nem tudok.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

"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]

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.

nekem is vannak ilyen félelmeim, de ezen a vonalon akkor is szívesebben elindulnék, legalább egy próba erejéig. ugyanez a próba GPU-ra átírás esetében szinte megfizethetetlen pénzben és szimplán időben is.

A vér nem válik VAZZE!™

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 ]

Az élet értelme:42 igen. Csupa páros szám, nem véletlenül:)

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.

Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.

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 ]

Az élet értelme:42 igen. Csupa páros szám, nem véletlenül:)

Ez is érdekes. Beleírtam ezt az opciót is. Valamelyik csak megtörténik. Köszi.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

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.

Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.

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

Az élet értelme:42 igen. Csupa páros szám, nem véletlenül:)

eleve nem lenne rossz, ha az ATX szabvány kicsit összezsugorodna, legalább a mostani 70 százalékára

A vér nem válik VAZZE!™

kompaktabb, csendesebb gépeket lehetne összerakni

Igen, igen! Vízhűtést a népnek.

Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.

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!™

É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 ]

Elfelejted, hogy HPC-piacra szánják. Itt a szerver nem más, mint egy sor 2 méter magas szekrény, megtömve 4-16-processzoros fiókokkal (RACK).

Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.

Rátapintottál a lényegre. De az Intel nem is mondta azt, hogy jól fognak futni az eddigi programok, csupán azt mondták, hogy futni fognak, ami természetesen igaz.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

Máig nem értem mire való ez a proci valaki PM-ben megírná?!

-

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

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.

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!™

Vannak kommunikációs csatornák, el lehet érni az Intel-t, ha akarjátok.

Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.

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!™

Felhívsz egyet és megkéred, hogy irányítson a megfelelő irányba, ha tud.

Aquatuning.de-ről rendelés hamarosan! Akit érdekel -> PÜ nekem! (Elhalasztva 1 hónappal!) 06.10-ig.

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

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...

"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

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...''

Jól beszélsz, ami a második bekezdést illeti

A vér nem válik VAZZE!™

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 ]