Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz Fiery #24 üzenetére

    Most is lehet bármit programozni a fémen, de annyira irreális az ezzel járó extra munka, hogy nincs értelme egy bizonyos szint alá menni. Az OpenCLnek vannak hibái, de nagyjából az a szint, ami még vállalható erőforrás befektetését követeli, és az eredmény is nagyon gyors. Ez alatt már a nyerhető extra megkérdőjelezhető jelentőségű, főleg annak tudatában, hogy mennyi erőforrást kell még belefektetni.

    1) A Knights Landing magját kapják, tehát annak a speckóit kell figyelni.

    2) A MIC magok nem kompatibilisek a mai fő magokkal. Hiába az x86 akkor sincs bináris kompatibilitás a normál és a MIC magok között. Ennek az az oka, hogy az x86 memóriamodelljét módosítani kellett hogy a rendszer skálázódjon.

  • LordX

    veterán

    válasz Fiery #24 üzenetére

    Ez a legnagyobb hülyeség amit tőled valaha olvastam, már bocsánat. Ha direkten szálakat futtatok, akkor nincs szinkronizáció? Annak nincs overheadje, akár kézzel történik (-> extra meló), akár az oprendszer csinálja (túl általános célú -> gyenge perf)? Nem véletlenül van context meg command queue - pontosan erre.

    És hogy írjak direkten ASM utasításokat? Mert a C++ fordító, OpenCL fordító nem ismeri őket, vagy mi? Ilyen alacsony szinten ma már senki nem dolgozik komolyan. Max egykét kritikus ponton optimizál kézzel, de ez pont azt jelenti, hogy nem dobják ki a magas szintű programnyelvet.

    Nem ez a különbség. A hagyományos grafkártya data parallel modellben működik, az Intel MIC meg task parallel. A kettő ég és föld - egyik se jobb a másiknál (azonos elméleti peak teljesítmény mellett, és itt viszont úgy tűnik a GPU-knak áll a zászló), de ha a másik kabátját akarod ráhúzni, akkor eléggé döcögősen fog menni.

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