Rozdeleni prace medzi cpu jadrami,GK atd..

[Zoltan Balaton]

Iny nazov ma nenapadol, i ked velmi nevystihuje moju dilemu.
Problem je to skor na uvolnenie ako nieco vazne.
Ide o to ze ked si otvorim napr pdf subor a zacnem myskou tahat posuvnik tak, ze obraz beha hore dole obraz sa zda byt mierne trhany a nepravidelny.Ked som pozrel do Spravcu uloh, tak sa zda ze makaju vsetky 4 jadra,ale ani jedno nie na plno.Ked to spravim na 1 jadrovom Celerone, tak ide cpu na cca 100%.
Co teda nestiha ze to trha?Graficka karta?Procesor?

[Snake]

volá sa to afinita, nastavovať to nemusíš, to že ti seká PDFko je kvôli prílišnej grafike alebo bolo to PDF robené non-Adobe programom.

[Zoltan Balaton]

co mi napada laicky,tak akoby win neidentifikoval primerane vytazenie HW(akehokolvek) voci "procesu"..kedze tahanie pdfka hore dole,nie je asi standardny "proces"

[Snake]

Acrobat je kódený multithreadovo, tzn že záťaž rozloží (je to lepšie a efektívnejšie), to neni chyba, či čo by si chcel? aby ti jedno jadro skočilo na 100% a keď treba viac tak pustí aj druhé?

[Zoltan Balaton]

ja by som chcel aby sa v pdf pri zlozitej grafike scrollovalo plynule..a ked to plynule nejde tak aspon nech sa hardvare neulieva

v tejto teme ale nejde o konkretny problem(pdf),to je len ukazka,ze kde asi smerujem uvahovo ..
proste preco to seka, ked sa hardware ulieva, aj ked vie vyuzivat viac jadier na raz

[faugusztin]

r.b.class, ocakavas aj svetovy mier ? Pretoze moznost, ze Adobe Reader nebude sekat je asi rovnako velka ako sanca toho svetoveho mieru.

To, ze je aplikacia viacvlaknova este neznamena, ze dokaze vyuzit vsetky prostriedky naplno.

[Jofo]

1. nema Acrobat Reader, ale Foxit Reader
2. Skus radsej PDF XChangeViewer, je zadara, a je aj 64-bitovy (ak mas x64 OS), a hlavne je o poznanie rychlejsi ako Foxit

[faugusztin]

Velke rozdiely nie je mozne pri prezerani dosiahnut, uz z principu ako PDF funguje. +/- rovnako rychlo funguju aj PDF prezerace pod Linuxom aj pod Windows, proste PDF je velmi zly priklad.

[Zoltan Balaton]

Nieje to len priklad pdf.Napr taka najnovsia veruia FL Studia uz dokaze prcovat multivlaknovo..tiez mi zatazuje v spravcovi vsetky 4 jadra naraz,ale tiez ked tam je toho vela, tak zacne sekat aj ked vytazuje cpu len na 40-50%,ma to vlastny cpu meter ktory ide vtedy na 100%)..proste program viditelne pouziva 4 jadra naraz,ale nedokaze ich vyuzit naplno..ci?
Preco?Je zle napisany?

[faugusztin]

Nie je zle napisany, viacvlaknove programovanie nie je mavnutie carovnym prutikom a hned aplikacia vyuziva vsetky jadra na 100%. Keby islo o cisto vypoctovu aplikaciu, nie je problem zatazit vsetko na 100% (vid OCCT). Ale ked ti do obrazu prichadzaju veci ako vzajomna zavislost vlakien (zamky, synchronizacia), cakanie na rozne I/O (pamat, disk, zvukovka a podobne), multitasking Windows,... tak jednoducho mas v drvivej vacsine pripadov vcelku velky problem napisat viacvlaknovu aplikaciu aby vytazila jadra na maximum.
Je to komplexna programatorska problematika, co neviem ci ma zmysel tu rozoberat. Jednoducho, viacvlaknovu aplikaciu z jednovlaknovej neurobis tym, ze prepnes nejaky prepinac v kompilatore. Musis ju tak navrhovat od zaciatku, a aj tak ti moze nastat situacia ze vypocetne tazku ulohu jednoducho nemozes rozdelit na viacej vlakien.

[Zoltan Balaton]

Cize je mozne, ze to je prakticky nemozne v niektorych aplikaciach vytazit x jadier na 100% i ked ich vie vyuzivat,nezavisle na akosti kodu?

[faugusztin]

Ano, presne tak. Na 100% dokaze CPU vytazit iba cisto vypoctovy proces, ktory necaka na ziadne I/O a nema ziadne zavislosti na inych vlaknach.

[Zoltan Balaton]

-no snad sa to zmeni..
-inak zaujimalo by ma ake procesy spomaluju pdf,na co sa akoze caka

[galen]

-no snad sa to zmeni..
-inak zaujimalo by ma ake procesy spomaluju pdf,na co sa akoze caka

nejde o to, co ho spomaluje, ale o to, co musi spravit ...

vezmi si to tak, ze z nejakeho zkompilovaneho suboru (.pdf) on musi ciernou magiou vyratat, co ti ma priblizne zobrazit
na to "priblizne zobrazit" musi zaplikovat transformacie vzhladom na akutalne nastavenie vystupu, teda zoom, farebne skaly, velkost okna, velkost zobrazovacej plochy a podobne ...

a potom pride uzivatel, ktory klikne na supatko na pravej strane okna, aby sa to cele posunulo o jeden pixel ...

takze on znova vydoluje (alebo si drzi v pamati) objekt/objekty ktore prave zobrazuje a najblizsie ma zobrazit,
prerata co z nich vlastne ma zobrazit, a samozrejme, znova zobrazi ...

znie to jednoducho, ale verim tomu, ze to jednoduche nieje, aj napriek tomu, ze si adobe vyalokuje slusnu cast pamate, kde ma potencial si svoje data drzat (a nemusi napriklad pokazde dekompilovat pdf subor), ale nemoze predpokladat vsetky moznosti, ktore s tym uzivatel bude robit ... vid kliknutie o 1 pixel dolava, alebo doprava ...
a co ked klikne o 4 pixely, a nie o 1?
alebo o stranku nizsie ?
zoomne?

[Zoltan Balaton]

akoby v pdf islo toho robit vela
no mohol by predrenderovat aspon polstrany dopredu,alebo nieco podobne..ked uz ide o pdf tak nie ze by mi to vadil,len nechapem tomu preco sa taka jednoducha vec ako prezeranie dokumentu musi chovat tak dramaticky..ved si zober co vsetko sa musi prepocitavat pri modernych 3d hrach a idu plynule..ten rozdiel mi tam proste nesedi