Новые компиляторы Intel для C/C++ полностью используют стек LLVM вместо своих прежних проприетарных решений в рамках ICC. Об этом в блоге сообщил эксперт компании Джеймс Рейндерс (James Reinders). По его словам, последние компиляторы Intel C/C++, использующие LLVM, обеспечивают ускорение компиляции, лучшую оптимизацию, расширенную поддержку стандартов и поддержку разгрузки на GPU и FPGA, чем те, что использовались ранее.

Компания отмечает, что новый компилятор oneAPI DPC++/C++ Compiler 2021.3 (icx) на базе LLVM обеспечивает ускорение на 14 % при сборке, чем проприетарный. Также заявлено, что версия 2021.3 обеспечивает более высокую производительность, чем GCC 11.1 — речь идёт о превосходстве в среднем на 41 %. А производительность в задачах с плавающей запятой стала выше на 19 %. На текущие момент решение Intel поддерживает SYCL, C++20, OpenMP 5.1 (в том числе для GPU). Но инженеры всё ещё работают над переводом своего компилятора Fortran на LLVM.

Intel рекомендует использовать новый компилятор во всех новых проектах. Существующие системы должны перейти на него в текущем году, так как инструментарий ICC вскоре будет признан устаревшим. Рейндерс уточнил, что новый компилятор Intel на базе LLVM достиг паритета с классической версией ICC, а также предложил лучшую технологию оптимизации, чем имеющаяся. Компания на протяжении нескольких лет активно отправляла свои наработки в основные ветки и LLVM, и GCC.

На этой неделе компания AMD без лишнего шума опубликовала новую версию своего компилятора AMD Optimizing C/C++ Compiler 3.1 (AOCC), который перебрался на платфолрму LLVM/Clang 12. В этом релизе фокус сделан на различные исправления вне основного дерева, которые вносят оптимизации для семейства процессоров на базе ядер AMD Zen. Так, например, улучшения коснулись Flang для сборки Fortran-программ и поддержки OpenMP 4.5.

Тем не менее, в AOCC 3.1 основным изменением стала актуализация его кодовой базы и связанных подпроектов, а также подгонка их под LLVM 12.0. Таким образом, нынешняя AOCC поставляется с последней стабильной версией LLVM, а на смену ей придет версия LLVM 13.0, которая должна выйти в сентябре. Правда, не уточняется, попадут ли обновления из AOCC 3.1 в основную ветку LLVM. Иных изменений нет или, как минимум, они не заявлены в явном виде. Скачать компилятор можно здесь.

Разработчики из компании Intel готовят патчи для ПО с поддержкой будущих процессоров Xeon семейства Sapphire Rapids, которые, как теперь выяснилось, будут включать инструкции AVX-512 FP16. Соответствующая документация была выложена в публичный доступ в самом конце июня. А вслед за этим появились патчи для GCC и LLVM, на которые обратил внимание ресурс Phoronix.

Поддержка FP16-вычислений с помощью AVX-512 будет актуальна, в первую очередь, для приложений машинного обучения. При этом не следует путать их с BF16 (Bfloat16), которая появилась ещё в семействе Cooper Lake в прошлом году. Для GCC Intel подготовила набор из 62 патчей для поддержки всех новых функций AVX512 FP16, а также автоматической векторизации _Float16 и связаных задач. Для LLVM добавлены патчи, «знакомящие» Clang с новым форматом и инструкциями.

Судя по всему, полноценная поддержка появится только в GCC 12, то есть, как теперь понятно, ближе к релизу самих процессоров в первой половине 2022 года. И очередные релизы крупных дистрибутивов её не получат. Что касается Clang, то есть все шансы, что поддержка будет добавлена уже в LLVM 13 — релиз намечен на осень.

Компания Red Hat не только продолжает активно вкладываться в GCC и наборы инструментов GNU, но также наращивает команду разработчиков компилятора LLVM, сообщает Phoronix. Под её крылом трудится Том Стеллард (Tom Stellard) вместе с другими инженерами LLVM. Но теперь группу расширяют.

developers.redhat.com

Сообщается, что компания хочет нанять ещё минимум двух специалистов по LLVM. По словам Стелларда, планируется нанять главного инженера-программиста для разработки функций и решения других задач поддержки пользователей в подпроектах LLVM, а также в самом LLVM и Clang. Также требуется специалист в области компоновщиков для работы над BFD и LLD.

При этом пока неясно, как именно будет далее развиваться стек компиляторов в Red Hat. В частности, в Fedora 35 позволят собирать больше пакетов с помощью Clang, а не GCC.

Релиз Fedora 34 должен выйти на этой неделе, но разработчики уже активно работают над Fedora 35, внося новые предложения. Так, например, сейчас в Fedora основным системным компилятором выступает GCC. Исключением может быть лишь тот случай, когда исходный проект поддерживает только LLVM/Clang. Однако в будущем возможен переход на LLVM там, где это целесообразно, в рамках всего дистрибутива.

В Red Hat предложили пересмотреть политику использования компиляторов для Fedora 35 — при создании пакета у сопровождающего его разработчика будет выбор между GCC и LLVM. При этом GCC останется в качестве системного компилятора по умолчанию, и большинство пакетов, вероятно, продолжат использовать именно его. Однако будет возможность собирать проекты и с помощью LLVM, причём даже те, которые официально поддерживают только GCC.

Среди пакетов, которые могут затронуть эти изменения, есть Firefox и некоторые другие. При этом пока что комитет по разработке и управлению Fedora ещё не оценил это изменение, потому решение пока что находится в «подвешенном» состоянии. Похожий подход используется в Intel Clear Linux, где для каждого конкретного пакета выбирается тот компилятор, который позволит получить лучшую производительность.

Вчера вечером состоялся релиз обновления набора компиляторов LLVM 12, выход которого несколько задержался из-за ошибок. Главным нововведением стала поддержка грядущих процессоров Intel Alder Lake и Sapphire Rapids, а также базовая поддержка AMD Zen 3 и дальнейшее улучшение работы с POWER.

Помимо этого, продолжена работа над поддержкой C++ 20. Стек Clang 12 также получил улучшения для Windows на ARM64, оптимизации ядра OpenCL, поддержку инструкций AVXVNNI и других, а также ряд других улучшений. Из небольших изменений отмечается снижение потребления памяти.

Все исходники, как обычно, доступны на GitHub. Отметим, что в новой версии обещали появление более тонкой оптимизации собираемого кода с учётом наличия того или иного типового набора общих инструкций x86-64.

Национальный энергетический научно-исследовательский вычислительный центр (NERSC), Национальная лаборатория им. Лоуренса в Беркли (LBNL) и вычислительный центр Argonne Leadership Computing Facility (ALCF) совместно с Codeplay Software работают над расширением возможностей компилятора LLVM SYCL GPU для ускорителей NVIDIA A100.

aesin.org.uk

SYCL — это открытый стандарт, поддерживаемый Khronos Group. Впервые его показали в 2014 году. Это открытый кроссплатформенный уровень абстракции, который позволяет писать код для гетерогенных процессоров. SYCL будет поддерживаться на грядущем экзафлопсном суперкомпьютере Aurora Министерства энергетики США.

Компания AMD сообщила о добавлении официальной поддержки процессоров Ryzen 5000 на архитектуре Zen 3 в компилятор GCC. Как обычно, произошло это с некоторым опозданием. Хорошим тоном считается подготовка ПО для разработчиков примерно за полгода до выхода чипов на рынок. Например, Intel ещё в июле добавила подддержку Alder Lake и Sapphire Rapids в GCC. Это гарантирует, что к моменту начала продаж компиляторы будут поддерживать новое «железо».

Phoronix сообщает, что для GCC выпущен первый патч, который добавляет поддержку Zen 3 с новой опцией -march=znver3. При этом других изменений там пока нет, а все специализированные оптимизации, касающиеся, например, планировщика, остаются прежними, как и для Zen 2. Позднее, как ожидается, для znver3 будет произведена более точная настройка под новую микроархитектуру.

picsart.com

Ожидается, что полная поддержка будет реализована в GCC 11 или в GCC 12. В любом случае, это означает, что стабильный компилятор GCC не сможет в полной мере использовать преимущества микроархитектуры Zen 3 до 2021 года. На данный момент поддержка znver3 касается только корректной работы на процессорах Zen 2. Это очень похоже на базовую поддержку znver3 в LLVM.

Впрочем, в скором времени AMD выпустит свой официальный патч для LLVM/Clang. Помимо этого, компания выпустила AOCC 2.3 в качестве своего базового компилятора на основе LLVM 11.0 с добавлением различных патчей AMD Zen. Здесь ситуация аналогична — AOCC 2.3 по-прежнему ориентирован на Zen 2, но содержит базовую поддержку Zen 3.

Тем не менее, такая ситуация возникает не впервые — в своё время задержались улучшения LLVM для AMD Zen 2. Задержка с добавлением патчей приводит к тому, что они не успевают попасть в стабильные версии наборов компиляторов и, как следствие, в ближайшие мажорные версии основных дистрибутивов.

Два популярных открытых средства разработки, GCC 11 и LLVM Clang 12, получили возможность более тонкой оптимизации собираемого кода с учётом наличия того или иного типового набора общих инструкций x86-64. Это не отменяет возможность оптимизации под конкретные поколения процессоров, но позволяет легче задавать системные требования не только для отдельных программ, но и, например, для крупных проектов, которые могут работать на разных CPU.

LLVM принимает новые опции через параметр -march=, а GCC — через опцию --with-arch_64=. Список ключей, которые соответствуют наборам инструкций, одинаков:

• x86-64: CMOV, CMPXCHG8B, FPU, FXSR, MMX, FXSR, SCE, SSE, SSE2
• x86-64-v2: CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
• x86-64-v3: AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE
• x86-64-v4: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL

Фото: Jeh/Wikipedia

Первый уровень является наиболее общим и универсальным вариантом для всех 64-бит процессоров x86. x86-64-v2 близок по набору дополнительных инструкций к архитектуре Nehalem, а x86-64-v3 — к Haswell. А вот x86-64-v4 из-за требования AVX-512 на текущий момент фактически ограничен достаточно современными процессорами Intel. В дальнейшем число наборов будет наверняка расширено, так как в v4, к примеру, не попали инструкции AVX-VNNI (в текущем виде это пока что полный эквивалент AVX512-VNNI).

Стандартизация наборов проведена при участии Red Hat, которая уже давно хочет повысить минимальные системные требования, чтобы более полно использовать возможности современных процессоров, а не собирать код под наиболее общий вариант x86-64, который включает CPU 15-летней давности. Новый инструментарий GCC и LLVM поможет компании в осуществлении задуманного. Этот шаг, очевидно, повлияет и на других игроков в индустрии.

Набор SIMD-инструкций Intel MMX, представленный в 1997 году, является откровенно устаревшим и уже давно вытеснен различными версиями SSE и AVX. Тем не менее, в средствах разработки они всё ещё формально поддерживаются. Правда, в силу редкости использования, их имплементация страдает от багов. Поэтому неудивительно, что их в очередной раз предложили выкинуть из популярного набора компиляторов LLVM.

В обсуждении, начатом в листах рассылки, предлагается переписать и заменить интринсики для MMX на новые, использующие уже имеющиеся для SSE или, лучше, SSE2. Текущие требуют некоторый внимательности от разработчика, так как при некорректном использовании программа будет не падать, а выдавать некорректные результаты. В дальнейшем предлагается исключить MMX из представления LLVM IR.

Единственный способ использования этих инструкций и сопутствующих регистров, если это по какой-то причине действительно нужно — использование ассемблерных вставок непосредственно в коде. Любопытно, что, судя по всему, даже физически отдельных регистров для x87/MMX в современных процессорах уже нет — они делят «кремний» с регистрами для маскирования AVX-512, так как вероятность высокой нагрузки со стороны обоих типов инструкций одновременно крайне маловероятна.

Отказ от MMX, естественно, повысит минимальные требования LLVM. Однако сейчас трудно найти работающую x86-систему, в которой нет поддержки SSE2 или хотя бы SSE. Это перекликается с активизировавшимися призывами отказаться от поддержки старых CPU вообще, 32-битных и без современных инструкций. В частности, Fedora и RHEL уже движутся в этом направлении.