Discreet · and · not · discrete.


Do you want to crack jokes about it or do you want me to go?

* * *
Enlgish readers, look no further: my english postings. Mostly about Haskell and its applications.

Про функциональное программирование и программирование вообще:Про язык Хаскель:Вне ЖЖ:Поиск по моему блогу:Потом еще чего добавлю.

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

Если при использовании сошлётесь на меня, буду благодарен.
* * *
  1. Здесь только то, что интересно мне.
    1. Мои посты именно об интересном мне.
    2. Для меня интересно чужое хорошо аргументированное мнение.
    3. Я предупрежу, если мне что-то станет неинтересным.
  2. Запрещены:
    1. Хамство.
    2. Мат.
    3. Мемы.
    4. Переходы на личности (в принципе, даже в виде "да это идиотское решение!", если только за ним не следует сразу уточнение технических деталей в виде извинения)
    5. Комментарии-однострочники.
  3. Я предпочитаю чужие посты чужим комментариям.
За запрещённое может последовать бан сразу.

За "неинтересное" будет бан после не выполненной просьбы перейти к постам.

Всё это, как и предыдущие правила, направлено на увеличение доли видимой или полезной информации.

PS
Исключения существуют - это давно знакомые мне пользователи ЖЖ.
* * *
http://www.youtube.com/watch?v=eh_HUIJkRzU

Космическая акула-гоблин, надо говорить.
* * *
Теперь надо ускорить программу в десять тысяч раз и сделать масштабируемой.
* * *
* * *
https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BB%D1%82%D0%B8%D1%81%D1%82%D0%BE%D0%B2,_%D0%95%D0%B2%D0%B3%D0%B5%D0%BD%D0%B8%D0%B9_%D0%A1%D0%B5%D1%80%D0%B0%D1%84%D0%B8%D0%BC%D0%BE%D0%B2%D0%B8%D1%87

"роман «Ноктюрн пустоты» (1988), описывающий заговор империалистов, угрожающих человечеству климатической войной".

Велтистов гениален, по-моему.
* * *
* * *
Одна из движущих сил стандарта плавающей точки IEEE 754 был, в частности, суперкомпьютер Крей. Но не потому, что Крей такой сторонник стандартов. Скорее наоборот.

На машине Крея код x=1/y; z = y*x мог дать заметный разброс значений потому, что Крей из умножения столбиком отрезал все младшие биты!

Вот так:
  123
 *466
-----
  738
 738
492
-----
572ХАХА
Вот так вот. Без переноса в старшие разряды.

Это было сделано для получения максимальной тактовой частоты. Что ему вполне удалось и за что Крея все и любили - более быстродействующей (практически) однопроцессорной системы в мире не было.
* * *
Вот Джон Кармак в Твиттере запостил ссылку: http://www.slideshare.net/cellperformance/data-oriented-design-and-c

Страница 120 - обсуждение энтропии и расположения данных. Страница 142 - распределение значений по времени для некоей булевской переменной в составе класса/структуры.

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

Что подводит нас к другой возможной оптимизации - а стоит ли хранить булевские значения, которые большую часть времени не меняются (долго Истина или долго Ложь) или имеют практически константное значение (как на странице 141 выше - ~7% времени истина).

Для таких случаев имеет смысл оптимизировать ещё и вычисления, если мы будем хранить маски и/или индексы в отдельных массивах. Здесь мы экономим на проверке флага и предсказании перехода - проверяем чохом и переходим редко. Техника может быть самая разная - от масок до реляционного where id == spawned_id.

Современные векторные расширения AVX и далее - наконец-то! - стали поддерживать выборку по индексам и регистры масок. В результате, одной командой можно сделать 4-8 выборок по индексам в массиве, что-то типа (a,b,c,d) = (a[i], a[j], a[k], a[m]). Если используется регистр-маска, то команду можно задать такую (a,b,c,d) = (a[i], a[j], с, a[m]) или такую (a,b,c,d) = (a[i], 0, a[k], a[m]). Похожее поведение есть и для команд сохранения.

Мой опыт построения игр говорит, что обычно код обновления объектов функционален, из текущего состояния и текущего окружения в новое состояние. Обновления обычно выполняются вне зависимости от порядка объектов, практически параллельно. Обновление, заметно меняющее статус объекта, обычно вредно - если в процессе работы А рассчитывал на статус "живой" у В, а связанный с первым Б получил статус "мертвый" у В (и при смерти В что-то важное отпустил), то это приводит к интересным эффектам. Поэтому, с моей точки зрения, проше обновлять не на месте, а создавая новые данные. Что и провоцирует вот этот вот реляционный подход.
* * *
Поскольку в LSM дереве есть несколько уровней "свежести" данных,и их надо сливать вместе при чтении, LSM читает медленней в несколько раз - в моей реализации скорость отличались до 6 раз в сравнении с BDB.

После помещения LSM внутрь реального сервера скорость чтения (SELECT x FROM table) стала меньше на 1% (один процент). Иногда 2%. Сервер наш быстрее MS SQL на чтении процентов на 10.

Поэтому чрезвычайно рекомендую. Реализуется много проще B+tree, просто поддерживать транзакци и, как выясняется, в реальной жизни ещё и не очень медленное даже на невыгодном сценарии.
* * *