• Моделирование динамических систем: численные методы решения ОДУ

    • Tutorial

    Введение


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



    Итак, задача:
    Камень бросают вертикально, без начальной скорости с высоты h = 100 м. Пренебрегая сопротивлением воздуха, определить закон движения камня, как функцию высоты камня над поверхностью Земли от времени. Ускорение свободного падения принять равным 10 м/с2
    Простая задачка? Да элементарная, имеющее аналитическое решение, которое легко напишет мало-мальски грамотный школьник. Но эта простая задача послужит нам весьма показательным примером
    Читать дальше →
  • Особенности промышленной аэрофотосъемки. Часть I. Подготовительные грабли

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

      Читать дальше →
    • Learn OpenGL. Урок 4.6 — Кубические карты

      • Перевод
      • Tutorial
      OGL3

      Кубические карты


      До сих пор нам приходилось пользоваться лишь двухмерными текстурами, однако, OpenGL поддерживает гораздо больше типов текстур. И в этом уроке мы рассмотрим тип текстурной карты, на самом деле, представляющий собой комбинацию нескольких отдельных текстур – это кубическая карта (cubemap).

      Кубическая карта, по сути, является одним текстурным объектом, содержащим 6 отдельных двухмерных текстур, каждая из которых соотносится со стороной оттекстурированного куба. Зачем может пригодиться такой куб? Зачем сшивать шесть отдельных текстур в одну карту вместо использования отдельных текстурных объектов? Суть в том, что выборки из кубической карты можно совершать используя вектор направления.
      Читать дальше →
      • +21
      • 2,7k
      • 5
    • Организация виртуальной памяти

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

        В предыдущей статье я рассказал про vfork() и пообещал рассказать о реализации вызова fork() как с поддержкой MMU, так и без неё (последняя, само собой, со значительными ограничениями). Но прежде, чем перейти к подробностям, будет логичнее начать с устройства виртуальной памяти.

        Конечно, многие слышали про MMU, страничные таблицы и TLB. К сожалению, материалы на эту тему обычно рассматривают аппаратную сторону этого механизма, упоминая механизмы ОС только в общих чертах. Я же хочу разобрать конкретную программную реализацию в проекте Embox. Это лишь один из возможных подходов, и он достаточно лёгок для понимания. Кроме того, это не музейный экспонат, и при желании можно залезть “под капот” ОС и попробовать что-нибудь поменять.
        Читать дальше →
        • +39
        • 37,6k
        • 4
      • Делаем мультизадачность

          Я стараюсь чередовать статьи про разработку ОС вообще и специфические для ОС Фантом статьи. Эта статья — общего плана. Хотя, конечно, я буду давать примеры именно из кода Фантома.

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

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

          Шедулер — это функция, которая отвечает на вопрос «какой нити отдать процессор прямо сейчас». Всё. Простейший шедулер просто перебирает все нити (но, конечно, готовые к исполнению, не остановленные) по кругу (RR алгоритм). Реальный шедулер учитывает приоритеты, поведение нити (интерактивные получают больше, чем вычислительные), аффинити (на каком процессоре нить работала в прошлый раз) и т.п., при этом умеет сочетать несколько классов приоритетов. Типично это класс реального времени (если есть хотя бы одна нить этого класса — работает она), класс разделения времени и класс idle (получает процессор только если два предыдущих класса пустые, то есть в них нет нитей, готовых к исполнению).

          На сём пока про шедулер закончим.

          Перейдём к собственно подсистеме, которая умеет отнять процессор у одной нити и отдать его другой.
          Читать дальше →
        • Как выйти на путь разработки ОС

          Данная статья служит одной простой цели: помочь человеку, который вдруг решил разработать свою операционную систему (в частности, ядро) для архитектуры x86, выйти на тот этап, где он сможет просто добавлять свой функционал, не беспокоясь о сборке, запуске и прочих слабо относящихся к самой разработке деталей. В интернете и на хабре в частности уже есть материалы по данной теме, но довольно трудно написать хотя бы “Hello world”-ядро, не открывая десятков вкладок, что я и попытаюсь исправить. Примеры кода будут по большей части на языке C, но многие другие языки тоже можно адаптировать для OSDev. Давно желавшим и только что осознавшим желание разработать свою операционную систему с нуля — добро пожаловать под кат.
          Читать дальше →
        • Современная операционная система: что надо знать разработчику

            Александр Крижановский (NatSys Lab.)


            Александр Крижановский

            Нас сегодня будет интересовать операционная система – ее внутренности, что там происходит… Хочется поделиться идеями, над которыми мы сейчас работаем, и отсюда небольшое вступление – я расскажу о том, из чего состоит современный Linux, как его можно потюнить?

            По моему мнению, современная ОС – это плохая штука.




            Дело в том, что на картинке изображены графики сайта Netmap (это штуковина, которая позволяет вам очень быстро захватывать и отправлять пакеты сетевого адаптера), т.е. эта картинка показывает, что на одном ядре с разной тактовой частотой до 3 ГГц Netmap позволяет 10 Гбит – 14 млн. пакетов в сек. отрабатывать уже на 500 МГц. Синенькая линия – это pktgen – самое быстрое, что, вообще, есть в ядре Linux’а. Это такая штуковина – генератор трафика, который берет один пакет и отправляет его в адаптер много раз, т.е. никаких копирований, никакого создания новых пакетов, т.е., вообще, ничего – только отправка одного и того же пакета в адаптер. И вот оно настолько сильно проседает по сравнению с Netmap (то, что делается в user-space показано розовой линией), и оно вообще где-то там внизу находится. Соответственно, люди, которые работают с очень быстрыми сетевыми приложениями, переезжают на Netmap, Pdpdk, PF_RING – таких технологий море сейчас.
            Читать дальше →
          • Трёхмерная графика с нуля. Часть 2: растеризация

            • Перевод
            image


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

            К сожалению, эта простота имеет свою цену: низкую производительность. Несмотря на то, что существует множество способов оптимизации и параллелизации трассировщиков лучей, они всё равно остаются слишком затратными с точки зрения вычислений для выполнения в реальном времени; и хотя оборудование продолжает развиваться и становится быстрее с каждым годом, в некоторых областях применения необходимы красивые, но в сотни раз быстрее создаваемые изображения уже сегодня. Из всех этих областей применения самыми требовательными являются игры: мы ожидаем рендеринга отличной картинки с частотой не менее 60 кадров в секунду. Трассировщики лучей просто с этим не справятся.

            Тогда как это удаётся играм?

            Ответ заключается в использовании совершенно иного семейства алгоритмов, которое мы исследуем во второй части статьи. В отличие от трассировки лучей, которая получалась из простых геометрических моделей формирования изображений в человеческом глазе или в камере, сейчас мы будем начинать с другого конца — зададимся вопросом, что мы можем отрисовать на экране, и как отрисовать это как можно быстрее. В результате мы получим совершенно другие алгоритмы, которые создают примерно похожие результаты.
            Читать дальше →
            • +36
            • 12,4k
            • 2
          • Обзор примитивов синхронизации — спинлоки и тайны ядра процессора

              Последняя статья про классические примитивы синхронизации.

              (Наверное, потом напишу ещё одну про совсем уже нетипичную задачу, но это потом.)

              Сегодня мы немножко заглянем в процессор. Чуть-чуть.

              По сути, мы будем говорить про единственный примитив, который принципиально отличается от остальных: спинлок. Spinlock.

              В комментариях к предыдущим заметкам возникла дискуссия — насколько справедливо вообще выделять спинлок как примитив, ведь по сути он — просто мьютекс, верно? Он выполняет ту же функцию — запрещает одновременное исполнение фрагмента кода несколькими параллельными нитями.

              На уровне процесса всё так и есть — различия между спинлоком и мьютексом — чисто технические, вопрос реализации и производительности.

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

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

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

              Итак, иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором. Мы в них немного заглянем сегодня.

              Как устроен спинлок?
              Читать дальше →
            • Пишу игрушечную ОС (о реализации мьютекса)


                Продолжаю блог о разработке игрушечной ОС (предыдущие посты: раз, два, три). Сделав паузу в кодировании (майские праздники, всё-таки), продолжаю работу. Только что набросал сканирование PCI-шины. Эта штука понадобится для работы с SATA-контроллером: следующее, что хочу сделать — это простенький драйвер диска. Он позволит поэкспериментировать с проецированием постоянной памяти на адресное пространство (своппинг, доведённый до логического конца). А пока хотел бы описать реализацию мьютекса.
                Читать дальше →