Эта статья входит в серию статей по улучшению производительности в .NET. Первую статью можно найти здесь.

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

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

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

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

Не знаю почему, но информации об этом новом класса в .NET Framework, действительно немного. Документация MSDN почти ничего не говорит о способах использования SynchronizationContext. Должен сказать, изначально я и сам плохо представлял назначение этого класса и как его использовать. После продолжительного изучения вопроса я наконец понял его назначение и решил написать эту статью чтобы помочь разобраться другим разработчикам.

UEFI – взгляд вперед (часть 1/3)

Не так давно приходилось разбираться с тем, что такое UEFI и с чем же его едят. Тема весьма актуальна, а статей на русском языке не очень много. Что же, постараюсь исправить ситуацию и поделиться информацией, кою удалось «нарыть». Для начала, вводная глава для ознакомления с тем, что же такое UEFI и зачем оно нужно.

UEFI (Unified Extensible Firmware Interface) является связующей оболочкой между операционной системой и аппаратной частью (железом). В будущем планируется, что UEFI полностью вытеснит BIOS (Basic Input Output System) и займет его место. UEFI является относительно старой технологией, разработанной в 2005 (Unified EFI Forum) году. Однако, сие высказывание некорректно относительно данной ситуации, так как несмотря на то, что 8 лет довольно большой срок для IT-технологии и в иных сферах за эти годы успевали сменить сразу по нескольку технологий, UEFI изначально развивался довольно медленно и лишь в последние годы стал получать все большую известность. Ниже вы можете ознакомиться с графиком релизов UEFI.



Первоочередной целью при создании UEFI была разработка удобной и многогранной оболочки для 64-х битных систем с более развитым пользовательским интерфейсом и сетевым контролем.
И так, какими же преимуществами обладает UEFI?

На этот раз нововведений гораздо меньше, чем в первой части. Все-таки С++14 считается незначительным релизом, нацеленным скорее на устранение недочетов С++11, чем привнесение новых возможностей.

Краткий перечень:

• Освобождение памяти определенного размера
• Одинарная кавычка, как цифровой разделитель
• Аттрибут [[deprecated]]
• Пользовательские литералы для std::complex
• Filesystem API
• Преобразование сетевого порядка байт

Обзор новых возможностей С++14: Часть 1
Текущий черновик стандарта

В апреле в Бристоле прошла встреча комитета С++, на которой были рассмотрены первые предложения по внесению изменений в новый стандарт С++14. Все рассматриваемые в этой статье изменения были одобрены на этой встрече и уже занимают свое почетное место в последней версии черновика нового стандарта (N3690 от 15 мая 2013).

Краткий перечень:

• Автоматическое определение типа возвращаемого значения для обычных функций
• Обобщенная инициализация захваченных переменных лямбд с поддержкой захвата-по-перемещению
• Обобщенные (полиморфные) лямбда-выражения
• Упрощенные ограничения на создание constexpr функций
• Шаблоны переменных
• exchange
• make_unique
• Обособленные строки
• Пользовательские литералы для типов стандартной библиотеки
• optional
• shared_mutex и shared_lock
• dynarray

Всемирная техподдержка

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

Конечно можно возразить, мол, что это за разделение такое, но такую вещь как национальный колорит отрицать ну никак нельзя, как и то, что он накладывает свой отпечаток на все сферы жизнедеятельности человечества.

Когда пользуешься сложными алгоритмами для решения задач компьютерного зрения — нужно знать основы. Незнание основ приводит к глупейшим ошибкам, к тому, что система выдаёт неверифицируемый результат. Используешь OpenCV, а потом гадаешь: «может, если сделать всё специально под мою задачу ручками было бы сильно лучше?». Зачастую заказчик ставит условие «сторонних библиотек использовать нельзя», или, когда работа идёт для какого-нибудь микроконтроллера, — всё нужно прогать с нуля. Вот тут и приходит облом: в обозримые сроки реально что-то сделать, только зная как работают основы. При этом чтения статей зачастую не хватает. Прочитать статью про распознавание номеров и попробовать самому такое сделать — огромная пропасть. Поэтому лично я стараюсь периодически писать какие-нибудь простенькие программки, включающие в себя максимум новых и неизвестных для меня алгоритмов + тренирующих старые воспоминания. Рассказ — про один из таких примеров, который я написал за пару вечеров. Как мне показалось, вполне симпатичный набор алгоритмов и методов, позволяющий достичь простенького оценочного результата, которого я ни разу не видел.



Сидя вечером и страдая от того, что нужно сделать что-то полезное, но не хочется, я наткнулся на очередную статью по нейросетям и загорелся. Нужно сделать наконец-таки свою нейросеть. Идея банальная: все любят нейросети, примеров с открытым кодом масса. Мне иногда приходилось пользоваться и LeNet и сетями из OpenCV. Но меня всегда настораживало, что их характеристики и механику я знаю только по бумажкам. А между знанием «нейросети обучаются методом обратного распространения» и пониманием того, как это сделать пролегает огромная пропасть. И тогда я решился. Пришло время, чтобы 1-2 вечера посидеть и сделать всё своими руками, разобраться и понять.

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

Одним из недешевых процессов с точки зрения производительности является boxing и unboxing. Напоминалку о том, что это такое, можно найти тут. Недавно я решил посмотреть весь IL код наших проектов и поискать инструкции box и unbox. Нашлось достаточно много участков, boxing'а в которых можно избежать легким движением руки. Все случаи, приводящие к ненужному boxing'у, очевидны, и допускаются по невнимательности в моменты концентрации на функциональности, а не на оптимизации. Я решил выписать наиболее часто встречающиеся случаи, чтобы не забывать о них, а затем автоматизировать их исправление. В данной статье и перечислены эти случаи.

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

Никого из нас не удивить банкоматом (АТМ). Даже люди старшего поколения мало-помалу привыкли к этому устройству и свою пенсию в состоянии как-то снять. Однако кроме всего прочего — банкомат – это крайне занятная штука с технической и организационной точки зрения. Даже сотрудники банковских учреждений (в т.ч. и связанных с платежными картами) не всегда представляют себе тонкости его работы. В прошлой жизни я достаточно много лет был связан с платежными картами и обслуживанием банкоматов. Мне доводилось и отогревать его феном и выковыривать оттуда по кусочкам мышь кровь кишки, застрявшую в обнимку с купюрами. Даже спалил один из подконтрольных банкоматов. Дважды. Поэтому поделюсь некоторыми, на мой взгляд, интересными техническими нюансами в работе АТМ.

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

Так как это моя первая статья на хабре, прошу прощения за, возможно, излишнюю сумбурность.

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

Если вы собираетесь написать n-ную платежную систему, рекомендую ознакомиться с типичными ошибками в реализации API, которые я собрал в процессе написания модулей для своего проекта.

Некоторое время назад на Хабре уже мелькали посты о работе банкоматов: один и два, но оба они описывали принципы работы банкоматов и вообще карточного процессинга весьма поверхностно.
Для интересующихся под катом много подробностей работы карточного процессинга банка (много букв).

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

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

В этом посте я поговорю о простом, но иногда полезном приеме программирования — method chaining. Также расскажу про потенциальный подводный камень, связанный с его использованием

Применительно к с++03 существует “правило трех”, с появлением с++11 оно трансформировалось в “правило 5ти”. И хотя эти правила по сути являются не более чем неформальными рекомендациями к проектированию собственных типов данных, но тем не менее часто бывают полезны. “Правило ноля” продолжает ряд этих рекомендаций. В этом посте я напомню о чем, собственно, первые 2 правила, а также попробую объяснить идею, стоящую за “правилом ноля”.

В этом посте я поговорю о шаблонах с переменным числом параметров. В качестве примера будет приведена простейшая реализация класса tuple. Также я расскажу о распаковке tuple'а и подстановки, хранимых там значений в качестве аргументов функции. И напоследок приведу пример использования вышеописанных техник для реализации отложенного выполнения функции, которое может быть использовано, например, в качестве аналога finally блоков в других языках.

"- После Мятежа Галактическое Содружество наложило строгие ограничения на метафункции высшего порядка. И не только из соображений этики; их власти опасаются вообще всякого проявления мании величия..."
(из поисковой выдачи google)

Предлагаю Вам сыграть в крестики-нолики с компилятором. Для игры знания c++ не потребуются, достаточно наличия cmake, python и собственно компилятора c++ ( потянет даже такой древний как gcc-3.3 ). Python используется только для ввода данных пользователя, запуска компилятора после каждого хода, и скомпилированной программы для получения результата. Все вычисления (следующий ход, определение победителя или констатации ничьей) производятся на этапе компиляции, в run-time только вывод результата.

Одна из новых возможностей C++11 — спецификатор constexpr. С помощью него можно создавать переменные, функции и даже объекты, которые будут рассчитаны на этапе компиляции. Это удобно, ведь раньше для таких целей приходилось использовать шаблоны. Но тут все не так просто. У тех, кто не так хорошо знаком с constexpr, может сложиться впечатление, что теперь не будет никаких проблем с расчетами на этапе компиляции. Но на constexpr-выражения наложены серьезные ограничения.

В первой части будет рассказано про constexpr, о том, какие будут изменения в стандарте C++14, а во второй части будет пример использования constexpr: библиотека, которая считает результат математического выражения в строке.
С помощью нее можно будет написать следующий код:

constexpr auto x = "(4^2-9)/8+2/3"_solve;
std::cout << "Answer is " << x;

И ответ в виде дроби будет получен на этапе компиляции:
Answer is 37/24
Сразу предупреждаю, код этой библиотеки сложно понять.
Кому эта тема интересна, добро пожаловать под кат!