Обсуждение участника:Viktorrulev
1 Статья Участник:Viktorrulev/Алгоритм устойчивой кластеризации с иcпользованием связей
1.1 Замечания
- Формулы нужно оформить в отдельные блоки для лучшей читаемости Teplov (обсуждение) 01:13, 23 октября 2016 (MSK)
- Исправлено (сделать все формулы в одном блоке и выровнять по левой стороне вики не позволяет) Viktorrulev (обсуждение) 12:18, 26 октября 2016 (MSK)
- В п. 2.7 необходимо указать ссылку на источник Teplov (обсуждение) 01:13, 23 октября 2016 (MSK)
- Исправлено Viktorrulev (обсуждение) 12:18, 26 октября 2016 (MSK)
- В п. 1.5 указать на каком языке представлена реализация Teplov (обсуждение) 01:13, 23 октября 2016 (MSK)
- Исправлено Viktorrulev (обсуждение) 12:18, 26 октября 2016 (MSK)
- В п. в п. 1.7 не указано для каких параметров построен граф. Teplov (обсуждение) 01:13, 23 октября 2016 (MSK)
- Исправлено Viktorrulev (обсуждение) 12:18, 26 октября 2016 (MSK)
- Нужно более полное описание вычислительной мощности алгоритма Teplov (обсуждение) 01:13, 23 октября 2016 (MSK)
- Дополнено Viktorrulev (обсуждение) 12:18, 26 октября 2016 (MSK)
- Отсутствуют данные по численному эксперименту и масштабируемости. Teplov (обсуждение) 15:01, 22 ноября 2016 (MSK)
2 Замечания от 2016_12_11 1
Разделы 1.1, 1.2, 1.3 описывают конкретную область (покупательная корзина и прочее), не имеющую никакого значения с точки зрения математической постановки задачи. Использование термина "транзакция" неоправданно затрудняет восприятие текста. Появляется много терминов, некоторые из к4оторых в контексте суперкомпьютерных технологий имеют совершенно иной, нежели в 'этом тексте смысл.
Например:
транзакция - передача блока данных;
домен - множество вершин расчетной сетки, обрабатываемых одним процессором.
- Я придерживался терминологии статьи. Переделал, теперь вроде бы используются только общепринятые термины. Viktorrulev (обсуждение) 12:29, 16 декабря 2016 (MSK)
Есть граф, вершины, метрика и взвешенные рёбра. Почему нельзя ограничиться этой общепринятой терминологией?
- Эта статья о кластеризации точек в пространстве, графы в описании алгоритма из статьи ни разу не упоминаются. Не вижу смысла писать о них в этой статье. Viktorrulev (обсуждение) 12:29, 16 декабря 2016 (MSK)
Стоит ли заставлять читателя запоминать термин "домен признака", хотя по существу в статье он не используется?
Дополните статью таблицей (хотя бы для двух-трёх размеров графа, например, M=500,1000,1500) с графами: число потоков, время выполнения, ускорение, эффективность.
Обратите внимание, в тексте нет понятия points, а на графике есть. Используйте одну систему обозначений.
- Заменил. Viktorrulev (обсуждение) 12:29, 16 декабря 2016 (MSK)
Раздел 1.6
Замените текст "имеет такую же вычислительную сложность, как и предыдущий шаг. " на "имеет сложность O(M). ". Не заставляйте читателя метаться по тексту, ему и так непросто.
- Исправил. Viktorrulev (обсуждение) 12:29, 16 декабря 2016 (MSK)
Раздел 1.7
Оценка сложности перемножения матриц в Вашей статье то [math]O(M^{2.37})[/math], то [math]O(M^2m_{nbr})[/math], что вполне можно понять, но ссылку на информационный граф перемножения плотных матриц указана на совершенно другой алгоритм, с оценкой [math]O(M^{3})[/math]. Определитесь, пожалуйста.
- Я указал ссылку на статью в алговики, в которой рассказываются общие вещи о перемножении плотных матриц. При рассмотрении ресурса параллелизма я рассмотрел наивное перемножение матриц, потому что на общую асимптотику оно не влияет, а найти высоту и ширину ЯПФ более сложных и быстрых алгоритмов у меня не получилось. На два других алгоритма ссылалась статья, и я решил о них упомянуть. Уточнил в статье, чтобы у читателя не возникало сомнений. Viktorrulev (обсуждение) 12:29, 16 декабря 2016 (MSK)
Если я правильно понял, Вы самостоятельно написали программы. Укажите это явно в разделе 2.4.
- Да. Указал это, дал ссылку на репозиторий на гитлабе. Viktorrulev (обсуждение) 12:29, 16 декабря 2016 (MSK)
Есть ли соображения, в чём причина отсутствия ускорения на Ломоносове? Какие там времена получились?
--Lira (обсуждение) 23:42, 11 декабря 2016 (MSK)
- Возможно потому, что я как-то неправильно собираю и запускаю проект, или неправильно измеряю время. Но скорее всего из-за того, что в реализации на MPI после каждой итерации каждый процесс несколько раз обменивается с каждым (два allgather) достаточно большими объемами информации. Придумать, как это сделать в помощью одного allreduce, у меня не получилось, хотя, возможно, это ускорило бы обмен. OpenMP-реализации на Ломоносове, как я понял, в принципе не очень эффективны (возможно, получилось бы быстрее, если бы OpenMP на Ломоносове поддерживал пользовательские reduce-операции). Результаты OpenMP:
- Threads: 1, time: 0.15 0.85 2.46 5.54 10.48 17.81 27.94 41.44 58.63 80.34
- Threads: 8, time: 0.2 0.87 2.43 5.43 10.31 17.51 27.18 40.42 57.33 78.81
- Threads: 16, time: 11.68 25.73 40.48 57.13 75.34 94.83 118.98 139.17 173.92 210.98
- Threads: 24, time: 18.95 39.87 61.52 85.27 110.02 136.77 167.49 201.79 237.88 283.29
- Результаты MPI-реализации не могу найти, но, если надо, могу получить. Насколько я помню, в них в зависимости от количества процессов время выполнения стабильно росло. Viktorrulev (обсуждение) 12:29, 16 декабря 2016 (MSK)
