JUNG Graph Performance — PageRank на плотном графике

Мне интересно, является ли относительно низкая производительность, которую я испытываю с JUNG2 и PageRank, разумной, учитывая данные, которые я использую.

Учитывая граф с ~200 вершинами и ~40000 ребер, вычисление PageRank графа занимает около 15 секунд. Учитывая граф с ~900 вершинами и ~800000 ребер, вычисление PageRank графа занимает почти 5 минут.

Я понимаю, что эти графики очень плотные, и, возможно, естественно ожидать, что для расчета потребуется некоторое время. Однако эти графы не особенно велики, и с такой скоростью было бы невозможно вычислить что-либо, кроме небольшого подмножества графа за раз. (примерно 8 часов для 10 000 вершин и 100 000 000 ребер).

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

Я запускаю jvm в режиме сервера с кучей пространства в куче и подтверждаю, что весь график помещается в память, и своп не используется.

Результаты ранжирования верны, их сумма равна 1, и они соответствуют тестовым примерам в источнике Юнга и в других местах.

Может быть, для этого есть гораздо более высокопроизводительный подход или библиотека? Но, даже если бы это было в 10 раз быстрее, не означает ли тот факт, что его временная сложность пропорциональна количеству ребер, что я быстро выйду за пределы какого бы то ни было подхода Я использую?

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

Кроме того, у меня медленная коробка, Dual Core 1Ghz, поэтому ваши цифры, вероятно, будут намного лучше (например, 4-5 секунд для моего первого примера), но суть верна. Меня больше всего беспокоит, ожидается ли, что код будет работать на порядок быстрее или будет масштабироваться логарифмически.

В любом случае, спасибо за ваши идеи.


person Scott Klarenbach    schedule 01.11.2014    source источник


Ответы (1)


Вкратце: асимптотически говоря, это неотъемлемое ограничение алгоритма PageRank.

Любой алгоритм, который хочет учитывать все ребра, будет иметь временную сложность Omega(|E|). И любой алгоритм, который пытается измерить глобальные топологические свойства (например, меры собственного вектора, такие как PageRank), должен будет просмотреть каждое ребро хотя бы один раз.

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

Обрамляющий вопрос: какова семантика вашего графика и что вы надеетесь узнать, вычисляя PageRank? Какую проблему ты пытаешься решить?

person Joshua O'Madadhain    schedule 03.11.2014
comment
Я ранжирую предложения в теле текста, где узлы — это предложения, а края — их семантическое сходство. Как вы можете себе представить, обработка nlp уже стоит дорого еще до того, как я доберусь до Page Rank. Я могу значительно уменьшить количество ребер, убрав ребра с низкой оценкой, которые вряд ли повлияют на конечный результат. Кроме того... я использую ориентированный граф с 2 (Vn) ребрами для учета различных весов для каждой исходной вершины. Это можно улучшить, переопределив getEdgeWeights, как вы предлагаете в соответствующем вопросе. - person Scott Klarenbach; 04.11.2014
comment
Другими словами... кажется, что мой единственный вариант - уменьшить количество ребер любыми средствами, необходимыми для расчета любого большого графа. Но интересно, как рассчитываются очень большие графики? Просто бросить аппаратное обеспечение на проблему? - person Scott Klarenbach; 04.11.2014
comment
Я согласен с тем, что NLP для всех пар, вероятно, будет немного дороже, чем расчет PR. Чтобы уменьшить ребра, вы можете попробовать сгруппировать предложения, если у вас есть способ сделать то, что не является также O (N), а затем вычислить ребра внутри кластера. Не уверен, что интересного в расчете PR для такого рода сети, но это ваша проблема. :) - person Joshua O'Madadhain; 04.11.2014
comment
Что касается вычислений для больших графов, есть два основных ответа: (1) большие полные графы очень редки (и непрактичны для очень большого количества узлов) и (2) да, для больших графов необходимо бросать ресурсы на решение такого рода проблем. Для разреженных графов вычисления обычно, по крайней мере, частично распараллеливаются, хотя управление параллелизмом для графовых алгоритмов само по себе является сложной задачей. - person Joshua O'Madadhain; 04.11.2014