Compiler seminar

26 views
Skip to first unread message

Daniel Berenyi

unread,
Feb 2, 2021, 2:44:18 PM2/2/21
to compiler-seminar-budapest
Sziasztok!

Holnap, szerdán délután 5-től lenne megint a compiler meeting.

Lehel Gábor most nem fogja folytatni a subtypingot, de ha jól emlékszem arról volt szó múltkor, hogy a maruról beszélünk kicsit az elején, utána szabad témák jönnek.

Most Csaba lesz a chair, mert én lehet, hogy nem érek vissza gépközelbe 5-ig.


üdv,
Dani

Attila Lendvai

unread,
Feb 3, 2021, 3:06:31 AM2/3/21
to Daniel Berenyi, compiler-seminar-budapest

Lehel Gábor most nem fogja folytatni a subtypingot, de ha jól emlékszem arról volt szó múltkor, hogy a maruról beszélünk kicsit az elején, utána szabad témák jönnek.

egy baratom eleg nagy szarban van, ezert bizonytalan, h be tudok-e ma csatlakozni. nem nagyon lesz ma idom vegiggondolni egy kerek eloadast, de ha leszek, akkor szivesen beszelek rola, meg valaszolok a kerdesekre.

- attila

Kéri Kálmán

unread,
Feb 3, 2021, 1:33:55 PM2/3/21
to Attila Lendvai, Daniel Berenyi, compiler-seminar-budapest

--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „compiler-seminar-budapest” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/jQNEGJlylHb3Z9PKorcSx_j47kDalMjK2JrGXIUHmZcQF3hU5EMfFzfkrcCeu9fpMCaiHIjlLCgR8RqjWJe2PbSj4ZFESlvxyTfaOpRQAww%3D%40lendvai.name.

Csaba Hruska

unread,
Feb 3, 2021, 1:34:38 PM2/3/21
to Attila Lendvai, Daniel Berenyi, compiler-seminar-budapest
Sziasztok,
A következő héten Attila fog beszélni a maru projektjéről és Kálmán pedig a backward proof search-öt implementáló (logikai nyelv) projektjéről.

Az eheti linkek pedig:
Gábor Horváth
https://lh3.googleusercontent.com/iJLiNmzsrkFKWtQ_O99f0RAVBATkqykkJSCzcKCzkPh3EQv4IP1_9UuyGetmyi_yDJa4h2Ic54qFkBlwVWw-xq8fXcDwSW-2I542bMsOMEXgpfY45I27voG0UVRJ7sM70PDNYKDdrW7AAL8BvB10gzR2WhxcRgSHy3XQ0vOE6J1GNfeTELNVpcscwN-KL2PjlvDhahqjOsX86vnDBvhorwPltPY9J1-djUJy7Fc0cDheOo93rM2emgN2XaU95ZHglV6lnh_bgk9YsijODvth0IxvmKerftxA_ZN_0qIEAAeo7iZZ0JPC0aFZ28SlOaoJeGSbdgeWV9weSNZORCSgBI5V_4e1VOvPdIxrUDQ8m6YJejym2Dzj1--hek_GBYTPmYIEdvzBcnUEqw8kSdEmnkVKN5SzaxG_MTUp6GuS9L3zUuIhyH5uhYhcrJBpQIT1j_C0cbTOFFluS-KkH9

András Kovács
https://www.youtube.com/watch?v=25RmUl88jSw

Gábor Lehel
(most nem néztem újra h mennyire kapcsolódik, csak az rémlik h GC:)

Balazs Komuves
kozben latom az ora anyagi is felkerultek, meg az a minap nem volt; de alul van par link is, peldaul az inline-os erdekesnek tunt elso ranezesre, de nem olvastam el

Gábor Lehel
https://twitter.com/pervognsen/status/1355729724375355400

Csaba Hruska
https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg/lib/Stg/Syntax.hs#L85-L132


Gábor Lehel

unread,
Feb 4, 2021, 3:08:55 AM2/4/21
to Csaba Hruska, Attila Lendvai, Daniel Berenyi, compiler-seminar-budapest
(Csak a forwarding pointeres témához még: (a) változat, mivel fwdptr csak GC közben kell, lehet hozzá csak a GC idejére allokálni akár egy külön bitmapet. (b) változat, pointer tagging: ha a bitmap azt mondja hogy ez egy pointer _és_ a pointer maga is aszerint van megtaggelve, akkor ez egy forwarding pointer. A pointernél kisebb unboxed típusokkal sincs sztem konfliktus, csak az allokációkat kell pointer méret/alignmentben minimalizálni -- de ezt amúgy is szokványos. Az interior pointerrel sincs asszem gond amíg "az egész objektumot átmásoljuk ha bármelyik részére van pointer"-nél maradunk, az ennél fine-grainedebb már 'érdekes kérdés'. Nem tudom egyébként hogy cache meg egyéb hatékonyság szempontjából ez a bitmapezés hogyan viszonyul vajon a header wordös változathoz...)

--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „compiler-seminar-budapest” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CANjChEoHV7fm2EoFn4_e0ue%2BVN-DttMnpBF%3DwqFJMz9Uqab2Cw%40mail.gmail.com.

Attila Lendvai

unread,
Feb 8, 2021, 9:26:07 AM2/8/21
to Csaba Hruska, Daniel Berenyi, compiler-seminar-budapest

A következő héten Attila fog beszélni a maru projektjéről

idokozben dolgoztam kicsit a doksikon. ha valakit komolyabban erdekel a tortenet, akkor erdemes lehet esetleg beleolvasgatni a doc/ konyvtarba, es akkor az interaktiv resznel melyebben belemehetunk a reszletekbe:

Daniel Berenyi

unread,
Feb 10, 2021, 6:08:03 AM2/10/21
to Attila Lendvai, Csaba Hruska, compiler-seminar-budapest
Sziasztok!

Ma is compiler meeting 5-től.
L. Attila levelét alább is.

Link:

üdv,
Dani

Gábor Lehel

unread,
Feb 10, 2021, 5:32:44 PM2/10/21
to Daniel Berenyi, Attila Lendvai, Csaba Hruska, compiler-seminar-budapest
Gondolkodtam még előtte h beszéljek-e majd erről, aztán végül fáradt voltam hozzá még ha maradt is volna idő... és inkább leírom akkor, mert jövő hétig lehet hogy megint tovaszáll az ihlet. :) Szóval a subtypingos ötletemet szerintem nem annyira nehéz elmondani, csak a legutóbb túlságosan a részletei végéről akartam megfogni (meg akkor is elfáradtam már a végére, meg pont a későbbi részekhez dolgoztam ki kevésbé a vázlatot előre, gondolván hogy majd úgyis leírom menetközben... stb).

A kiindulópont ill. motivációm hozzá ugye két dologból áll: (a) nem akarok automatikus meet-eket meg join-okat (if blabla { kutya } else { macská }-ból "állat"-ot inferálni), mert ez conflictol a statikus ad-hoc polimorfizmussal / típus-alapú rezolúcióval (mint a type classok, vagy C++ban az overloading), hanem csak 'egyeneságú' upcast-eket akarok támogatni; meg (b) a saját use case-emhez nem tetszik az mlsub algoritmusnak a skálázása (minden új consumernél végig kell menni minden meglévő produceren és vice-versa, és mindkettő idővel egyre csak gyarapodik). Ezeket a motivációkat lehet vitatni (meg nem kizárt hogy én is meggondolom akár magamat valamikor:), de ahhoz a kontextusról is többet kellene mondanom, úgyhogy ebben a scope-ban most egyelőre vegyük ezeket adottnak.

Az alapötlet annyiból áll, hogy minden metaváltozónak két oldala van: hogy mi az egyedi típus, amiképp ez a metaváltozó előállítódik, ill. mi az egyedi típus, amiként fel van használva; és ez a kettő külön-külön oldódik meg / állítódik be. És értelemszerűen a producer oldalnak subtypejának kell majd lennie a consumernek (ami triviálisan akkor is teljesül, amikor a kettő megegyezik). Az oldalankénti 1db egyedi típus megszorítás mögött az a logika, hogy ha a metaváltozó több, különböző típusból is előállna, akkor az azt jelentené, hogy ott impliciten a join-jukat vennénk, és hasonlóképp a másik oldalon a többféle típusként való felhasználás a meet-et jelentené.

Ha vesszük azt a függvényt, amit a múltkori pszeudokódban "requireEquals", "requireSubtype", ill. "unify"-nak neveztem kontextustól függően - amit a typechecker akkor hív meg, amikor tudja, hogy mi a provided type meg mi az expected type, és validálni akarja, hogy ezek kompatibilisek - akkor ez itt négy alapvető esetre bomlik:
  • Ha mindkét oldalon konkrét típus áll (nem metaváltozó), akkor semmi extra, ugyanúgy történik az upcastelés, mint a sima bidirectional typechecker esetén.  
  • Ha a provided type metaváltozó, és az expected type konkrét típus, akkor az előbbinek a "consumer" oldalát beállítjuk az utóbbira.
  • És fordítva, ha a provided type konkrét típus és az expected type metaváltozó, akkor az utóbbinak a "producer" oldalát állítjuk be az előbbire.
  • Ha mindkettő metaváltozó, akkor egyszerűen megoldjuk az egyiket a másikra tetszőleges irányban (és mindkét oldalukat beleértve), ugyanúgy mint a "sima" unification esetében is történne.
A második és harmadik esetnél, ha a "túloldali" típus ezen a ponton már be van állítva (most állítjuk be a producert, és már ott van a consumer is, vagy fordítva), akkor ezen a ponton csináljuk meg a subtyping ellenőrzést ill. "upcastelést" a két típus között. Ha pedig be van már állítva az az oldal, amit éppen mi is beállítanánk, akkor a két típust (a meglévő ill. "új" producert, vagy a meglévő és új consumert) egyenlővé tesszük: lényegében egy hagyományos unificationt hajtunk végre rajtuk, subtypingos aszimmetria nélkül. (Mert ugyebár csak 1db egyedi producer, ill. consumer típus lehet.)

A negyedik esetnél, ha a metaváltozók egyes oldalai be vannak már állítva, akkor hasonlóképp szimmetrikus/hagyományos módon unifikáljuk a két producer oldali típust egymással, ill. a két consumer oldali típust egymással.

A negyedik esetnek az indoklása az érdekes: hogy miért "szabad" itt közvetlenül egymásra megoldanunk (egyenlővé tennünk) a két metaváltozót, annak ellenére, hogy ez egy "aszimmetrikus" (producer-consumer) helyzet. Ez is abból fakad, hogy az adott metaváltozónak a producer ill. consumer oldali típusának egyedinek kell lennie. Logikailag ebben a helyzetben az "történik", hogy az egyik metaváltozó fel van használva a másikként, ill. a másik elő van állítva az egyikként: másképp fogalmazva, az derül ki, hogy az "expected type" metaváltozó az a "provided type" metaváltozónak a producere által fog előállítódni, tehát az előbbinek is az a producere, ami az utóbbié; és fordítva, a "provided type" metaváltozó az az "expected type" metaváltozónak a consumere által fog végül felhasználódni, így az előbbinek is az a consumere, ami az utóbbié. És mivel producerből meg consumerből is csak 1 lehet, ez meg is határozza, hogy a két producer oldal ugyanaz, meg a két consumer oldal is ugyanaz, tehát a két metaváltozó egy az egyben egyenlő.

Intuitíven itt valami olyasmi valósul meg ezáltal, hogy ha van egy felhasználási láncolat, amin keresztül egy érték eljut A pontból B-be, akkor mindegy, hogy hány metaváltozó van a kettő között, a két végpont között létre tud jönni az upcast. (A fejemben olyasmi képpel, hogy az upcast teleszkópos kézzel keresztülnyúl a kettő közötti távolságon, mint a rajzfilmekben...)

Ennyit akartam leírni róla. Minden kérdésnek örülök, hogy hol homályos még, vagy mi hiányzik még hozzá. :)

(Van még pár további érdekes kérdés is ezekből továbbindulva, de azokba csak akkor megyek bele, ha kiderül, hogy ez eddig nem volt teljesen érthetetlen, ill. valakit érdekel is; vagy az is lehet, hogy azokról esetleg a következő meetingen akkor.)

--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „compiler-seminar-budapest” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CABmfui0ouV-rY3KxO70rFecu%3D8BRW-sZkZY7pij10VE7viMKKA%40mail.gmail.com.

Daniel Berenyi

unread,
Feb 17, 2021, 3:21:36 AM2/17/21
to compiler-seminar-budapest
Sziasztok!

Ma is compiler meeting 5-től.
A múltkor nem értünk a végére a Maru-s témáknak, ezért valószínűleg azt folytatjuk majd.

Gábor Lehel

unread,
Feb 17, 2021, 1:49:36 PM2/17/21
to Daniel Berenyi, compiler-seminar-budapest
Nekem két érdekes linkem van egyébként:



Utóbbi a CBPV-ről egy előadás ami viszonylag szájbarágós (cserébe hosszú), és így hogy a legtöbb notációt már láttam korábban egész követhető volt számomra, szemben a többi anyaggal amivel előtte találkoztam. De nulláról indulva valószínűleg ez is durva lenne...

--
Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok „compiler-seminar-budapest” csoportjára.
Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való leiratkozáshoz küldjön egy e-amailt a(z) compiler-seminar-b...@googlegroups.com címre.
Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CABmfui2xFgJKo1xbkOmKd1EekDjH84T0LC6Q2mb32E_cRyw%3DdA%40mail.gmail.com.

Kéri Kálmán

unread,
Feb 17, 2021, 4:24:20 PM2/17/21
to Gábor Lehel, Daniel Berenyi, compiler-seminar-budapest
Az előadás nekem is érdekes. Az első harmada pont olyasmiről szól, amivel mostanában foglalkozom. A többit legalább magamba szívom, még ha nem is értem elsőre...

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CAFCmug_CWTN6OwrC22wKDUhFzWzAiM%2Bka7t-ODdhQNQ41MvO%2Bw%40mail.gmail.com.

Kéri Kálmán

unread,
Feb 24, 2021, 3:34:56 AM2/24/21
to Gábor Lehel, Daniel Berenyi, compiler-seminar-budapest
Sziasztok!

Ma újra szeretnék beszélni a logikai interpreterről, amin dolgozom. Azóta haladtam is vele valamennyit. Ezeket tervezem sorra venni:
- Beletettem a kódba a debug trace-t, így megnézhetjük részletesen néhány formula kiértékelését.
- Ezzel kapcsolatban elő fog kerülni a backpropagation. Mi az, és miért jó?
- Megpróbáltam változókat hozzáadni az interpreterhez, ennek nehézségeiről.
- Szekvenciális vs. fa ábrázolás, avagy hogy lesz a formulából program?
- Ha ez a logikai kalkulus megfeleltethető egy típusrendszernek únió és metszet típusokkal, akkor mi felel meg a subtyping relationnek?

Üdv:
K.

Daniel Berenyi

unread,
Feb 24, 2021, 4:07:34 AM2/24/21
to Kéri Kálmán, Gábor Lehel, compiler-seminar-budapest
Sziasztok!

Köszi, Kálmán az előzetest, ma délután 5-től akkor kíváncsian várjuk az előadásodat!

Meeting Link:

Üdv,
Dani

Kéri Kálmán

unread,
Feb 24, 2021, 10:47:57 AM2/24/21
to Daniel Berenyi, Gábor Lehel, compiler-seminar-budapest
Sziasztok, munkahelyi elfoglaltság miatt kések húsz percet.

Üdv:
K.

Daniel Berenyi

unread,
Feb 24, 2021, 1:03:26 PM2/24/21
to Kéri Kálmán, Gábor Lehel, compiler-seminar-budapest
Sziasztok!

Ma, amikor nem Kálmán beszélt, a következő dolgok kerültek be a chat-be:


Jövő héten valószínűleg megint kicsit kötetlenebbül beszélgetve körbejárunk kérdéseket, témákat, amik felmerültek, pl. András tervez beszélni a saját compileres ötleteiről.

üdv,
Dani

Daniel Berenyi

unread,
Mar 3, 2021, 4:45:58 AM3/3/21
to Kéri Kálmán, Gábor Lehel, compiler-seminar-budapest
Sziasztok!

Ma is compiler meeting 5-től, l. az előző levelet is.

Csaba Hruska

unread,
Mar 3, 2021, 1:28:12 PM3/3/21
to Daniel Berenyi, Kéri Kálmán, Gábor Lehel, compiler-seminar-budapest

Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CABmfui1qQxm6bFJ_E5Tq-2V%2Bdxk%2BAZ073eZOUjysbcER88hKxg%40mail.gmail.com.

Daniel Berenyi

unread,
Mar 10, 2021, 8:18:37 AM3/10/21
to Csaba Hruska, Kéri Kálmán, Gábor Lehel, compiler-seminar-budapest
Sziasztok!

Ma is compiler meeting 5-től. Azt hiszem nincs konkrét téma mára, de én megpróbálom feltenni a aprseres kérdésemet, amit múltkor nem sikerült:)

Daniel Berenyi

unread,
Mar 11, 2021, 4:07:43 AM3/11/21
to compiler-seminar-budapest
Sziasztok!

A tegnapi meetingen az alábbi linkek kerültek be a chat-be.
Jövő héten a másik mailban írtaknak megfelelően Diviánszky Peti fog beszélni. És Csaba megpróbálja intézni a felvételt.

Üdv,
D.

----------------------------------------


Gábor Lehel

unread,
Mar 11, 2021, 6:38:29 AM3/11/21
to Daniel Berenyi, compiler-seminar-budapest
A build systemes threadben is volt ilyenekről szó meg tegnap a parseolással kapcsolatban is; rám mély benyomást tett ez a két írás:




(Asszem vmennyire mások is felhozták ezt az érvelést tegnap? Csak részben tudtam sajnos odafigyelni.)

A cacheléssel meg inkrementális feldolgozásnál nem az a fő lényeg, hogy mi maga a feladat/számolás, amit megspórolunk, hanem inkább csak az, hogy mennyi ideig tart. A számokat most csak hasracsapás alapján, de lehet, hogy ami mondjuk 0.1ms-nél kevesebb ideig tart, azt nem érdemes cachelni/inkrementalizálni, viszont minden ami 10ms-ig vagy tovább, azt feltétlenül akarnánk. (Valamilyen számok mindenképp léteznek, amikre ezek teljesülnek.) Ebből következik, hogy ha maga az alapfeladat végrehajtását sokkal gyorsabbra tudjuk megcsinálni, akkor annál kevesebb részét kell cacheléssel/inkrementalizálással bonyolítani, sokkal egyszerűbb módon és coarse-abb granularity-ben is elégséges lehet. Ha az egyik fordító annyi idő alatt dolgoz fel egy file-t, mint a másik egy függvényt, akkor az előbbinek elég file szinten követnie a változásokat, hogy ugyanazt hozza, mint ha a másik kiépíti ahhoz az infrastruktúrát, hogy függvényenként tegye. És "mellesleg", bónuszként, a clean rebuild is sokkal gyorsabb lesz. Meg hasonló tendenciák vannak még a párhuzamosításnál is.


Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CABmfui2dLuRs1DL_UdqVVLseLPEz57si8WVYtR7X5rDv0EkRWg%40mail.gmail.com.

András Kovács

unread,
Mar 11, 2021, 7:23:21 AM3/11/21
to Gábor Lehel, Daniel Berenyi, compiler-seminar-budapest
Jó linkek, én is olvastam őket korábban. A "performant foundations simplify architecture"-el abszolút egyetértek, és ez lényegében az a fő implementációs elv, amire törekszek. A cache-elésen akkor kell elkezdeni gondolkodni, ha a) hiába optimális az architektúránk, mégsem tud real-time interakciót biztosítani b) meglévő, lassú rendszerünk van, ami realisztikusan "gyorsíthatatlan" (mélyen elrontott design miatt). A b)-re rengeteg példa van (sajnos). 


Ha szeretné megtekinteni ezt a beszélgetést az interneten, látogasson el ide: https://groups.google.com/d/msgid/compiler-seminar-budapest/CAFCmug_thR8papOCUcPf75Ou2wGb%3D4YOr3sds9TB_vsdvyzSFQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages