Hackování make pro urychlení kompilace Androidu (diskuse)

[mif]

Pekne ale mna by skor zaujimalo preco uprava DalvikVM? Vies to nejako rozviest, napr ake k tomu boli dovody alebo co sa tam upravuje?

[Tassadar]

Potřebuju udělat trace volání metod v aplikacích, a udělat to v dalviku bude nejrychlejší. Android sice už tracer má, ale já potřebuju něco trochu jiného (jednoduššího a za to rychlejšího).

[Limoto]

Trochu z jinýho soudku, jak dopadl tvůj výběr VŠ?

[Tassadar]

Skončil jsem na FI MUNI, Programovatelné technické struktury. K tomu jsem si našel na poloviční úvazek práci (vůbec nebyl problém s tím že by mě bez titulu nechtěli - naopak, problém byl to že bych tam kvůli škole nemohl být na plný úvazek, tak jsem nakonec šel na jinou, pro mě dokonce zajímavější, pozici). Co se týče školy, tak části jsou zajímavé (digitální systémy, ta, jak se od tranzistorů a diod dostanu k procesoru vykonávající instrukce mě vždy velmi zajímalo), ale je tam docela dost matematiky kterou nemám příliš rád ani mi nijak úžasně nejde. Nejsem si úplně jistý, jestli tam chci zůstat. No, uvidím po prvním zkouškovém a taky jak mi to půjde v práci.

[Limoto]

Já teď začínám prvák na FITu. Z předmětů nejzábavnější Assemblery a Teorie obvodů, jinak Základy programování jsou celkem nuda, Diskrétní matematika je u našeho přednášejícího celkem šílenost, ale to půjde asoftwarový inženýrství je takovej ne moc zajímavej předmět se spoustou teorie, ale věřím v jeho užitečnost. Ale náplň dalších semestrů vypadá zajímavěji...

Co se týče práce, poslední rok se živím v jedné prostějovské firmě jako programátor mikrokontrolérů, což mě celkem baví a je to směr, kterým bych si chtěl vybudovat co největší přehled (ale teda netvrdím, že bych se tím chtěl živit celej život...).

[dolik.rce]

nemyslím si, že zrovna jobservery k něčemu potřebuji

Jobserver je v make potřeba kdykoliv, když se pouští paralelní kompilace, tedy soudě podle příkladů i ve vašem případě. Bez toho aniž bych koukal do kódu si dovolím tipnout, že to při ukončování čeká až všechny childy doběhnou - a viset by to tedy mohlo proto, že díky forkování mu pak "nesedí účetnictví". Pokud tedy tu metodu nevoláte, mohlo by v určitých případech stát, že tam zůstane něco zbytečně viset.

[Tassadar]

Díky za nakopnutí, trochu jsem to prozkoumal a opravil. Problém je v tomhle kusu kódu:

/* Close the write side, so the read() won't hang.  */
close (job_fds[1]);

while (read (job_fds[0], &token, 1) == 1)

Ta jobs_fd pajpa je otevřená ještě před forkem, tj. po forknutí ji má otevřenou jak "daemon", tak i ten make co bude kompilovat. Ten kód ji pak zavře jednou, ale daemon ji má pořád otevřenou -> read nikdy nevrátí EOF. Řešením je otevírat tu pajpu až v childu, opraveno v patchi na gistu: https://gist.github.com/Tasssadar/f9f38d27253e88aa740b.

[Josef Kufner]

A nedala by se rozparsovaná data kešovat v jednom binárním souboru, který by odpovídal obsahu paměti po načtení makefilů?

A nedalo by se předřadit velkému makefile malý, který by kouknul, zda se něco nezměnilo a pokud ano, spustil ten velký makefile?

[xkucf03]

To mi přijde jako nudné řešení – ten hack je mnohem zajímavější

[Tassadar]

A nedala by se rozparsovaná data kešovat v jednom binárním souboru, který by odpovídal obsahu paměti po načtení makefilů?

To byla druhá možnost kdyby fork() pokus nevyšel, ale ukládání a načítání všech datových stuktur make by bylo pravděpodobně mnohem složitější.

A nedalo by se předřadit velkému makefile malý, který by kouknul, zda se něco nezměnilo a pokud ano, spustil ten velký makefile?

Ano, pravděpodobně by šlo něco takového vygenerovat. Ale opět mnohem časově náročnejší na výrobu, nicméně patches welcome :)

[Josef Kufner]

$ mv Makefile Makefile.orig
$ cat Makefile
.orig: *
        make -f Makefile.orig && touch .orig
$ make

[Tassadar]

Heh, obávám se, že tak jednoduché to nebude - on to není jeden Makefile, ale hromada *.mk souborů, která se do sebe různě includuje:

$ find -name *.mk | wc -l
4771
$

[Tassadar]

Navíc tedy nechci kompilovat když, se změní některý z Makefilů - teda, to taky, ale hlavně když se změní zdrojáky.

[dolik.rce]

Pokud bych to měl řešit pomocí skriptovaní, namísto toho nápaditého (a podstatně zábavnějšího ) hacku, tak bych zkusil něco takového:

make -pqB | sed '1,/^. Implicit Rules/d;/^[\x23]/d;/^$/d;' > preparsed.mk
make -f preparsed.mk -j4

Ten sed je tam jen proto, aby odstranil některé zbytečné části z výstupu, čtení a parsování komentářů přeci jen taky něco stojí. Teoreticky by to mohlo pomoct pokud ty makefily obsahují hodně logiky nebo velké kusy podmíněného kódu který se nakonec vůbec nepoužije. Docela by mě zajímalo vidět jak moc nebo málo na tomhle konkrétním projektu tenhle jednoduchý trik ovlivní dobu kompilace.

[Josef Kufner]

Pokud se změní makefile, tak chceš překompilovt úplně vše, protože nevíš, jak podstatná změna to byla. Vede to na skokové zvýšení WTFpm v následujících hodinách.

Pokud to byly jen závislosti v souborech, tak je vhodné mít tyto v druhém souboru (např. generovaným něčím jako je gcc -MM) a na tom už nezáviset.

[Josef Kufner]

Pokud to je v podadresářích, tak bych tím vyřadil zpracování celého podadresáře, pokud by v něm nebyla vůbec žádná změna. Pokud by změna byla, použil by se stávající komplikovaný makefile a vše by fungovalo jako dřív.

[Tom.š Ze.le.in]

No, autor Recursive Make Considered Harmful nedávno zemřel (R.I.P.), tak co čekáte.

[Tassadar]

Pokud to chápu dobře, tak zrovna tohle Android nepoužívá - je to pořád jen jedno Makefile, jen s hromadou include volání, kdežto ta práce mluví o samostatných Makefile a spouštění make pro každou složku.