Инлайнинг — одна из самых важных оптимизаций в компиляторах. Она не только убирает оверхед от вызова, но и открывает много возможностей для других оптимизаций, например, constant folding, dead code elimination и т.д. Более того, иногда инлайнинг приводит к уменьшению размера вызывающей ф-ции! Я опросил несколько человек на предмет знают ли они по каким правилам инлайнятся ф-ции в C# и большинство ответили, что JIT смотрит на размер IL кода и инлайнит только маленькие ф-ции размером, скажем, до 32 байт. Поэтому я решил написать этот пост, чтобы раскрыть детали реализации при помощи вот такого примера, который покажет сразу несколько эвристик в деле:
Рубрика «C#» - 28
Как JIT инлайнит наш C# код (эвристики)
2020-04-08 в 6:27, admin, рубрики: .net, .net core, C#, CoreCLR, inlining, jit, ryujit, Компиляторы, оптимизации, Программирование
.NET Core: интринсики x86_64 на виртуальных машинах
2020-04-03 в 9:01, admin, рубрики: .net, C#, intrinsics, netcore, qemu-kvm, x86_64, виртуализацияМы живём в эпоху доминирования архитектуры x86. Все x86-совместимые процессоры похожи, но и все при этом немного отличаются. И не только производителем, частотой и количеством ядер.
Архитектура x86 за время своего существования (и популярности) пережила много крупных апдейтов (например, расширение до 64 бит — x86_64) и добавлений «расширенных наборов инструкций». К этому приходится подстраиваться и компиляторам, которые по-умолчанию генерируют максимально общий для всех процессоров код. Но среди расширенных инструкций есть много интересного и полезного. Например, в шахматных программах часто используются инструкции для работы с битами: POPCNT, BSF/BSR (или более свежие аналоги TZCNT/LZCNT), PDEP, BSWAP и т.д.
В компиляторах C и C++ явный доступ к таким инструкциям реализован через «присущие (intrinsic) данному процессору функции». пример1 пример2
Для .NET и C# такого удобного доступа не существовало, поэтому когда-то давно я сделал свою обёртку, которая предоставляла эмуляцию таких функций, но если CPU их поддерживал, то заменяла их вызов прямо в вызывающем коде. Благо, большинство нужных мне интринсиков помещались в 5 байт опкода CALL. Подробности можно почитать на хабре по этой ссылке.
С тех пор прошло много лет, в .NET нормальных интринсиков так и не появилось. Но вышел .NET Core, в котором ситуацию исправили. Сначала появились векторные инструкции, в потом и почти весь* набор System.Runtime.Intrinsics.X86.
* — нет «устаревших» BSF и BSR
И всё вроде-бы стало хорошо и удобно. Если не считать того, что определение поддержки каждого набора инструкций всегда было запутанным (какие-то включаются сразу наборами, для каких-то есть отдельные флаги). Так .NET Core запутало нас ещё сильнее с тем, что между «разрешёнными» наборами есть ещё и какие-то зависимости.
Читать полностью »
ViennaNET: набор библиотек для backend’а
2020-03-31 в 12:28, admin, рубрики: .net, C#, open source, opensource, Блог компании Райффайзенбанк, микросервисыВсем привет!
Мы сообщество .NET-разработчиков Райффайзенбанка и мы хотим рассказать про набор инфраструктурных библиотек на .NET Core для быстрого создания микросервисов с единой экосистемой. Вывели его в Open Source!
Представляем .NET 5 Preview 1
2020-03-24 в 7:00, admin, рубрики: .net, .net 5, C#, microsoft, Блог компании Microsoft, ПрограммированиеВ конце прошлого года мы выпустили .NET Core 3.0 и 3.1. В этих версиях добавлены модели настольных приложений Windows Forms (WinForms) и WPF, ASP.NET Blazor для создания одностраничных приложений и gRPC для кроссплатформенного обмена сообщениями на основе контрактов. Мы также добавили шаблоны для создания сервисов, крутое генерирование клиентского кода для общения с gRPC, сервисы REST API и многое другое. Мы рады, что .NET Core 3 стала самой быстро-принятой версией .NET, и за последний год у нас появился еще миллион пользователей.
Мы также работали над этими выпусками, чтобы завершить перенос моделей приложений из .NET Framework. В .NET Core 3 мы перенесли все наиболее используемые модели приложений, а также представили новые кроссплатформенные инфраструктуры вместо тех, которые не были портированы.
В ожидании следующего основного выпуска .NET 5 мы продолжим объединять .NET в единую платформу, включив нашу модель приложения для мобильных устройств .NET (Xamarin) в .NET 5. .NET 5 будет включать ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin и ML.NET. Впервые вся платформа будет использовать унифицированный BCL (библиотеки базовых классов) для всех моделей приложений. Наличие версии 5, которая выше, чем у .NET Core и .NET Framework, также дает понять, что .NET 5 — это будущее .NET, единой унифицированной платформы для создания приложений любого типа.
Мы говорили это много раз, но мы еще раз повторим; .NET Core, а затем .NET 5 — это .NET, с помощью которого вам стоит создавать все свои новые приложения. .NET Framework будет поддерживаться до тех пор, пока поддерживается сама Windows. Мы будем продолжать обеспечивать безопасность и исправлять ошибки, а также обновлять сетевые и крипто API. Он будет оставаться безопасным и поддерживаться для работы ваших старых приложений на .NET Framework.
Оптимизации в JIT-компляторе для .NET 5
2020-03-23 в 9:26, admin, рубрики: .net, .net 5.0, C#, jit, ryujit, Компиляторы, оптимизацииНекоторое время назад я начал удивительное путешествие в мир JIT-компилятора с целью найти места, куда можно засунуть свои руки и что-нибудь ускорить, т.к. по ходу основной работы накопился небольшой багаж знаний в LLVM и его оптимизаций. В этой статье я хотел бы поделиться списком моих улучшений в JIT (в .NET он называется RyuJIT в честь какого-то дракона или аниме — я не разобрался), большая часть которых уже попала в master и будет доступна в .NET (Core) 5. Мои оптимизации затрагивают разные фазы JIT, которые очень схематично можно показать следующим образом:
Как видно из схемы, JIT — это отдельный модуль, связанный с рантаймом узким Jit-Interface, по которому JIT консультируется по некоторым вещам, например, можно ли скастить один класс к другому. Чем позже JIT компилирует метод в слой Tier1, тем больше информации может предоставить рантайм, например, что static readonly поля можно заменить константой, т.к. класс уже статически проинициализирован.
Читать полностью »
Ваш C# уже «функциональный», просто позвольте ему это
2020-03-21 в 20:58, admin, рубрики: C#, ооп, перевод, Программирование, функциональное программированиеПривет! Представляю вашему вниманию перевод оригинальной статьи «Your C# is already functional, but only if you let it» автора Igal Tabachnik.
Несколько дней назад я написал в Твиттере фрагмент кода C#, реализующий FizzBuzz, используя некоторые из новых «фичи» в C# 8.0 . Твит “стал вирусным”, несколько человек восхищались его лаконичностью и функциональностью, в то время как другие спрашивали меня, почему я не написал его на F#?
Прошло уже более 4 лет с тех пор, как я в последний раз писал на C#, и то, что я обычно использую функциональное программирование, явно повлияло на то, как я пишу код сегодня. Фрагмент, который я написал, кажется очень аккуратным и естественным, однако некоторые люди выразили опасения, что он не похож на код на C#.
«Он выглядит слишком функциональным.» – писали мне они.
В зависимости от того, кого вы спрашиваете, «функциональное программирование» означает разные вещи для разных людей. Но вместо того, чтобы обсуждать семантику, я хотел бы предложить объяснение того, почему эта реализация FizzBuzz кажется функциональной.
Читать полностью »
Организация кода в микросервисах и мой подход применения гексагональной архитектуры и DDD
2020-03-21 в 17:37, admin, рубрики: .net, C#, DDD, Microservices, микросервисы, Программирование, Проектирование и рефакторинг, Совершенный код
Привет! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 контроллерами и 1 — 10 действиями особо смысла городить слои абстракций нет. Для сложных микросервисов с различными состояниями и логикой перехода между ними наоборот лучше изначально не лениться. Я хочу рассказать о моем опыте организации кода и использования подходов DDD, Портов и Адаптеров для обоих случаев. Есть кратко суть статьи: Джун — пишет код в контроллере. Мидл — пишет кучу абстракций. Сеньор — знает когда нужно писать код в контроллере, а когда нужны абстракции.Читать полностью »
Краткий гайд по использованию GDB
2020-03-08 в 9:22, admin, рубрики: C#, c++, gdb, linux, python, python3, Разработка под Linux
В этом коротком туториале мы рассмотрим базовые приёмы работы с GDB, а также посмотрим как можно (и нужно) подготавливать файлы к отладке для GDB.
GDB — переносимый отладчик проекта GNU, который работает на многих UNIX-подобных системах и умеет производить отладку многих языков программирования, включая Си, C++, Free Pascal, FreeBASIC, Ada, Фортран, Python3, Swift, NASM и Rust.
Конвертация xls в xlsx и xml на C#
2020-03-07 в 23:47, admin, рубрики: .net, C#, c#.net, Excel, interop, npoi, office, xls, xlsx, Разработка для Office 365В этой статье я постараюсь рассказать об одном из возможных путей конвертации документов формата xls в xml.
Непосредственно моя задача выглядела примерно так:
Дано:
- 1-2 дня времени на поиск и реализацию решения
- Найденное решение должно быть на столько бесплатным, на сколько это возможно
- Известна примерная структура, размер и содержание файла, которые должны быть обработаны, что снимает необходимость читать графики, диаграммы и иные медианные из документа.
- Использовать Interop, равно как и иные библиотеки, которые требуют установки Office нельзя, так как это создает лишнюю нагрузку на сервер и требует дополнительной установки офисного пакета.Читать полностью »
Валидация ассетов в Unity3D
2020-03-06 в 8:46, admin, рубрики: C#, game development, Gamedev, unity, unity3d, ассеты, Блог компании Pixonic, валидация, геймдев, оптимизация кода, оптимизация рабочего времени, разработка игр, сериализация
Начнём с того, что я обожаю сериализацию в Unity. Она надёжна и очень проста в использовании. Я просто расширяю MonoBehaviour, ScriptableObject и подобные классы и настраиваю сериализуемые поля экземпляров в инспекторе.
Но у неё есть и слабости. Одна из них ― человеческий фактор. Представьте себе огромный проект, который живёт несколько лет и над которым работает около сотни человек. И любой из них может совершить ошибку: оставить пустую ссылку на объект, указать число вне диапазона, ввести строку в неверном формате, заполнить массив слишком маленьким или, наоборот, слишком большим количеством объектов. Уверен, у каждого из вас найдутся такие примеры из своего опыта. Причин и оправданий тоже множество: невнимательность, неожиданные последствия слияния веток, сбои редактора… И никто от этого не застрахован.
Такие ошибки до поры до времени остаются незаметными: компилятору до них нет дела, в отличие от опечаток в коде. Особенно неприятны они тем, что проявляются часто уже во время выполнения кода. Только тогда вы начинаете читать журнал сообщений и идёте проверять данные: тыкать их в редакторе или листать YAML. Но объектов может быть достаточно много, есть риск что-то пропустить или попросту залениться.
Конечно, можно добавить проверок в коде, но от этого он загрязнится. Иногда эти проверки негативно влияют на производительность. А ещё не всегда однозначно понятно, как именно обработать каждую конкретную ошибку.
Универсального или даже штатного метода бороться с подобным в Unity нет. Поэтому мы в Pixonic реализовали свою систему валидации ассетов. И это очень помогает нам жить.
Сейчас я опишу, как там всё устроено.
Читать полностью »