Я не спорю, что путь к LLVM прописан в CMakeLists.txt. Я не понимаю зачем. Вы сами написали, что собираете компилятором g++. LLVM никак не используется в вашем main.cpp. Зачем он тогда?
Вижу, что прописан project(LLVMPassSample) что подсказывает мне CMakeFiles.txt взят от балды из интернета от студенческого репозитория с реализацией своего pass'a.
Не увидел у вас ссылки на исходный код. Как мне проверить ваши измерения?
И так, лучшие настройки оптимизации для данного теста на платформах:
x86: Rust - O2, C++ - O3.
Как-то бедно вы смотрели. Откроем список опций в GCC https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html сделаем поиск по "-f" и получим 900+ результатов. Грубо говоря половина будет -fno. Грубая оценка даёт вам 450 опций управления компиляцией. А вы рассмотрели только одну. Также не пробовали режимы компиляции с профилем. Не пробовали опции -march=, которые на Эльбрусе дают большой прирост.
Я не понял какой компилятор вы использовали для Эльбруса.
В сравнении gcc и llc, gcc оказался чуть эффективнее, но разница очень маленькая
Это один и тот же компилятор. LCC является совместимым с GCC по опциям, чтобы облегчить жизнь пользователям по системе сборки. И на Эльбрусах gcc является алиасом lcc в системе. Так что если есть разница, то скорее всего это ошибка измерения.
У меня вызывает вопрос следующее:
C++: GCC v9.3.0 compatible; LLVM version 13.0.1.
Какая версия LLVM у lcc, если его там нет? Или вы тестировали clang? А если нет, то зачем написали?
Можете подробнее раскрыть "изменение потока данных"? Пока звучит так, что ошибка либо в данных (например, изменён порядок полей), либо в программе (она не учитывает какие-то особенности)
Это невозможно технически, так как вы в статике не знаете самые горячие пути исполнения программы (если только вы руками до этого не профилировали и не вставляли подсказки). -fprofile-generate/-fprofile-use даёт вам возможность для заданного тестового набора данных оптимизировать программу лучше. Но нужно держать в голове, что если на train данных у вас будет исполнен один код, а при реальном использовании другой, то вы получите замедление.
Также, в простом режиме -O2 вы собираете программу без LTO оптимизаций. Inline у вас будет работать в пределах одного модуля (если только не вынести всё в headers). Поэтому эффективность будет крайне ограничена.
Поэтому для более быстрого кода старайтесь использовать хотя бы такой набор -O3 -flto (или -fwhole) и сборку с профильной информацией с актуальными train данных.
Также крайне желательно узнать что там с вычислениями с плавающей запятой. -ffast -ffast-math могут тоже сильно ускорить программу.
Как разработчик компилятора для Эльбруса (который тоже VLIW) и которому PGO (Profile Guided Optimizations) дают также прирост производительности могу сказать, что возможно OpenSSL собирал не Intel, а просто обычные программисты, которые никогда не заглядывали в список опций. Даже если открыть список GCC, можно очень долго перебирать те опции, которые есть. Когда опций больше 500, то определить те, которые дают прирост производительности очень сложно. У меня лежит штук 20 научных статей по методам автоматического подбора. А большинство приложений собираются с -O2 и не более.
По тексту ошибок могу добавить, что текст зависит от компилятора. И иногда, чтобы понять о чём идёт речь, легче собрать несколькими компиляторами один модуль. Текст ошибок отличается и где-то в одном случае лучше написано у Clang, где-то у GCC
Только в институте, когда на первом курсе аспирантуры нам читали курс "История и философия науки" я осознал многие вещи из физики и математики. Но сам этот курс наверно будет не понятен, если не изучил всю теорию, которая упоминается в этом курсе. Такая вот петля, где 2 элемента и оба зависят друг от друга.
Я использую Google диск. Для смартфона Drive Sync, для Win10 Google Drive. Вот для Linux нормального приложения я не нашёл, чтобы ещё кеширование нормально работало.
Сидел долго и на том, и на том. Могу сказать, что Lineage более плавный, в нем нет кучи мусора (аж 8Гб освободилось, для меня это критично). Но до сих пор не могу стандартное приложение камеры запихнуть в кастомную прошивку. А без него нормально не работают модули (не все распознаются), нет режимов склейки в 100+Мп и тд. Если не пытаться снимать на камеру, как на фотоаппарат, а использовать её для фотографирования счётчиков - то всё замечательно и Lineage (да и вообще любой кастом) будет лучше MIUI
То что вы в первый раз про него слышите это ваши персональные проблемы.
Что же так грубо?
широко известны по всему миру, за исключением разве что постсоветских стран (видимо, из-за долгого отсутствия перевода).
Перевод мне и не нужен. Я читал те книги, что привёл в оригинале (в объёме нужном для разработчика компилятора). Возможно, это неплохая книга для вечернего чтива, если совсем не разбираться в устройстве современных процессоров. Но я ни разу не видел, чтобы хоть один серьёзный институтский курс включал её у себя в список рекомендуемой литературы. Ни у нас, ни за рубежом. Книга Харрисов написана не сложнее, а даёт на несколько порядков больше.
Книга, кстати, включает в себя проекты по разработке и компилятора, и виртуальной машины, и ОС. И для вхождения в тему, имхо, подходит на порядок лучше Таненбаума и Харриссов вместе взятых.
Это называется обо всём и ни о чём. Книга указана в разделе "Архитектура компьютера". Зачем в неё запихивать ещё 3 темы? В этой книге уделено всего лишь 24 страницы архитектуре. Она не рассказывает ничего про необходимые программисту вещи. Ни про предсказатель переходов, ни про иерархию памяти, ни про параллелизм (на уровне инструкций, векторные команды, потоки) и тд.
Если уж начали писать про книги, то упоминайте классику. Про алгоритмы, если уж для "профи", то почему нет "Алгоритмы построение и анализ" Кормена и Штайна? Можно сюда же запихнуть "Алгоритмические трюки для программистов" Уоррена Более специфичные вещи: "Text Algorithms" Maxime Crochemore
По архитектуре компьютера первый раз слышу про Ноам Нисана, но не приведены классические книги: Харрис и Харрис "Цифровая схемотехника и архитектура компьютера, Дэвид М. Харрис" и для мощных ребят "Computer Architecture A Quantitative Approach" за авторством Hennesy и Patterson.
По ОС почему-то нет 4х томника Андерсона "Operation Systems Principles and Practice" и "Операционные системы Внутренняя структура и принципы проектирования" за авторством Столлингса. А про bash и команды Linux stackoverflow расскажет лучше, когда будете решать конкретную задачу.
Почему-то нет книг по компиляторам. Вроде тоже CS. Cooper & Torzon "Engineering a compiler", фиолетовый дракон, "Advanced compiler design and implementation" Steven S. Muchnick, "Modern Compiler Implementation in C" Andrew W. Appel, "Linkers & Loaders" John R. Levine
Виртуальные машины: "Virtual machines" Smith & Nair.
Также в CS входят ещё куча всего, например программирование графики и компьютерное зрение, распределённые системы, базы данных и тд.
Мне кажется, что если бы вы свою таблицу заменили на хэш-таблицу <key: символ value:набор из 2 цифр>, то сложность вашего решения сразу бы резко упала. Тем более, вы оперируете с заранее известным алфавитом и эту таблицу можно инициализировать статически.
Зачем текст разбивать на слова? Почему просто нельзя итерироваться по массиву символов в один проход?
Свитч, как уже сказали действительно страшный, не ясно зачем он вообще нужен
Я не спорю, что путь к LLVM прописан в CMakeLists.txt. Я не понимаю зачем. Вы сами написали, что собираете компилятором g++. LLVM никак не используется в вашем main.cpp. Зачем он тогда?
Вижу, что прописан
project(LLVMPassSample)что подсказывает мне CMakeFiles.txt взят от балды из интернета от студенческого репозитория с реализацией своего pass'a.Не увидел у вас ссылки на исходный код. Как мне проверить ваши измерения?
Как-то бедно вы смотрели. Откроем список опций в GCC https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html сделаем поиск по "-f" и получим 900+ результатов. Грубо говоря половина будет -fno. Грубая оценка даёт вам 450 опций управления компиляцией. А вы рассмотрели только одну. Также не пробовали режимы компиляции с профилем. Не пробовали опции -march=, которые на Эльбрусе дают большой прирост.
Я не понял какой компилятор вы использовали для Эльбруса.
Это один и тот же компилятор. LCC является совместимым с GCC по опциям, чтобы облегчить жизнь пользователям по системе сборки. И на Эльбрусах gcc является алиасом lcc в системе. Так что если есть разница, то скорее всего это ошибка измерения.
У меня вызывает вопрос следующее:
Какая версия LLVM у lcc, если его там нет? Или вы тестировали clang? А если нет, то зачем написали?
Можете подробнее раскрыть "изменение потока данных"? Пока звучит так, что ошибка либо в данных (например, изменён порядок полей), либо в программе (она не учитывает какие-то особенности)
Это невозможно технически, так как вы в статике не знаете самые горячие пути исполнения программы (если только вы руками до этого не профилировали и не вставляли подсказки). -fprofile-generate/-fprofile-use даёт вам возможность для заданного тестового набора данных оптимизировать программу лучше. Но нужно держать в голове, что если на train данных у вас будет исполнен один код, а при реальном использовании другой, то вы получите замедление.
Также, в простом режиме -O2 вы собираете программу без LTO оптимизаций. Inline у вас будет работать в пределах одного модуля (если только не вынести всё в headers). Поэтому эффективность будет крайне ограничена.
Поэтому для более быстрого кода старайтесь использовать хотя бы такой набор -O3 -flto (или -fwhole) и сборку с профильной информацией с актуальными train данных.
Также крайне желательно узнать что там с вычислениями с плавающей запятой. -ffast -ffast-math могут тоже сильно ускорить программу.
Как разработчик компилятора для Эльбруса (который тоже VLIW) и которому PGO (Profile Guided Optimizations) дают также прирост производительности могу сказать, что возможно OpenSSL собирал не Intel, а просто обычные программисты, которые никогда не заглядывали в список опций. Даже если открыть список GCC, можно очень долго перебирать те опции, которые есть. Когда опций больше 500, то определить те, которые дают прирост производительности очень сложно. У меня лежит штук 20 научных статей по методам автоматического подбора. А большинство приложений собираются с -O2 и не более.
Скрытый текст
Был бы благодарен, если Вы приведёте ссылку на ветку сюда
Третий пункт в тексте прочитал несколько раз. Подумал, что уже совсем с головой не дружу и не вижу взаимосвязи
По тексту ошибок могу добавить, что текст зависит от компилятора. И иногда, чтобы понять о чём идёт речь, легче собрать несколькими компиляторами один модуль. Текст ошибок отличается и где-то в одном случае лучше написано у Clang, где-то у GCC
Не дождался похорон легаси с x86s https://habr.com/ru/news/736568/ . А хотелось взглянуть
Только в институте, когда на первом курсе аспирантуры нам читали курс "История и философия науки" я осознал многие вещи из физики и математики. Но сам этот курс наверно будет не понятен, если не изучил всю теорию, которая упоминается в этом курсе. Такая вот петля, где 2 элемента и оба зависят друг от друга.
Я использую Google диск. Для смартфона Drive Sync, для Win10 Google Drive. Вот для Linux нормального приложения я не нашёл, чтобы ещё кеширование нормально работало.
Интересная эволюция Южной Кореи в Северную
А если нужно динамически изменять необходимые в данный момент компоненты прошивки? Не собирать же прошивки со всеми возможными комбинациями.
Вы можете и сейчас получить доступ к эльбрусам https://t.me/elbrus_gensokyo/3
Сидел долго и на том, и на том. Могу сказать, что Lineage более плавный, в нем нет кучи мусора (аж 8Гб освободилось, для меня это критично). Но до сих пор не могу стандартное приложение камеры запихнуть в кастомную прошивку. А без него нормально не работают модули (не все распознаются), нет режимов склейки в 100+Мп и тд. Если не пытаться снимать на камеру, как на фотоаппарат, а использовать её для фотографирования счётчиков - то всё замечательно и Lineage (да и вообще любой кастом) будет лучше MIUI
Анонимный дедушка постарался, и подарок приехал прям 31го декабря. Наш питомец тоже захотел распаковать подарочек :)
Что же так грубо?
Перевод мне и не нужен. Я читал те книги, что привёл в оригинале (в объёме нужном для разработчика компилятора). Возможно, это неплохая книга для вечернего чтива, если совсем не разбираться в устройстве современных процессоров. Но я ни разу не видел, чтобы хоть один серьёзный институтский курс включал её у себя в список рекомендуемой литературы. Ни у нас, ни за рубежом. Книга Харрисов написана не сложнее, а даёт на несколько порядков больше.
Это называется обо всём и ни о чём. Книга указана в разделе "Архитектура компьютера". Зачем в неё запихивать ещё 3 темы? В этой книге уделено всего лишь 24 страницы архитектуре. Она не рассказывает ничего про необходимые программисту вещи. Ни про предсказатель переходов, ни про иерархию памяти, ни про параллелизм (на уровне инструкций, векторные команды, потоки) и тд.
Если уж начали писать про книги, то упоминайте классику.
Про алгоритмы, если уж для "профи", то почему нет "Алгоритмы построение и анализ" Кормена и Штайна?
Можно сюда же запихнуть "Алгоритмические трюки для программистов" Уоррена
Более специфичные вещи: "Text Algorithms" Maxime Crochemore
По архитектуре компьютера первый раз слышу про Ноам Нисана, но не приведены классические книги: Харрис и Харрис "Цифровая схемотехника и архитектура компьютера, Дэвид М. Харрис" и для мощных ребят "Computer Architecture A Quantitative Approach" за авторством Hennesy и Patterson.
По ОС почему-то нет 4х томника Андерсона "Operation Systems Principles and Practice" и "Операционные системы Внутренняя структура и принципы проектирования" за авторством Столлингса. А про bash и команды Linux stackoverflow расскажет лучше, когда будете решать конкретную задачу.
Почему-то нет книг по компиляторам. Вроде тоже CS. Cooper & Torzon "Engineering a compiler", фиолетовый дракон, "Advanced compiler design and implementation" Steven S. Muchnick, "Modern Compiler Implementation in C" Andrew W. Appel, "Linkers & Loaders" John R. Levine
Виртуальные машины: "Virtual machines" Smith & Nair.
Также в CS входят ещё куча всего, например программирование графики и компьютерное зрение, распределённые системы, базы данных и тд.
Мне кажется, что если бы вы свою таблицу заменили на хэш-таблицу <key: символ value:набор из 2 цифр>, то сложность вашего решения сразу бы резко упала. Тем более, вы оперируете с заранее известным алфавитом и эту таблицу можно инициализировать статически.
Зачем текст разбивать на слова? Почему просто нельзя итерироваться по массиву символов в один проход?
Свитч, как уже сказали действительно страшный, не ясно зачем он вообще нужен
Ну и статья не совсем для хабра на мой взгляд.