Size: a a a

Compiler Development

2020 January 11

DP

Dmitry Ponyatov in Compiler Development
что-то подумалось, а почему так мало мануалов и статей по самокомпиляции динамических языков?

ну т.е. например Python или тот же JS дает полный доступ к своей внутрянке (байт-код, информация по наследованию)
почему не стало одной из распространенных практик для юзеров уровня мидла и выше фишка по написанию самокомпиляторов?
источник

LW

Lev Walkin in Compiler Development
Dmitry Ponyatov
что-то подумалось, а почему так мало мануалов и статей по самокомпиляции динамических языков?

ну т.е. например Python или тот же JS дает полный доступ к своей внутрянке (байт-код, информация по наследованию)
почему не стало одной из распространенных практик для юзеров уровня мидла и выше фишка по написанию самокомпиляторов?
Чтобы что?
источник

DP

Dmitry Ponyatov in Compiler Development
Lev Walkin
Чтобы что?
ну например JITить куски числомолотильного кода, и генерировать обертки для внешних .dll

по идее такая штука должна была появится в виде отдельного мануальчика из ряда advanced Python где-нибудь в версии 1.2.3 и маленькая библиотечка которая скрывает совсем уж кишки конкретной реализации
источник

DP

Dmitry Ponyatov in Compiler Development
Py3 уж точно должен был уже сделанным поверх LLVM в комплекте со всеми фишками
http://ceur-ws.org/Vol-1129/paper4B.pdf
источник

DP

Dmitry Ponyatov in Compiler Development
похоже нашел ответ: Гвидо решил что "одно сплошное UB" кардинально испортит репутацию языку
источник

I

Ioann_V in Compiler Development
Aleksey Shipilev
Могу ещё дальше мозг форматнуть. Смотрите опять на пример:
Thread 2: y = 1
Thread 3: r2 = y; // r2 <- 0
Thread 4: r3 = y; // r3 <- 1

Вы сказали, что такое возможно, потому что "Поток 3 перед потоком 2, а 4-ый после второго". И это правильный ответ. Но есть *ещё один правильный ответ*, который не очевиден без гвоздодёра:

Thread 2: y = 1   // выполнился первым
Thread 3: r2 = y; // выполнился вторым, и НЕ УВИДЕЛ 1
Thread 4: r3 = y;

Другими словами, выполнение "первый-второй-третий" НЕ говорит, что эффекты видны в таком порядке. (То есть, у нас нет некоторого строго-консенсусного последовательного хранилища) (То есть, у нас нет глобального порядка) (То есть, это самое "время" нам вообще ничем не помогает). В этом состоит гвоздь иллюзии про сериализованную память.

Хардварная аналогия, если так хочется: исполнение реально доехало до инструкций в каждом потоке в порядке "первый-второй-третий", каждый поговорил с подсистемой памяти, но получил *разные* ответы! (ввиду простых физических ограничений во время полёта обеих записей).
в вашем примере, как r2 может не увидеть, если используем acq / rel? Разве не будет синхронизации?
источник

EM

Evgenii Moiseenko in Compiler Development
Ioann_V
в вашем примере, как r2 может не увидеть, если используем acq / rel? Разве не будет синхронизации?
Синхронизация происходит только если acq читает из rel,
При этом acq чтение вообще не даёт никаких гарантий откуда прочитает значение
источник

EM

Evgenii Moiseenko in Compiler Development
Оно гарантирует только, что если прочитали из rel, то будет синхронизация, иначе нет
источник

BD

Berkus Decker in Compiler Development
@shipilev хорошая лекция, спасибо)
источник

AT

Alexander Tchitchigin in Compiler Development
Ioann_V
в вашем примере, как r2 может не увидеть, если используем acq / rel? Разве не будет синхронизации?
А там начальное значение 0 ведь тоже записано с rel или сильнее - вот именно его acc и читает. 😉
источник

AT

Alexander Tchitchigin in Compiler Development
Никаких гарантий насчёт "последней" записи с rel нет, потому что нет никакого " последний".
источник

꧁Станцуем жизнь꧂ in Compiler Development
источник

МБ

Михаил Бахтерев in Compiler Development
Как-то вы сложно объясняете. Не проще ли сказать, что release и acquire - это про локальный порядок операций с памятью? Одно форсит публикацию записей и чтений до записи, другое - после чтения. В доках у Итаника хорошо это всё расписано. Рекомендую
источник

I

Ioann_V in Compiler Development
Evgenii Moiseenko
Синхронизация происходит только если acq читает из rel,
При этом acq чтение вообще не даёт никаких гарантий откуда прочитает значение
ну вот смотрите, про неочевидное поведение в комментарии Михаила:
Т2 пишет У = 1, релизом, Т3 грузит экваером, как он может не увидеть? Или, что вы имееете в виду под отсутствием гарантий откуда прочитает?
источник

EM

Evgenii Moiseenko in Compiler Development
Ioann_V
ну вот смотрите, про неочевидное поведение в комментарии Михаила:
Т2 пишет У = 1, релизом, Т3 грузит экваером, как он может не увидеть? Или, что вы имееете в виду под отсутствием гарантий откуда прочитает?
У вас сохраняется иллюзия наличия некой "глобальной памяти" куда потоки пишут. То что т2 записал что-то хоть relax, хоть release, ещё не гарантирует, что другой поток эту запись увидит
источник

I

Ioann_V in Compiler Development
Вне зависимости от того, как читает? Или если чтение seq cst, то увидит, а во всех остальных кейсах - не факт? Тогда зачем это нужно?
источник

EM

Evgenii Moiseenko in Compiler Development
Ioann_V
Вне зависимости от того, как читает? Или если чтение seq cst, то увидит, а во всех остальных кейсах - не факт? Тогда зачем это нужно?
Если чтение rlx или acq, то да.
источник

EM

Evgenii Moiseenko in Compiler Development
Ioann_V
Вне зависимости от того, как читает? Или если чтение seq cst, то увидит, а во всех остальных кейсах - не факт? Тогда зачем это нужно?
давайте ещё один классический пример рассмотрим, чтобы понять для чего нужно acq/rel

T1: x_rlx = 42; y_rel =1
T2: r1 = y_acq; r2 = x_rlx

смотрите, тут во втором потоке в r1 может быть прочитано или 0, или 1
Если 0, то на чтение r2 = x_rlx нет никаких гарантий, мб прочитано как 0 так и 42,
но если в r1 было прочитано 1, то в r2 обязано быть прочитано 42
источник

EM

Evgenii Moiseenko in Compiler Development
т.е. если acq чтение прочитало из rel записи, то между двумя потоками "локально" произошла синхронизация, и поток, выполнивший acq чтение видит все изменеия, которые были сделаны до release записи
источник

EM

Evgenii Moiseenko in Compiler Development
но никаких "глобальных" гарантий нет
источник