OT: Hyper Threading, bylo: OT: Asus Eee - prijemne prekvapeni

Bc. Marek Pavlu pavlu@HWserver.cz
Středa Říjen 22 21:29:51 CEST 2008


Zdravim,

> -----Original Message-----
> From: hw-list-bounces@list.hw.cz [mailto:hw-list-bounces@list.hw.cz] On
Behalf
> Of Galloth
> Sent: Wednesday, October 22, 2008 8:49 AM
> To: HW-news
> Subject: Re: OT: Hyper Threading, bylo: OT: Asus Eee - prijemne prekvapeni
> 
> No co pisete se mi moc nezda, ale rad se necham poucit.

>  Prvni vec je ze preklad vice souboru je samozrejme paralelizovatelny
> a bezne se dela, takze to muzeme povazovat za vyreseno.

Eee, nedela:). Kouknete napriklad ten TeX, tam se tak nedeje a neminim to
delat za prekladac.
Dost toho, ze musim ztratit moho casu primo v TeXu/LATEXU.
Prevazna vetsina prekladacu mi zatezuje pouze jedno jadro.


 Nedela se to
> na urovni prekladace, ale na urovni spousteni jednotlivych uloh. Napr.

Systemem: paralalizace ulohy na n-jadrovem procesoru spustenim n-uloh vede
do pekel, okamzite pametova narocnost vzroste n-krat,
          Ale vykon n-krat nevzroste, je potreba paralelizovat samotny
proces zpracovani

         Tento system muz pracovat rozumne pouze na n-procesorech, ktere
jsou navzajem oddeleny pametove, respektive nejakou pamet sdileji...

> v linuxu znamy make. Takze se vracime k souboru co ma 100000 radek.

U soubor co ma 100k radek je snaha o lidskou optimalizaci v dobe, kdy co dva
roky prichazeji nove instrukce pro optimalizaci toho ci onoho na strojich
x86 cira fantazie. Navic je kod extremne neprehledny a tudiz roste mira
chyb.

Proste ja a  i mnoho odborniku, dokonce se to i vyucuje, povazuje
optimalizaci kodu clovek opravdu za fantasmagorii, to bez urazky:)...
V tech stovkach instrukci v asm a nebo pri slozitosti kodu uz nemate sanci
optimalizovat.

Hadejte, procpak intel vyviji vlastni prekladac, integruje se do Visual
Studia a provadi analyzu, kde to nejvice zdrzuje.
Navic automaticky paralelizuje nektere casti kodu atd...



> Proc psat takovy soubor? Pro optimalizaci. Jestlize rozdelite kod na
> vice bloku a tak tim znemocnite optimalizace urciteho druhu. Napriklad
> pokud vite, ze linker bude spojovat prave tyto dve funkce a ne jine,
> tak muzete s klidem vyhodit nejake testovani podminek, pretypovavani,
> ukladani do pameti a podobne veci.  Duvod proc se to nedela je prave
> rychlost prekladu.
> 
> Takze k tomu co vy pisete o jednom souboru. Dobra pro provedeni
> lexikalni analyzy si to muzu udelat tak jak popisujete, ale ja se ptam
> k cemu mi to bude? Prekladacum moc nerozumim, ale podle toho co jsem
> pochopil, jsou trochu slozitejsi nez lexikalni analyzator. Pracuje
> totiz asi takto (me porozumeni)
> Lexikalni analyzator -> Syntakticky analyzator -> Semanticky
> analyzator -> Optimalizace -> generovani kodu
> 

Lexikalni analyzu jsem vzal jako prvni krok. Pokud vim, tak se z pihledu
jistych teorii na preklad nahlizi i jako na na ndatabazove operace.
Nevim zda budete souhlasit, ale [prodavam,jak jsem nakoupil:)..
A v posledni dobe je tu vyrazna snaha o paralelizaci databazovych operaci
prave pro vicejadra. Priklad muze byt z oblasti .NET LINK/PLINK.


Skutecne hoddte si dotaz na googlu a zjistite, ze paralelizace prekladacu
neni fantazie, ale i realna snaha a postupne to bude i nutnost.


> Kde samozrejme optimalizace a Semanticka analyza zabiraji nejvice
> casu. S cehos plyne, ze vetsinu casu prekladac travi prave
> optimalizovanim a semantickou analyzou a jen minimum v lexikalni
> analyze. Takze vase paralelizace lexikalni analyzy by toho prilis
> neprinesla maximalne by vyustila v automaticke rozdeleni souboru do
> nekolika mensich souboru, to jest tedy k tomu, co uz tu je.
> 

Uvedl jsem jen tako nastrel.
Kdyby neslo paralelizaci niceho dosahnout, tak by ty iniciativy neexistovaly
a spolecnosti jako MS/Intel by do toho nevrazely prachy:).


> V podstate se naopak totiz domnivam, ze vlastni paralelizace
> prekladace (opravdu prekladace, ne pusteni vice prekladu) je docela
> slozita uloha. Protoze se musi paralelizovat prave ty optimalizace a
> semanticka analyza, ktere jsou slozite sami o sobe. Urcite by to slo
> ale otazkou je, jaka by byla ve vysledku rezije.

Jiste, pro paralelizaci nemate totiz skoro nikde zadny klasicky a rozsireny
jazyk s podporou.
Neminim tim dodatecne knihovny jako OpenMP a dalsi...
Ale ani bezne nastroje nejsou pripraveny na masivni multithreading...

Zde je prvni problem.
Druhy je, ze se nam lepe uvazuje sekvencne.


> 
> Tesim se na vase vysvetlujici pripominky.
> 
> PS: Latex nema velkou spotrebu pameti, tak rozdelte vasi ulohu na vice
> souboru a prekladejte je paralelne a zrychleni mate.

Te na houby, to ma byt zabudovane.


M.P.



---
avast! Antivirus: Odchozi zprava cista.
Virova databaze (VPS): 081022-1, 22.10.2008
Testovano: 22.10.2008 21:29:51
avast! (c) copyright 1988-2008 ALWIL Software.
http://www.avast.com






Další informace o konferenci Hw-list