Скажу честно, мы с некоторым недоверием посмотрели на эту идею:
— Как мы применим 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.

Type Signature	Java Type
Z	boolean
B	byte
C	char
S	short
I	int
J	long
F	float
D	double
L fully-qualified-class ;	fully-qualified-class
[ type	type[]
( arg-types ) ret-type	method type

For example, the Java method:
long f (int n, String s, int[] arr);

has the following type signature:
(ILjava/lang/String;[I)J

Хм.. не густо и не особо понятно. Попробую описать своими словами.

JNI-сигнатура состоит из списка типов формальных параметров и типа возвращаемого значения. Формат записи похож на Pascal-style определения методов: сначала параметры потом возвращаемое значение (к слову, не многие знают что многие концепции Java были скопированы с языка и операционной системы Oberon являющихся дальнейшим развитием идей Н.Вирта, создателя Pascal). В JNI-сигнатурах пробелы запрещены - каждый символ имеет значение и не может быть выброшен без потери смысла. Элементы списка параметров не разделяются никакими символами. О обозначении типов формальных параметров ниже. Условно можно выделить 4 правила:

1. Примитивные типы: кодируются соответствующей буквой латинского алфавита (см.таблицу выше):
2. Массивы: для обозначения того, чо будет передаваться не скалярный тип, а массив используется символ "[". Находящееся правее квадратной скобки обозначение типа - тип элемента массива. Размер массива не обозначается.
3. Ссылочные типы (объекты): Обозначение класса начинается с заглавной латинской L после которой идет без пробелов полное имя класса, состоящее из: пакета (вложенные пакеты разделяются слешами) и имени класса (также разделенных слешем). Запись является регистро-зависимой. После имени класса должна обязательно идти запятая, являющаяся окончанием определения типа. Обращаю внимание, что опускать запятую нельзя (в том числе и в описании типа возвращаемого значения метода).
4. Возвращаемый тип void (т.е. ничего) заменяются символом "V"

Теперь продемонстрирую это на практике:

1. int MyMethod1(float a, char b) -> (FC)I

2. int[] MyMethod2(long[] a) -> ([J)[I

3. void MyMethod3(package1.subpackage2.MyClass[] a, String b) -> (Lpackage1/subpackage2/MyClass;Ljava/lang/String;)V

4. package1.subpackage2.MyClass[] MyMethod4(String a, Class[] b, float c) -> (Ljava/lang/String;[java/lang/Class;F)[Lpackage1/subpackage2/MyClass;

Так что магические на первый взгляд последовательности символов оказываются достаточно просты (с отличии от сигнатур в языке C).

P.S. Набирал эту заметку на планшете в метро. Оказалось, планшеты вполне пригодны для создания контента. Хотя над удобством клавиатуры андроида еще можно поработать))

Я решила рассказать о том, что не вошло в наше отправленное решение на конкурс 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-дерево? Потому что почти суффиксные, но не совсем.

//this match can be shifted on i and j
if(i + 1 < refSeq.length() && j + 1 < otherSeq.length() && L[i][j] <= L[i+1][j+1])
     continue;
//this match can be shifted on j
if(i < refSeq.length() && j + 1 < otherSeq.length() && L[i][j] <= L[i][j+1])
     continue;
//this match can be shifted on i
if(i + 1 < refSeq.length() && j < otherSeq.length() && L[i][j] <= L[i+1][j])
     continue;

Основная идея заключается в том, что указанный код эквивалентен 2 условиям:

Строки начинающиеся с позиций i и j должны быть отброшены в том случае, если
(1) число подряд идущих одинаковых символов с символов i и j различается или
(2) символы в позициях i-1 и j-1 совпадают.

Рассмотрим пример:

1234567890123456
ATGCCCCCCCCCCGTA
TGACCCCCCATG

Строки 4-9 и 4-9 отбрасываем, так как в первой строке с 4 символа идут 10 одинаковых символов, а во второй только 6. С другой для строк 8-13 и 4-9 условие выполняется и они вполне могут быть искомым совпадением.

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

Список из элементов, по два значения в каждом: {длина 1 участка, повторяются ли на нем символы}, {длина 2 участка, повторяются ли на нем символы}, {длина 3 участка, повторяются ли на нем символы}.

Главное преимущество такого хранения — это очень низкие затраты памяти. Недостаток: нет возможности получить значение для случайной позиции. Но если список (строку) проходить последовательно, то получается очень быстро. Частично решить указанный недостаток можно, составив массив ключевых позиций, и тогда можно начинать просмотр с них.
Уменьшить длину списка можно рассматривая участки с повторами длиной меньше или равной длине минимальной искомой строки как участки с не повторяющимися символами и группируя их с соседними участками (если там символы тоже не повторяются).

Задача состояла в том, чтобы найти общие подстроки длины не менее 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 – размер выхода, что уже является практически линейным решением.

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