Почему-то .size() у вектора сбивает анализ, как и проверка в сейф версии раста, хотя по идее это не должно влиять. Кажется небольшой недочет в оптимизаторе.
Да, я видел. Я пишу немного на расте и я к тому что если ипользоваь clang — у меня всегда выходило примерно "сравнять" оптимизации. Разница была лиш в том что раст вставляет проверки, а компилер по сути один и тот-же.
Это правда могло вызывать дополнительный спиллинг регистров, что на асме может сильно сказаться. Так же на расте иногда сложно сравнять даже с интринзиками, в специфических случаях, например из-за alloca https://github.com/rust-lang/rfcs/issues/618https://github.com/rust-lang/rust/issues/48055, асм вставка тут не поможет т.к. надо со стеком корректно играться (ну или памятью пожертвовать, если там не гигабайты в худшем случае). Когда Unsized Rvalues допилят — одна из пробелм уйдет. А вот в обратную сторону — на С/С++ можно сделать все что позволяет AST clang`а.
Ну это понятно, я уже выше писал что принципиально разные omp и thread::spawn — это можно сравнивать, будем сравнивать эффективность crt. Но там где сравнивается участки с принципиально большим количеством действий (fgets + strlen) и когда их можно привести к одному виду (там даже есть комментарий про fread) — так сравнивать нельзя. Как я понимаю в С++ используется не эффективный подход из-за правил, а в Раст коде правило нарушено.
Ну интринзики можно было бы и в C++ и в Раст добавить, было бы понятно как модифицировать другой пример чтобы сравнять, сравнивались бы уже сами компиляторы. Хотя clang это и C++ и Раст и так =)
Про преимущества оптимизации у мемори-сейф, ну так в С++ тоже есть всякие restrict и расширения, которые теоретически эту разницу нивелируют.
Тут же Раст прямо нарушает условия, так что С++ даже нельзя в ответ модифицировать.
Посмотрел первый тест reverse-complement. Прямо с самого начала идут различия.
В Расте:
stdin.lock().read_to_end(&mut data).unwrap();
В С++:
// read line-by-line, according to game rule. Should be replaced by fread()
while (fgets_unlocked(cur_pos, remainbytes, stdin) != 0)
Разве это можно напрямую сравнивать на большом количестве строк? Дальше там еще больше различий идет. Если omp c thread::spawn еще можно сравнить, то в треде там совсем по разному обработка идет.
Есть еще более быстрый вариант с process_vm_readv/process_vm_writev, в рамках задачи это конечно не критично. С правами тоже самое — нужен PTRACE_MODE_ATTACH_REALCREDS.
На другом компе с GTX760 на том же FF70 ошибки нет, но очень долго компилится шейдер, так и не дождался. Не работает на компе с RTX2080. По логу wasm скачался, похоже он все же запустился и ассертит после компиляции шейдера.
Ну тут вы правы, epoll() только ожидание и только вариант (1) и придется делать доп. сискол для чтения. Однако я делал и то и то и на винде у меня впринципе не получалось добиться приемлимой производительности. А io_uring как раз решит и эту проблему и доп. сисколов не понадобится, но он пока не широко доступен в продакшене.
В случае TCP, когда пингует сервер, в случае разрыва из-за сети очень часто приходит RST и сервер сразу узнает о проблеме. Так что пробы можно слать хоть раз в 5сек, а вот таймаут главное настроить больше максимального энергосберегающего цикла мобильных ос, чтобы клиент успел ответить. Тогда хоть и не во всех случаях, но об оффлайне узнаем максимально быстро, при пингах с клиента так не получится.
У Matrix все-же больше другая проблема — крайне тормознутая реализация. Когда сервер на go начили писать совсем другое дело стало, но фичи не все реализовали.
То-есть по сути это си с векторными интринзиками и типами? Типа как __m128/float32x4_t _mm_shuffle_ps/vcombine_f32? Но что мешает тогда использовать их в OpenCL? В nvidia драйвере полно таких вендорных расширений, их только проверить надо перед использованием, более того, можно ptx asm вставку сделать.
Думаю тут как раз большая разница именно ssd или нет. Когда CompatTelRunner.exe сканирует все файлы, на ноутбуках с ссд действительно куда менее заметно чем на мощных стационарных с большим хдд и количеством файлов. Там есть какая-то эвристика чтобы сканирование прекратить, но на вьюер может и не сработать.
Я нашел, вот так код 1 в 1 получается: https://godbolt.org/z/vitnPr
Почему-то .size() у вектора сбивает анализ, как и проверка в сейф версии раста, хотя по идее это не должно влиять. Кажется небольшой недочет в оптимизаторе.
Забавно что в расте он развернул цикл на 2, но только в unsafe случае. Интересно, с чем это связано?
Да, я видел. Я пишу немного на расте и я к тому что если ипользоваь clang — у меня всегда выходило примерно "сравнять" оптимизации. Разница была лиш в том что раст вставляет проверки, а компилер по сути один и тот-же.
Это правда могло вызывать дополнительный спиллинг регистров, что на асме может сильно сказаться. Так же на расте иногда сложно сравнять даже с интринзиками, в специфических случаях, например из-за alloca https://github.com/rust-lang/rfcs/issues/618 https://github.com/rust-lang/rust/issues/48055, асм вставка тут не поможет т.к. надо со стеком корректно играться (ну или памятью пожертвовать, если там не гигабайты в худшем случае). Когда Unsized Rvalues допилят — одна из пробелм уйдет. А вот в обратную сторону — на С/С++ можно сделать все что позволяет AST clang`а.
Ну это понятно, я уже выше писал что принципиально разные omp и thread::spawn — это можно сравнивать, будем сравнивать эффективность crt. Но там где сравнивается участки с принципиально большим количеством действий (fgets + strlen) и когда их можно привести к одному виду (там даже есть комментарий про fread) — так сравнивать нельзя. Как я понимаю в С++ используется не эффективный подход из-за правил, а в Раст коде правило нарушено.
Ну это да, потому и пишу расширений. У gcc есть еще
__attribute__с кучей всего полезного не стандартного. У msvc есть __assume() итд.Ну интринзики можно было бы и в C++ и в Раст добавить, было бы понятно как модифицировать другой пример чтобы сравнять, сравнивались бы уже сами компиляторы. Хотя clang это и C++ и Раст и так =)
Про преимущества оптимизации у мемори-сейф, ну так в С++ тоже есть всякие restrict и расширения, которые теоретически эту разницу нивелируют.
Тут же Раст прямо нарушает условия, так что С++ даже нельзя в ответ модифицировать.
Посмотрел первый тест reverse-complement. Прямо с самого начала идут различия.
В Расте:
В С++:
Разве это можно напрямую сравнивать на большом количестве строк? Дальше там еще больше различий идет. Если omp c thread::spawn еще можно сравнить, то в треде там совсем по разному обработка идет.
Есть еще более быстрый вариант с process_vm_readv/process_vm_writev, в рамках задачи это конечно не критично. С правами тоже самое — нужен PTRACE_MODE_ATTACH_REALCREDS.
А не пробовали кейс переключения сетей? Как вебсокеты к этому отнесутся, особенно на мобилах?
В gcc 9.2 похоже уже норм:
при этом демка с фруктами работает.
FF70
Телега не электрон, соответственно сравнивать надо с не-электроном.
У Matrix все-же больше другая проблема — крайне тормознутая реализация. Когда сервер на go начили писать совсем другое дело стало, но фичи не все реализовали.