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

• #26 Kotomicuki senior tag MCBASSTION #8

  Új Válasz 2012-06-13 14:02:53 #26

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Kotomicuki

  senior tag

  válasz MCBASSTION #8 üzenetére

  +1

  ...

  (#11) MongolZ:

  Nézzük kicsit távolabbról a dolgot:
  Lehet, hogy 5-10x annyi idő és költség a jó program(kód) létrehozása, de mivel jól működik (a plusz idő nagy része a tesztre/hibajavításra (esetleg optimalizálásra) megy el - tapasztalt programozónál), ezért nem éri 100-1000x akkora kár a felhasználóját (/db; ha többen vannak, akkor ez tovább halmozódik; bár csak elméletben írható ez a nyereség oldalra, ellenben a veszteség gyakorlati, "kézzel fogható" lesz...), mintha a gyorsan elkészült selejt miatt áll az arra épülő, sokkal nagyobb értéket képviselő projekt.
  A jól működő dolgoknak ára van, ez a legtöbb esetben a rászánt idő lesz az: a megtérülést mindig bele kell kalkulálni a képletbe.
  (Ahol az 5x szoftverköltség - filléres tétel a kiadási listán - már veszélyezteti a nyereséget, ott nem ezzel a szoftverrel/hozzáállással/egyéb kellékekkel kell nekifogni az adott dologhoz...)

  (#16) Jim Tonic:

  Aki fizet vmilyen programért, az valószínűleg az az által elérhető teljesítménytöbbletért teszi azt. Az árú-kapcsolt piacgazdaságnál - és a tudatlan vásárlók (itt: a tudatos ellentéte) magas aránya miatt - , persze, ez nem feltétlenül igaz, de legyünk jóhiszeműek a fennálló rendszerrel szemben...

  ...

  Remélem, a "közkézbe" való kiadása nem fogja zátonyra futtatni ezt, az alapjába véve hasznos "találmányt".

  A regisztrációdat véglegesen kitiltottuk a következő ok miatt: III.10.8 Üdvözlettel: PROHARDVER!

• #70 Kotomicuki senior tag Jim Tonic #47

  Új Válasz 2012-06-14 21:38:22 #70

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Kotomicuki

  senior tag

  válasz Jim Tonic #47 üzenetére

  Hát, ha hozzátesszük, hogy mint minden elemének, amely számításokat végez a PC-ben a legfőbb visszafogója - a szoftveres/op.rendszeres(w) berendezkedésen kívül - az egymással való, megfelelő sebességű ÉS késleltetésű kommunikáció, akkor már más fényben tűnik fel az a mondat is.

  Ha a számításhoz szükséges a CPU-(d)GPU közötti alacsony késleltetésű kapcsolat - az egymás által kiszámított adatokra sűrűn támaszkodó ((ehhez) nem optimalizált ) programkódnál - , akkor a (d)GPU-t a PCI-E-n keresztül használó, heterogén programkód kevéssé hatékony. Az APU-ban ezt próbálják meg helyrerakni, a CPU-GPU egyetlen lakán való elhelyezésével: ekkor már a RAM elérés/sávszélesség válik a legfőbb teljesítményromboló tényezővé - a több számítás, több/gyorsabb tárhelyigénnyel is él (itt ehhez is kell optimalizálni a kódot) és a 240-pin-s DDR3 modul (sebessége nagyjából fix, csak a csatornák számának növelésével javulna a teljesítménye, de az már messze nem pénztárcabarát megoldás) jelentős hátrányban van a 256-512 bites, 1500-1750 MHz-s(effektív 6-7GHz) DDR5 vRAM-l szemben (a GPU mellett, a VGA-n, viszonylag szabadon variálható elrendezésben és mennyiségben).

  Ha nem szempont a CPU-nál gyorsabb végrehajtás, akkor amúgy sincs értelme a hagyományos kódot újraírni, csak azért, hogy heterogén legyen - + a zintel-AMD processzorerőbeni különbségek. De ha számít a teljesítményben való előrelépés, akkor a fenti tényezőket is figyelembe kell venni a kód megírásánál, optimalizálásánál.

  [Ha a következő RAM-generáció paraméterei rosszabbak lesznek a mostani DDR5-s vRAM-éinál, akkor az APU-ban rejlő potenciál kihasználatlan/kihasználhatatlan marad/lesz!]

  A regisztrációdat véglegesen kitiltottuk a következő ok miatt: III.10.8 Üdvözlettel: PROHARDVER!

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