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

• #183 ddekany veterán hcl #179

  Új Válasz 2009-08-26 17:18:17 #183

  Ú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

  

  ddekany

  veterán

  válasz hcl #179 üzenetére

  "Sajnos manapság rengeteg ilyen van, hogy simán arra építenek a fejlesztők hogy majd a bika HW elviszi a cuccot."

  Hát azért, van egyszer az ócska programozás, meg van hogy egy fejlettebb/komplexebb keretrendszer, ami fixen valamennyivel többet eszik (mondjuk +50% RAM, +20% CPU). Előbbi (ócska programozás, azaz hibás tervezés) tudja igazán megdobni az erőforrás igényeket akár nagyságrendekkel is. Utóbbi nem akkora gond, kicsivel erősebb vasat kell használni... olcsóbb, mint szívni a fejlesztéssel. Végül is, azért fejlődik a hardver, hogy kiszolgálja a szoftvert. Nem csak többet zabálnak a mai cuccok, de könnyebb is őket kifejleszteni (azonos funkcionalitásúra).

• #182 ddekany veterán hcl #179

  Új Válasz 2009-08-26 17:09:07 #182

  Ú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

  

  ddekany

  veterán

  válasz hcl #179 üzenetére

  Azért ezt, hogy sebességigényes alkalmazásokhoz nem jó egy .Net/Java-szerű valami, nem látom bizonyítottnak... FFT-t meg hasonlókat .Net/Java C-vel azonos sebességen tud nyomni (néha vannak "érdekességek", bugok amiért nem... de potenciálisan ugyan olyan gyors). Ami eredendően más erőforrás használat karakterisztikát tud adni a tradicionális (natívra fordított C, C++, Delphi) programokkal szemben, az egyrészt a GC -- na de ki akar már GC nélkül programozni, legyen az bármilyen "nyelv" --, másrészt, hogy be kell tölteni egy elég gazdag (tehát nagy...) keretrendszert -- ez a hátrány meg eltűnik, ha a keretrendszer az OS része és/vagy sok alkalmazás használja. Ezen kívül... ja, hát kell JIT-ni egy nagyot betöltésnél. (Ez utóbbit, ha nagyon érezhető lenne, azért csak meg lehetne oldani valamiféle cache-eléssel. De valószínűleg nem érdemes.) Meg, ezekben nincs stack-ban allokált objektum, de ez sem nagy érvágás, ha gyors a GC rövid életű objektumokkal. (Egyébként is, ha akarnák, lehetne... de nem véletlenül nem akarják.) És, még amiatt is szoktak ezek többet zabálni, mert minden szöveget "UNICODE-ban" kezelnek, ami helyből 2x annyi memória, de ez megint olyan, hogy nem akarna senki visszatérni a charset-es szenvedésekre... (illetve ha mégis efféle perverzió ütné fel a fejét, akkor technikailag semmi akadálya, hogy egy .Net/Java szerű dolog tudjon olyat).

• #180 Sanyix őstag hcl #179

  Új Válasz 2009-08-26 14:00:06 #180

  Ú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

  

  Sanyix

  őstag

  válasz hcl #179 üzenetére

  Mondom hogy úgyis fog tenni valamit az m$ hogy ne legyen jó .netezni winen kívül máson. Ez 100%. Ezt csinálta a directx-el is, mert ez az érdeke. Semmiben sem szabad bízni aminek köze van az m$-hez, bár én is többször beleestem ebbe a hibába.

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