YS
На ифы + goto можно
+ опасное обращение к полям придётся
Size: a a a
2020 January 03
AK
+ опасное обращение к полям придётся
Это как?
E
В этом случае ничего эффективнее и не придумаешь :)
Оптимизация достигается уже в более серьезных видах ПМ, позволяющих вложенные образцы
И там грубо говоря оптимизация происходит за счет использования информации о типах-суммах (сюда же exhaustiveness checking) и уже разобранном префиксе образца
Например, пусть вот мы находимся сейчас в какой-то ветке и уже что-то разобрали, а что-то сломалось
И использую всю имеющуюся информацию о ветках и используемых в них типах, компилятор вставляет дополнительные прыжки, которые перемещают сразу в ту ветку и ту конкретную ее часть, где либо префикс гарантированно такой же, а то что сломалось проверяется уже по новому условию, либо, если то, что сломалось проверять уже не с чем, пытаемся немножко уменьшить префикс и найти следующую подходящую ветку
В общем там минимизируется количество заведомо проигрышных тестов и необходимость по два раза проверять одно и то же
И все это в условиях, что какие-то ветки можно переставлять, какие-то нет
По сравнению с if-else, это как если можно было сразу через несколько блоков else прыгнуть, заведомо зная, что они провалятся, а когда найдешь нужный, сразу перейти через несколько внутренних вложенных if-ов, заведомо зная, что они выполнятся
На пальцах у меня как-то плохо получается объяснить :(
Более того, там в каждой схеме компиляции свои фишки используются
Оптимизация достигается уже в более серьезных видах ПМ, позволяющих вложенные образцы
И там грубо говоря оптимизация происходит за счет использования информации о типах-суммах (сюда же exhaustiveness checking) и уже разобранном префиксе образца
Например, пусть вот мы находимся сейчас в какой-то ветке и уже что-то разобрали, а что-то сломалось
И использую всю имеющуюся информацию о ветках и используемых в них типах, компилятор вставляет дополнительные прыжки, которые перемещают сразу в ту ветку и ту конкретную ее часть, где либо префикс гарантированно такой же, а то что сломалось проверяется уже по новому условию, либо, если то, что сломалось проверять уже не с чем, пытаемся немножко уменьшить префикс и найти следующую подходящую ветку
В общем там минимизируется количество заведомо проигрышных тестов и необходимость по два раза проверять одно и то же
И все это в условиях, что какие-то ветки можно переставлять, какие-то нет
По сравнению с if-else, это как если можно было сразу через несколько блоков else прыгнуть, заведомо зная, что они провалятся, а когда найдешь нужный, сразу перейти через несколько внутренних вложенных if-ов, заведомо зная, что они выполнятся
На пальцах у меня как-то плохо получается объяснить :(
Более того, там в каждой схеме компиляции свои фишки используются
все твои аргументы быстро разбиваются о ПГО который и свитч и ифы перевернет как надо
PS
ну как так можно? типы — это не только запреты, но и дополнительная информация
А какая здесь связь с возможностями именно PM? Выразительный и мощный PM в динамических языках бесплатно ведь не дается: страдает производительность, многие ошибки остаются таковыми до времени выполнения. А вот в статических языках ограниченный вариант PM можно хорошо оптимизировать, строить DAG'и решений и проч.
YS
Это как?
std::optional::get
BD
Да, как и ожидалось: PM в C++ %)) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1371r1.pdf
О, тов Парк протолкнул таки свою либу в стандарт. Молодец.
AB
все твои аргументы быстро разбиваются о ПГО который и свитч и ифы перевернет как надо
Простите, не владею терминологией
Что Вы имеете в виду под ПГО?
Что Вы имеете в виду под ПГО?
E
Простите, не владею терминологией
Что Вы имеете в виду под ПГО?
Что Вы имеете в виду под ПГО?
а вообще если вы думаете что свитч — это когда мы сразу идем в нужную метку пропуская проверки другие - то увы, это не так. будут пройдены все проверки до сработавшей (если это не совсем простой свитч, который оптимизировался в битмаску или джамп тейбл)
FO
Или это профилировщик
YS
А какая здесь связь с возможностями именно PM? Выразительный и мощный PM в динамических языках бесплатно ведь не дается: страдает производительность, многие ошибки остаются таковыми до времени выполнения. А вот в статических языках ограниченный вариант PM можно хорошо оптимизировать, строить DAG'и решений и проч.
ну, в АТД, наверно, разница не очень заметна, кроме проверки ошибок и исчерпания, но в Хаскеле, например, есть элементы зависимых типов в синтаксисе case-of, когда отдельные ветки могут нести больше информации об оригинальном типе, чем известно снаружи
M
В этом случае ничего эффективнее и не придумаешь :)
Оптимизация достигается уже в более серьезных видах ПМ, позволяющих вложенные образцы
И там грубо говоря оптимизация происходит за счет использования информации о типах-суммах (сюда же exhaustiveness checking) и уже разобранном префиксе образца
Например, пусть вот мы находимся сейчас в какой-то ветке и уже что-то разобрали, а что-то сломалось
И использую всю имеющуюся информацию о ветках и используемых в них типах, компилятор вставляет дополнительные прыжки, которые перемещают сразу в ту ветку и ту конкретную ее часть, где либо префикс гарантированно такой же, а то что сломалось проверяется уже по новому условию, либо, если то, что сломалось проверять уже не с чем, пытаемся немножко уменьшить префикс и найти следующую подходящую ветку
В общем там минимизируется количество заведомо проигрышных тестов и необходимость по два раза проверять одно и то же
И все это в условиях, что какие-то ветки можно переставлять, какие-то нет
По сравнению с if-else, это как если можно было сразу через несколько блоков else прыгнуть, заведомо зная, что они провалятся, а когда найдешь нужный, сразу перейти через несколько внутренних вложенных if-ов, заведомо зная, что они выполнятся
На пальцах у меня как-то плохо получается объяснить :(
Более того, там в каждой схеме компиляции свои фишки используются
Оптимизация достигается уже в более серьезных видах ПМ, позволяющих вложенные образцы
И там грубо говоря оптимизация происходит за счет использования информации о типах-суммах (сюда же exhaustiveness checking) и уже разобранном префиксе образца
Например, пусть вот мы находимся сейчас в какой-то ветке и уже что-то разобрали, а что-то сломалось
И использую всю имеющуюся информацию о ветках и используемых в них типах, компилятор вставляет дополнительные прыжки, которые перемещают сразу в ту ветку и ту конкретную ее часть, где либо префикс гарантированно такой же, а то что сломалось проверяется уже по новому условию, либо, если то, что сломалось проверять уже не с чем, пытаемся немножко уменьшить префикс и найти следующую подходящую ветку
В общем там минимизируется количество заведомо проигрышных тестов и необходимость по два раза проверять одно и то же
И все это в условиях, что какие-то ветки можно переставлять, какие-то нет
По сравнению с if-else, это как если можно было сразу через несколько блоков else прыгнуть, заведомо зная, что они провалятся, а когда найдешь нужный, сразу перейти через несколько внутренних вложенных if-ов, заведомо зная, что они выполнятся
На пальцах у меня как-то плохо получается объяснить :(
Более того, там в каждой схеме компиляции свои фишки используются
Оптимизация по сравнению с if-else? Я вот не могу себе представить как ADT c PM который с собой еще и tag тягает может быть быстрее if-else=) Максимум так же будет оптимизирован
M
Вот наглядный пример на Rust
https://godbolt.org/z/eac7iP
https://godbolt.org/z/eac7iP
BD
А почему так???
Именованный матч
AB
а вообще если вы думаете что свитч — это когда мы сразу идем в нужную метку пропуская проверки другие - то увы, это не так. будут пройдены все проверки до сработавшей (если это не совсем простой свитч, который оптимизировался в битмаску или джамп тейбл)
Нет конечно
Наверное Вы меня неправильно поняли
Или я что-то не так написал
Компилятор оптимизирует ПМ в сложный набор из свитчей (честных, последовательных) и goto (хитрых, в любое место, куда компилятор посчитает нужным)
Наверное Вы меня неправильно поняли
Или я что-то не так написал
Компилятор оптимизирует ПМ в сложный набор из свитчей (честных, последовательных) и goto (хитрых, в любое место, куда компилятор посчитает нужным)
M
MaxGraey
Вот наглядный пример на Rust
https://godbolt.org/z/eac7iP
https://godbolt.org/z/eac7iP
А если смотреть на это без оптимизации то станет ясно, что в функции с PM мы передаем этот самый тэг через стек:
https://godbolt.org/z/UZKg3K
test1 (c PM):
sub rsp, 24
mov eax, dword ptr [rdi]
mov ecx, eax
mov rdx, rcx
sub rdx, 1
…
test2 (if-else):
sub rsp, 16
mov eax, dword ptr [rdi]
mov ecx, eax
cmp rcx, 1
https://godbolt.org/z/UZKg3K
test1 (c PM):
sub rsp, 24
mov eax, dword ptr [rdi]
mov ecx, eax
mov rdx, rcx
sub rdx, 1
…
test2 (if-else):
sub rsp, 16
mov eax, dword ptr [rdi]
mov ecx, eax
cmp rcx, 1
PS
ну, в АТД, наверно, разница не очень заметна, кроме проверки ошибок и исчерпания, но в Хаскеле, например, есть элементы зависимых типов в синтаксисе case-of, когда отдельные ветки могут нести больше информации об оригинальном типе, чем известно снаружи
Вот у меня реальный пример возможностей динамического PM — преобразование в Ror.
ror = rule(
alt(
BitOr(Shl(X, i32(N)), Shr(X, i32(M))),
BitOr(Shr(X, i32(M)), Shl(X, i32(N))),
),
guard(lambda e: e.M == 32 - e.N),
to(lambda e: Ror(e.X, i32(32 - e.N)))
)
AB
MaxGraey
Вот наглядный пример на Rust
https://godbolt.org/z/eac7iP
https://godbolt.org/z/eac7iP
Я и писал выше, что в таких простейших ПМ, которые в сущности switch из C, особо нечего оптимизировать
Я говорю про обилие вложенных образцов
Я говорю про обилие вложенных образцов
M
Я и писал выше, что в таких простейших ПМ, которые в сущности switch из C, особо нечего оптимизировать
Я говорю про обилие вложенных образцов
Я говорю про обилие вложенных образцов
А какая разница? Тэг каким то магическим образом испариться?)
AB
MaxGraey
А какая разница? Тэг каким то магическим образом испариться?)
Тут мы кажется уже переходим на вопрос, перевешивают ли затраты на протаскивание тэга, применяемые компилятором оптимизации по прыжкам
Ну тут если только бенчмаркать остается
Я не знаю, какие в Rust оптимизации ПМ применяются
Но уверен, что они есть и на достойном уровне
Можно сделать какой-нибудь средних размеров пример с ПМ, if-ами и померить
Ну тут если только бенчмаркать остается
Я не знаю, какие в Rust оптимизации ПМ применяются
Но уверен, что они есть и на достойном уровне
Можно сделать какой-нибудь средних размеров пример с ПМ, if-ами и померить
E
за последние года два я паттерн матчинг видел только в примерах про паттерн матчинг или в сравнениях языков -_-