Keresés

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

  • hcl

    félisten

    LOGOUT blog

    válasz ddekany #51 üzenetére

    Szoftverből túlkínálat van, szóval azt a progit fogják venni, amiben van sok szolgáltatás, és azonos hardveren gyorsabb. Azt meg úgy lehet, ha párhuzamosítanak.

    "pl. adott szoftver fejlesztője, akinek a vásárlói elsősorban nem a sebesség alapján választanak,"
    De az alapján választanak, csak soszor azt hiszik, hogya gép lassú...

    Megérni meg azért nem éri meg, mert leginkább a tempó számít, de nekem attól még izélja a csőröm, hogy fos programok miatt nem lehet kihasználni a bitang hardvert, és tulajdonképp ezért kéne újabb cuccot venni...
    ...ahogy a világ többi része, ez is el van kissé ferdülve.

    Mutogatni való hater díszpinty

  • hcl

    félisten

    LOGOUT blog

    válasz ddekany #53 üzenetére

    Figyeld, a fejlesztők tudnk párhuzamosítani, ha akarnak. Szerverkörnyezetben már régóta alap, meg a rendesebb felhasználói szoftvereknél - Maya, Apache, stb. is teljesen megoldott.

    "Úgy is nézheted, hogy a fos hardverek miatt nem fut rendesen az egyszálú program... "
    Na most akkor egy alapvetően 64 bites, 4 magos CPU-n, ami már elég sok esetben alapvető, hogy van, miért egy 32 bitre forgatott, egyszálú szoftvert kéne futtatni?

    Amúgy az oprendszer is sokat segíthet a többszálúságon - már ha jó - az itthoni gépemen pl. több egyszálú folyamat nagyon szépen szét van osztva a több magra, nem zavarják egymást.

    "Igen, csak épp a két tényező közül ált. az első többet nyom a mérlegen... és ráadásul a kettő ált. egymás rovására megy."
    Igen, sajnos a piac mai állása szerint inkább vesz alá a user egy jobb gépet, és ezt az állapotot a hw és a sw gyártóknak is érdeke fenntartani; de ettől még az egész egy agyrém marad.
    Mondjuk manapság ez már csak a jéghegy csúcsa.

    Mutogatni való hater díszpinty

  • julius666

    addikt

    válasz ddekany #61 üzenetére

    Na végre valaki aki nem a szarfos programozók szöveget tolja. A többszálúsítás az asztali alkalmazások jó részénél felesleges/akár nem is lehetséges.

    Ezeknél a beépített GPU-knál ugyanez lesz a helyzet, csak itt sokkal hatványozottabban fog megjelenni. Az olyan feladatoknál, amik SIMD feldolgozást igényelnek, valóban "aranyat ér" a GPU befogása munkára. Azonban az erre nem alkalmas feladatoknál lényegében használhatatlan.

    Na ha most elkezdjük sorba venni, asztali alkalmazásoknál hol van igazán igény komolyabb SIMD feldolgozásra (ahol ugye a CPU SIMD egységeihez képest valódi sebességbeli előnyre lehetne szert tenni), akkor a számítógépes grafikán kívül nem sok ilyet látok. Nem hiába került GPU névvel a PC-be a SIMD feldolgozó.
    Szóval a grafikai programok, raytracing motorok meg egyebek baromi sokat profitálnak a dologból (bár hozzáteszem ezek eddig is, vagyis legalábbis a lehetőségük már megvolt rá rég, a fusion csak közelebb vitte a GPU-t a CPU-hoz), a költségvetés-készítő progik következő verziója viszont semennyit sem fog. Abu85 álomképeit nem szabad elhinni, őt túl könnyen meg lehet etetni a marketingszövegekkel. :))

    De sajnos hiába tépjük a szánkat, 1-2 év múlva úgyis ugyanúgy fog menni a szarfosprogramozók szöveg, miért nem tudják GPU-ra megírni a zoffiszt. :(

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