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

[Galloth]

Dekuji za vysvetleni. Vas pohled na nektere veci je mi uz jasnejsi. U
nekterych se shodneme a u nekterych ne:
Latex a make odpovidaji unixove filozofii delej jedno ale dobre. Vy
mate spise pohled Windowsovsky delej vsechno a neobtezuj uzivatele. To
je veci nazoru. Tedy ohledne paralelizace prekladu na urovni
jednotlivych souboru se v podstate shodneme. Me to staci tak jak je to
nyni (make a tex, vy si prejete integraci do jedineho kroku. Budiz)

Dne 22. říjen 2008 21:29 Bc. Marek Pavlu <pavlu@hwserver.cz> napsal(a):
> 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.
>
>
>  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
Nyni se mi zda, ze si torchu odporujete. POkud spustim n krate gcc na
n ruznych souboru, paralelizuji n uloh na n procesoru a pametova
narocnost samozrejme roste, ale pokud bych to chtel delat na urovni
gcc tak bych mel pouze dve moznosti, toto deleni by provedlo gcc, tedy
gcc by samo spustilo nekolik instanci prekladu pro ruzne souboru. Tedy
pametova narocnost by rostla stejne a nebo by gcc paralelizovalo
preklad jednoho souboru. Pokud paralelizujete preklad jednoho souboru
tim, ze jej rozdelite na n bloku a pak spustite na kazdy blok preklad
paralelne, tak v podstate delate uplne to same jako by jste poustel
preklad na vice souboru.


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

>
>> 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.
Prilis Vam nerozumim, co myslite pod pojmem optimalizace cloveka.
Optimalizaci samozrejme musi provadet prekladac, a v podstate plati,
ze cim vice informaci ma, tim vice toho muze zoptimalizovat. Jiste
souhlasite, ze pokud budu mit funkci A, ktera bude na konci ukladat
vypoctenou hodnotu do pameti. A Pak mam funkci B, ktera bude vyslednou
hodnotu nacitat z pameti. A nikde jinde se uz ta hodnota nepouzije.
Tak pokud mam k dispozici obe funkce, tak mohu optimalizovat, naopak
pokud je kazda funkce v samostatnem modulu, tak neudelam nic.

>
> 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.

Jak rekam nevim co myslite pojmem "optimalizace kodu clovek". Kde se to vyucuje?
>
> 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...
Nebudu hadat. A navic nevidim smysl teto repliky. O nutnosti
kompilatoru se snad shodneme oba. Jen resime vyhody a nevyhody
paralelniho prekladu.
>
>
>
>> 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.
Bohuzel tyto jiste teorie neznam, ale obavam se, ze prohledavani
databaze a prijimani retezce automatem jsou docela rozdilne veci.
Takze bych spise od ocekaval nejake rozumne vysvetleni jak
paralelizovat semantickou analyzu a optimalizace.

>
>
> 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:).

Ja nevyvracim paralelizaci obecne, ale ja jen chtel vedet nejaky
rozumny argument jak paralelizovat vlastni proces prekladu.
>
>
>> 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...
Bavime se jeste vubec o paralelizaci prekladu nebo o paralelizaci
vysledneho kodu????? OpenMP prece vubec nesouvisi s prekladem, ale s
paralelizaci vlastniho programu....
>
> 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.
Ja to tak udelal u gcc: pri prekladu knihovny cmph

make -j        Real time
bez               42.92
2                  21.24
3                  16.83
4                   12.19
8                   10.25

Po make clean jsem jeste provedlo time cp * ~/tmp2  a dostal jsem real time 9.18

Pocitac mel 1 procesor
CPU	Xeon(R) CPU E5320 @ 1.86GHz
RAM	: 2GB

Myslim ze je to dvoujadro. Je pravda, ze uvedena tabulka neni prilis
vypovidajici, protoze se vzdy jedna jen o jedno mereni. Kdyz jsem
mereni zopakovat vysledky se samozrejme lisili, ale nemam ted cas
delat vsechno dvacetkrat a pak zpracovavat protokol. Myslim, ze
zakladni myslenku tabulka vystihuje.

>
>
> 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
>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>



-- 
Jan Kastil
galloth@jabbim.cz