Hirdetés

Keresés

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

  • MaUser

    addikt

    válasz dezz #44 üzenetére

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

  • P.H.

    senior tag

    válasz dezz #44 üzenetére

    "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? :)

  • P.H.

    senior tag

    válasz dezz #38 üzenetére

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

  • orbano

    félisten

    válasz dezz #38 üzenetére

    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.

  • orbano

    félisten

    válasz dezz #22 üzenetére

    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.

  • orbano

    félisten

    válasz dezz #16 üzenetére

    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 :)

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