Если вы занимаетесь системным программированием под Windows, то могли бы заметить, что весьма полезные функции Heap32First/Heap32Next и другие из того же семейства стали работать существенно медленнее начиная с Windows 7. Что же с ними случилось?

Давайте перенесёмся в далёкий 1992 год. Разрабатывается Windows 3.1. Одним из новых компонентов в ней стал ToolHelp. Он позволил немного покопаться во внутренностях ядра ОС. Для нас в нём наиболее интересны функции, позволяющие просматривать данные в куче (heap). Поскольку Windows 3.1 использовала кооперативную многозадачность, вызывая подобные функции можно было быть уверенным в том, что содержимое кучи не изменится между вызовами HeapFirst и HeapNext, ведь у ОС не было права прервать выполнение процесса и переключить контекс на выполнение другого. Вот были времена!

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

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

Что такое Изменение? У нашего продукта есть Платформа: базовое устройство, на которое «навешивается» сверху все требования покупателя и его инфраструктуры. Когда мы приходим к покупателю с ценой – она за Продукт. Продукт = Платформа + Специфика. Продукт – это то, что будет описано в Спецификациях и ТЗ. Но потом начинается работа по детальному проектированию и подготовке к производству. И вот тут начинаются Изменения. Изменения – это Дельта к Продукту. То есть Проданный_Продукт + Дельта = Произведенный_Продукт.

Перенос программного обеспечения с одной компьютерной архитектуры на другую в принципе, с некоторыми оговорками, дело относительно простое. Здесь на помощь приходят такие общеизвестные инструменты, как autoconf / automake/ libtool / gnulib. Собрать программу из исходников на каком нибудь Raspberry/ARM бывает так же просто, как и на ПК с Ubuntu/x86-64.

А вот как заставить проект ПЛИС разработанный для одной платы работать на другой плате? Там и сама ПЛИС может быть другой и на плате совершенно другие компоненты могут стоять. Простой перекомпиляцией проекта не обойтись.

Расскажу о своем опыте портирования проекта MIPSfpga для платы Марсоход3 с ПЛИС MAX10 Intel. Статьи о проекте MIPSfpga неоднократно появлялись на хабре. Они были так интересны, что мне захотелось и самому попробовать этот проект в имеющейся у меня плате. В своей работе я опирался на хабровские статьи

• Как начать работать с MIPSfpga
• MIPSfpga – практический опыт
• MIPSfpga и внутрисхемная отладка

И многие другие…

Итак, что нужно сделать, чтобы портировать проект ПЛИС на другую плату?

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

Привет, я Тони Альбрехт (Tony Albrecht), инженер в Riot. Мне нравится профилировать и оптимизировать. В этой статье я расскажу об основах профилирования, а также проанализирую пример С++-кода в ходе его профилирования на Windows-машине. Мы начнём с самого простого и будем постепенно углубляться в потроха центрального процессора. Когда нам встретятся возможности оптимизировать — мы внедрим изменения, а в следующей статье разберём реальные примеры из кодовой базы игры League of Legends. Поехали!

По роду своей деятельности (Windows Kernel) мне регулярно приходится разбирать дампы BSOD'ов. Не единичны случаи, когда у конечного пользователя успешно пишутся только Mini-дампы, в которых сохраняется только значение регистров процессора и стек падения. А другого средства отладки клиентской машины просто нет. Но что делать, если в стеке нет нашего драйвера, а заказчик настаивает, что падения начались после установки продукта и закончились после отключения драйвера этого продукта? В моем случае хорошим решением оказалось ведение небольшого журнала последних событий в циклическом буфере. Осталось только сохранить этот циклический буфер в дампе.

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

Введение

В последнее время довольно часто говорят о перспективах блокчейн систем, о том, что в будущем блокчейн заменит классические платёжные системы, такие как, например, Visa или Mastercard, а затем, возможно, коренным образом изменит и юриспруденцию благодаря возможностям «умных» контрактов. Но, несмотря на все ожидания, полноценной и всеобъемлющей платёжной системы на блокчейне пока не создано. Оплата реальных товаров и услуг криптовалютами, как правило, осуществляется в тех случаях, когда на использование классических способов оплаты наложены какие-то ограничения. При этом значительная часть сделок с использованием криптовалют несёт спекулятивный характер.

Факторов, сдерживающих развитие блокчейн систем, безусловно, много. Они могут иметь как техническую, так и экономическую, политическую или даже психологическую природу. В данной статье будут рассмотрены только некоторые технические ограничения двух наиболее популярных блокчейн систем — Bitcoin и Ethereum.

Гейзенбаг — это худшее, что может произойти. В описанном ниже исследовании, которое растянулось на 20 месяцев, мы уже дошли до того, что начали искать аппаратные проблемы, ошибки в компиляторах, линкерах и делать другие вещи, которые стоит делать в самую последнюю очередь. Обычно переводить стрелки подобным образом не нужно (баг скорее всего у вас в коде), но в данном случае нам наоборот — не хватило глобальности виденья проблемы. Да, мы действительно нашли баг в линкере, но кроме него мы ещё нашли и баг в ядре Windows.

В сентябре 2016 года мы стали замечать случайно происходящие ошибки при сборке Хрома — 3 билда из 200 провалились из-за крэша процесса protoc.exe. Это один из бинарников, который при сборке Хрома сначала собирается сам, а затем запускается для генерации заголовочных файлов других компонентов. Но вместо этого он падал с ошибкой «access violation».

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

Начнём с того, что компьютеры под управлением ОС Windows склонны со временем терять память. Ну, по крайней мере, у меня, при моём способе ими пользоваться. После пары недель без перезагрузок (или, например, всего одного уикэнда за который я 300 раз пересобрал Хром) я стал замечать, что диспетчер задач начинает показывать мне очень маленькое количество свободной оперативной памяти, но в то же время в системе нет никаких процессов, которые эту самую память активно используют. В том примере выше (с 300 сборками Хрома) диспетчер задач сказал мне, что в системе занято 49.8 ГБ плюс ещё 4.4 ГБ памяти сжато — но при этом запущено всего несколько процессов, и все они в сумме даже и близко не используют столько памяти:



В моём компьютере 96 ГБ оперативной памяти (да, я счастливчик) и когда у меня нет вообще никаких запущенных процессов — я, знаете ли, хотел бы видеть ну хотя бы половину этой памяти свободной. Я правда рассчитываю на это. Но иногда этого достичь не удаётся и мне приходится перезагружать ОС. Ядро Windows написано качественно и надёжно (без шуток), так что память не должна бы пропадать бесследно. Но всё же она пропадает.

Привет, Хабрахабр! В этой статье буду делиться собственным опытом отладки большой незнакомой системы, но со стороны собственно написанного инструмента — pdbe. Он поможет с самого начала проекта разобраться в потоке выполнения кода в проекте. Если вам интересно, что спрятано под капотом и какие фичи вы можете использовать — прошу под кат.

В компании Rollbar, которая занимается созданием инструментов для работы с ошибками в программах, решили проанализировать базу из более чем 1000 проектов на JavaScript и найти в них ошибки, которые встречаются чаще всего. В результате они сформировали список из 10 наиболее часто встречающихся ошибок, проанализировали причины их появления и рассказали о том, как их исправлять и избегать. Они полагают, что знакомство с этими ошибками поможет JS-разработчикам писать более качественный код.

Сегодня мы публикуем перевод их исследования.

В качестве антенны радиопередатчика используется шина между процессором и памятью

В информационной безопасности есть понятие «физической изоляции» (air gap), когда безопасная компьютерная сеть физически изолирована от небезопасных сетей: интернета и локальных сетей с низким уровнем безопасности. Это военные системы, командные центры, системы управления АЭС, медицинское оборудование и проч.

Но если кто-то инфицировал физически изолированный компьютер, а потом ему позарез нужно снять информацию — что делать? Здесь приходится выдумывать разные хитроумные и нестандартные способы. Например, превратить обычный ПК в генератор радиосигнала — и ловить этот сигнал радиоприёмником. Именно такую задачу выполняет утилита System Bus Radio, которая однажды упоминалась на GT. Хотя если честно, то вряд ли кто-то будет использовать её для шпионажа — это просто любопытная программка для развлечения. Она использует системную шину ПК или ноутбука как радиопередатчик для трансляции любых звуков на установленной радиочастоте.

За время, прошедшее с начала разработки, пользователи собрали обширную статистику, на радиоприёмниках какой модели и на какой частоте ловится сигнал. Кроме того, создан онлайновый модулятор, где вы можете сочинять музыку не выходя из браузера — и генерировать радиосигнал на частоте 1560 Гц нажатием одной кнопки Play Tune.

Добрый день, Хабрасообщество! Как и большинству айтишников, мне нравится создавать что-то новое, классное, нечто способное как-то повлиять на мир или хотя бы принести небольшую пользу другим людям. Надеюсь, что описываемый далее инструмент для тестирования онлайн систем с ВебСокетами как раз такая вещь.

В третьей статье мы продолжим разбирать условия. В прошлый раз мы так и не посмотрели оптимизированные версии if-else.

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

Эта статья является продолжением статьи из далекого 2014 года. Напомню, о чем шла речь в прошлой статье.

Какую задачу будем решать

Мы пишем ПО на языке С++, в среде Visual Studio 2015. У нас в проекте, естественно, есть пользовательские типы данных. В качестве примера таких типов могу привести класс MbSolid. Этот класс входит в состав математического ядра C3D и является абстракцией твердого тела. Тело описывается гранями, грани какими-то поверхностями и т.д. Т.е. структура класса довольно сложная, и в процессе отладки собственных алгоритмов хотелось бы визуально прикинуть, какое тело получилось на данный момент.

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



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

При создании PHP-приложения или библиотеки обычно у вас есть три вида зависимостей:

• Жёсткие зависимости: необходимые для запуска вашего приложения/библиотеки.
• Опциональные зависимости: например, PHP-библиотека может предоставлять мост для разных фреймворков.
• Зависимости, связанные с разработкой: инструменты отладки, фреймворки для тестов...

Как управлять этими зависимостями?

Я большой поклонник Prometheus и Grafana. Поработав SRE в Google, я научился ценить хороший мониторинг и за прошедший год предпочитал пользоваться комбинацией этих инструментов. Я использую их для мониторинга своих личных серверов (black-box и white-box мониторинг), внешних и внутренних событий Euskal Encounter, для мониторинга клиентских проектов и много другого. Prometheus позволяет очень просто писать кастомные модули экспорта для мониторинга моих собственных данных, к тому же вполне можно найти подходящий модуль прямо из коробки. Например, для создания симпатичной панели имеющихся метрик Encounter-событий мы используем sql_exporter.

Недавно в компании Reside Real Estate столкнулись с проблемами: в самые ответственные моменты начал падать Node.js-сервер. Подозрение пало на память. Сотрудники компании прибегли к временным мерам, что позволило избавить от неудобств пользователей, и занялись поисками источника проблем. В результате им удалось найти и устранить неполадки.

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