День добрый! В прошлой статье я описывал, как «поднять» с нуля SoC от Altera.
Мы остановились на том, что измерили пропускную способность между CPU и FPGA, когда копирование выполняется процессором.

В этом раз мы пойдем немного дальше и реализуем примитивный DMA в FPGA.
Кому интересно — добро пожаловать под кат.

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


Рис 1. Кремниевая пластина процессоров R1

Если сравнивать человека с компьютером, то его тело – это hardware, а то, что вдыхает в него жизнь – software. И сегодня речь пойдёт о человеческом software – его геноме.

Моя Анаконда

Это моя третья попытка написать обзор E:D. Одно дело – поиграть несколько часов, почитать мнения на форумах и написать обзор. Но я следил за игрой с июня 2014 года, и она постоянно менялась – что-то добавлялось, что-то исчезало. Поэтому я пытаюсь описать не несколько часов, а несколько месяцев игры, которые я провёл, бороздя тёмные моря космоса.

Сказать по правде, E:D была выпущена незаконченной, и она не закончена до сих пор. Судя по всему, выход версии 1.0 16 декабря был сделан только для того, чтобы сдержать обещание «выйти до конца 2014 года». Но много деталей игровой механики, например симуляция развития экономики и политики без участия игрока, не работали или просто отсутствовали. В игре было много плохо оттестированных или незамеченных возможностей для нечестной игры. p2p-архитектура была очень нестабильной и небезопасной. До недавнего времени в мультиплеере единственной возможностью общения с игроком было взорвать его корабль.

И несмотря на всё это, и на то, что даже после двух больших патчей от всех багов игра не избавилась, E:D настолько хороша, что проблемы уходят на второй план. Когда я надеваю Oculus Rift DK2 и оглядываюсь в рубке – я управляю своим собственным космическим кораблём.

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

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

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

Квантовые частицы могут быть соединены через червоточины пространства-времени

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

Описание новой идеи, ER = EPR – будто инициалы, вырезанные на дереве. Это объединение двух идей, предложенных Эйнштейном в 1935 году. Одна – парадокс Эйнштейна-Подольского-Розена (EPR), «пугающее дальнодействие» между двумя элементарными частицами (spooky action at a distance). Вторая – связь двух чёрных дыр через червоточины (мост Эйнштейна-Розена, ER). Во время рождения этих идей между ними не просматривалось никакой связи.

Сегодня, как и обещала, я продолжу тему планирования легких сущностей, которую уже начала в своем цикле статей. В нем я рассказала о внутреннем устройстве tasklet, workqueue и protothread. Конечно, тема не ограничивается лишь этими примерами: есть еще FreeRTOS с ее coroutine, или GNU Portable threads; или можно отойти от структур и библиотек, применяющихся в ОС, и вспомнить различные green threads, которых становится все больше и больше.

На этот раз я хочу поделиться тем, как мы реализовали легкие потоки в проекте Embox. С одной стороны мы постарались учесть опыт предыдущих разработок, с другой — привнести что-то новое.

Детальный взгляд на логирование переключение контекста с помощью Event Tracing API для Windows.

В ответ на пост прошлой недели, я получил следущее электронное письмо:

Может быть, я немножко опоздал с вопросом по поводу Вашего недавнего поста, но, на всякий случай, спрошу: Вы имеете какие-либо методы (стратегии) работы с внешней библиотекой, от которой Вы не можете избавиться, и которая нарушает некоторые (или все) принципы написания дизайна API (скорее всего, имеются в виду принципы, рекомендации, которые описаны в предыдущей статье автора. Прим. перев.)? Может, есть какие-то истории? Это расплывчатый вопрос, но я просто спрашиваю о любом опыте (как пользователя) использования API, который действительно запомнился.

— Michael Bartnett

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

Наверное, это была бы неплохая статья в цикле еженедельного разбора плохих API. Но, поскольку у меня нет времени на что-то подобное и есть возможность разобрать только один API, то возникает наиболее ВАЖНЫЙ вопрос — какой именно API я должен выбрать?

Event Tracing API для Windows

Привет, Хабр!

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

Часто первое знакомство с линейной алгеброй выглядит как-то так:



Не очень вдохновляет, правда? Сразу возникает два вопроса: откуда это все взялось и зачем оно нужно.

Начнем с практики

Когда я занимался вычислительной гидродинамикой (CFD), один из коллег говорил: «Мы не решаем уравнения Навье-Стокса. Мы обращаем матрицы.» И действительно, линейная алгебра — «рабочая лошадка» вычислительной математики:

Rust начинался как проект, решающий две трудные проблемы:

• Как обеспечить безопасность (работы с памятью) в системном программировании?
• Как сделать многопоточное программирование безболезненным?

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

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

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

С точки зрения многопоточности это означает, что вы можете пользоваться различными парадигмами (передача сообщений, разделяемое состояние, lock-free-структуры данных, чистое функциональное программирование), и Rust позволит избежать наиболее распространённых подводных камней.

Вот какие особенности у многопоточного программирования в Rust:

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

По роду своей деятельности мне приходится осуществлять контроль различных параметров наземных импульсно-фазовых радионавигационных систем (ИФРНС) «Чайка» и Loran-C. В этой статье я хочу поделиться одним из методов обнаружения времени прихода импульса ИФРНС при наличии шумов. Метод применим во многих задачах поиска сигнала известной формы.

1. Введение

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

Для прочтения и осознания информации из статей вам понадобятся следующие навыки:

• Основы разработки ПО для Windows (достаточно умения программировать в любой визуальной среде, такой как Delphi или Visual Basic)
• Базовые знания из области криптографии (что такое шифр, симметричный, ассиметричный алгоритм, вектор инициализации, CBC и т.д. Рекомендую к обязательному прочтению Прикладную Криптографию Брюса Шнайера).
• Базовые навыки программирования на любом языке, хотя бы отдаленно напоминающем Java по синтаксису (Java, C++, C#, PHP и т.д.)

Цель цикла — познакомить читателя с Ява-картами (литературы на русском языке по их использованию крайне мало). Цикл не претендует на статус «Руководства по разработке защиты ПО на основе Ява-карт» или на звание «Справочника по Ява-картам».

Состав цикла:

• Глава 1. Ява-карта. Общие-сведения.
• Глава 2. Ява карта с точки зрения разработчика апплетов
• Глава 3. Установка и настройка IDE
• Глава 4. Пишем первый апплет
• Глава 5. Безопасность

В течение десяти с небольшим лет своего существования ReSharper был ориентирован на .NET-разработчиков, что не удивительно для плагина к Visual Studio. 2 года назад, в чем-то благодаря удачной первоапрельской шутке, мы вплотную занялись поддержкой С++ в ReSharper, и вот совсем недавно был выпущен первый официальный релиз ReSharper C++ — нового продукта специально для разработчиков на C/С++ в Visual Studio. (Тем, кто заждался релиза CLion для кросс-платформенной разработки на C/C++, понадобится еще немного терпения.)

Чем же может быть полезен ReSharper C++? Разберем основные возможности продукта.

Сейчас в это трудно поверить, но еще каких-то два десятка лет назад — считалось большой удачей, если «по межгороду» удавалось дозвониться с первого раза. Широкополосный доступ? Беспроводной интернет? Телефон-коммуникатор в кармане у каждого? Это ведь откуда-то из «миров Полдня» Стругацких, я угадал?


Самая первая антенна, установлена на крыше ангара Всероссийского Энергетического Института. В котором я еще застал стоящий там самолет Миг-21 и экспериментальные стенды, имитирующие разряды молний.

И вот в 1995 году никому не известная компания SFMT Ltd (впоследствии выросшая в «Голден Телеком») начала строительство «наложенной» (т.е. работающей параллельно с национальной общероссийской) сети связи. А в качестве основного транспорта — было решено использовать собственные спутниковые каналы связи. Первый канал Москва-Владивосток — при запуске имел скорость всего в 128 Кбит/с (килобит!). Однако через этот канал — подавалась телефония (включая выход на достаточно популярную в то время службу Совинтела «World Access Card»), и канал передачи данных для модемного пула РоссияОнЛайн (СОВАМ Телепорт, полузабытая легенда).

Расскажу о телепорте, и его основных компонентах. Осторожно, трафик: много фотографий.

000. Предыстория

В 1959 году Н. П. Брусенцов разработал для МГУ уникальную вычислительную машину «Сетунь». Она была основана на троичной системе счисления и хотя элементная база была частично двоичной, что приводило к перерасходу деталей, машина зарекомендовала себя как экономичная и надёжная. Сегодня троичную машину можно увидеть разве что в музее, двоичный код победил.

Но, как я говорил ранее, всегда найдутся люди, готовые сохранять технологии прошлого в виде эмуляторов.

После того, как я воплотил свою давнишнюю мечту и все-таки (хотя и с опозданием почти на 30 лет) построил Радио 86РК, некоторое время мне казалось, что на этой части моей истории поставлена вполне достойная точка.

Тем не менее, обнаружилось, что болезнь до конца не вылечена, и она вернулась еще более острым рецидивом. Наверное, сказались как неожиданно успешный опыт постройки 86РК, так и то, что у меня в ходе данного процесса образовалось довольно большое количество весьма притягательно выглядящих инструментов, приборов и деталей, которым очень хотелось найти применение.
В конце концов ломка стала нестерпимой, и мне пришлось снова взяться за паяльник, а также вспомнить некоторые другие навыки из прошлого. Что из этого получилось, можно увидеть вместе с некоторым количеством картинок и очень (повторяю – ОЧЕНЬ) большим количеством букв (и даже не букв, а страниц) дальше…

Современные компиляторы очень хорошо умеют оптимизировать код. Они удаляют никогда не выполняющиеся условные переходы, вычисляют константные выражения, избавляются от бессмысленных арифметических действий (умножение на 1, сложение с 0). Они оперируют данными, известными на момент компиляции.
В момент выполнения информации об обрабатываемых данных гораздо больше. На её основании можно выполнить дополнительные оптимизации и ускорить работу программы.
Оптимизированный для частного случая алгоритм всегда работает быстрее универсального (по крайней мере, не медленнее).
Что если для каждого набора входных данных генерировать оптимальный для обработки этих данных алгоритм?
Очевидно, часть времени выполнения уйдёт на оптимизацию, но если оптимизированный код выполняется часто, затраты окупятся с лихвой.
Как же технически это сделать? Довольно просто — в программу включается мини-компилятор, генерирующий необходимый код. Идея не нова, технология называется “компиляция времени исполнения” или JIT-компиляция. Ключевую роль JIT-компиляция играет в виртуальных машинах и интерпретаторах языков программирования. Часто используемые участки кода (или байт-кода) преобразуются в машинные команды, что позволяет сильно повысить производительность.
Java, Python, C#, JavaScript, Flash ActionScript — неполный (совсем неполный) список языков, в которых это используется. Я предлагаю решить конкретную задачу с использованием этой технологии и посмотреть, что получится.

Предлагаю читателям «Хабрахабра» перевод статьи «Why free monads matter».

Интерпретаторы

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

• скомпилировать и выполнить его;
• непосредственно запустить с помощью традиционного интерпретатора;
• сжать и архивировать;
• просто оставить его в покое.

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