Společnost Meta otevírá svůj operační systém Meta Horizon OS pro headsety pro virtuální a rozšířenou realitu. Vedle Meta Quest se bude používat i v připravovaných headsetech od Asusu a Lenova.
Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
Ještě letos vyjde Kingdom Come: Deliverance II (YouTube), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
Thunderbird 128, příští major verze naplánovaná na červenec, přijde s nativní podporou Exchange napsanou v Rustu.
Byly vyhlášeny výsledky letošní volby vedoucího projektu Debian (DPL, Wikipedie). Novým vedoucím je Andreas Tille.
Po osmi měsících vývoje byla vydána nová verze 0.12.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 268 vývojářů. Přehled novinek v poznámkách k vydání.
11.11.2010 00:44
Jardík | skóre: 40
| blog: jarda_bloguje
11.11.2010 01:12
Jardík | skóre: 40
| blog: jarda_bloguje
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
10.11.2010 23:46
for (uint32_t j = 0; j < 10; ++j)
{
for (i = 0; i <= 99999999u; ++i) {
IntToStr8(i, pwd);
}
}
V případě C funkce 19s, v případě mé funkce v assembleru 2m4s a při použití sprintf() 3m48s. A to se opravdu vyplatí
void IntToStr8(uint32_t num, char* str)
{
uint32_t rem;
for (int i=7;i>=0;i--) {
rem=num%10;
str[i]=(char)(unsigned char)(rem + 0x30);
num /= 10;
}
}
11.11.2010 11:39
Jardík | skóre: 40
| blog: jarda_bloguje
Googluj BarsWF.
11.11.2010 15:44
Jardík | skóre: 40
| blog: jarda_bloguje
11.11.2010 15:53
Jardík | skóre: 40
| blog: jarda_bloguje
. Škoda, že x86 nemá nějaký pořádný instrukce pro převody mezi bin a dec. Vím, že existují nějaký AAM AAD apod. ale ty nejsou pro větší registry než 8bit (teda aspoň u CPU tak do pentia2, novější jsem nestudoval...).
. Já jsem totiž mluvil o instrukci DIV jen v části o omezenosti na registrech, to se dá v mikrokódu krásně obejít. Pro zmiňovanou úlohu pak zase není DIV potřeba, tam jsem psal o dělení 10 což je úplně jiná úloha.
Jinak dělička v počítači může mít mnoho podob, jedna z nich může být třeba tabulka, ale to už je dost extrém . Nicméně ta pak má dobu trvání jeden takt.
.
11.11.2010 01:13
Jardík | skóre: 40
| blog: jarda_bloguje
Jinak asi vím, jak by ten kód šel ještě zrychlit, pokud jsou vstupní hodnoty malé, ale nechce se mi to zkoušet :)
11.11.2010 02:54
Jardík | skóre: 40
| blog: jarda_bloguje
Přišlo mi to pomalé a potřebuju zrychlení.
11.11.2010 12:12
Jardík | skóre: 40
| blog: jarda_bloguje
.
P.S. Jak dlouho trvá vygenerování rainbow tabulky?
Takový DMA by musel počítat s tím, že souvislý blok paměti z heldiska procesu není souvislý blok ve fyzické paměti.To je fakt, granularita po stránkách ujde. Jinak scatter gather.
Dále by DMA musel počítat s tím, že fyzická paměť dokonce vůbec nemusí existovat, ale může být ve swapu.To je fakt. Ale to je stejný jako u memcpy imho.
Dále DMA může umět zapsat někam, kde to proces nemá povoleno.Tak to je na OS
.
Nevěřte tomu, že by 1KB DMA byl obecně rychlejší. Se vším tím servisem kolem by zoufale zaostával.Tak samozřejmě musely by být nějaký semafory apod. Ale je celkem blbý v době, kdy probíhá po světě paralelizace úloh kopírovat celým jádrem bajt po bajtu. Jinak ten kilobajt jsem prostě jen tak nadhodil, klidně to může být ona stránka. Ale je fakt škoda, že DMA neumí spolupracovat s MMU
.
11.11.2010 20:26
Gilhad | skóre: 20
| blog: gilhadoviny
.
Právě že zas tak moc ne, protože když DMA obejde CPU, tak si toho OS prostě nevšimne
Právě že zas tak moc ne, protože když DMA obejde CPU, tak si toho OS prostě nevšimneMyslel jsem to tak, že by měl OS vědět kam se může zapisovat a kam ne a tedy znát, že celej rozsah je validní a lze do něj zapisovat. Jinak třeba na takovým OMAPu se používá DMA na triviality jako rotace bitmapy.
11.11.2010 21:33
Gilhad | skóre: 20
| blog: gilhadoviny
nebo by se to DMA muselo používat jako volání OS, nikoli jako funkce v programu.To tak ale obvykle bývá, že když využíváš nějaké zařízení, používáš k tomu volání jádra. (Další zdroj zdržení a důvod dělat to rovnou.)
ARM jádro pracuje s pamětí setsakra blbě a setsakra pomalu. Jeho RISCová architektura typu load/store potřebuje třeba i několik instrukcí na paměťovou operaci ve strojáku na to, co x86 dokáže často jednou instrukcí.... až na to, že těch i několik instrukcí zvládne provést rychleji než odpovídající x86. To, že odpovídající x86 je dneska zastaralá šunka, je důsledek faktu, že x86 má mnoholetý náskok ve vývoji (než se zjistilo, že pro mobilní stroje apod. se x86 nechytá a že to chce něco jiného - efektivnějšího.)
x86 je jiná architektura, navíc na ní jsou provozovány chytřejší operační systémy, které počítají se stránkováním, ochranou pamětiPoužívání ARM nic takového nevylučuje.
U ARMu je to z hlediska jádra cpu externí součást, kterou neřídí a nezná o ní přímo podrobnosti.[citation needed] Nebo jinak - co je podle tebe externí součást? Čip o kousek vedle procesoru? Kdy žiješ? A btw. i kdyby to tak bylo, nic to nemění na tom, že bude fungovat stránkování, ochrana paměti atd.
x86 je jiná architektura, navíc na ní jsou provozovány chytřejší operační systémy, které počítají se stránkováním, ochranou paměti, swapováním a ochranou procesů mezi sebou.No já nevím, thumb módy v ARMu jsou imho dost velkej hi-tech
.
co x86 dokáže často jednou instrukcíI po rozložení do vlastního mikrokódu? Já si osobně myslím, že DMA by šla pro memcpy použít a i přes náročný servis by to pro tisíce bajtů bylo větší zrychlení, i když možná jen pro speciální případy. Kopírování textu do konzole uživateli stačí imho bit po bitu
, pro periodické kopírování by to význam mělo určitě (nebylo by potřeba nastavovat vše znova).
BTW takový multimedia taky mají svojí podporu v CPU.To jo, ale to už je trochu něco jiného. U multimediálních instrukcí je to použít nejstarší x86 instrukce a dělat něco dlouho vs. použít mutimediální instrukce a dělat to rychleji. U kopírování pomocí DMA chceš kopírovat pomocí DMA enginu a zároveň dělat něco jiného. V tom prvním případě se mění jenom to, jak něco děláš z hlediska instrukční sady. V tom druhém se pokoušíš paralelizovat něco, co dost dobře paralelizovat nejde (viz. ten kus kódu níže), tzn. v praxi by ti stejně nezbylo nic jiného, než během kopírování buď čekat*, nebo zpracovávat úplně jinou úlohu (nevýhody jsem popisoval jinde) * tohle by mohlo mít smysl třeba v případě, že bychom chtěli šetřit energii. Během kopírování by se CPU přepnul do nějakého úsporného režimu (malá úspora, rychlé probuzení) a kopírování by zajistil na energii méně náročnější DMA engine. I v tomhle případě bych ale řekl, že by bylo jednodušší prostě umožnit uspávání těch částí CPU, které se při kopírování nevyužijí. I když tady se zase objevují záležitosti typu jak poznat, že teď je možné se uspat atd.
a = cekej_na_nejaka_data_a_vrat_na_ne_ukazatel(); b = dej_mi_ukazatel_na_cilovy_blok(); c = rekni_mi_kolik_bytu_mam_kopirovat(); memcpy(b, a, c); // implementováno neblokující instrukcí, která používá DMA udelej_neco_s_daty_v_bloku(b);Ještě mě napadlo, že vlastně by ten příklad šel i s DMA, například pokud by bylo vyžadováno malé latence, ale vyžadovalo by to paralelnější přístup k kódu. Ta memcpy totiž pro určité funkce udelej_neco_s_daty_v_bloku() nemusí nutně kopírovat celý béčko. Pokud by zkopírovala jen třeba prvních 64bajtů, tak by se během dalšího přenosu 64bajtů mohlo současně zpracovávat tou funkcí těch prvních 64B. Což by ve výsledku mohlo znamenat třeba i dvojnásobný zrychlení.
To je fakt. Ale to je stejný jako u memcpy imho.Není (a Gilhad v #40 o kousek vejš nemá pravdu). Memcpy běží v userspace, takže když se pokusí sáhnout na paměť, která je zrovna odswapovaná, CPU hodí výjimku, jádro ji chytí, stránku někam nahraje a pak se program nechá běžet dál. Nic takového, jako že by memcpy po bytech kontrolovala, jestli nedošlo k výpadku paměti, se neděje. Dokonce AFAIK ani nemůže (proces neví, které jeho stránky v paměti jsou a které ne)
Tak samozřejmě musely by být nějaký semafory apod.Hádám, že servisem je myšleno nastavit to DMA zařízení atd. To bude trvat relativně dlouho (I/O), dost dlouho na to, aby se vyplatilo udělat to přímo.
Ale je celkem blbý v době, kdy probíhá po světě paralelizace úloh kopírovat celým jádrem bajt po bajtu.a) nevim, kde jste přišli na to byte po bytu. Na moderních procesorech to pravděpodobně bude v o něco větších kusech. b) klidně můžeš udělat paralelní kopírování. Nastavení vláken a jejich vzájemné čekání atd. atp., zkrátka to zase bude trvat déle než to zkopírovat sériově jedním CPU.
Není (a Gilhad v #40 o kousek vejš nemá pravdu). Memcpy běží v userspace, takže když se pokusí sáhnout na paměť, která je zrovna odswapovaná, CPU hodí výjimku, jádro ji chytí, stránku někam nahraje a pak se program nechá běžet dál.Tak by se před inicializací provedl test dané stránky zda existuje na určeném místě a případně jí natáhl ze swapu (btw už to samotný natažení ze swapu pravděpodobně koná DMA).
Nic takového, jako že by memcpy po bytech kontrolovala, jestli nedošlo k výpadku paměti, se neděje. Dokonce AFAIK ani nemůže (proces neví, které jeho stránky v paměti jsou a které ne)Jo to mě trochu zmátlo...
.
Hádám, že servisem je myšleno nastavit to DMA zařízení atd. To bude trvat relativně dlouho (I/O), dost dlouho na to, aby se vyplatilo udělat to přímo.Tak na x86 asi jo, někde jinde nemusí
.
a) nevim, kde jste přišli na to byte po bytu. Na moderních procesorech to pravděpodobně bude v o něco větších kusech.To byla nadsázka, ale klidně můžeš nahradit bajt skalárem a bude to mít stejnej význam. Právě jsem myslel, že by se hodilo v tomhle případě pracovat s vektorem. Teoreticky by šla substituovat současná instrukce REP MOVSD na nějakej triviální automat skalárního kopírování, pro program by se to jevilo jako vektor.
b) klidně můžeš udělat paralelní kopírování. Nastavení vláken a jejich vzájemné čekání atd. atp., zkrátka to zase bude trvat déle než to zkopírovat sériově jedním CPU.Jj, ale to dneska znamená plýtvat ALU jednoho jádra na kopírování, při DMA by byl celý ALU k dispozici a mohl třeba Jardíkovi louskat md5
.
Třeba na tom Vámi zmiňovaném ARMu je rychlost I/O katastrofa. I/O je tam realizováno mapováním do paměti.Fuj, radši pomalejší zápis do MMIO než používání brutálně neflexibilního IN/OUT na x86, navíc když to fyzicky používá tak jako tak stejný adresní dráty do procesoru. Věci jako MMU na IO je pak pozitivní vedlejší produkt. Programování I/O ve stylu 8bit je humus. Typově třeba uart řadič na způsob tady je registr na vysílaný bajt, ale pokud je v tom a tom registru v tom a tom bitu tahle hodnoa, tak to je nastavení děličky hodin, ale jen jedna polovina, druhá polovina (8bit) je zase v jiným registru, kterým se jinak ovládá něco jinýho. Když pak člověk pracuje třeba v 32bit prostředí a má 32bit registry, tak si rve vlasy proč to prostě nemohli dát do 32bit registru, kde by dělička měla rezervu na tisíc let dopředu
.
Nedělejte si iluze, x86 je hodně nalepovák, ale z hlediska výkonu je to excelentně dobrá architektura.No moje priority jsou: nalepovák → určitě ne nejlepší řešení.
Není to tak dávno, kdy se řada odpůrců těšila na to, že x86 architektura a celé CISC půjde do háje z důvodů nedostatečného výkonu. Nakonec se ukázalo, že právě univerzalita a vysokoúrovňovost x86 strojáku je mocná zbraň pro dosahování výkonu.To spíš kvůli vendor lock-inu.
Na x86 architektuře klidně můžete mít I/O mapované do paměti. Naprosto nic tomu nebrání. A také se to v řadě případů dělá.Takže tu je IN/OUT a ještě MOV? teda dva různé cykly generované chipsetu. To je ještě horší
.
Nebo si pročtěte v manuálu kolik taktů hodin u ARMu trvá reakce na přerušení. Budete zvracet. Když ARM na FIQ (fast interrupt request) zareaguje do 30 taktů hodin, jste zhruba na nejnižší možné hodnotě zpoždění.To bude hlavně kvůli tomu, že má každý blok vlastní hodiny ne? BTW v manuálu OMAP3 je u interrupt latency hodnota 10 (ale je možný se se ještě někde nabere). Jinak já mám Duron 600MHz a stačí mě to. Mě o nějaké latence přerušení fakt nejde. Za to mě jde třeba o dokumentaci čipu, takový zamknutý násobiče u Intelu je fakt opruz.
V tom případě si ARM také rovnou škrtněte. ARM je poměrně dosti nalepen.Ale já nechci škrtat. Jen v případě nalepováku se prostě sníží priorita meho zájmu.
Jestli si myslíte, že budete mít někdy architekturu starou 20 let a nebude v ní hafo nalepováků, tak jste naivní.S tím počítám.
Není to tak dávno, kdy se řada odpůrců těšila na to, že x86 architektura a celé CISC půjde do háje z důvodů nedostatečného výkonu. Nakonec se ukázalo,...že když x86 převezme nějaké myšlenky RISC architektury, že může existovat dál. Což se stalo asi tak před pěti - deseti lety. Hlavní výhoda RISC architektur je v tom, že má sice jednoduché instrukce, takže na stejnou věc jich je potřeba víc, ale ty instrukce se vykonávají mnohem rychleji, takže celkově je ten procesor podstatně rychlejší. Mimo jiné, srovnávat dnešní ARM s dnešními x86 není úplně fér, protože x86 se přece jenom vyvíjelo déle. A krom toho - kdyby x86 uměla všechno, co je potřeba, ARM by nikdo nepoužíval. Vývoj není zadarmo, přesto se ARM vyvíjí a používá, což nějaký důvod asi mít bude.
A krom toho - kdyby x86 uměla všechno, co je potřeba, ARM by nikdo nepoužíval. Vývoj není zadarmo, přesto se ARM vyvíjí a používá, což nějaký důvod asi mít bude.+1 a vendor lockin, nezapomínej na vendor lockin
.
Ale nenechte se realitou nikterak zneklidnit.... říká astrolog, co tu nedávno tvrdil, že dělení na FPU je rychlejší než pomocí SSE2 a trvá jeden tik hodin. (Nebo tak nějak to bylo, že?)
Je se to v praxi nepotvrzuje, takový drobný detail.V praxi se to potvrdilo velmi dobře, třeba v době, kdy ještě byly peníze na vývoj (řekněme rok '95), PowerPC naprosto válcovalo x86. Co se výkonu týče, x86 bylo za PowerPC opožděno o nějaké dva až tři roky. Ano, svět x86 nakonec to zpoždění dohnal, jenže ne díky CISC architektuře, ale díky tomu, že jistý majoritní OS PowerPC nepodporoval, takže trh s těmito CPU byl menší a tím bylo i míň peněz na vývoj.
Ano, svět x86 nakonec to zpoždění dohnal, jenže ne díky CISC architektuře, ale díky tomu, že jistý majoritní OS PowerPC nepodporoval, takže trh s těmito CPU byl menší a tím bylo i míň peněz na vývoj.
Není to hlavně tím, že x86 CPU jsou od jisté doby uvnitř RISCové? Pokud se pamatuji, tak uvnitř se dělá překlad x86 instrukcí na RISCové. Tedy aspoň to tak výrobci prezentovali.
Není to hlavně tím, že x86 CPU jsou od jisté doby uvnitř RISCové?Viz první odstavec v #58 (o kousek výš)
Všechno souvisí se vším. Kdyby nebylo tolik peněz na vývoj, respektive kdyby výchozí postavení těch procesorů bylo rovnocenné, těžko by si někdo mohl dovolit udělat takový převrat v architektuře. Neměl by na to prachy.
V praxi se to potvrdilo velmi dobře, třeba v době, kdy ještě byly peníze na vývoj (řekněme rok '95), PowerPC naprosto válcovalo x86. Co se výkonu týče, x86 bylo za PowerPC opožděno o nějaké dva až tři roky.Ono je to vidět i nedávno/dnes. Viz třeba obliba PS3 s Cellem.
Ono je to vidět i nedávno/dnes.A nejenom na "velkých" procesorech typu x86... u malých jednočipů to platí úplně stejně
Nicméně v absolutním výkonu ARM nemůže x86 konkurovat.Jo, tady se projevuje ten několikaletý náskok ve vývoji.
Znovu zdůrazňuji, ARM instrukce jsou pomaleji vykonávány, než x86 instrukce a to přesto, že x86 instrukce nahradí často několik ARM.Jestli to náhodou trochu nesouvisí s tím, že ARM CPU bývají taktovány na ~500MHz, kdežto x86 na 2GHz a více.
V neposlední řadě do vývoje a zdokonalování x86 byly vraženy takové prachy, jaké ARM mít nikdy nebude.Hvězdy promluvily...
Jestli to náhodou trochu nesouvisí s tím, že ARM CPU bývají taktovány na ~500MHz, kdežto x86 na 2GHz a více.Dle mych zkusenosti maji bezne ARMy vyrazne nizsi vypocetni vykon/MHz i pri srovani s Atomem, a ten ma zase vyrazne nizsi vykon/MHz nez mainstreamove x86 procesory. Jina vec je ale vypocetni vykon/Watt prikonu.
12.11.2010 11:59
Gilhad | skóre: 20
| blog: gilhadoviny
.
Postupně v ARM narůstá spousta věcí, které jsou tam pouze z historických důvodů (protože pro to byl před lety dobrý důvod, dnes už nikoli).Samozřejmě se ani jako zastánce ARMu redukční dietě nebráním.
Nicméně v absolutním výkonu ARM nemůže x86 konkurovat.Ovšem ale takovej Atom na 800MHz má víc než čtyřnásobnou spotřebu než OMAP3 na 800MHz. Takže na stejný zdroj jako Atom se může zapojit čtyřnásobek OMAPů
.
V neposlední řadě do vývoje a zdokonalování x86 byly vraženy takové prachy, jaké ARM mít nikdy nebude.No právě vendor lockin.
.
Myslím, že je čas, abych v této debatě skončil.Myslím, že je čas si vzpomenout, jak jsi říkal něco o tom, že už tu nebudeš přispívat. Ale jasně, jestli jsi to vyčetl z hvězd, tak je pochopitelné, že ani tahle předpověď ti nevyšla...
Ovšem SSE2 má dnes i hodně zastaralej křáp.To můžu rovnou napsat pro SSE3...
Jinak možná Vám to uniklo, ale autor příspěvku používal 64bitový asm.Což ovšem k řešení vůbec nebylo potřeba. Řešený problém lze naprogramovat klidně v BASHi, kde se bude wgetem volat server, který má už dávno rainbow tabulku předgenerovanou.
Vy jste tu přispěl spoustou nesmyslných tvrzení, o kterých nemáte moc ponětí.Muhehe vyhrál jsem
, vydržel jsem dýl a nesnížil jsem se k snižování oponenta (hmm ne že by to nutně nebyla pravda).
Další Vaše taktika je jen se politicky prosadit a někoho dostat.Přirozeně. Pokud se o ARM bude zajímat víc lidí, tak bude mít aspoň x86 konkurenci a třeba na to zapracuje. Navíc to může mít taky důsledek, že lidi budou lépe řešit úlohy zmíněné v zápisku.
11.11.2010 22:31
Gilhad | skóre: 20
| blog: gilhadoviny
memcpy běží na CPU jako proces uživatele (se všemi omezeními a "iluzemi" o souvislé dostupné paměti, nepřerušovaném běhu atd atd), na rozdíl od DMA, které běží hardwarově jinde a "sahí si přímo na železo", takže ho ty "iluze" ani neomezují (a tudíž by měl OS problémy testovat oprávněnost přístupu do paměti) ani mu nepomáhají (takže neví, kde a zda má který proces namapované stránky).
Tak by se před inicializací provedl test dané stránky zda existuje na určeném místě a případně jí natáhl ze swapu (btw už to samotný natažení ze swapu pravděpodobně koná DMA).
A taky zda jde o jednu stránku, nebo třeba několik, zda a jaké práva k přístupu má uživatel ke kterým z nich a po natažení ze swapu by se dotaz rozdělil na několik, podle toho, kam by se to natáhlo a pak by se to po dokončení dotazu zase muselo označit jako modifikované - ono toho není málo, co je pro takovou věc potřeba zařídit, aby "iluze" víceuživatelského OS fungovala bezchybně.
Výhoda memcpy je, že má všechny tyhle věci ošetřené přez cetrální mechanizmus (čili jednotně se zbytkem systému), který ani nevidí (takže to nemůže poškodit)
Tak by se před inicializací provedl test dané stránky zda existuje na určeném místě a případně jí natáhl ze swapuCož musí udělat jádro, čímž se zase dostáváme k syscallům a k tomu, že to rychlejší nebude.
Jj, ale to dneska znamená plýtvat ALU jednoho jádra na kopírování, při DMA by byl celý ALU k dispoziciTo jo, ale pro nějakou jinou úlohu; většina programátorů ale chce spíš, aby jejich program běžel rychle. Navíc započítej přepnutí kontextu, spuštění jiného programu, který nemá data v cache, návrat k původnímu programu, který už také nemá data v cache (použití toho enginu manipuluje přímo s pamětí; to, co bylo v cache CPU, už není pravda), celkově to dost snadno bude pomalejší, než prostě ta data přesunout.
a = cekej_na_nejaka_data_a_vrat_na_ne_ukazatel(); b = dej_mi_ukazatel_na_cilovy_blok(); c = rekni_mi_kolik_bytu_mam_kopirovat(); memcpy(b, a, c); // implementováno neblokující instrukcí, která používá DMA udelej_neco_s_daty_v_bloku(b); ...Zpracování té instrukce implementující memcpy bude chvíli trvat, jenže my v následujícím příkazu už potřebujeme, aby byla hotová. To znamená, že i když instrukce sama neblokuje, bude potřeba použít jinou, která zablokuje běh programu do doby, než se kopírování dokončí. Z kódu je přitom vidět, že memcpy dřív zavolat nemůžeme, protože nemáme všechna potřebná data. A takhle bude s velkou pravděpodobností vypadat hodně případů použití memcpy(), tím pádem se moc času neušetří a tranzistory investované do dané instrukce by bylo pravděpodobně lepší využít na něco jiného.
mezitím by byl CPU prakticky volnej pro jiný vlákno.Psal jsem jinde. Podle mě by to nefungovalo dobře kvůli přepínání kontextů - přepnutí kontextu nějakou dobu trvá a není to málo. U vlákna to možná není takový problém jako u procesu, ale i tak. Nové vlákno by ti vytěsnilo z cache data původního vlákna, přičemž by samo čekalo na data z paměti (jestliže kopírujeme tak velký objem dat, že se nám vyplatí přepnutí na jiné vlákno/proces, je to druhé vlákno/proces pravděpodobně cache-cold). Po přepnutí zpátky by na načtení dat muselo čekat původní vlákno. Do toho si předej, že to jiné vlákno předtím možná běželo na jiném CPU a musí se tedy počkat, až původní CPU vypíše data za svých cachí do paměti, aby je bylo možné načíst na nové CPU Tohle všechno by IMO v součtu zabralo mnohem víc času, než prostě udělat staré dobré kopírování kousek po kousku.
). Jinak já uvažuju těch kopírovacích jednotek víc (i DMA má víc kanálů).
Ale při sdílené sběrnici se tomu nevyhneme, koneckonců DMA funguje taky na sdílené sběrniciNo nevim, podle mě je rozdíl mezi situací, kdy DMA vyvolá zařízení (mám smůlu, zrovna to padlo na mě a ne na Frantu) a kdy ho vyvolá Frantův proces (Franta mi užírá můj čas CPU)
Jakákoliv DMA má být z definice transparetní tedy neužírá žádný čas CPUTo je pravda. Jenže k čemu je mi dobrý čas CPU, když nemám instrukce/data, protože se musí dodat z paměti.
MOV AX,[0x4242] DIV BLA přece se to dá ve větším kontextu optimalizovat pro co nejmíň "bublin". I kdyby se proces po spuštění DMA zastavil, tak s DMA jako instrukcí bude task manager konat efektivněji, protože mu ubyde proces, na kterým má přepínat (a tedy i přepínací overhead).
12.11.2010 14:22
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
. Ale to je extrém. Jinak jestli chápu dobře kontext, tak jsme se tam bavili o hypotetické optimalizované DMA.
12.11.2010 20:14
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
12.11.2010 20:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
12.11.2010 21:07
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
. V OMAPu 3 to jede určitě, ale podle if konstrukcí v .c bude základní funkcionalita všude. Ten plat-omap adresář je společnej.
13.11.2010 00:29
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
ak by mohl být kód za DMA instrukcí zastaven a spuštěn až po dokončení DMA, mezitím by byl CPU prakticky volnej pro jiný vláknoTohle vicemene resi hyperthreading. Pokud bude nejaky program kopirovat spoustu pameti, tak bude vecne blokovany pristupem do pameti a nevyuzivane ALU jednotky mezi tim pouzije jine 'hypervlakno' bezici na stejnem jadre.
11.11.2010 11:47
Jardík | skóre: 40
| blog: jarda_bloguje
12.11.2010 00:16
Jardík | skóre: 40
| blog: jarda_bloguje
12.11.2010 02:26
Jardík | skóre: 40
| blog: jarda_bloguje
13.11.2010 11:50
tsLnox | skóre: 31
| blog: Blog jednoho ukecaného Gentoolemana
| Žďár nad Sázavou
Řetězec musí bít zarovnané vpravoA sakra. Jdu se zarovnat vlevo, nerad bych dostal řetězcem
11.11.2010 08:17
int lkp[10000];
void IntToStr8init()
{
int a0,a1,a2,a3;
for (a3=0;a3<10;++a3) for (a2=0;a2<10;++a2) for (a1=0;a1<10;++a1) for (a0=0;a0<10;++a0) lkp[a3*1000+a2*100+a1*10+a0]=((a3+'0'))+((a2+'0')<<8)+((a1+'0')<<16)+((a0+'0')<<24);
}
void IntToStr8j(int num, char* str)
{
int p,q;
p=num/10000;
q=num%10000;
*(int*)str=lkp[p];
*(1+(int*)str)=lkp[q];
}
Tiskni
Sdílej:
