Огромные возможности нейросетей иногда сравнимы с их непредсказуемостью. Теперь математики начинают понимать, как форма нейросети влияет на её работу

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

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

When you run queries in ClickHouse, you might notice that the profiler often shows the LZ_decompress_fast function near the top. What is going on? This question had us wondering how to choose the best compression algorithm.

ClickHouse stores data in compressed form. When running queries, ClickHouse tries to do as little as possible, in order to conserve CPU resources. In many cases, all the potentially time-consuming computations are already well optimized, plus the user wrote a well thought-out query. Then all that's left to do is to perform decompression.



So why does LZ4 decompression becomes a bottleneck? LZ4 seems like an extremely light algorithm: the data decompression rate is usually from 1 to 3 GB/s per processor core, depending on the data. This is much faster than the typical disk subsystem. Moreover, we use all available CPU cores, and decompression scales linearly across all physical cores.

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Иногда полезно представить граф в графической форме, так чтобы была видна структура. Можно привести десятки примеров, где это может пригодиться: визуализация иерархии классов и пакетов исходного кода какой-нибудь программы, визуализация социального графа (тот же Twitter или Facebook) или графа цитирования (какие публикации на кого ссылаются) и т.д. Но вот незадача: количество ребер в графе зачастую настолько велико, что нарисованный граф просто невозможно разобрать. Взгляните на эту картинку:



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

Перед тем, как рассказать о нашем проекте, я хочу рассказать Вам, кто такой я, Грант Джордан, и кто такой Кайл Вогт (Kyle Vogt), который работает на Justin.tv. Мы студенты Массачусетского Технологического института, у которых много свободного времени. И у нас есть множество интересных проектов, как например, устройство для взлома сейфов, которое позволяет открывать сейфы с наивысшей степенью защиты. Однако понять, почему мы занялись именно спамом, поможет ответ на вопрос: кем мы не являемся?

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

Каждый раз, открывая Вашу почту, Вы находите там спам. Это советы, как увеличить размер пениса, или письма от «плохих» девочек из России, или уведомление, в котором бывший принц Нигерии сообщает, что сделал Вас наследником своих миллионов. Однако один вид спама привлекал внимание больше других – это был спам о фондовом рынке. Это были странные «подсказки», призывающие купить определённые акции, курс которых вот-вот подскочит «выше крыши». Как и большинство людей, я удалял этот спам, но однажды Кайл родил одну из самых глупых идей, которые я когда-либо встречал: «Должен же быть способ, который поможет нам отобрать часть денег этих самых спамеров»!

Недавно я увлёкся программированием FPGA и решил, что будет интересно реализовать на FPGA алгоритм игры FizzBuzz. FPGA (программируемая пользователем вентильная матрица) — интересная микросхема. Она программируется на выполнение произвольной цифровой логики. Можно сконструировать сложную схему, не прокладывая физические каналы между отдельными вентилями и триггерами. Микросхема способна превратиться во что угодно, от логического анализатора до микропроцессора и видеогенератора.

Тест FizzBuzz — написать программку, которая выдаёт числа от 1 до 100, где кратные трём заменяются словом “Fizz”, кратные пяти — словом “Buzz”, а кратные пятнадцати — “FizzBuzz”. Поскольку такая программа реализуется в нескольких строчках кода, то её часто задают на собеседованиях чтобы отсеять тех, кто вообще не умеет программировать.


Плата Mojo FPGA, подключенная к порту serial-to-USB. Большой чип на плате — это Spartan 6 FPGA

Реализация FizzBuzz в цифровой логике, а не в коде, довольно бессмысленна, но показалась мне хорошим примером для обучения.¹ Для этого проекта я использовал простую плату разработки Mojo V3 FPGA для начинающих. На ней установлен FPGA семейства Xilinx Spartan 6. Это один из самых маленьких FPGA, но у него 9000 логических ячеек и 11 000 триггеров — так что малыш на многое способен.

Я написал программу для очистки отсканированных конспектов с одновременным уменьшением размера файла.

Исходное изображение и результат:


Слева: исходный скан на 300 DPI, 7,2 МБ PNG / 790 КБ JPG. Справа: результат с тем же разрешением, 121 КБ PNG ^[1]

Примечание: описанный здесь процесс более-менее совпадает с работой приложения Office Lens. Есть другие аналогичные программы. Я не утверждаю, что придумал нечто радикальное новое — это просто моя реализация полезного инструмента.

Если торопитесь, просто посмотрите репозиторий GitHub или перейдите в раздел результатов, где можно поиграться с интерактивными 3D-диаграммами цветовых кластеров.

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

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

На всякий случай, а то вдруг санкции применят (смаил). Описываемый случай не имеет никакого отношения к реальности и является целиком и полностью выдумкой автора

Раньше было про потоки, семафоры, очереди и HAL

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



Вооружившись осциллографом, я полез внутрь.

HAL 9000: I'm completely operational, and all my circuits are functioning perfectly.

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

Раньше было про потоки, про семафоры и очереди

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

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

Но не так давно ST поняла, в какую яму она угодила и начала усиленно из нее выбираться, привлекая новые силы. И именно благодаря этому сейчас время старта сократилось до несуразно маленьких величин. Как это выглядит на практике? Добро пожаловать под кат.

Раньше: про потоки и про семафоры

«Вас много, а я одна!» — классическая фраза продавщицы, которую затерроризировали покупатели с вопросами «А есть ...?». Вот и в микроконтроллерах случаются полностью аналогичные ситуации, когда несколько потоков требуют внимания от какой-либо медленной штуки, которая просто физически не способна обслужить всех разом.

Возьмем наиболее яркий и богатый проблемами пример, на котором «валятся» большинство неопытных программистов. Есть мощный и достаточно быстрый микроконтроллер. К нему подключен с одной стороны адаптер com-порта, через который пользователь подает команды и получает результаты, а с другой — шаговый двигатель, который согласно этим командам поворачивается на какой-то угол. И конечно же, прикольная кнопочка, которая тоже что-то этакое значит для пользователя. Где можно наловить проблем?

Часть первая, про потоки

В реальной жизни часто случается так, что некоторые события происходят с разной переодичностью (а могут и вообще не происходить). Скажем, заказ сока в «Макдональдсе», нажатие кнопки пользователем или заказ лыж в прокате. А наш могучий микроконтроллер должен все это обрабатывать. Но как это сделать наиболее удобно?

Данный цикл из 5 статей рассчитан на тех, кому стало мало возможностей привычных «тинек» и ардуинок, но все попытки перейти на более мощные контроллеры оканчивались неудачей или не приносили столько удовольствия, сколько могли бы. Все ниженаписанное проговаривалось мной много раз на «ликбезе» программистов нашей студии (которые часто сознавались, что переход с «тинек» на «стмки» открывает столько возможностей, что попадаешь в ступор, не зная за что хвататься), поэтому смею надеяться, что польза будет всем. При прочтении подразумевается, что читающий — человек любопытный и сам смог найти и поставить Keil, STM32Cube и понажимать кнопки «ОК». Для практики я использую оценочную плату STM32F3DISCOVERY, ибо она дешевая, на ней стоит мощный процессор и есть куча светодиодиков.

Каждая статья рассчитана на «повторение» и «осмысление» где-то на один околовечерний час, ибо дом, семья или отдых…

TCP-стеганография не является чем-то принципиально новым, например Джон Торакис в 2016 году реализовывал на Питоне довольно интересные вещи, жаль не все они есть в открытом доступе. Не была она принципиально новой и на момент написания статей Торакисом. Вот пост на Хабре 2009 года, описывающий идею и, например, программа Covert_TCP далекого (а может и не очень) 1996 года, написанная на чистом Си и реализующая довольно тонкие настройки.

Если Covert TCP предлагает передавать по одному байту полезной нагрузки в TCP пакете, Торакис использовал от 2 до 6 байт на пакет и предложил идею создания протокола в протоколе. Но даже таким образом затруднительно передать большие массивы данных.

Тут на помощь может прийти система одноразовых сообщений. Действительно, почему бы не объединить 2 подхода, раз они изобретены до нас?

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

Популярный сайт околоатомных новостей World Nuclear News пишет про запуск (первую плазму) токамака ST40, принадлежащего частной английской компании Tokamak Energy. Новость довольно интересная, особенно если знать контекст, который я попробую и изложить.


Основатель Tokamak Energy Alan Sykes возле разреза ST-40 в масштабе 1 к 1.

Tokamak Energy (TE) основана в 2009 году (по соседству с крупнейшим в мире на сегодня токамаком JET), и с 2012 получило финансирование (на сегодня стартап собрал 35 миллионов долларов) на строительство серии токамаков, ведущих к энергетическому реактору. На фоне ИТЭР стоимостью 20+ миллиардов долларов, не ведущим к энергетическому реактору, смотрится странно? Давайте разбираться.

Всем привет!
Хочу начать вольный перевод замечательной книги «Learning Three.js- The JavaScript 3D Library for WebGL». Я уверен, что эта книга будет интересна не только новичкам, но и профессионалам своего дела. Ну не буду долго затягивать вступление, только приведу пример того, что мы совсем скоро сможем делать:

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

При изучении любого незнакомого дела, особенно когда речь идет о микроконтроллерах, возникает вопрос — «С чего начать». Ведутся поиски статей по ключевым словам «Getting Started», неизбежно появляется дилема выбора среды разработки и программатора-отладчика. Чтобы помочь вам определиться с ответами на возникшие вопросы, я поделюсь своим опытом в освоении 32-битных контроллеров семейства STM32F от ST Microelectronics.

Выбор контроллера

Вариантов по сути дела было два — STM32F или NXP (LPC1xxx). На микроконтроллеры STM32F мой выбор пал по нескольким причинам.