На этой неделе компания 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 — релиз намечен на осень.

Аргоннская национальная лаборатория вместе с Ок-Риджской национальной лабораторией (ORNL) заключила с Codeplay Software контракт на реализацию компилятора oneAPI DPC++, расширения открытого стандарта SYCL для работы в составе высокопроизводительных гетерогенных вычислительных систем.

Компилятор планируется использовать для суперкомпьютеров экзафлопсного класса Aurora и Frontier на базе CPU и GPU Intel и AMD соответственно. Как отмечается, SYCL станет одной из основных моделей программирования для них, что позволит упростить разработку научных приложений, объединить кодовые базы и облегчить перенос ПО с одного суперкомпьютера на другой.

Ранее Codeplay и ряд научно-исследовательских центров начали работу над расширением компилятора SYCL и DC++ для NVIDIA A100, а теперь компания сосредоточится на поддержке ускорителей AMD, покрыв таким образом основные современные платформы. Отметим, что не только Codeplay занимается разработкой и расширением компиляторов для SYCL — есть различные реализации как от частных компаний, так и от научных институтов.

Компания CacheQ, основанная двумя бывшими руководителями Xilinx и группой инженеров, обещает совершить революцию в мире разработки ПО. CacheQ Compiler Collection позволит компилировать проекты так, чтобы они выполнялись намного быстрее за счёт распараллеливания процесса. А изюминка в том, что, по словам создателей, нет необходимости массового ручного переписывания кода и использования особых библиотеках или сложных API для параллелизации.

Это даёт разработчикам возможность заниматься бизнес-логикой приложения, не задумываясь о проблемах распараллеливания. Более того, количество потоков можно регулировать на стадии исполнения, а часть нагрузки при желании перенести на FPGA или SoC. При этом поддерживается сборка для архитектур x86-64, ARM (Apple M1) и RISC-V.

semiwiki.com

Результаты впечатляют. На процессоре x86 с 12 ядрами прирост быстродействия в работе приложения составляет почти 500 % по сравнению с однопоточным выполнением и сборкой с помощью GCC. На процессоре M1 с восемью ядрами Arm — на 400 % быстрее традиционного «однопотока».

«Секрет» заключается в тщательной работе с циклами и особенно вложенными циклами. Исходный код анализируется и преобразуется фирменной системой qthreads в код на C++, который можно собрать любым компилятором, или в Verilog для последующей сборки для FPGA. Впрочем, CacheQ предлагает полный набор инструментов для разработки, отладки, профилирования, симуляция и оптимизации кода и работы с памятью.

Компания 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.

Компания IBM готовит к выпуску компилятор COBOL версии 1.1 для ОС на базе Linux для архитектуры x86-64. В комплекте идёт также набор runtime-библиотек, а сама сборка основана на том же оптимизирующем компиляторе, что и версия Enterprise COBOL для z/OS. Новинка позволяет создавать приложения COBOL для Linux в системах с процессорами x86-64. Релиз запланирован на 16 апреля.

Как отмечается, новая система совместима с текущими спецификациями, поддерживает современные дистрибутивы, а также пригодна для создания бизнес-приложений. Компилятор совместим со стандартом COBOL 1985, а также некоторыми спецификациями COBOL 2002 и 2014. Программы, написанные на COBOL, теперь можно развёртывать в гибридных облачных системах на основе IBM Z (z/OS), IBM Power (AIX) и x86-64 (Linux).

medium.com

COBOL 1.1 для Linux включает следующие функции и возможности:

• Оптимизирующий компилятор и runtime-библиотеки IBM COBOL для Linux.
• Поддержка IBM TXSeries на разных платформах.
• Совместимость с IBM Db2 для Linux, UNIX и Windows.
• Поддержка Unicode, позволяющая приложениям COBOL напрямую обрабатывать данные в этой кодировке.
• Встроенная поддержка XML, которая позволяет приложениям COBOL анализировать входящие и генерировать исходящие XML-сообщения.
• Совместимость с IBM Enterprise COBOL для z/OS и IBM COBOL для AIX.
• Утилита преобразования исходного кода (scu) для помощи в переносе исходного кода, разработанного с помощью компиляторов COBOL других производителей.
• Совместимость с Red Hat Enterprise Linux 7.8 или новее, а также Ubuntu Server 16.04 LTS, 18.04 LTS или новее.

Отметим, что языку программирования COBOL уже более 60 лет, однако на нём написан софт, который используется в банковской и многих других сферах. Появление официального компилятора IBM для Linux позволит банковским и финансовым структурам улучшить работу и перевести свою инфраструктуру на Linux, в том числе в облака.

В Ubuntu 21.04 планируется включить оптимизацию во время линковки (Link-Time Optimization, LTO) по умолчанию для сборки пакетов основного репозитория (main), что должно повысить общую производительность ПО. Подобное уже сделано в Fedora и openSUSE, а в Canonical планы относительно включения LTO обсуждались ещё в январе этого года.

LTO будет использоваться для архитектур x86_64 (AMD64), ARM64, PPC64EL и s390x при сборке с помощью GCC. Это, вероятно, последнее крупное изменение, которое стоит ждать в Ubuntu 21.04, так как кодовая база уже заморожена, а до релиза осталось всего несколько недель.

wikipedia.org

Естественно, такая оптимизация может и негативно сказаться на работе или даже сборке приложений, поэтому для части ПО она вручную отключена. На этой неделе состоится очередная глобальная пересборка пакетов, и разработчики попытаются или исправить ошибки, или отключить поддержку LTO примерно в 80 проблемных пакетах.

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

aesin.org.uk

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