pure functional

[stas]

Кстати, а что думают функциональщики про spectre и meltdown? По-моему, это самое суровое и жизненное обьяснение отличия pure functional от кода с side effects, которое я встречал до сих пор. Правда, непонятно, какая в этом практическая польза.

Comments

[gb0]

А где можно посмотреть на массовую машинерию для исполнения pure functional code, чтобы она не была оберткой вокруг фон-неймановской ЭВМ с регистрами, кэшами, общим ОЗУ для кода и данных, и тд?

[stas]

Отож :)

[gb0]

Мож кто расскажет, например, что для начала нужно отказаться от массового тииражирования фон-неймановских ЭВМ. Код отдельно, данные отдельно, и это решит 99% всех проблем с локальной безопасностью. Вобщем, даешь переход на ADSP-21992, а хаскель мы туда потом подтянем.

[irene221b]

Так это же будет гол в свои ворота! Можно написать самую pure functional лямбду, а компилятор все равно внутрь вставит ту же самую неонку, с оптимизациями и спекуляциями.
Или я не уловила тонкий сарказм?

[stas]

Компилятор тоже не боги пишут. Раз уж реорганизовывать рабкрин, так последовательно.

[vlad_m]

Meltdown/spectre не зависят от языка/компилятора/ОС.
Они используют утечку, происходящую в процессоре на микропрограммном уровне.

[irene221b]

Последовательно революция дойдет до самого железа, и упрется в то, что железо никак не запихивается в математику функционального программирования.
Я в физике ничего не понимаю, но восстановление дисков же, к примеру, местами основано на том, что нулевой бит помнит, что он когда-то был единицей и т.п.?

[beldmit]

Мне кажется, это скорее про протечку абстракций.

[stas]

Ну в каком-то смысле да, но одно из преимуществ PF, как оно продаётся, именно в том, что такого не должно происходить. Конечно, там обычно разговор о параллелизме и на другом уровне, но принцип тот же. Одно дело что-то типа rowhammer, где против лома нет приёма - а тут дело другое, тут проблема не в протечке на другой уровень, а в неправильном учёте side effects. Вот и интересно, могут ли люди, которые говорят, что они знают, как с этим бороться, что-нибудь интересное предложить.

[beldmit]

Против Rowhammer мне попадалось уже N+1 приёмов, и каждый раз находят что-то новое. Но вообще утечка абстракций тут на уровне самого процессорного кеша как явления.

[juan_gandhi]

ФП имеет смысл на определенных уровнях. Функциональных машин нет; приходится моделировать на имеющемся железе. И на определенном уровне архитектуры (типа "вот вам микросервисы") ФП тоже не вписывается (ну или пока что).

[stas]

А почему нет? Т.е. я не спрашиваю на уровне "в каждом айфоне", но насчёт каких-то экспериментальных образцов? Раньше вон пролог-машины строили, лисп-машины... Конечно, нифига не вышло, но пытались же.

[juan_gandhi]

Да было бы любопытно, конечно.

[gb0]

java-машины вроде были. Осталось туда скалу портировать или jlisp какой :)

Без разницы

[malobukov]

Программа, написанная на любом языке программирования (функциональном или императивным), в итоге компилируется или интерпретируется в инструкции, которые выполняются тем же самым процессором. Поскольку уязвимость в процессоре, то и эксплуатировать её можно из любого языка.

По крайней мере теоретически. Возможно, что на практике это не одинаково легко (может таймеров нужного разрешения нет или ещё какие ограничения).

[http://users.livejournal.com/sorcerer-/]

Думаем, что они никакого отношения к не имеет. По крайней мере в варианте недо-языков типа хаскеля.
А данные уязвимости отличная иллюстрация как раз того куда приводит борьба за перформанс сингл треда в 2018 году. Когда уже даже последнему дебилу должно быть понятно, что x86 - это дорога в никуда.

[stas]

Ну, допустим. И вопрос - где дорога в куда?

[http://users.livejournal.com/sorcerer-/]

GPU - это современный процессор. Массовая мультитредность, как надо, чере файл регистров, охуеный перформанс, прямой доступ в память без кэшей, возможность управления кэшами и т.д.

[jsn]

Мне всё-таки непонятно, что имеется в виду в этом посте. На таком уровне, на котором контроль сайд-эффектов в случае meltdown/spectre поможет, он никакой функциональности не требует -- достаточно в обычном компиляторе (например, Си) убивать кодогенератором speculative (фенсы ставить, branch predictor обманывать, и т.д.). Понятно так же, почему это отвратительное решение.

[stas]

Нет, конечно, не требует - в смысле, PF не единственный способ достигнуть контроля эффектов (особенно же контроля именно этого типа эффектов), конечно. Но коль скоро одним из основных selling points PF является именно контроль эффектов, интересно, есть ли им что-нибудь сказать по этому вопросу.

[jsn]

Ну вы тут повторяете то, что сказано в посте -- мне от этого понятнее не стало. Мне стало немного понятнее после этого: http://wingolog.org/archives/2018/01/11/spectre-and-the-end-of-langsec (характерно, что в https://news.ycombinator.com/item?id=16124297 -- обсуждении на HN этого поста -- удивительно мало комментирующих, которые вообще понимают, о чём речь, и имеют что сказать по этому вопросу).

В целом, если с этой стороны заходить, то вопрос разваливается на две составляющие.

Во-первых, проблема с эффектами, через которые работает Meltdown et ol, в том, что они толком неспецифицированы. То есть буквально, вендоры процессоров про то, как это на самом деле работает, просто не рассказывают. Ресёрчеры, обнаружившие Meltdown et ol, а также придумывающие к ним mitigation, это всё своими руками мерили и выясняли бесчисленными экспериментами (и до сих пор, как они пишут, выяснили не всё даже из важного). То есть, даже если бы у нас были самые идеальные средства для идеальной работы с этими эффектами, FP or no FP, это бы не помогло, потому что эффекты эти создателям, например, компиляторов просто неизвестны и, в нынешней ситуации, не могут быть известны до конца.

Во-вторых, если мы таки в результате этой истории окажемся в прекрасном новом мире, в котором эти эффекты будут эксплицитно описываться в спеках железа и учитываться при проектировании этого железа -- тогда, в свою очередь, их учёт и контроль окажется совершенно не rocket science (ну со spectre дела чуть похуже могут быть, хотя и это не обязательно). Тогда соответствующие барьеры между security domain-ами (как между процессными контекстами, так и, в идеале, внутри одного процессного контекста) можно будет вставлять более-менее любыми средствами, хоть библиотечными вызовами в бейсике, хоть возвышенными типами в FP.

[cjelli]

В этом смысле гипервизор (например, VMware) оказывается очень полезным.

[http://users.livejournal.com/sorcerer-/]

Спектр ессно работает и для гипервизоров. А почему нет?

[cjelli]

Ну и что проще исправить? Виртуальный CPU или физический кусок кремния.

[http://users.livejournal.com/sorcerer-/]

Немного подумал, таки чисто функциональные процессы без сайд эффектов спасли бы отца русской демократии, но никто не сделал такого (даже наш zerovm был недостаточно упорот для этого).