Исправление quiet_readonly, (текущая версия) :
Скорость компиляции определенно интересует конечных пользователей.
Clang спроектирован как платформа для сред разработки и инструментов анализа кода, для которых скорость крайне критична. Какую паузу между вводом . либо -> и появлением подсказки программист готов потерпеть? 50 мс, 500 мс, 3 секунды, 8 секунд?
С исполняемым файлом что, где код быстрее ? Можно не отвечать я и так знаю )
Код быстрее там, где у программиста была возможность его нормально ускорить: в GUI надо любые действия с длительностью более 1/50 секунды делать асинхронными, в числодробилках правильно применить OpenMP и устранить узкие места, в клиент-серверных приложениях нужен гибкий механизм кеширования, при обработке данных (да хотя бы при индексировании кода на сервере тем же clang) надо обеспечить сериализацию и выгрузку данных на диск и т.д.
Где здесь участвует компилятор - я как-то не вижу. То есть, конечно, с -march=native -Ofast -flto эффект будет, но скорее всего вместо ускорнеия будет непереносимая на старые процессоры, а то и поломанная программа (из-за LTO или изменения семантики float/double). На форониксе тестировали Mesa: никакого ускорения, т.к. узкое место не в Месе, а LTO и вовсе поломанный бинарник дал.
И да, на последних тестах фороникса gcc и clang вровень кроме тех тестов, где есть openmp.
Исправление quiet_readonly, :
Скорость компиляции определенно интересует конечных пользователей.
Clang спроектирован как платформа для сред разработки и инструментов анализа кода, для которых скорость крайне критична. Какую паузу между вводом . или -> программист готов потерпеть? 50 мс, 500 мс, 3 секунды, 8 секунд?
С исполняемым файлом что, где код быстрее ? Можно не отвечать я и так знаю )
Код быстрее там, где у программиста была возможность его нормально ускорить: в GUI надо любые действия с длительностью более 1/50 секунды делать асинхронными, в числодробилках правильно применить OpenMP и устранить узкие места, в клиент-серверных приложениях нужен гибкий механизм кеширования, при обработке данных (да хотя бы при индексировании кода на сервере тем же clang) надо обеспечить сериализацию и выгрузку данных на диск и т.д.
Где здесь участвует компилятор - я как-то не вижу. То есть, конечно, с -march=native -Ofast -flto эффект будет, но скорее всего вместо ускорнеия будет непереносимая на старые процессоры, а то и поломанная программа (из-за LTO или изменения семантики float/double). На форониксе тестировали Mesa: никакого ускорения, т.к. узкое место не в Месе, а LTO и вовсе поломанный бинарник дал.
И да, на последних тестах фороникса gcc и clang вровень кроме тех тестов, где есть openmp.
Исходная версия quiet_readonly, :
Скорость компиляции определенно интересует конечных пользователей.
Clang спроектирован как платформа для сред разработки и инструментов анализа кода, для которых скорость крайне критична. Какую паузу между вводом ".«/»->" программист готов потерпеть? 50 мс, 500 мс, 3 секунды, 8 секунд?
С исполняемым файлом что, где код быстрее ? Можно не отвечать я и так знаю )
Код быстрее там, где у программиста была возможность его нормально ускорить: в GUI надо любые действия с длительностью более 1/50 секунды делать асинхронными, в числодробилках правильно применить OpenMP и устранить узкие места, в клиент-серверных приложениях нужен гибкий механизм кеширования, при обработке данных (да хотя бы при индексировании кода на сервере тем же clang) надо обеспечить сериализацию и выгрузку данных на диск и т.д.
Где здесь участвует компилятор - я как-то не вижу. То есть, конечно, с -march=native -Ofast -flto эффект будет, но скорее всего вместо ускорнеия будет непереносимая на старые процессоры, а то и поломанная программа (из-за LTO или изменения семантики float/double). На форониксе тестировали Mesa: никакого ускорения, т.к. узкое место не в Месе, а LTO и вовсе поломанный бинарник дал.
И да, на последних тестах фороникса gcc и clang вровень кроме тех тестов, где есть openmp.