Comments 52
По моему скромному мнению, не нужно путать две задачи — повышение вычислительной мощности и развитие алгоритмов и методов решения задач с использованием больших вычислений. Автор оригинального текста кажется призывает притормозить тем, кто занимается первой проблемой, и подождать тех, кто занят второй. Какой смысл? Наоборот, разумнее создавать запас по производительности, если существует такая возможность. Кто знает, может через некоторое время темпы развития «алгоритмов» перегонят темпы развития «железа», и тогда наработанный буфер будет очень кстати.
UFO just landed and posted this here
Да автор безусловно прав, Какой то университет или институт закупает Супер компьютер и потом думает что с ним делать. Супер компы нужны для обрабатывания большого объема информации. Например для определение каптчи и создание Кибернетического интеллекта.
Студент напишет код который будет работать. Но далеко не факт что с точки зрения скорости алгоритма, программа будет быстро работать!!!
Буду краток, нужны крупные исследования для улучшения технологий как таковых.
В любом случае у любой программы есть входные данные. Была бы хороша статья которые описывала какие математические расчеты производят с помощью супер компьютера.
Забавно другое, что для анализа данных адронного колайдера использовались сервера Яндекса, и распределенная сеть компьютеров, каждый мог загрузить объем данных и проанализировать его и снова загрузить обратно.
Студент напишет код который будет работать. Но далеко не факт что с точки зрения скорости алгоритма, программа будет быстро работать!!!
Буду краток, нужны крупные исследования для улучшения технологий как таковых.
В любом случае у любой программы есть входные данные. Была бы хороша статья которые описывала какие математические расчеты производят с помощью супер компьютера.
Забавно другое, что для анализа данных адронного колайдера использовались сервера Яндекса, и распределенная сеть компьютеров, каждый мог загрузить объем данных и проанализировать его и снова загрузить обратно.
Какой то университет или институт закупает Супер компьютер и потом думает что с ним делать.
А такое бывает? Известные мне мне суперкомпьютеры загружены чуть менее чем полностью, а простаивающих я вживую не видел…
Буду краток, нужны крупные исследования для улучшения технологий как таковых.
Такие исследования постоянно идут.
Была бы хороша статья которые описывала какие математические расчеты производят с помощью супер компьютера.
Спектр задач охватывает все области науки, по этому не сильно ошибаясь можно сказать, что любые.
Забавно другое, что для анализа данных адронного колайдера использовались сервера Яндекса, и распределенная сеть компьютеров, каждый мог загрузить объем данных и проанализировать его и снова загрузить обратно.
Почему забавно? Первичная обработка экспериментальных данных часто слабосвязная задача, по этому оптимально использовать распределенные решения, а в каком-либо моделировании преобладают сильносвязные задачи, по этому оптимальнее использовать суперкомпьютеры с быстрыми и с низкими задержками интерконнектами…
UFO just landed and posted this here
Это вопрос не отсутствия задач, а отсутствия грамотного администрирования ресурсов.
Вот если бы они его покупали на свои деньги…
Мой универ понтов ради купил 5 лет назад кластер (к сожалению мощностей не знаю) и всё. До сих пор он стоит в серверной выключенный, в то время как преподы на свои деньги докупают оперативы в преподовательский ПК в компьютерной аудитории, что бы рендер матлаба делать не на студенческих недокомпах а на преподавательском >_< (и этот рендер занимал четверть часа на каждого студента. а на студенческие компы просто вешал наглухо)
They said that Lomonosov does not.
Простите, что?
Уточните, пожалуйста, к какой части моего сообщения этот комментарий?
Уточните, пожалуйста, к какой части моего сообщения этот комментарий?
Да, виноват — комментировал с телефона на скорую руку.
Я апеллировал к этому абзацу:
>>А такое бывает? Известные мне мне суперкомпьютеры загружены чуть менее чем полностью, а >>простаивающих я вживую не видел…
Ибо в 2009 -2011 годах кластера РАН и новоиспеченный в те годы кластер МГУ «Ломоносов» работали, «мягко говоря», недогруженными.
Я апеллировал к этому абзацу:
>>А такое бывает? Известные мне мне суперкомпьютеры загружены чуть менее чем полностью, а >>простаивающих я вживую не видел…
Ибо в 2009 -2011 годах кластера РАН и новоиспеченный в те годы кластер МГУ «Ломоносов» работали, «мягко говоря», недогруженными.
Автор не хрен с горы, а один из ведущих разработчиков MPI, и о темпах развития алгоритмов знает не из вторых рук. Именно с этой позиции он пишет, что запас производительности должен быть лучше обоснован, чем сейчас.
На мой взгляд — наоборот, неразумно. Рост мощности провоцирует решение любой проблемы «в лоб» — методом грубой силы. Когда в руках молоток — любая проблема похожа на гвоздь. В результате мы имеем парадоксальную ситуацию, когда значительно более старший ПК выполняет задачи своего более современного собрата быстрее и лучше. Что не есть нормально, какими бы благими намерениями оно не декларировалось.
Это справедливо, когда рост мощности опережает потребности, а в HPC рост реальной мощности от потребностей значительно отстает.
Проблема в другом. Существующие метрики производительности перестали коррелировать с решаемыми задачами, а новых универсальных метрик и методик оценки не видно. Автор пишет не про избыток мощности, а про то, что используемая методика оценки этой мощности вызывает много вопросов.
Так, что если бы был молоток, то таких статей бы не было, а все бы радовались, но молотка, к сожалению, нет…
Проблема в другом. Существующие метрики производительности перестали коррелировать с решаемыми задачами, а новых универсальных метрик и методик оценки не видно. Автор пишет не про избыток мощности, а про то, что используемая методика оценки этой мощности вызывает много вопросов.
Так, что если бы был молоток, то таких статей бы не было, а все бы радовались, но молотка, к сожалению, нет…
Мне кажется об этом автор и говори, что надо проанализировать потребности, после чего решить, нужно ли по прежнему наращивать мощности или решать какие-то иные проблемы.
Я думаю, что вопрос не в том, нужно ли наращивать мощность, тут ответ однозначный — Нужно. Ни один ученый не откажется от возможности посчитать что-нибудь с большей точностью за меньшее время.
Вопрос в том, КАК наращивать мощность и в чем эту самую мощность измерять. И вот тут во всей красе появляются множество «каких-то иных проблем», а не только FLOPS'ы…
Вопрос в том, КАК наращивать мощность и в чем эту самую мощность измерять. И вот тут во всей красе появляются множество «каких-то иных проблем», а не только FLOPS'ы…
Ну понимаете, наращивание вычислительной мощности — это не дешевый процесс. И вопрос, стоит ли например университетам вкладываться во все более мощные машины, или может стоит обратить внимаение на другие аспекты.
Так что вопрос именно в том, КАК наращивать мощности, но в плане даже не способов и подходов, а в плане ресурсов. Является ли наращивание вычислительной мощности приоритетом?
Так что вопрос именно в том, КАК наращивать мощности, но в плане даже не способов и подходов, а в плане ресурсов. Является ли наращивание вычислительной мощности приоритетом?
Ну вот я сталкивался с такой проблемой, что доктора и аспиранты университетов знают, что они хотят посчитать, но их знания в программировании весьма поверхностны. В результате пишется «маленькая, но гаденькая программка» (с) на Матлабе, которая работает кучу времени и использует много памяти. Профессиональный программист может оптимизировать такую программу в десятки раз по обоим параметрам, но на это требуется время. Человеко-часы, человеко-дни. Шеф лаборатории предпочитает использовать время этого программиста для решения других задач, нежели оптимизация алгоритмов. Как-то приемлемо оно работает — и ладно.
Нанять больше программистов — не хватает денег. Самим разбираться в дебрях оптимального программирования — нет времени, его лучше использовать для собственно науки.
Думаю, лед тронется только тогда, когда удастся автоматизировать работу программистов в такой степени, чтобы программы автоматически составлялись по техзаданию.
Нанять больше программистов — не хватает денег. Самим разбираться в дебрях оптимального программирования — нет времени, его лучше использовать для собственно науки.
Думаю, лед тронется только тогда, когда удастся автоматизировать работу программистов в такой степени, чтобы программы автоматически составлялись по техзаданию.
Оптимизация алгоритмов в этих областях — это скорее задача ученых, а не программистов, так как слишком много факторов будут влиять на этот процесс и не факт, что алгоритм с лучшей временной сложностью подойдет для данного случая с точки зрения математики (например, алгоритм может просто не сойтись и тогда станет неважно, получили ли неправильный ответ за час или за секунду).
А вот с тем, что профессиональный программист иногда сможет ускорить имеющуюся реализацию, я согласен.
А вот с тем, что профессиональный программист иногда сможет ускорить имеющуюся реализацию, я согласен.
Программисты уже разучились доказывать сходимость и оценивать погрешность алгоритмов?
Вот именно. Все вышеперечисленное является задачей скорее программиста, нежели ученого. Ученому надо просто посчитать, он знает формулы из теории. Подобрать подходящий алгоритм и реализацию — задача программиста. Ну или человека на стыке между двумя этими профессиями. Очевидно, что программист, работающий в этой области, должен иметь представление о задачах, которые решаются учеными.
Ожидать, что какой-нибудь биолог досконально изучит вопросы сходимости алгоритмов и погрешностей при вычислениях — слишком оптимистично. Да и это будет напрасной тратой его времени, пусть лучше биологией занимается.
Ожидать, что какой-нибудь биолог досконально изучит вопросы сходимости алгоритмов и погрешностей при вычислениях — слишком оптимистично. Да и это будет напрасной тратой его времени, пусть лучше биологией занимается.
Думаю, лед тронется только тогда, когда удастся автоматизировать работу программистов в такой степени, чтобы программы автоматически составлялись по техзаданию.
Боюсь Вас огорчить, но в общем случае, это алгоритмически неразрешимая задача.
Человек может составлять алгоритмы по техзаданию. Следовательно, можно ожидать, что когда-нибудь будет создана машина, делающая это по меньшей мере не хуже, чем человек.
Надо полагать, для написания алгоритмов по техзаданию понадобится разработать строго формальный язык техзаданий, и программист будет заниматься тем же программированием — писать техзадание для машины, которая уже создаст из этого дела алгоритм.
upd: собственно, то же реализовано в программировании и сейчас — человек пишет на понятном ему языке, машина транслирует этот язык в машинные коды. Возможно, когда-то и будет сделан шаг, что человек будет писать на естественном языке, но слишком уж живой этот язык. А строгая формализация правил написания техзаданий уже равносильна потере естественности.
upd: собственно, то же реализовано в программировании и сейчас — человек пишет на понятном ему языке, машина транслирует этот язык в машинные коды. Возможно, когда-то и будет сделан шаг, что человек будет писать на естественном языке, но слишком уж живой этот язык. А строгая формализация правил написания техзаданий уже равносильна потере естественности.
Человек может составлять алгоритмы по техзаданию.
Спорное утверждение. :)
Речь идет не только и не столько об оптимизации алгоритмов, а о том, какова должна быть аппаратура, чтобы эффективно решать поставленные задачи. Тезис в том, что флопсы в качестве (единственного) мерила производительности не годятся. Действительно, в большинстве численных задач достигается довольно низкий КПД (отношение реально полученной производительности к пиковой, и то и другое измеряется в тех же флопсах). На Линпаке КПД обычно бывает в пределах 50%...90%, но это самый легкий класс задач; а бывают задачи, где КПД составляет доли процентов и вовсе не из-за тупо написанных алгоритмов — затык в том, чтобы накормить вычислительные устройства данными.
Правильно ли я понял что Производительность != Способности_решать_насущные_проблемы?
Так же как Мегапиксельность != Шедевральности, а Лошадинные_Силы != Мастерство_Вождения?
Так же как Мегапиксельность != Шедевральности, а Лошадинные_Силы != Мастерство_Вождения?
Я считаю, что для таких мощностей нужны подходящие алгоритмы, которые, например, хорошо распараллеливаются
Автор статьи прав, но на мой взгляд в заключении перевода есть неточность, которая искажает смысл статьи.
некорректно переводить как:
И дело тут вот в чем. К настоящему времени сама мера FLOPS перестала быть адекватной мерой для решаемых задач. Метрика во FLOPS'ах — это производительность суперкомпьютера на одной конкретной задаче решения СЛАУ, а реальные вычисления строятся далеко не только на методах их решения. Даже производители процессоров в кулуарах говорят, что FLOPS'ы стали пузомеркой, а не отражением реальных задач.
Автор скорее имеет ввиду нечто подобное: «Для того, чтобы экзамасштабы стали реальными мы должны перестать говорить только об экза(флопс)шкале измерений.». И тем самым намекает на существующий перекос в сторону оптимизации для бенчмарка LINPACK, а не реальных задач.
И подвижки в этой области уже есть. Можно привести в пример рейтинги Top500, где измеряют FLOPSы и рейтинг Graph500, где измеряют производительность обработки больших массивов данных и места в этих рейтингах не совпадают.
To make Exascale a reality, we need to stop talking just about Exascale.
некорректно переводить как:
Для того, чтобы новые рекордные производительности стали реальностью, мы должны перестать гнаться за производительностью.
И дело тут вот в чем. К настоящему времени сама мера FLOPS перестала быть адекватной мерой для решаемых задач. Метрика во FLOPS'ах — это производительность суперкомпьютера на одной конкретной задаче решения СЛАУ, а реальные вычисления строятся далеко не только на методах их решения. Даже производители процессоров в кулуарах говорят, что FLOPS'ы стали пузомеркой, а не отражением реальных задач.
Автор скорее имеет ввиду нечто подобное: «Для того, чтобы экзамасштабы стали реальными мы должны перестать говорить только об экза(флопс)шкале измерений.». И тем самым намекает на существующий перекос в сторону оптимизации для бенчмарка LINPACK, а не реальных задач.
И подвижки в этой области уже есть. Можно привести в пример рейтинги Top500, где измеряют FLOPSы и рейтинг Graph500, где измеряют производительность обработки больших массивов данных и места в этих рейтингах не совпадают.
Спасибо за ценное замечание. И да, с тех пор, когда это было близко к реальности, FLOPS'ы засели в мозгах как синоним к «производительности».
Мне кажется, что раньше FLOPS'ы еще меньше отражали реальную производительность, по крайней мере до того, как американцы сделали прорыв в области технологий разделяемой памяти количество разных архитектур больших вычислителей зашкаливало. И сравниваться они могли только на реальных задачах.
Одна из причин, почему раньше FLOPSы могли отражать реальность — раньше не было всяких SSE, out-of-order исполнения и других страшных слов, по этому FLOPSы можно было конвертировать в операции из реальной задачи. Сейчас это соотношение слабопредсказуемо. Интерконнект скорее влияет на отношение пиковой и LINPACK-производительности, но эта относительная величина более близка к практике чем абсолютные значения сейчас.
Расскажите пожалуйста подробнее, о чем идет речь?
как американцы сделали прорыв в области технологий разделяемой памяти
Расскажите пожалуйста подробнее, о чем идет речь?
Да просто система кэшей и их когерентности в связке с быстрыми шинами и другими SMP технологиями. До этого вычислители развивались, грубо говоря, путем разработки топологий и иерархических узлов.
Для HPC эти технологии не так критичны, так как это машины с распределенной памятью и они даже не всегда поддерживают многозадачность в рамках одного вычислительного узла.
А интерконнекты, топология и иерархия вычислительных узлов(ядер) — это сейчас еще большая головная боль, так как производительности процессоров выросли, скорости передачи данных выросли, а задержки никуда не делись из-за ограничения скорости света, а сетевые задержки могут всю производительность свести в ноль. Основные проблемы сейчас не в узлах, а в соединяющих их сетях по сути.
А интерконнекты, топология и иерархия вычислительных узлов(ядер) — это сейчас еще большая головная боль, так как производительности процессоров выросли, скорости передачи данных выросли, а задержки никуда не делись из-за ограничения скорости света, а сетевые задержки могут всю производительность свести в ноль. Основные проблемы сейчас не в узлах, а в соединяющих их сетях по сути.
А как Вы думаете считается производительность вашей функции умножения матриц или быстрого преобразования Фурье в этих самых ФЛОПСАХ?
Я ответ знаю, т.к. сам считал тесты линейной алгебры и FFT. Может быть и Вы, его знаете. Тогда, давайте, сравним знания и подходы.
Пусть Вы имеете теоретический алгоритм. На нем вычисляете количество операций. Потом Вы делаете замер реальных вызовов ваших функций, которые АКТИВНО используют все, что дает Вам процессор: SSE, кэши и то, на что хватит ума у программиста.
Затем поделив количество операций из теоретического алгоритма на реальное время получается FLOPS показатель.
И это значение будет разным в зависимости от того, где лежат Ваши данные, и чем занимаются другие процессы на машине, когда вы вызываете вычислительные процедуры.
Так что FLOPS все еще отражают реальную производительность аппаратно-программного решения, хотя бы в пределах одного вычислительного узла.
А как пошел Интерконнект в вашем кластере — тут да, тут начинается порнография )
Я ответ знаю, т.к. сам считал тесты линейной алгебры и FFT. Может быть и Вы, его знаете. Тогда, давайте, сравним знания и подходы.
Пусть Вы имеете теоретический алгоритм. На нем вычисляете количество операций. Потом Вы делаете замер реальных вызовов ваших функций, которые АКТИВНО используют все, что дает Вам процессор: SSE, кэши и то, на что хватит ума у программиста.
Затем поделив количество операций из теоретического алгоритма на реальное время получается FLOPS показатель.
И это значение будет разным в зависимости от того, где лежат Ваши данные, и чем занимаются другие процессы на машине, когда вы вызываете вычислительные процедуры.
Так что FLOPS все еще отражают реальную производительность аппаратно-программного решения, хотя бы в пределах одного вычислительного узла.
А как пошел Интерконнект в вашем кластере — тут да, тут начинается порнография )
Железо легко продавать. Алгоритмы (библиотеки) продать немного сложней + всегда есть риск появления чужого (возможно открытого) решения. Как итог, железо развивается коммерческим сектором по естественным причинам. Алгоритмы, наоборот, рождаются/улучшаются в университетах на гранты. Что медленно, не так качественно, не так ориентированно на результат. Поменять это простым призывом нельзя, нужно чтобы фундаментальные исследования проблем кто-то покупал.
Напомнило мне CINT и тесты его производительности.
Картинка в формате BMP с расширением JPG? Тонко…
Прикладная балталогия: если в результате рассуждений вы пришли к выводу, который начинается со слова «пора» или «надо» — значит где-то в рассуждения вкралась ошибка, можно передохнуть и начинать рассуждать с начала. Экономит уйму времени.
Немного не в тему, но производителям мобильных устройств тоже стоило бы задуматься над прекращением наращивания разрешений, оперативки, мощности процессора и наконец задуматься над батарейкой
вспомнился один из ярких примеров, как люди находят способ обойти ограничения вычислительной мощности не увеличивая флопсы.
<grammar_nazi_mode>
Согласно ГОСТ 8.417-2002 кратная приставка для 10^18 пишется так: экса-.
Хотя экза- мне тоже больше нравится.
</grammar_nazi_mode>
Согласно ГОСТ 8.417-2002 кратная приставка для 10^18 пишется так: экса-.
Хотя экза- мне тоже больше нравится.
</grammar_nazi_mode>
Sign up to leave a comment.
2013: пора прекратить погоню за флопсами