Компания 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 Министерства энергетики США.

Компания 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. Задержка с добавлением патчей приводит к тому, что они не успевают попасть в стабильные версии наборов компиляторов и, как следствие, в ближайшие мажорные версии основных дистрибутивов.

Xilinx приобрела Falcon Computing и теперь владеет технологиями компиляторов, для создания высокопроизводительных приложений с использованием FPGA и адаптивных систем на кристалле (SoC).

Falcon Computing Solutions разработала технологии оптимизации для компилятора высокого уровня (HLS), который позволяет использовать аппаратное ускорение для приложений. Xilinx заявила, что после приобретения Falcon Computing, ее технологии адаптивных вычислений станут более доступными для разработчиков программного обеспечения за счет улучшения унифицированной программной платформы Vitis с помощью автоматизированных оптимизаций для аппаратного обеспечения.

Интеграция технологий Falcon Computing в платформу Vitis позволит ускорять приложения, написанные на C++, не обладая при этом глубокими знаниями оборудования, что снижает нагрузку на разработчиков приложений при адаптации своего кода для конкретного «железа». По словам Falcon Computing, использование Merlin позволяет достигать ускорения на порядок больше, чем при использовании обычных средств разработки, за счет повторного использования данных при вычислениях, разделения памяти, параллельного и конвейерного ускорения вычислений.

Использование единого исходного кода, по стилю похожего на OpenMP, очень удобно для большинства разработчиков на C/C++, которые привыкли использовать стандартные конструкции языка программирования при разработке своих приложений.

Компилятор Merlin от Falcon Computing позволяет приложениям использовать параллельные вычисления в комбинации со специализированным оборудованием, таким как многоядерные процессоры, графические ускорители и FPGA. Компилятор автоматически преобразует код, написанный на C/C++ в код для FPGA, таким образом устраняя разрыв в специализированных навыках разработчиков и делая доступным эту технологию для более широкого круга программистов, которые до этого имели сложности с оптимизацией кода для гетерогенных платформ.

Falcon Computing не первая компания, которую купила Xilinx, в 2010 году она приобрела AutoESL (который теперь стал платформой Vitis), в 2013 году Neptune Design Automation (теперь Vivado). Xilinx стремится создать большую экосистему для эффективной разработки, покупая профильные компании, причем это не поглощение с целью уничтожения конкурентов, а приобретение технологий, с целью расширения своего бизнеса.

Два популярных открытых средства разработки, 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 поможет компании в осуществлении задуманного. Этот шаг, очевидно, повлияет и на других игроков в индустрии.

Ни для кого не секрет, что единой оптимальной вычислительной архитектуры не существует. Разные виды задач и сценариев порождают и разные виды нагрузок, с которыми разные процессоры справляются по-разному. Программировать подо всё это разнообразие очень непросто, вот почему Intel взяла на себя задачу создать единую модель разработки в рамках проекта oneAPI, первый мажорный релиз которой вышел на днях.

Архитектура Intel oneAPI

По мере того, как вычислительная техника и ИТ-технологии проникают во все сферы жизни, рождаются всё новые и новые виды нагрузок. К примеру, в последнее время очень популярна поддержка целочисленных форматов типа INT8 для задач машинного обучения, где точностью, достигаемой в формате FP64, можно пожертвовать ради скорости и эффективности. Процессоры «обвешиваются» всё новыми инструкциями, появляются целые новые классы вычислительных устройств — и над всеми ними встаёт вопрос о том, как подо всё это эффективно писать программное обеспечение.

Многие видят ответ в создании унифицированных прослоек, вроде упомянутой недавно VMware с её Project Monterey. Корпорация Intel придерживается похожей точки зрения со своим проектом oneAPI. Данная разработка представляет собой унифицированную и открытую программную платформу, позволяющую абстрагироваться от аппаратной архитектуры устройств и писать код, задействующий все имеющиеся вычислительные ресурсы, будь то CPU, GPU, DPU или иные. Основой для oneAPI стал язык DPC++, который, в свою очередь, базируется на стандартах C++ и Kronos SYCL.

Один API, чтобы править всеми (видами вычислений)

Впервые об oneAPI мир узнал в конце 2018 года, а сегодня проект достиг важной вехи: компания официально объявила о релизе oneAPI 1.0. Проект, как уже было сказано, имеет открытые спецификации, с которыми можно ознакомиться в соответствующем разделе сайта, посвящённого oneAPI; есть у новинки и свой репозиторий на GitHub. В состав oneAPI входят базовые библиотеки, компилятор DPC++ на базе LLVM/Clang, ряд библиотек производительности Intel, а также средства анализа и отладки кода.

Немаловажен и тот факт, что в состав проекта входит средство миграции кода, написанного на CUDA — таким образом, всё программное богатство, наработанное для ускорителей NVIDIA, может быть сделано доступным и для других платформ. Отдельно заслуживает упоминание богатство библиотек для создания приложений с использованием машинного обучения и аналитики: oneDNNL, one Video Processing Library и других. Опробовать oneAPI можно также в специальной облачной «песочнице», развёрнутой Intel специально для разработчиков, заинтересованных в новых методах разработки ПО.

Так как и сама платформа, и нижележащая инфраструктура LLVM открыты, расширить возможности oneAPI относительно просто, чем и занимается ряд организаций. Например, над совместимостью с NVIDIA работает Codeplay, центр URZ занят добавлением расширений DPC++ в проект hipSYCL, который работает с любыми CPU (OpenMP), GPU NVIDIA (CUDA) и AMD Radeon (HIPC/ROCm). А некоторые one-библиотеки от самой Intel уже имеют поддержку ARM и POWER. Для собственных FPGA у Intel тоже есть наработки, а вот Xilinx, похоже, пока остаётся за бортом. Последняя, впрочем, имеет своё видение процесса разработки.

Набор 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 уже движутся в этом направлении.

Без поддержки со стороны ПО и особенно средств для его разработки, толку от любого аппаратного обеспечения мало. Поэтому вендоры стараются заранее добавить поддержку новых платформ в популярные проекты. В первую очередь, в наборы компиляторов. Причём сделать это надо заранее, до выхода очередного мажорного релиза. Из патчей для них также можно почерпнуть информацию об особенностях ещё не вышедших платформ.

Конкретно с Sapphire Rapids подготовка к выходу выглядит несколько преждевременной, так как эти чипы появятся только в 2021 году или, если говорить точнее, до конца 2021 года. Мы уже знаем, что они получат поддержку PCIe 5.0 и DDR5, но гораздо интереснее то, какие инструкции они получат. Впрочем, тут пока ничего неожиданного нет — статус самого крупного и значимого нововведения после появления AVX-512 всё ещё числится за набором Intel AMX, который создан специально для матричных операций. Они расширят возможности работы с машинными обучением, дополнив поддержку bfloat16 и VNNI.

Фото: PCWatch Japan

Clang в LLVM получит поддержку AMX-TILE, AMX-INT8 и AMX-BF16 в дополнение к ранее объявленным в GCC инструкциям AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, AVX512VNNI, AVX512BF16 и AVX512VP2INTERSECT. Кроме того, есть ряд новых инструкция, связанных с TSX, работой с кешем/регистрами/буферами, энергосбережением и трассировкой в самом CPU. Это пока не полный список всех нововведений, но большая часть из них должна быть добавлена к финальным релизам: GCC 11 должен появиться в самом начале 2021 года, а выход LLVM 12 запланирован на февраль.

Microsoft является платиновым членом Linux Foundation, в её облаке Azure доминирует Linux и, в целом, уже пора перестать удивляться работе корпорации с этой ОС. Но она всё равно порой преподносит сюрпризы. На конференции Linux Plumbers Conference 2020 разработчики компании рассказали об экспериментах по оптимизации сборки ядра Linux.

Любопытно, что эта работа выполняется по внутреннему запросу, а оптимизация делается для повышения производительности Linux на ARM-процессорах Marvell ThunderX2. Это особенно интересно в свете резко изменившихся планов Marvel относительно будущих ThunderX3: компания займётся достаточно глубокой оптимизацией CPU под нужды конкретных заказчиков и не будет выпускать «общие» версии. Теперь она ориентирована в первую очередь на гиперскейлеров, к которым относится и Microsoft.

Так вот, разработчики Microsoft изучают использование LTO (Link Time Optimization) вместе с PGO (Profile-guided optimization) для ускорения работы ядра. Обе техники не являются чем-то новым сами по себе, однако LTO лишь относительно недавно стала применяться для сборки ядра Linux и других пакетов в некоторых дистрибутивах, что было связано с незрелостью её поддержки в популярных открытых наборах компиляторов GCC и LLVM. А вот применение PGO для ядра всё ещё довольно редко. Интересно, что Microsoft активно использует LTO и PGO в Windows — PGO даёт улучшение производительности на 5% – 20 %.

LTO позволяет компилятору перед компоновкой «окинуть взглядом» весь проект целиком, а не только отдельные объекты во время компиляции, и сделать оптимизацию. PGO же ещё подразумевает множественные тестовые запуски итоговых бинарных файлов и отслеживание их поведения с целью дальнейшей оптимизации на основе собранной статистики. Обе техники заметно повышают требования компиляторов к ресурсам (особенно памяти) и увеличивают время сборки, порой весьма существенно.

На той же конференции разработчики Google поделились своим опытом оптимизации сборки ядра. В частности, продукты под брендом Pixel с 2018 года получают ядра с LTO. А сейчас корпорация изучает работу AutoFDO — ещё одной техники, которая собирает данные о работе от perf-подсистемы ядра и аппаратных счётчиков CPU. Собранные профили «скармливаются» компилятору. Таким образом для x86-64 удалось на 12% сократить число используемых циклов CPU. На других платформах результат тоже положительный, но уже не такой заметный.