L4zySh4rk Posted August 28 Posted August 28 Параллельная генерация кода, оптимизация LLVM и изменения в менеджере памяти для 64-разрядной версии Linux Intel и Windows Arm64EC. Предварительная версия: этот пост в блоге основан на предварительной версии программного обеспечения RAD Studio и написан с особого разрешения компании Embarcadero. Ни одна функция не будет включена в продукт до его официального релиза. В предыдущем посте я рассказал о переработанном компиляторе Delphi для 64-разрядной версии Linux Intel. Этот компилятор и компилятор Delphi для Windows Arm64EC теперь основаны на одном и том же поколении LLVM 20, что позволяет нашим научно-исследовательским подразделениям использовать наработки для компиляторов на обеих платформах. Когда мы говорим о производительности компилятора, мы задаем два разных вопроса: 1) Сколько времени занимает сборка приложения? и 2) Насколько быстро выполняется код, сгенерированный компилятором после сборки? Новый LLVM обеспечивает превосходную оптимизацию, но для этого компилятору приходится выполнять больше работы, что требует больше времени. Наша команда прилагает значительные усилия для решения обеих проблем. Оглавление Параллельная генерация кода (впервые для Delphi) Что меняет новый оптимизатор Менеджеры памяти в Arm и Linux Пакеты времени выполнения и другие Windows в Arm работают Параллельная генерация кода (впервые для Delphi) 64-разрядные исполняемые файлы компилятора теперь могут генерировать код для нескольких модулей Delphi параллельно. По умолчанию компилятор выбирает количество рабочих потоков в зависимости от доступных ядер процессора. Это значение можно изменить глобально, для каждого проекта или в командной строке, в том числе отключить параллельную генерацию, если нужно изолировать проблему в работе компилятора. Новая опция «Количество рабочих потоков» в диалоговом окне «Параметры инструментов» Обратите внимание, что эта функция не поддерживается в 32-разрядных версиях компиляторов и в 32-разрядной среде разработки, так как требует больше памяти и может привести к превышению доступного объема памяти при сборке больших приложений. Эффективность улучшения во многом зависит от проекта и конфигурации сборки. В ходе одного внутреннего тестирования перекомпиляция модулей FireMonkey на 10-ядерном процессоре Intel Core i9-13900H была примерно в два раза быстрее в режиме отладки и примерно в 14 раз быстрее в режиме релиза. Я бы не стал использовать эти цифры в качестве стандарта для всех проектов. Однако они показывают, почему параллельная работа особенно важна для оптимизированных сборок в режиме релиза, где LLVM приходится выполнять значительно больший объем работы и без этой функции процесс был бы довольно медленным. Что изменилось в новом оптимизаторе Как для 64-разрядных систем Linux Intel, так и для Windows Arm64EC интерфейсная часть компилятора теперь может пропускать код Delphi через более широкий набор проходов оптимизации LLVM IR. Это включает в себя обработку исключений — одну из областей, в которых семантика языка и универсальный оптимизатор должны полностью совпадать. Во многих наших тестах время выполнения сократилось в два-четыре раза, а в одном из тестов Conway’s Life — примерно в семь раз. При включенных новых оптимизациях компиляция релизной версии на Arm64EC может занять больше времени — в текущих тестах на 34–42 % больше, если не учитывать параллельную генерацию кода. Это справедливый компромисс: потратить больше времени на компиляцию, чтобы получить более быстрый код, а затем использовать доступные ядра процессора, чтобы сократить время ожидания. Менеджеры памяти на Arm и Linux Мы также портировали менеджер памяти Delphi на основе FastMM4 на Windows Arm64EC и сделали его менеджером памяти по умолчанию. Оригинальный распределитель памяти, который мы выпустили в версии 13.1, был особенно медленным при некоторых сценариях перераспределения памяти, в том числе при многократной конкатенации строк. FastMM обеспечивает более сбалансированное поведение и сохраняет функцию отслеживания утечек памяти, к которой привыкли разработчики Windows Delphi. В дополнение к FastMM4 команда представляет менеджер памяти rpmalloc, который доступен в качестве альтернативы как для Arm64EC, так и для 64-разрядной версии Linux для Intel. В наших тестах он показал стабильную работу и может быть очень быстрым при многопоточных операциях выделения памяти — иногда в два, а то и в 30 раз быстрее, в зависимости от теста. К недостаткам можно отнести более высокий расход памяти — зачастую в два раза больше — и отсутствие эквивалентного встроенного отчета об утечках. Поэтому он остается опцией, а не выбором по умолчанию. Пакеты среды выполнения и другие возможности Windows на Arm Наряду с изменениями в компиляторе мы продолжаем развивать платформу Windows Arm64EC. Основное улучшение — это функция, которая не была включена в версию 13.1: поддержка пакетов среды выполнения. Конфигурация пакетов среды выполнения для платформы Windows на Arm Пакеты среды выполнения — не единственное улучшение платформы Windows на Arm: команда также работала над улучшением работы с плавающей запятой, обработкой кода с большим количеством обобщений, совместимостью со статическими библиотеками, ресурсами, компоновкой, обработкой исключений, импортированными функциями и информацией об отладке. Большинство этих функций не являются ключевыми, но в совокупности они определяют, сможет ли существующее приложение Delphi без проблем перейти на эту платформу. В этом и предыдущем посте мы рассказываем о работе компилятора Delphi в RAD Studio 13.2. Но, конечно, это не единственное улучшение. В ближайшее время я расскажу о других улучшениях в версии 13.2. Предварительный обзор функций: этот пост основан на информации о предварительной версии программного обеспечения RAD Studio и написан с особого разрешения компании Embarcadero. Ни одна функция не будет включена в релиз до выхода продукта в общий доступ. Original: https://blogs.embarcadero.com/coming-in-rad-studio-13-2-faster-builds-and-faster-applications-with-delphis-llvm-20-compilers/#Parallel_Code_Generation_A_First_for_Delphi 7099.pdf
Recommended Posts