Обсуждение участника:Viktorrulev: различия между версиями

Материал из Алговики
Перейти к навигации Перейти к поиску
 
Строка 26: Строка 26:
 
домен - множество вершин расчетной сетки, обрабатываемых одним процессором.
 
домен - множество вершин расчетной сетки, обрабатываемых одним процессором.
  
 +
:: Я придерживался терминологии статьи. Переделал, теперь вроде бы используются только общепринятые термины. [[Участник:Viktorrulev|Viktorrulev]] ([[Обсуждение участника:Viktorrulev|обсуждение]]) 12:29, 16 декабря 2016 (MSK)
  
 
Есть граф, вершины, метрика и взвешенные рёбра. Почему нельзя ограничиться этой общепринятой терминологией?  
 
Есть граф, вершины, метрика и взвешенные рёбра. Почему нельзя ограничиться этой общепринятой терминологией?  
 +
 +
:: Эта статья о кластеризации точек в пространстве, графы в описании алгоритма из статьи ни разу не упоминаются. Не вижу смысла писать о них в этой статье. [[Участник:Viktorrulev|Viktorrulev]] ([[Обсуждение участника:Viktorrulev|обсуждение]]) 12:29, 16 декабря 2016 (MSK)
 +
 
Стоит ли заставлять читателя запоминать термин "домен признака", хотя по существу в статье он не используется?
 
Стоит ли заставлять читателя запоминать термин "домен признака", хотя по существу в статье он не используется?
 
  
 
Дополните статью таблицей (хотя бы для двух-трёх размеров графа, например, M=500,1000,1500) с графами: число потоков, время выполнения, ускорение, эффективность.
 
Дополните статью таблицей (хотя бы для двух-трёх размеров графа, например, M=500,1000,1500) с графами: число потоков, время выполнения, ускорение, эффективность.
  
 
Обратите внимание, в тексте нет понятия points, а на графике есть. Используйте одну систему обозначений.
 
Обратите внимание, в тексте нет понятия points, а на графике есть. Используйте одну систему обозначений.
 +
 +
:: Заменил. [[Участник:Viktorrulev|Viktorrulev]] ([[Обсуждение участника:Viktorrulev|обсуждение]]) 12:29, 16 декабря 2016 (MSK)
  
 
  Раздел 1.6  
 
  Раздел 1.6  
 
Замените текст "имеет такую же вычислительную сложность, как и предыдущий шаг. "
 
Замените текст "имеет такую же вычислительную сложность, как и предыдущий шаг. "
 
на "имеет сложность O(M). ". Не заставляйте читателя метаться по тексту, ему и так непросто.
 
на "имеет сложность O(M). ". Не заставляйте читателя метаться по тексту, ему и так непросто.
 +
 +
:: Исправил. [[Участник:Viktorrulev|Viktorrulev]] ([[Обсуждение участника:Viktorrulev|обсуждение]]) 12:29, 16 декабря 2016 (MSK)
  
 
  Раздел 1.7  
 
  Раздел 1.7  
 
Оценка сложности перемножения матриц в Вашей статье то <math>O(M^{2.37})</math>, то <math>O(M^2m_{nbr})</math>,
 
Оценка сложности перемножения матриц в Вашей статье то <math>O(M^{2.37})</math>, то <math>O(M^2m_{nbr})</math>,
 
что вполне можно понять, но ссылку на информационный граф перемножения плотных матриц указана на совершенно другой алгоритм, с оценкой <math>O(M^{3})</math>. Определитесь, пожалуйста.
 
что вполне можно понять, но ссылку на информационный граф перемножения плотных матриц указана на совершенно другой алгоритм, с оценкой <math>O(M^{3})</math>. Определитесь, пожалуйста.
 +
 +
:: Я указал ссылку на статью в алговики, в которой рассказываются общие вещи о перемножении плотных матриц. При рассмотрении ресурса параллелизма я рассмотрел наивное перемножение матриц, потому что на общую асимптотику оно не влияет, а найти высоту и ширину ЯПФ более сложных и быстрых алгоритмов у меня не получилось. На два других алгоритма ссылалась статья, и я решил о них упомянуть. Уточнил в статье, чтобы у читателя не возникало сомнений. [[Участник:Viktorrulev|Viktorrulev]] ([[Обсуждение участника:Viktorrulev|обсуждение]]) 12:29, 16 декабря 2016 (MSK)
  
 
Если я правильно понял, Вы самостоятельно написали программы. Укажите это явно в разделе 2.4.  
 
Если я правильно понял, Вы самостоятельно написали программы. Укажите это явно в разделе 2.4.  
 +
 +
:: Да. Указал это, дал ссылку на репозиторий на гитлабе. [[Участник:Viktorrulev|Viktorrulev]] ([[Обсуждение участника:Viktorrulev|обсуждение]]) 12:29, 16 декабря 2016 (MSK)
  
 
Есть ли соображения, в чём причина отсутствия ускорения на Ломоносове? Какие там времена получились?
 
Есть ли соображения, в чём причина отсутствия ускорения на Ломоносове? Какие там времена получились?
+
 
 
--[[Участник:Lira|Lira]] ([[Обсуждение участника:Lira|обсуждение]]) 23:42, 11 декабря 2016 (MSK)
 
--[[Участник:Lira|Lira]] ([[Обсуждение участника: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|Viktorrulev]] ([[Обсуждение участника:Viktorrulev|обсуждение]]) 12:29, 16 декабря 2016 (MSK)

Текущая версия на 12:29, 16 декабря 2016

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)