Ранее (1, 2) мы обосновали и продемонстрировали возможность существования
пространственного индекса, обладающего всеми плюсами обычного B-Tree — индекса и
не уступающего по производительности индексу на основе R-Tree.
Под катом обобщение алгоритма на трёхмерное пространство, оптимизации и бенчмарки.

В прошлый раз мы пришли к выводу, что для эффективной работы пространственного индекса на основе Z-order необходимо сделать 2 вещи:

• эффективный алгоритм получения подинтервалов
• низкоуровневую работу с B-деревом

Вот именно этим мы и займёмся под катом.

Индекс на основе Z-order кривой в сравнении с R-деревом имеет массу преимуществ, он:

• реализован как обычное B-дерево, а мы знаем что
• страницы B-дерева имеют лучшую заполняемость, кроме того,
• Z-ключи сами по себе более компактны
• B-дерево имеет естественный порядок обхода, в отличие от R-дерева
• B-дерево быстрее строится
• B-дерево лучше сбалансировано
• B-дерево понятнее, не зависит от эвристики расщепления/слияния страниц
• B-дерево не деградирует при постоянных изменениях
• ...

Впрочем, у индексов на основе Z-order есть и недостаток — сравнительно низкая производительность :). Под катом мы попробуем разобраться с чем связан этот недостаток и можно ли что-то с этим сделать.

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

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

Так что автор из свойственной ему любознательности попытался разобраться с доступной документацией и составить более — менее цельную картину. Если читателю это интересно — добро пожаловать под кат.

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

Вы спросите: «Кому вообще интересны эти небесные объекты?» и даже: «Ну и при чём здесь 2ГИС?» и будете отчасти правы. Ведь методы пространственного индексирования являются универсальной ценностью.

Обычно, имея дело с геоданными, мы работаем с локальной проекцией на плоскость и тем самым отмахиваемся от искажений. В масштабах планеты это сделать труднее — начинают выпирать астрономические проблемы.
Что касается объёмов данных, уже сейчас в OSM более 4 млрд точек и 300 млн дорог. Это соизмеримо с масштабами, характерными для звёздных объектов. Да и помимо всего прочего, звёздные атласы — отличный стенд для разработки и отладки пространственных алгоритмов.

Обещанные тонкости и выводы под катом.

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

Предыдущие статьи:
1 — описание работы на линейном куске
2 — вызов функций, сохраняем регистры
3 — вызов функций, взгляд изнутри

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

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

В данной статье мы будем разрабатывать (программную) модель суперскалярного процессора с OOO и фронтендом стековой машины.

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

Автор назвал эту технику “loops fracking” по аналогии с, например, “loops unrolling” или “loops nesting”. Тем более, что термин отражает смысл и не занят.

Предшествующая статья про исключения в С++ оставила кучу тёмных мест,
главное, что осталось непонятным — так как же всё-таки осуществляется
передача управления при возбуждении исключения?
С SJLJ всё понятно, но, утверждается, что эта технология практически
вытеснена некоторым без-затратным (при отсутствии исключений) табличным механизмом.
А вот что это за механизм такой и как он устроен, будем разбираться под катом.

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

Ни один из известных нам сервисов не строил маршрут из точки А до точки Б там, где нет тропинок и тротуаров, зато полно заборов и домов причудливых очертаний.

2ГИС решил эту проблему. Мы научились строить маршруты для пешеходов по растеризованной карте местности. Карта формально представляется графом с вершинами на регулярной решётке в местах, где пешеход может находиться физически.

Принято считать, что такой способ строить маршруты неприемлем, потому что съедает много ресурсов. Под катом — как мы с этим справились.

Ранее мы рассматривали прототип масштабируемой read-only файловой системы. Удалось показать, что, используя предложенную архитектуру, можно построить файловую систему любой емкости, с гарантированным временем доступа, соизмеримым с таковым для доступа к файлу в пределах одного физического диска.
Далее постараемся разобраться, может ли подобный подход принести пользу при построении файловой системы общего назначения.

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

Исключения и связанная с ними раскрутка стека – одна из самых приятных методик в C++. Обработка исключений интуитивно понятно согласуется с блочной структурой программы. Внешне, обработка исключений представляется очень логичной и естественной.

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

Тем не менее, в C++, исключения традиционно рассматриваются буквально как исключительные ситуации, связанные с восстановлением после ошибок. Трудно сказать, является ли это причиной или следствием того, что реализация обработки исключений компиляторами чрезвычайно дорога. Попробуем разобраться почему.

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

Данная статья повествует о пользе низкоуровневых вычислений на примере атласа звездных объектов 2MASS.
2MASS — это ~471 млн. объектов, для которых приведены координаты, а также сопутствующая информация, всего 60 атрибутов.
Физически — это 50Гб исходных гзипнутых текстовых файлов.
Можно ли работать с такой базой, не прибегая к «тяжелой артиллерии»?
Давайте попробуем.

Данная статья написана в продолжение серии, повествующей о прототипировании простого и производительного динамического web map сервера. Ранее рассказывалось о том, как в нем устроены пространственные индексы, а так же о том, как можно просто так вот взять и нарисовать пространственный слой. Сейчас мы сделаем это чуть изящнее.

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

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



Есть мнение, что специализированная read-only файловая система при прочих равных обладает преимуществами перед оной общего назначения т.к:

1. не обязательно управлять свободным пространством;
2. не надо тратиться на журналирование;
3. можно не заботиться о фрагментации и хранить файлы непрерывно;
4. возможно собрать всю мета-информацию в одном месте и эффективно ее кэшировать;
5. грех не сжимать мета-информацию, раз уж она оказалась в одной куче.

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