Скажу честно, мы с некоторым недоверием посмотрели на эту идею:
— Как мы применим SSE в нашем, еще не существующем, решении?
Но внесли её в список todo и, когда код уже начал обретать законченный вид, мы нашли места "приложения рычага".
Потратив всего несколько часов (на чтение документации по STTNI, эксперименты и переписывание) нам удалось ускорить "тяжелые" фрагменты в два-три раза!

Небольшое предупреждение: не ожидайте что SSE инструкции превратят неэффективный алгоритм в конфетку. Уделяйте внимание прежде всего асимптотике и простоте. Затем беритесь за специальные инструменты для участков кода на которые указал профайлер.

Я постараюсь описать картину крупными мазками. За подробностями загляните в руководство по SSE4 для разработчиков. Хорошая документация по командам и параметрам лежит в MSDN. Оба ресурса на английском языке.

Что включает в себя SSE4.2

• операции с парами строк — именно о них пойдет речь дальше
• вычисление CRC32
• подсчет количества установленных бит
• операция "больше чем" упакованных 64-битных знаковых чисел (Compare Packed Signed 64-bit data For Greater Than)

Выбираем форму

Существует 4 инструкции процессора и целых 14 команд поддерживаемых компилятором.
Следующий рисунок поможет разобраться с ними:

• e или i в середине команды говорит о том, как определена длина входных строк: explicit — длина указывается явно или implicit — процессор сам определит длину нуль-терминированной строки.
• суффикс команды определяет тип результата: index — значение индекса или mask — битовая маска. Кроме этого, можно получить значение арифметических регистров (выделены синим), которые изменяются в зависимости от содержимого операндов и полученного результата. Это пригодится, если вам, к примеру, интересно не точное местоположение символа в строке, а сам факт его наличия.

... и содержание

Последний аргумент каждой из команд — управляющий байт (imm8 control byte) объясняет как нужно интерпретировать данные и что с ними нужно сделать.

Байт формируется комбинацией флагов которые определяют:

• формат данных: знаковые или беззнаковые числа? Байты или пары байт (unicode)?
• тип сравнения:
  • равенство любых символов — для поиска символов из набора (_SIDD_CMP_EQUAL_ANY)
  • равенство символов из диапазона — поиск символов из диапазона (_SIDD_CMP_RANGES)
  • посимвольное сравнение — сравнение строк (_SIDD_CMP_EQUAL_EACH)
  • упорядоченное сравнение — поиск подстрок (_SIDD_CMP_EQUAL_ORDERED)
• промежуточное преобразование результата (polarity). Подробности в документации. Ниже будет пример с использованием этого флага
• для результата-индекса — нужно ли вернуть наименьший (_SIDD_LEAST_SIGNIFICANT) или наибольший найденный индекс (_SIDD_MOST_SIGNIFICANT)
• для результата-маски — вернуть битовое (_SIDD_BIT_MASK) или целочисленное (_SIDD_UNIT_MASK) её представление.

Примеры

Пара примеров прямо из нашего кода. Мы оперируем беззнаковыми байтами в силу специфики решения.

Поиск первого вхождения любого символа из строки:

int get_first_index_of_symbol(unsigned char * needle, int needle_length,
	unsigned char * haystack, int haystack_length)
{
	return _mm_cmpestri(
		_mm_loadu_si128((const __m128i*)needle), needle_length,
		_mm_loadu_si128((const __m128i*)haystack), haystack_length,
		_SIDD_UBYTE_OPS | _SIDD_CMP_EQUAL_ANY | _SIDD_LEAST_SIGNIFICANT);
}

Длина строк известна и нам нужна позиция символа. Выбор падает на _mm_cmpestri.

Определяемся с флагами:

• мы оперируем с беззнаковыми байтами — _SIDD_UBYTE_OPS
• нужно найти вхождения символа в любом месте — _SIDD_CMP_EQUAL_ANY
• нас интересует первое вхождение — _SIDD_LEAST_SIGNIFICANT

Все эти флаги можно опустить, поскольку они установлены по умолчанию.

Поиск первого несовпадающего символа для строк равной длины (используется для нахождения длины наибольшего общего префикса):

int get_first_unmatch(unsigned char * a, unsigned char * b, int length)
{
	return _mm_cmpestri(
		_mm_loadu_si128((const __m128i*)a), length,
		_mm_loadu_si128((const __m128i*)b), length,
		_SIDD_CMP_EQUAL_EACH | _SIDD_NEGATIVE_POLARITY);
}

Обратите внимание, что поменялись только управляющие флаги:

• нужно посимвольное сравнение — _SIDD_CMP_EQUAL_EACH
• нас интересует несовпадение — _SIDD_NEGATIVE_POLARITY

Что получится, если символ не был найден или строки совпадают? Мы получим в ответ 16 (или 8, если бы операции были над строками из двухбайтовых символов).

Чтобы не быть голословной, утверждая что STTNI дает преимущество, я замерила время выполнения участка кода для файла размером 200 Мб:

• без SSE - 360 мс

  //i - текущее положение в строке buffer размера size
  while (i < size && buffer[i] != '\n' && buffer[i] != '>') i++;
  //i выходит за пределы строки или указывает на искомый символ
  

• с SSE - 171 мс

  //i - текущее положение в строке buffer размера size
  char * needle = "\n>";
  while (i + 15 < size)
  {
  	int r = get_first_index_of_symbol(
  		(unsigned char *)needle, 2,
  		(unsigned char *)(buffer + i),
  		16);
  	i += r;
  	if (r != 16) break;
  }
  while (i < size && buffer[i] != '\n' && buffer[i] != '>') i++;
  //i выходит за пределы строки или указывает на искомый символ
  

Результат налицо (:

Интересно, а кто еще использовал SSE4.2 в решении? Насколько быстрее оно сделало ваш код?

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

Дерево только из короткой строки
В конкурсной задаче максимальные общие подстроки (LCS) ищутся только из 2 источников. При таком ограничении смысла в так называемом обобщенном дереве нет (вот было бы исходных строк 3 - пришлось бы строить обобщенное дерево по 2 из них). Вместо этого можно "пройтись второй строкой" по дереву, построенному по первой, запоминая "места" (пара: позиция в строке - позиция в дереве) максимального совпадения, и после несложной обработки получить из них ответы в нужном формате.

Строить дерево лучше по более короткой строке, потому что оно занимает очень много памяти.

typedef unsigned int uint;
// в 64-битных системах размер uint - 4 байта, любой ссылки - 8 байт.
// структура вершины дерева - 48 байт
struct vertex {
        uint left, right; // срез в строке, соотв. подвешивающему эту вершину ребру
        uint length; // right - left, используется очень часто
        // 5 8-байтных ссылок было бы уже слишком накладно
        // vertex *child = tree + v->children['A']; // арифметика указателей
        uint children[5]; // ACTG$
        // При особом желании можно было бы сэкономить еще 8 байт (8 + 8 - 4 - 4)
        // так же, как в children. Но неудобно, эти ссылки часто используются
        vertex *parent, *link;
};
// Дерево: C-style массив
vertex *tree;

Теоретически, для составленной из 4 букв строки длины L суффиксное дерево может содержать от 1,34L до 2L вершин, практический диапазон для генома - 1,6-1,7L. Таким образом, в среднем наше дерево жрет около 48*1,66 = 80 байт на каждую букву строки. Это критичный недостаток с точки зрения формальных конкурсных ограничений: для строки длиной в 2^32 буквы дерево занимает 320 Гб! Но вполне терпимо, если рассматриваются только реальные геномы: скажем, в самой длинной хромосоме человека 250 млн нуклеотидов, ее дерево - "всего" 20 Гб.

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

Эту проблему можно решить модификацией (тривиальной при использовании суффиксных деревьев) алгоритма нахождения LCS: пусть он возвращает не только совпадения, большие M (min match length), но и любой длины, заканчивающиеся в конце одной или обоих строк (частей исходных строк, в реальности). Если какое-то большое фактическое совпадение из-за разбиения входных строк придется склеить из K совпадений между частями, то все они, кроме, возможно, последнего, как раз будут заканчиваться в точке разбиения. Например на рисунке выше совпадение 1 заканчивается в точке разбиения 1-й строки. Т. о. после "склейки" еще нужно попробовать продлить полученное совпадение вправо - максимум на M - 1 символов. В примере выше получится продлить совпадение 1 на длину совпадения 2.

Однако, если на этом ограничиться, количество ответов будет слишком большим (допустим, если одна из строк заканчивается на 'A', придется вывести все позиции буквы A во второй строке, и наоборот). Поэтому мы разбиваем строки с фиксированным перекрытием (OL, overlap): очередная часть начинается на OL символов раньше, чем закончилась предыдущая. Тогда, очевидно, можно не выводить совпадения, заканчивающиеся в конце одной из строк и меньшие OL. Нетрудно заметить, что если M существенно меньше длин входных строк (а в реальности так оно и есть), можно разбивать их с перекрытием M и вообще отказаться от модификации алгоритма нахождения LCS.

Я решила рассказать о том, что не вошло в наше отправленное решение на конкурс Accelereate 2012 из-за ограничения на размер.
Для начала рекомендую прочитать краткую версию, чтобы быть в контексте.

Итак:

Получение бинарного кода символа

Поскольку символов во входной последовательности всего 4, то их можно закодировать всего двумя битами.
Решение "в лоб":

switch (c)
{
case 'A':
	return 0;
case 'C':
	return 1;
case 'G':
	return 2;
case 'T':
	return 3;
}

Очень просто, но наличие ветвления в таком "популярном" месте не радует. Попробуем посмотреть внимательно на символы:

A = 0x41 = 1000(00)1
C = 0x43 = 1000(01)1
G = 0x47 = 1000(11)1
T = 0x54 = 1010(10)0

Видно, что выделенные биты у каждого символа разные, поэтому switch можно заменить на

return c >> 1 & 3;

Хранение тестовых последовательностей

В промежуточном решении для хранения координаты суффикса из тестовой строки мы использовали пару <#тестовой строки, индекс>. Это неэффективно с точки зрения использования памяти (нужно 8 байт на каждый суффикс).

Немного поразмыслив, мы переписали работу с тестовыми строками: все они хранятся в сцепленном (concatenated) виде. Для разделения существует массив с информацией о длинах. Это позволило вдвое уменьшить размер структуры хранения суффиксов и на четверть — массива результатов (в одной записи результата мы теперь храним всего три 4-х байтовых числа - индексы рефересной и тестовой строк и длину).

Параллельное чтение файлов

Мы пытались реализовать чтение с помощью TBB Pipeline. Но, к сожалению, при использовании pipeline возникали странные артефакты в виде неправильного определения длины файла в Windows (на первый взгляд — из-за трактовки переносов строк). Наверняка рецепт исправления был прост, но поскольку времени уже не оставалось, решили просто обернуть процедуру чтения в OpenMP parallel for вместе с помещением чтения файла в критическую секцию.

Вывод результатов

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

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

int digit(char a1, char a2, char a3, char a4, char a5, char a6){
	int d = 0;
//1
	switch (a1){
		case 'C':
			d += 1024;
		break;
		case 'G':
			d += 2048;
		break;
		case 'T':
			d += 3072;
		break;

		default:  break;
	}
//2
	switch (a2){
		case 'C':
			d += 256;
		break;
		case 'G':
			d += 512;
		break;
		case 'T':
			d += 768;
		break;
		default:  break;
	}
//3
	switch (a3){
		case 'C':
			d += 64;
		break;
		case 'G':
			d += 128;
		break;
		case 'T':
			d += 192;
		break;
		default:  break;
	}
//4
	switch (a4){
		case 'C':
			d += 16;
		break;
		case 'G':
			d += 32;
		break;
		case 'T':
			d += 48;
		break;
		default:  break;
	}
//5
	switch (a5){
		case 'C':
			d += 4;
		break;
		case 'G':
			d += 8;
		break;
		case 'T':
			d += 12;
		break;
		default:  break;
	}
//6
	switch (a6){
		case 'C':
			d += 1;
		break;
		case 'G':
			d += 2;
		break;
		case 'T':
			d += 3;
		break;
		default:  break;
	}
	return d;
}

На основе хэша, в данном случае легко получить исходную строку, но для решения поставленной задачи этого не требовалось.
Для хранения хэшей ref-строки использовались вектора: vector<size_t> **L = new vector<size_t>*[4096];
Для нахождения общих подстрок использовался такой же принцип, как и в предоставленном решении, только вместо массива использовались 2 строки.
Вот собственно и все…

С нетерпением жду решение победителя, очень хочется увидеть оптимальный вариант решения данной задачи.

Самый простой и самый не быстрый из методов поиска одинаковых участков в нуклеотидных цепочках - "наивный" перебор строк со смещением. Он хорошо подходит для коротких цепочек, так как не требует предварительной обработки и дополнительных объемов памяти.
Но требование O(nm) по времени в общем случае нас не устроит, потому будем подбирать другие варианты.

Подготовка данных
Для начала подумаем об ускорении используя подготовку данных.
Так как мы будем проводить поиск в нуклеотидных цепочках, мы можем ограничить алфавит или же понизить битность на один символ. Всего таких символов у нас 4, а именно АЦГТ (ACGT). Это дает возможность использовать всего 2 бита вместо 8 (ANSII). Каким же образом построить соответствие? Если у нас нет дополнительных наполеоновских планов, можно в любом, но если вспомнить что эти нуклеотиды составляют пары (А-Т, Ц-Г) лучше на будущее провести такие аналогии:

• A = 00₂=0
• T = 11₂=3
• C = 01₂=1
• G = 10₂=2

Таким незамысловатым способом мы бы могли решить одну маленькую проблему - проверку пары нуклеотидов на комплементарность. В общем случае на это приходилось бы 8 проверок, в нашем же - только одна, проверка суммы значений на равенство 3. Уже неплохое ускорение в 8 раз. Правда времени потратим О(N). Ну да ладно - не смертельно, все-равно надо от мусора (перевод строк или пробелы) избавляться при считывании из неподготовленных данных.

Теперь подумаем вот о чем: а почему бы нам каким-нибудь образом сравнивать не по одной паре, а сразу по несколько. Ну что же, на помощь к нам придут хеш-функции для задания соответствия некоторой цепочки нуклеотидов длиной W и целого натурального числа. Таким образом, если два значения хеш-функции не совпадают, значит и цепочки гарантированно разные.
С равенством возможны варианты. Если использовать хеш-функции без коллизий (например, представление цепочки как число по основанию 4), мы также сможем гарантировать и идентичность цепочек. Такая хеш-функция будет цикличной, что позволит использовать предыдущее рассчитанное значение при смещении на 1 нуклеотид. Но тут возникают некоторые трудности с хранением данных - в переменную размером К бит мы сможем сохранить только К/2 нуклеотида. Затраты на подготовку О(N), при использовании цикличных хеш-функций типа такой:

int32_t W_ = W - 1;
for (i = 0; i < W_; i++) {
	key = ((key << 2) + Seq[i]) & mask;
}
for (i = W_, p = 0; i < Seq_l; i++, p++) {
	key = ((key << 2) + Seq[i]) & mask;
	Table_Key[p] = key;
}

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

Но ведь нам все-равно придется сравнивать одно и тоже по несколько раз. А если нам надо сравнить не одну пару, а некий набор пар в которые входит одна и та же строка? Для ускорения поиска можем построить индекс позиций подстрок у которых значения хеш-функций (одной или нескольких) совпадают. Этот этап мы можем организовать по-разному.

Первый способ
После превращения цепочки в массив хешей, каждый элемент записать как пару хеш-позиция. Дальше нам предстоит отсортировать этот массив по порядку значений хешей. Затраты по времени от O(N*Log(N)).
На этом можно и остановиться, а можно для ускорения поиска по нему преобразовать в двумерный массив. В нем элемент первого порядка будет соответствовать значению хеш-функции, а элементы второго порядка - позициям. При необходимости можно отсортировать и массив позиций - необходимо, если надо искать свертку одной строки на себя же (комплементарная связь, а не идентичность).
Такой способ подойдет в том случае если значения хеш-функции находятся в большом диапазоне величин, но используемых намного меньше от суммарного.
Поиск нужного значения хеш-функции возможен либо через бинарный поиск, либо через индексацию диапазонов с последующим бинарным поиском.

Второй способ
По-другому можем поступить в случае, если хеш-функция имеет ограниченный в разумных рамках диапазон величин.
Для примера используем хеш-функцию без коллизий, приведенную выше. В ней диапазон величин будет зависеть только от длины цепочки W, для которой мы строим соответствие. И этот диапазон составит от 0 до 4^W-1. Таким образом мы сможем воспользоваться уже "линейной" сортировкой с временем О(N) для построения двумерного массива соответствий значений хеш-функции и позиции.
Смысл простой. Создаем два массива: линейный S размером 4^W и двумерный T размером по первому индексу также 4^W, а по второму как получится (см. ниже).
На первом этапе воспользуемся массивом S для построения гистограммы вхождений значений хеш-функции в массив за время O(N).
На втором этапе выделяем память для подмассивов Т на количество элементов, указанных в соответствующей ячейке S.
Для окончательного заполнения будем использовать массив S как счетчик заполненности. В Т первый индекс будет соответствовать значению хеш-функции, второй берем из S, значение - позиция хеша в начальном массиве. Время, затраченное на заполнение, также О(N).
При желании и необходимости этот массив можно "причесать" - для хеш-функций соответствующих однородным строкам (АА..АА и подобных) выкинуть часть позиций по некоторым правилам.
В итоге за линейное время получим двумерный массив-индекс Т для быстрого определения положений подстроки длиной W по части (так же длиной W) заданного шаблона.
Затраты по времени общей подготовки О(N). Затраты на дополнительную память зависят от выбранной длинны W: массив хешей будет больше начальной строки в 2-4-... раза в зависим от выбранного типа данных (16, 32 и больше бит). Массив S будет содержать 4^W элементов размером от 8 до 32+ бит в зависимости от размеров строк. Массив Т будет занимать по объему примерно такой же объем как S (первый уровень индексации) и начальный массив суммарно.
Поиск нужного значения хеш-функции будет происходить за время О(1), но накладные затраты (массив S и первый уровень массива Т) могут быть больше чем полезная нагрузка (списки позиций).

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

Сравнение с другими методами
Казалось бы, что приведенный выше метод не очень хорош, так как дает только "точки соприкосновения" двух подстрок. И дальнейшее расширение до необходимой минимальной длины может "съесть" все ускорение. Но:

• иногда минимальная необходимая длина достаточно маленькая (W = W_min), что бы массив индексов был не столь уж и большим.
• алгоритм поиска с помощью суффиксных деревьев/массивов точно потребует объем в много раз превышающий размер входных данных, при сравнимых скоростях поиска

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

1. Создание массива хешей подстрок
Ну тут все довольно просто - делим начальную строку на участки, каждый участок своему потоку. Учитываем при этом, что на построение N хешей необходимо N+W-1 нуклеотидов. То есть нарезка происходит с перехлестами. Запись готовых результатов тоже разделена в памяти. Как дополнительные вычисления на каждый поток будет просчет первых W-1 хешей недостаточной длины. Но это явно мелочи по сравнению с выгодой в скорости. Но и кидаться в крайности тоже не стоит - должно выполняться условие ограничение разбиения P*W << N, где P - количество участков.

2. Индексация подстрок
Эту проблему я решил так же разбиением начального массива уже готовых хешей на несколько участков. Для разделения участков записи в конечных индекс воспользовался массивами счетчиками для каждого потока, с последующим суммирование нужных и использованием значения как сдвиг начала при записи. Основной проигрыш - использование дополнительных массивов под гистограммы и доступ к нужной ячейке с помощью сдвига. Тут тоже стоит себя ограничивать в бездумном дроблении - каждый массив под гистограмму имеет 4^W элементов от 8 до 64 бит. Что при большом количестве потоков может занимать значимый объем памяти.

3. Поиск совпадений
Тут еще проще - всю работу можно разделить на задания которые между собой не сильно связаны. Таким заданием, в случае сравнения массива и индекса, будет проверка совпадений для подстроки из шаблона и списка позиций возможных совпадений из индекса. Их будет приличное количество - динамическое распределение работы между потоками позволит адекватно балансировать нагрузку.
Для сравнения двух индексов неделимым заданием может быть как сравнения списка позиций для совпадающих хешей, так и более мелким - просчет результата для пары из возможного списка комбинаций позиций. Это решит проблему перекоса в случае если в обоих индексах некоторые значения хеш-функций будут содержать значительно большее количество позиций, чем остальные.
Еще вариант при котором будем отсекать некоторые варианты, если необходимо найти совпадение подстрок длиной намного больше чем 2*W. При этом возьмем две подстроки длиной W на таком расстоянии L, так что бы 2*W + L = W_min. Дальше будем сравнивать массивы позиций из индекса для хешей этих двух строк. Если расстояние между определенными элементами будет также равно L - возможно совпадение больших подстрок, что подтвердится полной проверкой. Оценка по времени такой проверки на совпадения О(Log(n₁)*Log(n₂)), где n_i - длины списков.
Чтобы не использовать критические секции, для каждого потока можно использовать отдельные массивы для хранения найденных результатов. С последующим слиянием и сортировкой/выборкой за время O(К + К*Log(К)).

Общее время алгоритма стремится к О(N + K + K*Log(K)), где N общий объем входных данных, К - объем не фильтрованных выходных данных.

Данный пост написан в рамках конкурса Accelerate Your Code 2012.
Спасибо за внимание. ЦУ буду рад прочитать в комментариях.

В этой статье мы опишем разработанный нами метод решения задачи с конкурса параллельного программирования Accelerate 2012. В задаче требовалось найти наибольшие общие подстроки у двух генетических последовательностей (то есть строк, состоящих из символов A,G,T,C), превосходящие по длине наперёд заданную величину M ≥ 6.

Пожалуй, первая мысль человека, знакомого с алгоритмами поиска подстроки — построить суффиксное дерево, однако после просмотра ограничений на размеры строк (а именно — они не длиннее 2³²) мысль отпадает. Несмотря на небольшую константу в оценке O(n), размер дерева будет весьма велик, и кэш процессора практически не будет задействоваться. В итоге перемещение по дереву станет довольно медленным.

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

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

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

Эта проблема решается, но пока что нас это интересовать не будет.

Возьмем строку mississippi (кстати, как раз алфавит из четырех символов!), и рассмотрим её суффиксный массив:

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

Решение в виде следующей структуры-подсказки очевидно:

Структура просто показывает сегмент суффиксного массива, где находятся суффиксы, начинающиеся с определенного символа.

Давайте вспомним, что нам необходимо найти совпадение длины M. Заменим суффиксный массив на массив, «элементами» которого будут подстроки длины M. Он несильно отличается от суффиксного массива, как и техника его построения.
В дальнейшем будем его называть s-массив.

s-массив сроки missmississippi (внимание — мы удлинили строку) для M=4 будет выглядеть так:

Теперь структуру-подсказку можно немного модифицировать, и она может подсказывать, используя, скажем, две-три первых буквы строки:

Ещё один очевидный плюс от использования подсказки — мы можем теперь не сравнивать первые символы с элементами s-массива, поскольку мы уже установили, что они совпадают.

Однако что нам мешает сделать подсказку длины M? Понятно, что при M>17, оперативной памяти может уже не хватить. Но, скажем, подсказку длины 14 построить можно.Ответ состоит в весьма возможной неравномерности распределения подстрок, то есть подстроки какого-то вида встречаются сильно чаще других. Это довольно характерно для генетических последовательностей.

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

Решение напрашивается: введем структуру-подсказку для длинных сегментов. Таким образом, структуры-подсказки образуют дерево, которое мы и назовем s-деревом. (В примере подсказки используют только один символ из соображений наглядности — ничто не мешает корню s-дерева использовать на реальных данных сразу 5 символов для подсказки, и это весьма эффективно). Количество символов,используемых подсказкой, назовем количеством ярусов узла s-дерева.

Паралельное построение s-дерева и s-массива.

Ранее мы подразумевали, что s-массив уже построен, и мы лишь строим структуру для ускорения поиска в нем. Однако все ещё интереснее — s-дерево и будет помогать строить s-массив.

Изначально произвольным образом инициализируем s-массив:

И начнем строить дерево от корня:

Заметим, что фактически мы разбили элементы s-массива по первому символу. Эта процедура проводится сортировкой подсчетом (независимо от того, сколько ярусов имеет узел) и занимает линейное время. Заметим попутно, что трудность, связанная с необходимостью посимвольного сравнения достаточно близких суффиксов, исчезла автоматически.

Далее продолжаем иерархически упорядочивать s-массив:

На схеме выше мы развернули узлы i и s . То есть будем считать, что раньше эти узлы были неразвернуты, а теперь — развернуты.

В нашем примере увеличивать глубину дерева особенного смысла нет. Обратите внимание на то, что наш массив ещё не до конца упорядочен:

Можно провести упорядочивание до конца, отсортировав элементы в одном листе, но мы это не делали.

Таким образом, процедура поиска строки в s-дереве довольно проста

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

Оптимизации

Наверное, у читателя пока что складывается ощущение, что такая структура крайне неповоротлива. Покажем, как её можно адаптировать под разные ситуации и ускорить.

Оптимизация 1. Ленивость.

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

Давайте будем строить s-дерево лениво, то есть по требованию: скажем, мы построили уже корень s-дерева, и нам приходит запрос найти в дереве строку issi. В этот момент мы разворачиваем узел i. Если нам не пришлось искать строку, начинающуюся на s, узел s так и останется неразвернутым.

Оптимизация 2. Многопоточность.

На самом деле ту часть дерева, которая почти наверняка нам пригодится, мы построим заранее, причем это будет делаться сразу всеми доступными потоками. В частности, одно удовольствие строить корень s-дерева сразу многими потоками, потому что алгоритм сортировки подсчетом прекрасно распараллеливается.

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

Оптимизация 3. Хранение строк.

Обе строки будем хранить в массиве из int16 в следующем формате:
каждому элементу в массиве будет соответствовать один элемент int16, который будет хранить в запакованном виде сам символ и семь, следующих за ним:

A  G  T  C  C  T  C  A  T     <- cтрока
00 01 10 11 11 10 11 00 10    <- коды символов

00 01 10 11 11 10 11 00       <- бинарное представление первого элемента массива
   01 10 11 11 10 11 00 10    <- второго
      10 11 11 10 11 00 10 00 <- третьего (пустое место заполнили нулями)
                                 и т.д.

Подобный метод хранения данных позволяет быстро запрашивать от одного до восьми бит, а значит

• Быстро проводить подсчет в сортировке подсчетом по первым n символам, если n<9
• Быстро передвигаться при движении по s-дереву, когда для передвижения в следующую вершину нам надо считать несколько символов.

Оптимизация 4. Эвристика совпавшего суффикса.

Собственно, эвристика уже не связана напрямую с s-деревом, но имеет отношение к решению задачи.

Зададимся вопросом, как мы будем искать совпадения с другой строкой (например, iispimispispi). Мы будем двигаться с конца второй строки. Предположим, что мы ищем с указанного места совпадение минимальной длины M=4 с уже рассмотренной строкой missmississippi.

       ↓
iispimispispi

В процессе поиска в s-дереве мы выясним, что строка
missmississippi не содержит даже подстроки sp. Очевидно, что мы уже не найдем совпадений длины 4, если начнем поиск с указанных позиций:

     ↓↓
iispimispispi

поэтому мы можем сразу сдвинуться на три позиции влево:

    ↓
iispimispispi

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

Для тех, кто хочет поломать свою голову:

    ↓
mmippi

В указанной выше ситуации мы не найдем совпадение ippi со строкой missmissisippi, если будем пользоваться построенным нами деревом. Задача: почему и как это исправить?

Заключение

Пожалуй, излагать ещё какие-то подробности будет излишним.

Подведем итог:

1. Мы посмотрели на структуру, которую мы назвали s-деревом
   (вполне возможно, что она была уже раз десять изобретена до нас, но пока мы об этом не в курсе:))
2. Посмотрели на процедуру построения этого дерева, которая может производиться лениво — по мере надобности, а также хорошо распараллеливается.
3. Познакомились с некоторыми приемами ускорения построения и использования дерева
   • Ленивостью, которая позволяет экономить при малом количестве строк, поданных на поиск в дереве
     (переводя на язык условий задачи, при длине reference сильно больше длины input)
   • Эвристикой совпавшего суффикса, которая позволяет нам ускоряться при большом значении параметра M
   • Так как при малой длине референсной строки дерево мало, мы защитились от самых разных «перекосов» во входных данных.
4. Планируем поделиться умными мыслями, появившимися в процессе чтения статьи, в комментариях. Да, это приглашение:)

PS. Почему s-массив и s-дерево? Потому что почти суффиксные, но не совсем.

Задача состояла в том, чтобы найти общие подстроки длины не менее N из заданной ref строки (представляющей собой участок ДНК и потом состоящей только из символов A, G, C, T) и некоторого набора in строк (найти нужно именно подстроки, не подпоследовательности, то есть связные общие части). Мы не сразу поняли одну особенность этого конкурса: здесь фактически нужно было не написать программу, полностью соответствующую описанию, а скорее оптимизировать прилагающееся референсное решение, так как сама постановка была нечеткой, а на форуме мы получили ответ, что программа должна дать абсолютно такой же результат как и референсный код. Ну что же, задание необычное, но тем более интересное.

Для начала проанализируем референсное решение. В исходном алгоритме для каждой in-строки динамически строится матрица L[i][j] - максимальная длина общей подстроки в ref и in строках, с позициями конца подстроки i и j соответственно. После построения этой матрицы достаточно найти все элементы со значением не менее N. Также в референсном решении отсекаются случаи, когда можно сдвинуть правый конец одной или обоих подстрок на 1 вправо с неуменьшением длины общей подстроки.

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

h -= rem * int64(s[i-1]);
h = h * MOD + int64(s[i+minMatchLength-1]);
hash[i] = h;

мы потратим в среднем О(m+n) времени, просто сравнивая все хеши с хешем образца. Недостатком этого алгоритма является то, что в «плохих» случаях он может работать за квадратичное время, однако на форуме мы получили ответ, что плохих случаев в тестах не будет, что повлияло на выбор этого алгоритма.

Для данной конкретной задачи, конечно, пришлось делать модификации. Мы можем найти все хеши подстрок длины N из in строки и поместить их в хеш-таблицу, этот процесс можно распараллелить через библиотеку TBB. Далее мы можем пройтись по подстрокам длины N из ref строки и сверять их хеш с таблицей. При этом вставка в хеш-таблицу медленнее, чем проверка, поэтому заметим, что задача практически симметрична относительно ref и in строк, поэтому если ref строка длиннее, то создадим хеш таблицу для in строки и наоборот. Когда мы находим совпадение хешей, то находим наибольшую общую подстроку (зная начальные индексы) и запоминаем этот ответ. Есть еще небольшая сложность связанная с тем, что ответы получатся не в том порядке в котором они идут в референсном решении, поэтому придется еще применить сортировку для ответа, однако это не должно сильно замедлить алгоритм.

В итоге получается, что сложность этого алгоритма составляет O(N + KlogK), где N – суммарный размер входа, K – размер выхода, что уже является практически линейным решением.

Хотелось бы услышать комментарии, замечания или вопросы и от остальных участников и конечно, делитесь вашими идеями!

В первую очередь я, конечно, хочу порекомендовать наш сайт viva64.com. Здесь можно найти много статей и записей в блоге, касающихся разработке качественного кода. Например, предлагаю познакомиться с 28 уроками, посвященными разработке 64-битных приложений на языке Си/Си++.

Для удобства я разбил ссылки на несколько тем. Желаю приятного чтения.

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

Си++ живее всех живых

• Большой список известных проектов, которые разрабатываются на языке Си/Си++: C++ Applications. И после этого кто-то говорит, что язык Си++ вымирает?
• Computer Language Benchmarks Game. Как всегда по скорости лидируют языки Fortran, Си и Си++. И вряд ли что-то в обозримом времени изменится. Если вы разрабатываете ресурсоемкое программное обеспечение, то Си++ может оказаться оптимальным выбором.
• Why is C++ still a very popular language in quantitative finance?
• Why do they program in C++?
• 9 reasons to start using C++11

Интересные блоги

• Steve Hanov's Blog
• Visual C++ Team Blog
• The Old New Thing

Арифметика с плавающей запятой

• What Every Computer Scientist Should Know About Floating-Point Arithmetic
• Tricks With the Floating-Point Format
• Stupid Float Tricks
• Comparing Floating Point Numbers, 2012 Edition

Разные приёмы при программировании

• Bit Twiddling Hacks
• Table-driven methods with no relocations
• Reduce Compilation Dependencies in Large Scale C++ Projects: Factory Pattern
• Exceptions in C with Longjmp and Setjmp
• Catching Integer Overflows in C. Article N1, N2
• Cool C Tricks

О кодировках символов и управляющих символах

• Unicode, UTF-8 and all that: An intentionally incomplete character set introduction for hasty C programmers
• What the xxxx Is UTF-8? A Character Encoding Primer.
• ASCII Characters
• Control character
• The UTF-8 Everywhere manifesto

Стандарты кодирования

• Google C++ Style Guide
• CERT. C Secure Coding Standard, C++ Secure Coding Standard
• Joint Strike Fighter (F-35) C++ Coding Standard

Группы

• Reddit: Cpp, C_Programming.
• Facebook: C++ Programming, For the love of C++, C Programming, Visual C++ Developer, C Plus Plus (C++)
• LinkedIN: C++ Community Group, C++ Developers Forum, C++ Developers Group, C++ Professionals

Разное

• What's Wrong With GNU make?
• Почему strncpy не безопаснее strcpy: strncpy? just say no
• A Guide to Undefined Behavior in C and C++. Part N1, N2, N3
• Компиляция 64-битных приложений в Visual C++ 2008 Express Edition. Visual C++ 2008 Express Edition And 64-Bit Targets
• Windows Data Alignment on IPF, x86, and x64
• C/C++ Low Level Curriculum. Part N1, N2, N3, N4, N5, N6, N7, N8
• Ссылки на различные ресурсы по тематике Си++. Список ссылается на много старых ресурсов, но его стоит посмотреть.
• Functional Programming in C++
• The C++ Lands (забавная картинка)
• Translate C declaration
• Arbitrary Data Sizes with C

Добро пожаловать!

Так же на страничке документации, как обычно, документы из последнего обновления и выложен новый вариант doxygen-документации.

--Владимир

И он нашелся. Им оказалась библиотека Intel TBB с её концепцией планировщика задач (Task Scheduler). Для тех, кто с TBB не знаком я коротко объясню суть этого паттерна: вы абстрагируетесь от количества логических\физических процессоров, от числа потоков операционной системы и создаёте свой алгоритм в терминах "задач". Задаче передаётся что-то на вход, она что-то делает и возвращает что-то на выход. Задач может быть много (сильно больше числа процессоров), они могут быть независимы друг от друга, или порождаться друг другом.

На первый взгляд может показаться, что всё это ничем не отличается от классических потоков со всеми вытекающими плюсами и минусами. Но это только на первый взгляд. Копнув глубже, я понял, что уже не чувствую себя художником из примера выше. Я чувствую себя владельцем крупной арт-мастерской. Мне ничего не нужно делать самому! У меня есть некоторые производственные мощности и очень грамотный управляющий. Когда мне приходит заказ на 100 картин, я вызываю его к себе и говорю : "Вот что надо сделать. Вот ресурсы. Вот инструкции по работе. Вперед!". И дальше я могу удаляться на свою любимый тропический остров лежать в шезлонге, попивая мартини, и знать, что работа будет выполнена. Управляющий сам оценит объем работ и имеющиеся ресурсы (CPU), наймет нужное количество работников (Tasks), проследит, чтобы каждому из них достались средства для работы и достачный (но посильный) объем задач. При этом по ходу работы он будет контролировать нагрузку, перекидывать задачи и ресурсы для достижения равномерной загруженности, подстёгивать лентяев и разгружать перегруженных трудяг. Вся работа будет выполнена строго по моим инструкциям: что должно делаться последовательно - будет сделанно именно так, что может быть распараллелено - обязательно будет. Более того, я уверен, что этот управляющий сделает всё вышеуказанное намного лучше меня - ведь на его создание и обучение очень много умных людей (сильно умнее меня) потратили очень много времени. Вряд ли я обладаю знаниями того же уровня для координации всей этой работы.

Лично мне такой подход к параллельному программированию нравится намного больше. Я не привязан к конкретным потокам, я не сильно беспокоюсь о низкоуровневых деталях. Конечно, кое-какие заморочки с синхронизацией остались (куда же без них!), но воспринимаются они совсем по-другому. В общем, я остался приятно удивлен библиотекой Intel TBB и советую всем, кто с ней еще не знаком - обязательно взглянуть.

Начать читать можно где-то отсюда.
Советую начинать с Tutorial - там всё коротко и весьма понятно. Если решите использовать библиотеку серьёзно - читайте также полную документацию и Design Patterns