Прошло более двух лет с момента последней проверки кода проекта LLVM с помощью нашего анализатора PVS-Studio. Давайте убедимся, что анализатор PVS-Studio по-прежнему является лидирующим инструментом по выявлению ошибок и потенциальных уязвимостей. Для этого проверим и найдём новые ошибки в релизе LLVM 8.0.0.
Читать полностью »
It's been two years since we last checked the code of the LLVM project with PVS-Studio, so let's see if PVS-Studio is still the leader among tools for detecting bugs and security weaknesses. We'll do that by scanning the LLVM 8.0.0 release for new bugs.
Читать полностью »
Это последняя часть моего обзора компилятора Swift. Я покажу, как можно осуществить генерацию LLVM IR из AST и что выдаёт настоящий фронтенд. Если вы не читали предыдущие части, то переходите по ссылкам:
На одном личном проекте на C++ мне потребовалось получать информацию о типах объектов во время выполнения приложения. В C++ есть встроенный механизм Run-Time Type Information (RTTI), и конечно же первая мысль была использовать именно его, но я решил написать свою реализацию, потому что не хотел тянуть весь встроенный механизм, ведь мне нужна была лишь малая часть его функционала. А еще хотелось попробовать на практике новые возможности C++ 17, с которыми я был не особо знаком.
В этом посте представлю пример работы с парсером libclang на языке Python.
От переводчика: этот пост был опубликован в блоге автора 15 марта 2018 года. Так как язык развивается, в настоящее время его синтаксис может отличаться. Всё описанное относится к Zig 0.2.0, текущая версия языка — Zig 0.3.0.
Я связался с автором поста, и он любезно предоставил ссылку на репозиторий с актуальной версией исходников проекта на Zig 0.3.0: https://github.com/jfo/zigf/commit/7b1c563a9bd20e084243bfa0c7435e3cb468ccf2
Здравствуйте! Давайте напишем интерпретатор Brainfuck! «Зачем?» — можете спросить вы, но вы не найдёте здесь ответа.
Я сделаю это на Zig.
…новый язык программирования. Он пока в бета-версии, и быстро развивается. Если вы видели код на Zig раньше, код в этом посте может показаться вам немного другим. Он действительно другой! Zig 0.2.0 только что вышел, совпав с релизом LLVM 6 несколько недель назад, и включает в себя множество изменений синтаксиса и общие усовершенствования языка. Главным образом, многие «заклинания» были заменены ключевыми словами. Смотрите здесь для более глубокого объяснения всех изменений!
Zig разработан, чтобы быть читаемым, и относительно интуитивным для тех, кто знаком с компилируемыми и типизированными языками, такими, как C, C++, и, в некоторых моментах, Rust.
Код был скомпилирован и протестирован с Zig 0.2.0, который доступен прямо сейчас, по различным каналам, включая homebrew, если вы на OSX: brew install zig.
Читать полностью »
Итак, пришло время поговорить о следующем поколении мультиклеточных процессоров: MultiClet S1. Если вы впервые слышите о них, то обязательно ознакомьтесь с историей и идеологией архитектуры в этих статьях:
На данный момент новый процессор находится в разработке, но уже появились первые результаты и можно оценить, на что он будет способен.
Читать полностью »
Я планировал написать статью о том, как LLVM оптимизирует функцию, но сначала необходимо написать, как Clang транслирует C или C++ в LLVM.
От переводчика: GraalVM — новая, интересная технология, но на Хабре по ней не так много статей, которые бы могли показать примеры возможностей Graal. Статья ниже — это не просто перечисление того, что GraalVM умеет, но ещё и небольшой мастер-класс, аналогичный тому, который Chris Seaton и Олег Шелаев проводили на Oracle CodeOne 2018. Вслед за автором, призываю — пробуйте делать примеры из статьи, это действительно интересно.
В GraalVM много всего разного, и, если вы слышали это название раньше, или даже видели доклады, то все равно есть много вещей, о которых вы наверняка ещё не знаете, но которые GraalVM может делать. В этой статье мы рассмотрим разнообразные возможности, которые предоставляет GraalVM и покажем, что с их помощью можно сделать.
Моя первая попытка написать проход LLVM — люблю эти сегфолты
Недавно я столкнулся с интересной задачей — мне понадобился детерминированный и кросплатформенный способ определения времени выполнения кода С++. Под словом «детерминированный» я подразумеваю, что один и тот же код будет выполняться за одно и то же количество единиц времени. Под кроссплатформенностью я понимаю, что один и тот же код под Windows и под Ubuntu будет выполняться за одно и то же количество единиц времени.
Естественно, измерение времени на CPU не удовлетворяет этим условиям. Машинный код меняется в зависимости от архитектуры и операционной системы, и один и тот же код займёт различное количество времени при выполнении. Даже на одной и той же машине, такие факторы, как промахи кэша, будут играть большую роль — достаточную для того, чтобы исказить результаты измерения времени выполнения одного и того же кода. Мне нужно было что-либо более умное…
Читать полностью »
Мой друг Aras недавно написал один и тот же трассировщик лучей на разных языках, в том числе на C++, C# и компиляторе Unity Burst. Разумеется, естественно ожидать, что C# будет медленнее, чем C++, но мне показалось интересным, что Mono настолько медленнее .NET Core.
Опубликованные им показатели были плохими:
Я решил посмотреть, что происходит, и задокументировать места, которые можно улучшить.
В результате этого бенчмарка и изучения этой проблемы мы обнаружили три области, в которых возможно улучшение:
Опорной точкой этого теста были результаты прогона трассировщика лучей на моей машине, а поскольку железо у меня другое, сравнивать числа мы не можем.
Результаты на моём домашнем iMac для Mono и .NET Core были следующими:
| Рабочая среда | Результаты, MRay/sec |
|---|---|
.NET Core 2.1.4, отладочная сборка dotnet run |
3.6 |
.NET Core 2.1.4, релизная сборка dotnet run -c Release |
21.7 |
Ванильный Mono, mono Maths.exe |
6.6 |
| Ванильный Mono с LLVM и float32 | 15.5 |
