Разумеется, это работает не всегда, поэтому вторым шагом задействуется алгоритм, который пытается синтезировать нужное выражение перебором. При этом эффективность поиска повышается за счёт затравочных термов. Их получают, символически вычисляя RFS на списке некоторой фиксированной длины и заменяя конкретные константы в полученных выражениях на новые дырки.
Почему это работает? Потому что, хоть задача и сводится к синтезу выражений, вместо синтеза online алгоритма целиком метод пытается синтезировать отдельные независимые кусочки итоговой программы и при этом эксплуатирует индуктивность итоговой программы. Авторы провели сравнение своей реализации с синтезаторами программ общего назначения и обнаружили, что их метод значительно эффективнее. Из 51 задачи генерации online алгоритма их метод справился со всеми, кроме одной: вычисление kurtosis, четвёртого центрального предела. Соответствующая online программа в одном месте имела терм, слишком большой для поиска перебором.
Разумеется, у этого метода есть и ограничения.
Самое очевидное — он полагается на тот факт, что исходный алгоритм можно представить в функциональном виде. На практике это, впрочем, не является проблемой, поскольку функциональный язык со свёрткой достаточно выразителен.
Другое ограничение, чуть менее явное — метод существенным образом полагается на предположение, что очередной шаг можно вычислить, опираясь на конечное число скалярных значений, подсчитанных на предыдущих значениях, и что RFS можно представить в виде коньюкции равенств.
Ещё одно ограничение, которое авторы почему-то не упоминают в разделе "Limitations" и упоминают лишь мельком:
Ideally Opera [так авторы назвали реализацию] would check equivalence between the online and offline expressions over all possible input streams. However, since automatically checking equivalence is out of scope for existing techniques, Opera resorts to unsound equivalence checking methods based on testing and bounded verification. However, in practice, we have not come across any cases where the equivalence checker yielded an incorrect result.
Ещё авторы пишут, что их метод стремится получить точный эквивалент, в то время как для многих практических применений может быть достаточно приближённого решения. На мой взгляд, это не является серьёзным недостатком.
А вот напоследок хочется попенять сам папир. Исходники Opera авторы не выложили. Также в некоторых местах для теорем отсутствуют доказательства, за которыми авторы отсылают к "extended version of paper", но таковой в открытом доступе, судя по всему, пока не существует и не будет раньше июня. 😒
Почему это работает? Потому что, хоть задача и сводится к синтезу выражений, вместо синтеза online алгоритма целиком метод пытается синтезировать отдельные независимые кусочки итоговой программы и при этом эксплуатирует индуктивность итоговой программы. Авторы провели сравнение своей реализации с синтезаторами программ общего назначения и обнаружили, что их метод значительно эффективнее. Из 51 задачи генерации online алгоритма их метод справился со всеми, кроме одной: вычисление kurtosis, четвёртого центрального предела. Соответствующая online программа в одном месте имела терм, слишком большой для поиска перебором.
Разумеется, у этого метода есть и ограничения.
Самое очевидное — он полагается на тот факт, что исходный алгоритм можно представить в функциональном виде. На практике это, впрочем, не является проблемой, поскольку функциональный язык со свёрткой достаточно выразителен.
Другое ограничение, чуть менее явное — метод существенным образом полагается на предположение, что очередной шаг можно вычислить, опираясь на конечное число скалярных значений, подсчитанных на предыдущих значениях, и что RFS можно представить в виде коньюкции равенств.
Ещё одно ограничение, которое авторы почему-то не упоминают в разделе "Limitations" и упоминают лишь мельком:
Ideally Opera [так авторы назвали реализацию] would check equivalence between the online and offline expressions over all possible input streams. However, since automatically checking equivalence is out of scope for existing techniques, Opera resorts to unsound equivalence checking methods based on testing and bounded verification. However, in practice, we have not come across any cases where the equivalence checker yielded an incorrect result.
Ещё авторы пишут, что их метод стремится получить точный эквивалент, в то время как для многих практических применений может быть достаточно приближённого решения. На мой взгляд, это не является серьёзным недостатком.
А вот напоследок хочется попенять сам папир. Исходники Opera авторы не выложили. Также в некоторых местах для теорем отсутствуют доказательства, за которыми авторы отсылают к "extended version of paper", но таковой в открытом доступе, судя по всему, пока не существует и не будет раньше июня. 😒
arXiv.org
From Batch to Stream: Automatic Generation of Online Algorithms
Online streaming algorithms, tailored for continuous data processing, offer substantial benefits but are often more intricate to design than their offline counterparts. This paper introduces a...
❤2🔥2
Forwarded from Нюта из Наруто • club • (Anna Mashkova)
Самый приятный комплимент это комплимент от врача что у тебя красивые внутренние органы и правильный образ жизни 😌
🥰19
Forwarded from Технологический Болт Генона
У мошенников появился новый вид обмана в Telegram.
Скамеры под видом техподдержки мессенджера связываются с потенциальными жертвами, утверждая, что получена «заявка на удаление аккаунта», затем пытаются убедить отменить несуществующую «процедуру» и зайти на фишинговый сайт.
Это слишком тупой развод. Каждый активный пользователь Телеги знает, что поддержка тут никак не работает вообще 🌝
💯23😁19
Forwarded from Время госзакупок
– Шутковал вчера про пропаганду, а сегодня Rutube забанил мой канал про ZX Spectrum за радугу на логотипе.
Думаю, ну бот, наверное, какой-то автоматический, написал в поддержку"Товарищ Сталин, произошла чудовищная ошибка!", что радуга на логотипе с начала 1980-х годов, и что это символ того, что компьютер цвета может отображать. Ответили: убирай радугу – Радиолюбители Санкт-Петербурга и Ленобласти.
Думаю, ну бот, наверное, какой-то автоматический, написал в поддержку
🤡21😁6🫡2🎉1
#science
Нептун гораздо менее синий, чем многие считают.
ras.ac.uk/news-and-press/news/new-images-reveal-what-neptune-and-uranus-really-look
Нептун гораздо менее синий, чем многие считают.
ras.ac.uk/news-and-press/news/new-images-reveal-what-neptune-and-uranus-really-look
😢16🤔2🤷2💩1
Forwarded from Врен о Японии для туриста
А вот так волшебно цветёт персик в горной деревне на острове Сикоку в долине реки Ниёдо. Фотографы называют эту локацию «Шангри-ла», но непонятно, насколько это официально.
🥰12👍3💩2🤡1🖕1
Forwarded from Lil Functor
В блоге Фигмы (это гугл-документы от мира графического дизайна) вышла отличная статья (https://clck.ru/JsUmz) о том, как они делали многопользовательский редактор макетов.
Там почти нет программистских подробностей, интересно скорее то, как они максимально упрощали решение очень сложной на первой взгляд задачи. Заявленный принцип «no more complex than necessary to get the job done» применялся и к технической реализации, и к продуктовым требованиям.
Ещё в статье есть про то, почему они не стали применять Operational Transformation и честный CRDT, как они реализовали многопользовательский undo-redo и совместное редактирование древовидных документов. Всё написано простым языком и с наглядной анимацией.
А вот ещё одна статья (https://clck.ru/JsUnC) из их блога про то, как они решали проблему совместного редактирования упорядоченных последовательностей.
Там почти нет программистских подробностей, интересно скорее то, как они максимально упрощали решение очень сложной на первой взгляд задачи. Заявленный принцип «no more complex than necessary to get the job done» применялся и к технической реализации, и к продуктовым требованиям.
Ещё в статье есть про то, почему они не стали применять Operational Transformation и честный CRDT, как они реализовали многопользовательский undo-redo и совместное редактирование древовидных документов. Всё написано простым языком и с наглядной анимацией.
А вот ещё одна статья (https://clck.ru/JsUnC) из их блога про то, как они решали проблему совместного редактирования упорядоченных последовательностей.
👍5
#prog #cpp #article
An informal comparison of the three major implementations of std::string
(GCC, MSVC и clang)
Все три варианта поддерживают SSO, но по разному этого достигают.
(thanks @itpgchannel)
An informal comparison of the three major implementations of std::string
(GCC, MSVC и clang)
Все три варианта поддерживают SSO, но по разному этого достигают.
(thanks @itpgchannel)
Microsoft News
An informal comparison of the three major implementations of std::string
Pros and cons.
🔥5👍1
Forwarded from commit -m "better"
#llvmweekly
https://c3.handmade.network/blog/p/8852-how_bad_is_llvm_really
TL;DR - медленно, семантика промежуточного представления (над которым производятся оптимизации) заточены на С/С++, и сделать иначе - невозможно. Ну, например, деление на 0 в LLVM - UB, а какой-то "другой" язык хочет уметь это обрабатывать. В итоге, LLVM навязывает некоторую семантику любому языку, которые хочет его использовать. Например, бесконечный цикл в rust, который некорретно оптимизировался llvm - https://github.com/rust-lang/rust/issues/28728
Зато много готовых оптимизаций из коробки.
Так же автор (очень справедливо!) вопрошает, какого хрена в коде LLVM не используются арены и пулы, везде, налево, и направо, потому что основные причины тормозов LLVM - это деревянные структуры без data locality.
У автора замена аллокатора для LLVM на mimalloc дает хороший буст в скорости (+10%).
Я систематически бенчил clang с разными аллокаторами, и остановился на tcmalloc от Google, по скорости тот же mim, но в пике жрет прямо существенно меньше памяти.
Неутешительный вывод такой - начинать разработку компилятора стоит с LLVM, а вот дальше есть варианты.
https://c3.handmade.network/blog/p/8852-how_bad_is_llvm_really
TL;DR - медленно, семантика промежуточного представления (над которым производятся оптимизации) заточены на С/С++, и сделать иначе - невозможно. Ну, например, деление на 0 в LLVM - UB, а какой-то "другой" язык хочет уметь это обрабатывать. В итоге, LLVM навязывает некоторую семантику любому языку, которые хочет его использовать. Например, бесконечный цикл в rust, который некорретно оптимизировался llvm - https://github.com/rust-lang/rust/issues/28728
Зато много готовых оптимизаций из коробки.
Так же автор (очень справедливо!) вопрошает, какого хрена в коде LLVM не используются арены и пулы, везде, налево, и направо, потому что основные причины тормозов LLVM - это деревянные структуры без data locality.
У автора замена аллокатора для LLVM на mimalloc дает хороший буст в скорости (+10%).
Я систематически бенчил clang с разными аллокаторами, и остановился на tcmalloc от Google, по скорости тот же mim, но в пике жрет прямо существенно меньше памяти.
Неутешительный вывод такой - начинать разработку компилятора стоит с LLVM, а вот дальше есть варианты.
Handmade Network
How bad is LLVM really?
LLVM used to be hailed as a great thing, but with language projects such as Rust, Zig and others c…
👍5