Что значит медленный код

Ремонт и техническое обслуживание автомобилей

Считывание кодов неисправностей

Бортовая система диагностики

Любая современная микропроцессорная система управления, установленная на борту автомобиля, обладает некоторыми диагностическими возможностями. Эти возможности реализуются бортовым компьютером в соответствии, с программой, заложенной в его постоянной памяти (ПЗУ), и во время, когда микропроцессор компьютера не полностью загружен выполнением основных управляющих функций (т. е. в так называемом фоновом режиме).

Во время обычной эксплуатации автомобиля бортовой компьютер периодически тестирует электрические и электронные системы и их компоненты. При обнаружении неисправности контроллер компьютера переходит в аварийный режим работы, подставляя подходящее значение параметра вместо того, которое дает неисправный блок.
Например, если контроллер обнаружит неисправность в цепи датчика температуры охлаждающей жидкости, программа установит резервное значение температуры, рассчитанное для работы двигателя в штатном режиме (обычно для 80 °С), и будет использовать это значение при реализации управляющих алгоритмов, чтобы автомобиль оставался на ходу. Резервное значение будет записано в память ЭБУ как аварийное.

Водитель информируется о неисправности с помощью контрольной лампы CHECK ENGINE (или светодиода), расположенной на панели приборов. Микропроцессор ЭБУ заносит специфический код неисправности в КАМ память.
КАМ (Кеер Аlive Меmогу) память способна сохранять информацию при отключении питания ЭБУ. Это обеспечивается подключением микросхем КАМ памяти отдельным кабелем к аккумуляторной батарее или применением малогабаритных подзаряжаемых аккумуляторов, размещенных на печатной плате ЭБУ.
Коды неисправностей иногда условно делят на медленные и быстрые.

Медленные коды

При обнаружении неисправности ее код заносится в память и включается лампа CHECK ENGINE на панели приборов. Выяснить, какой это код, можно одним из следующих способов в зависимости от конкретной реализации ЭБУ:

• светодиод на корпусе ЭБУ периодически вспыхивает и гаснет, передавая таким образом информацию о коде неисправности;
• соединить проводником определенные контакты диагностического разъема, и лампа CHECK ENGINE начнет периодически мерцать, передавая таким образом информацию о коде неисправности;
• подключить светодиод или аналоговый вольтметр к определенным контактам диагностического разъема и по вспышкам светодиода (или колебаниям стрелки вольтметра) получить информацию о коде неисправности.

Так как медленные коды предназначены для визуального считывания, частота их передачи очень низкая (около 1 Гц), объем передаваемой информации мал. Коды обычно выдаются в виде повторяющихся последовательностей вспышек. Код содержит две цифры, смысловое значение которых затем расшифровывается по таблице неисправностей, входящей в состав эксплуатационных документов автомобиля. Длинными вспышками (1,5 секунды) передается старшая (первая) цифра кода, короткими (0,5 секунды) – младшая (вторая). Между цифрами пауза несколько секунд.

Например, две длинные вспышки, затем пауза в несколько секунд, четыре коротких вспышки соответствуют коду неисправности 24. В таблице неисправностей указано, что код 24 соответствует неисправности датчика скорости автомобиля – короткое замыкание или обрыв в цепи датчика. После обнаружения неисправности ее необходимо локализовать, т. е. выяснить, что конкретно отказало: сам датчик, разъем, проводка, крепление и т. д.

Медленные коды просты, надежны, не требуют дорогостоящего диагностического оборудования, но мало информативны. На современных автомобилях такой способ диагностирования уже не используется. Хотя, например, на некоторых современных моделях Сhrysler с бортовой диагностической системой, соответствующей стандарту ОВD-II, можно считывать часть кодов ошибок с помощью мигающей лампочки.

Быстрые коды

изготовителе, он же применяется и при диагностике.
Наличие диагностического разъема позволяет, не нарушая целостности электропроводки автомобиля, получать диагностическую информацию от различных систем автомобиля (двигатель, АБС, трансмиссия, подвеска и т. д.) с помощью сканера или мотор-тестера.

Проверка на рациональность

Датчик может быть неисправен и посылать в компьютер неверную информацию. Если проверка на рациональность сигнала датчика, т. е. на соответствие требуемым (штатным) сигналам в программе микроконтроллера ЭБУ не предусмотрена, то в таких ЭБУ управляющие алгоритмы реализуются с использованием неверной информации датчика.
При этом неправильно рассчитываются угол опережения зажигания и длительность импульса отпирания форсунок, что приводит к ухудшению ездовых характеристик автомобиля, двигатель может глохнуть после запуска и т. д.

Но пока неверный сигнал с датчика будет в пределах нормы, никаких кодов ошибок в память ЭБУ не запишется, и аварийная ситуация никак не обозначится. Чтобы обнаружить неисправность, можно отключить подозрительный датчик. Тогда ЭБУ запишет в память код ошибки и сигнал с датчика изменится на расчетное (резервное) значение.
Например, при отключении датчика массового расхода воздуха ЭБУ заменит его сигнал резервным сигналом, рассчитанным по положению дроссельной заслонки и оборотам двигателя. Если после отключения подозрительного датчика работа двигателя улучшится – датчик не исправен.

В современных ЭБУ по мере совершенствования материальной базы и программного обеспечения появляется возможность выявлять неисправные датчики, выдающие неправильный сигнал, но в пределах нормы. Это так называемая проверка на рациональность и правильное функционирование, которая реализуется в бортовых диагностических системах второго поколения ОВD-II.
Она заключается в том, что текущие значения сигналов со всех датчиков постоянно проверяется на взаимно однозначное соответствие со штатными сигналами для данного режима работы двигателя. Штатные значения сигналов хранятся в постоянной памяти микропроцессора ЭБУ.

Источник

Медленный код — вообще не проблема, если ты знаешь как его ускорить. Главное красиво

Я много раз слышал, как программисты смеются над тиммейтами, которые написали медленный код. Резкие, самодовольные фразы в стиле «этот болван четыре раза пробежался по коллекции, хотя можно было один», и тому подобное. Когда слышишь такое, сразу думаешь — ну тут все по делу, зачем делать лишние итерации? Почему нельзя изучить пару элементарных вещей, вроде принципов работы LINQ выражений в C#, и писать нормальный код? Ты смеешься над некомпетентными тупицами до тех пор, пока смеяться не начнут над тобой. И можете мне поверить — никакие знания в программировании не спасут вас от ситуации, когда вы по незнанию зафигачили квадратичный алгоритм вместо линейного.

Я не знаю, смеялся ли кто-то над моим кодом, но я точно уверен — не раз и не два я писал решение, которое было в сто раз медленнее, чем могло бы быть. Но в этих случаях я сознательно писал неоптимально. Например в C# есть цикл for, и есть метод коллекции Select (в других япах он чаще называется map). Цикл быстрее, но я считаю функциональный подход более эстетичным — и использую его. Я знаю, что данных мало, тут не будет ботлнека, и пишу код, который по-моему красивей, читабельней и потому лучше. Таких решений при разработке очень много — и я выбираю писать производительный код только когда точно знаю, что иначе просадки станут проблемой.

Есть очень много разрабов, которые делают по-другому, и искренне считают, что такие как я — дерьмовые инженеры. У меня есть друг, опытный разраб высокого класса, который на днях выпнул человека с собеса, потому что тот предоставил медленное решение. Задача была — реализовать специфичный LINQ метод. В C# эти методы следует делать ленивыми — через итераторы и yield — а парень просто зафигачил новый список, и стал пихать в него значения, чем сломал ленивость. На больших срезах данных это может создать крупные — и главное неожиданные — просадки в производительности, достаточные, чтобы на доске завелся баг. По большому счету, тут дело даже не в снижении производительности, а в перемещении ботлнека в неожиданное место — не самая приятная хрень.

Я бы никогда не поставил крест на разработчике из-за такого, потому что сам не заморачиваюсь с yield, пока данных не становится по-настоящему много. С новым листом сделать интуитивно проще, принципы работы LINQ я хорошо понимаю. У меня нет задачи писать какой-то совершенный, абсолютно отказоустойчивый код заранее, и даже тогда, когда мне оптимизация ничего не стоит, я не всегда её применю. И я такой не один. В майкрософтской доке по LINQ пример добавления своего метода предложен именно с новым списком — потому что у создателя примера были дела поважнее, чем возиться с итераторами.

Мы позвали в подкаст Андрея Акиньшина — человека, который действительно разбирается в производительности. Создатель BenchmarkDotNet, автор книги Pro .NET Benchmarking, топовый докладчик на темы производительности, поведения рантайма и бенчмаркинга в дотнете, и просто очень, очень, очень крутой инженер. Мой друг, который прогнал человека с собеса — слепой котеночек в вопросах перформанса по сравнению с ним.

Знаете, что нам сказал Андрей? Что эстетика важнее производительности, пока у тебя нет ботлнеков.

Что если тебе больше нравится Select — ты пишешь Select. Потому что когда ты действительно узнаешь, сколько вещей у тебя работают неоптимально, ты перестаешь верить, что сможешь поправить их все, и начинаешь верить, что исправлять их надо только тогда, когда тебе это действительно нужно.

Есть много разрабов, которые с этим согласны. Они даже придумали термин «преждевременные оптимизации» — который как бы намекает, что этого делать не нужно. Ещё мы часто говорим «экономия на спичках». Так мы высмеиваем дурачков, которые тратят кучу времени и сил на то, чтобы сэкономить одну миллионную долю секунды.

И эти спичечники считают, что они крутые парни, а все остальные — вшивые говноделы. Мне есть что им сказать. Если ты взял for вместо select, хотя оба варианта нас устраивают по скорости, то почему ты тогда остановился на этом? Какой ещё C#, братан, C# — это медленно. Давай возьмем C++. А лучше ассемблер. Нет, стоп, ассемблер неоптимален — давай сразу фигачить машинные коды. Эстетика, поддерживаемость, читабельность — это же все х**ня собачья. Важно, чтобы все четыре элемента связного списка были выведены на экран наиболее быстрым способом.

Но машинные коды мы не хотим, потому что на них невозможно делать большие и сложные проекты. Мы хотим приятный, удобный и понятный C#. Его создатели разрулили сто тысяч трейдофов за нас. Мы получили дофига плюшек — надежность, поддерживаемость, инструменты для переиспользования кода — и заплатили за это производительностью. И наши приложения все ещё достаточно быстры, чтобы не думать об этом.

Хорошо, когда скорость и красивость не противоречат друг другу. Если по условиям задачи тебе больше подходит Queue, а не List — взять очередь будет и эстетичнее, и производительнее. Но люди, которым совершенно не интересно быстродействие, никогда об этом не узнают. Вы легко отличите их шарповый код — там везде будут листы.

Идея, что ты не должен оптимизировать свой код заранее понятна и справедлива. Но тут есть одна проблема. Иногда я пишу тормозной код не потому что все обдумал и принял решение — иногда я понятия не имею, как его ускорить. Одно дело, когда сознательно выбираешь эстетику вместо производительности, другое — когда ты ничего не выбираешь, потому что не умеешь делать производительно. Это очень, очень разные вещи.

Все эти понятия — “преждевременные оптимизации”, “экономия на спичках” — создают иллюзию, что оптимизации — штука неважная, и поэтому разрабы могут их не изучать. Такая иллюзия опасна, ведь изучать тонкости рантаймов, устройства ЯПов, алгоритмы и структуры данных — долго и сложно. И если ты выращиваешь поколение разработчиков, которые это не делали — ты получаешь отвратительную инженерную культуру, ужасные, супер медленные инструменты и приложения. И людей, которые в сто раз опаснее спичечников.

За примерами далеко ходить не надо — достаточно просто посмотреть на современных фронтендеров. Большая часть из них, когда увидят «производительность, C#, LINQ» захлопнут эту статью, и не дочитают до этого места. Так что теперь мы можем поговорить, что у них нет никакой инженерной культуры. Они делают самые тормозные вещи в мире — вроде всяких электронов — у них в языке из коробки всего два вида коллекций — они про другие и знать не знают. Их инструменты для билдов и управления пакетами работают так медленно, что после ввода «yarn start» можно смело идти смотреть сериал. Итоговые файлы, которые получаются после компиляции весят раз в сто больше, чем должны были. Создается эффект снежного кома. Как теперь не переучивай их, какую культуру не прививай — с большинством проблем фронтенд инфраструктуры особо ничего и не сделаешь — если только не переписать её с нуля.

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

Культура — это когда стремление знать не становится культом, а невозможность познания не ведет к отказу от изучения. Это всегда компромиссы, но осознанные.

Нет ничего страшного, что ты выбрал покрасивее, а не побыстрее. И нет трагедии, когда ты просто не знал, что твое решение — супер неоптимальное. Проблема начинается тогда, когда ты говоришь, что производительность — это чушь, и пусть этим занимаются отдельные люди. Нет братан. Изучать, как можно ускорить код — это не удел перформанс задротов, это часть нашей работы. Когда от твоего нежелания изучать сложные вещи твой код становится и медленным, и уродливым — вот тогда у тебя большие проблемы.

Источник

Почему большинство высокоуровневых языков медленно работают

Авторизуйтесь

Почему большинство высокоуровневых языков медленно работают

Последние пару месяцев мне часто задают этот вопрос, поэтому я решил ответить на него статьей.

Причин, по которым большинство высокоуровневых языков программирования медленно работают, обычно две:

• они плохо работают с кэшем;
• сборка мусора отнимает много ресурсов.

На самом деле, обе причины сводятся к одной — в таких языках происходит большое количество выделений памяти.

Следует уточнить, что я говорю в первую очередь о клиентских приложениях, где важна локальная скорость выполнения. Если приложение тратит 99,9% времени на ожидание ответа по сети, вряд ли важно, насколько медленным является язык, проблема оптимизации сетевого взаимодействия будет важнее.

ABBYY , Москва, можно удалённо , От 250 000 ₽

Я возьму в качестве примера C# по двум причинам: во-первых, это высокоуровневый язык, который я часто использую последнее время, и во-вторых, если бы я взял Java, фанаты C# могли бы возразить, что использование value-типов в C# избавляет от большинства проблем (это не так).

Кроме того, я буду исходить из предположения, что пишется идиоматичный код, в одном стиле со стандартными библиотеками и с учетом принятых соглашений. Я не буду рассматривать уродливые костыли в качестве «решения» проблемы. Да, в некоторых случаях это позволяет обойти особенности языка, но не устраняет изначальную проблему.

Работа с кэшем

Для начала, давайте посмотрим, почему важно правильно использовать кэш. Вот график задержек памяти в процессорах Haswell, основанный на этих данных.

Задержка при чтении из кучи составляет примерно 230 тактов, в то время, как чтение из L1 кэша — 4 такта. Получается, что неправильная работа с кэшем может сделать код почти в 50 раз медленнее. Более того, благодаря многозадачности современных процессоров, чтение из кэша может происходить одновременно с работой с регистрами, поэтому задержку при чтении из L1 можно вообще не учитывать.

Проще говоря, кроме разработки алгоритма, промахи кэша — основная проблема производительности. Как только вы решите проблему эффективного доступа к данным, останутся только небольшие оптимизации, которые, в сравнении с промахами кэша, не так сильно влияют на производительность.

Хорошие новости для разработчиков языка: вам нет необходимости разрабатывать самый эффективный компилятор и вы можете сэкономить свое время с помощью некоторых абстракций. Все, что вам нужно — организовать эффективный доступ к данным, и программы на вашем языке смогут посоревноваться в скорости исполнения с C.

Почему использование C# приводит к частым промахам кэша

Проще говоря, C# разработан так, что не учитывает современных реалий работы с кэшем. Ещё раз, я не говорю об ограничениях, накладываемых языком и «давлении», которое они оказывают на программиста, заставляя писать не самый эффективный код. Теоретически, для многих из этих вещей есть обходные пути, хотя и не самые удобные. Я говорю о том коде, к написанию которого нас побуждает язык как таковой.

Основная проблема C# в том, что он очень скудно поддерживает value-типы. Да, в нём есть структуры, которые представляют из себя значения, хранящиеся там же, где и объявлены (например, на стеке или внутри других объектов). Но есть несколько довольно серьезных проблем, из-за которых эти структуры являются скорее костылями, чем решениями.

• Вы обязаны объявлять типы данных заранее, что означает, если вам когда-либо нужно, чтобы объект этого типа существовал в куче, то все объекты этого типа всегда будут выделяться в куче. Конечно, вы можете написать классы-обёртки для нужных типов данных и использовать для каждого случая нужную обёртку, но это довольно болезненный путь. Было бы лучше, если классы и структуры всегда объявлялись одинаково, но использовать их было возможно по-разному и именно так, как нужно в данном конкретном случае. Т. е. когда вам нужно что-либо на стеке, вы объявляете это как значение, а когда в куче — как объект. Именно так работает С++, например. Там вас не заставляют делать всё объектами хотя бы потому, что есть некоторые вещи, которые должны быть в куче (по разным причинам).
• Возможности ссылок сильно ограничены. Вы можете передать что-либо по ссылке в функцию, но на этом всё. Нельзя просто так взять и получить ссылку на элемент в List , например. Для этого нужно хранить в списке и ссылки и значения одновременно. Нельзя получить указатель на что-либо выделенное на стеке или расположенное внутри объекта. Можно только скопировать всё, либо передать в функцию по ссылке. Причины такого поведения, конечно, вполне понятны. Если безопасность типов в приоритете, то довольно затруднительно (если не вообще невозможно) поддерживать гибкую систему ссылок и одновременно гарантировать такую безопасность. Но даже резонность таких ограничений не изменяет того факта, что эти ограничения всё таки есть.
• Буферы с фиксированным размером не поддерживают пользовательские типы и требуют директивы unsafe .
• Ограниченная функциональность подмассивов. Существует класс ArraySegment , однако он мало кем используется. Если вам надо передать набор элементов из массива, вам придется создавать IEnumerable , а значит выделять память. Даже если API поддерживает ArraySegment , этого все равно недостаточно: вы не сможете использовать его ни для List , ни для массива на стеке , только для обычного массива.

В итоге, язык всегда, кроме самых простых случаев, подталкивает в активному использованию кучи. Если все ваши данные в куче, вероятность промаха становится выше (поскольку вы не можете решать, как именно расположить данные). В то время как при написании программы на C++ программисту приходится думать, как эффективно обеспечить доступ в данным, C# поощряет их расположение в отдельных участках памяти. Программист теряет контроль над расположением данных, что влечет за собой ненужные промахи и, как следствие, падение производительности. Причем тот факт, что вы можете скомпилировать программу на C# в нативный код, не имеет значения. Рост производительности не скомпенсирует плохую локальность кэша.

Кроме того, неэффективно используется место. Каждая ссылка — это 8 байт на 64-битной машине, каждой аллокации сопутствуют метаданные. В куче, которая заполнена крошечными объектами со ссылками на них, остается намного меньше свободного места, чем если бы в них были расположены крупные объекты с содержимым внутри, расположенным на фиксированном смещении. Даже если вас не беспокоит впустую растраченное место, если куча переполнена заголовками и ссылками, весь этот мусор пойдет в кэш, что, опять же, приведет к большому количеству промахов и падению производительности.

Конечно, есть обходные пути. К примеру, вы можете использовать структуры и размещать их в пуле из List . Это позволит, например, обойти список и обновить все объекты на месте. К сожалению, теперь, чтобы получить ссылку на объект, вам надо получить ссылку на пул и индекс элемента, и в дальнейшем пользоваться индексацией по массиву. В отличие от C++, в С# такой трюк выглядит ужасно, язык просто не предназначен для этого. Более того, теперь доступ к одному элементу из пула дороже, чем при использовании просто ссылки — теперь может быть два промаха, поскольку надо будет разыменовывать сам пул. Вы можете, конечно, продублировать функционал List в структуре, чтобы избежать этого. Я написал много подобного кода за свою практику: он уродлив, работает на низком уровне и не застрахован от ошибок.

Наконец, я хочу отметить, что это проблема возникает не только в узких местах. В идиоматично написанном коде ссылочные типы будут повсюду. Это значит, что по всему коду постоянно будут происходить задержки в несколько сотен тактов, перекрывая все оптимизации. Если даже оптимизировать ресурсоемкие участки, ваш код будет равномерно медленным. Так что, если вы не хотите писать программы, используя пулы памяти и индексы, работая, возможно, на более низком уровне, чем C++ (зачем тогда использовать C#), вы вряд ли что-то можете сделать, чтобы избежать этой проблемы.

Сборка мусора

Я полагаю, что читатель понимает, почему сборка мусора сама по себе составляет серьезную проблему для производительности. Случайные зависания на время сборки совершенно недопустимы для программ с анимацией. Я не буду останавливаться на этом и перейду к тому, как дизайн самого языка может ухудшить ситуацию.

Из-за ограничений языка в работе с value-типами, разработчику зачастую приходится вместо одной большой структуры данных (которую даже можно положить на стек) использовать много маленьких объектов, которые размещаются в куче. При этом надо помнить, что чем больше объектов размещено в куче, тем больше работы для сборщика мусора.

Есть определенные тесты, в которых C# и Java превосходят C++ в производительности, поскольку выделение памяти в языке со сборкой мусора обходится заметно дешевле. Однако, на практике такое происходит редко. Написать программу на C# c таким же количеством выделений памяти, как в самой наивной реализации на C++, требует намного больше усилий. Мы сравниваем сильно оптимизированную программу на языке с автоматическим управлением памятью, с нативной программой, написанной «в лоб». Если мы потратим такое же количество времени на оптимизацию C++ кода, мы вновь оставим C# далеко позади.

Я знаю, что возможно написать сборщик мусора, обеспечивающий высокую производительность (например, инкрементальный, с фиксированным временем на сбор), но этого недостаточно. Самая большая проблема высокоуровневых языков — то, что они поощряют создание большого количества объектов. Если бы в идиоматичном C# было бы такое же количество выделений памяти, как и в программе на C, сборка мусора представляла бы гораздо меньшую проблему. И если бы вы использовали инкрементальный сборщик мусора, например, для систем мягкого реального времени, вам, скорее всего, понадобился бы барьер записи для него. Но насколько бы он дешево не обходился, в языке, который поощряет активное использование указателей, это означает дополнительную задержку при изменении полей.

Посмотрите на стандартную библиотеку .Net — выделения памяти на каждом шагу. По моим подсчетам .Net Core Framework содержит в 19 раз больше публичных классов, чем структур. Это значит, что при ее использовании вы столкнетесь с большим количеством аллокаций. Даже сами создатели языка не смогли сопротивляться соблазну! Я не знаю, как собрать статистику, но используя библиотеку базовых классов, вы точно заметите, что по всему коду происходит огромное количество выделений памяти. Весь код написан с учетом предположения, что это дешевая операция. Нельзя даже вывести int на экран без создания объекта! Представьте себе: даже используя StringBuilder вы не можете просто передать в него int без аллокации с помощью стандартной библиотеки. Это же глупо.

Это встречается не только в стандартной библиотеке. Даже в API Unity (игровой движок, для которого важна производительность) повсюду методы, которые возвращают ссылки на объекты или массивы ссылочных типов, или заставляют пользователя выделять память для вызова этих методов. К примеру, возвращая массив из GetComponents , разработчики выделяют память для массива только для того, чтобы посмотреть, какие компоненты есть в GameObject . Конечно, есть альтернативные API, однако если следовать стилю языка, лишних выделений памяти не избежать. Ребята из Unity пишут на «хорошем» C#, у которого ужасная производительность.

Заключение

Если вы разрабатываете новый язык, пожалуйcта, учитывайте производительность. Никакой «достаточно умный компилятор» не сможет обеспечить ее пост-фактум, если не заложить эту возможность изначально. Да, сложно обеспечить типобезопасность без сборщика мусора. Да, сложно собирать мусор, если данные представлены неоднородно. Да, сложно разрешать вопросы области видимости, если есть возможность получить указатель на любое место в памяти. Да, здесь много проблем. Но разработка нового языка — это решение именно этих вопросов. Зачем делать новый язык, если он мало отличается от тех, что были созданы в 60-ых?

Даже если вы не сможете решить все проблемы, можно постараться справиться с большинством из них. Можно использовать region types как в Rust для обеспечения безопасности. Можно отказаться от идеи «типобезопасности любой ценой», увеличив количество рантайм-проверок (если они не вызывают дополнительных промахов кэша). Ковариантные массивы в C# — как раз тот случай. По сути, это обход системы типов, который ведет к выбросу исключения во время выполнения.

Подводя итог, могу сказать, что если вы хотите разработать альтернативу C++ для высокопрозводительного кода, вам необходимо задуматься о расположении данных и их локальности.

Источник