Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
hmm.. uz ked sa takto snazia upravit cpu aby rozlozil vlakno na mensie "priadze" aby slo na viacjadrovych cpu rychljsie, nebolo by jednoduchsie upravit prostredie pre jednovlaknove aplikacie aby videli multicpu ako jednojadro na sposob sli/crossfire? ci ako to robi hydra v pripade grafik? aby sa akoze tvarilo ze je to jednojadro ale riesia to dve a viac jadier? snad som to napisal jasne ;)
V případě toho SLI/CrossFire ovšem nejde o jedno vlákno jednoho procesu.
a co ked ho budu" vidiet" ako jedno jadro.. To nic neznamena,,,
oni ho aj dnes tak vidia...
Zjavne nepatrte medzi 1% koderov, co problematike rozumie
http://www.theinquirer.net/inquirer/news/1026585/programmers-prepared-gl...
Nejde. Zásadní problém je v tom, že když máš sekvenci výpočtů:
a
b
c
tak abys mohl spočítat C, potřebuješ většinou výsledek B a B zase potřebuje A. Částečně se to určitě paralelizovat dá důkladnou analýzou zdrojáku a zjištěním, jaké části kódu jsou na sobě nezávislé (předpokládám, že to dělá ten kompilátor), ale s tím ostatním nijak nepohneš.
No dovedu si predstavit vyuziti. Treba interpret jazyka Python je jednovlaknovy a thready potom v ramci toho jednoho vlakna simuluje. Zde mam zaruceno, ze jednotlive virtualni thready na sebe necekaji, pokud nejsou synchronizovany a synchronizaci uz lze resit standardne.
Protoze interpret Pythonu je odflaknuty. Jenom lenoch nebo blbec implementuje virtualni thready tak ze je interpretuje uvnitr jednoho threadu. Nastesti pro Intel lenochu a blbcu je plno takze vyuziti toho kompilatoru nic nebrani ...
Ono ten CPU zas tak moc upraveny nebude, nejvic prace odre ten kompilator ze ktereho se bude kourit az bude podle zdrojoveho kodu ve vyssim programovacim jazyce hadat co se da paralelizovat. Kdyby to udelal programator, bylo by to mnohem efektivnejsi ... jenze ten programator by se nad tim musel zamyslet. A museli by se prepsat knihovny od operacniho systemu vys, protoze spousta z nich jeste ted multithreadove bezet neumi ...
A co spouštět multithreadově samotné knihovny ?
CPU bude upravený tak, aby jednotlivá jádra mohla rychle a efektivně mezi sebou komunikovat a vyměňovat si mezivýsledky výpočtů. Myslím že na tom Intel začal pracovat už i u Core i7, Sandra ukazuje výrazný nárůst Inter-core Bandwidth ve srovnání s Core 2.
A nebylo by lepší, kdyby se ty jednovláknové aplikace přepsali na vícevláknové? Já sice programování nerozumím, ale myslím si, že je to jen o změně pár hodnot v kódu na pár minut/hodin.
Takto si Intel namastí kapsy, vydělá totiž na blbosti a lenosti tvůrců starých, ale dobrých aplikací.
:))))
Kdyby to šlo tak snadno, už by to někdo udělal, ne?
Říká se, že napsat a odladit 2 vláknovou aplikaci trvá (a stojí) 2x tolik... Vzniká tam spousta problémů se synchronizací vláken, přístupem do sdílené paměti, vůbec vymyšlení nějakého složitějšího paralelního algoritmu je obtížné a někdy i nemožné. Ve výsledku to zanese do aplikace dost chyb a výkonový přínos dvojnásobný rozhodně není. Takže se k tomu přistupuje jen u těch aplikací, které nutně musí být co nejrychlejší (konverze videa, fotek atd)
Tak to jo. Psal jsem, že o programování nic nevím.
Proboha jak jste vy dva prisli na to, ze Python je "jednovlaknovy" a ze "simuluje vlakna"? Co je to za totalni nesmysl? V Pythonu funguji vlakna jako v kazdem jinem programovacim jazyce. V Linuxu se pouzivaji pthreads, ve Win32 pak normlani windows vlakna.
http://docs.python.org/library/threading.html
No systemove thready mozno vyuziva, ale kvoli globalnemu locku interpretera, vdaka ktoremu vzdy bezi len jeden thread, je to irelevantne. Pokial ide o thready, ktore napriklad cakaju na nejaky vstup zo siete, tam sa to vyuzije - ale to iste sa da spravit jednovlaknovo. Pokial chces robit v dvoch vlaknach nejake vypocty, nic neziskas. Takze je cisty nezmysel porovnavat python s "kazdym inym programovacim jazykom".
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.