Высокопроизводительные вычисления: проблемы и решения

    Компьютеры, даже персональные, становятся все сложнее. Не так уж давно в гудящем на столе ящике все было просто — чем больше частота, тем больше производительность. Теперь же системы стали многоядерными, многопроцессорными, в них появились специализированные ускорители, компьютеры все чаще объединяются в кластеры.
    Зачем? Как во всем этом многообразии разобраться?
    Что значит SIMD, SMP, GPGPU и другие страшные слова, которые встречаются все чаще?
    Каковы границы применимости существующих технологий повышения производительности?

    Введение


    Откуда такие сложности?

    Компьютерные мощности быстро растут и все время кажется, что все, существующей скорости хватит на все.
    Но нет — растущая производительность позволяет решать проблемы, к которым раньше нельзя было подступиться. Даже на бытовом уровне есть задачи, которые загрузят ваш компьютер надолго, например кодирование домашнего видео. В промышленности и науке таких задач еще больше: огромные базы данных, молекулярно-динамические расчеты, моделирование сложных механизмов — автомобилей, реактивных двигателей, все это требует возрастающей мощности вычислений.
    В предыдущие годы основной рост производительности обеспечивался достаточно просто, с помощью уменьшения размеров элементов микропроцессоров. При этом падало энергопотребление и росли частоты работы, компьютеры становились все быстрее, сохраняя, в общих чертах, свою архитектуру. Менялся техпроцесс производства микросхем и мегагерцы вырастали в гигагерцы, радуя пользователей возросшей производительностью, ведь если «мега» это миллион, то «гига» это уже миллиард операций в секунду.
    Но, как известно, рай бывает либо не навсегда, либо не для всех, и не так давно он в компьютерном мире закончился. Оказалось, частоту дальше повышать нельзя — растут токи утечки, процессоры перегреваются и обойти это не получается. Можно, конечно, развивать системы охлаждения, применять водные радиаторы или совсем уж жидким азотом охлаждать — но это не для каждого пользователя доступно, только для суперкомпьютеров или техноманьяков. Да и при любом охлаждении возможность роста была небольшой, где-то раза в два максимум, что для пользователей, привыкших к геометрической прогрессии, было неприемлемо.
    Казалось, что закон Мура, по которому число транзисторов и связанная с ним производительность компьютеров удваивалась каждые полтора-два года, перестанет действовать.
    Пришло время думать и экспериментировать, вспоминая все возможные способы увеличения скорости вычислений.

    Формула производительности

    Возьмем самую общую формулу производительности:



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



    Первая часть полученного произведения — количество инструкций, выполняемых за один такт (IPC, Instruction Per Clock), вторая — количество тактов процессора в единицу времени, тактовая частота.
    Таким образом, для увеличения производительности нужно или поднимать тактовую частоту или увеличивать количество инструкций, выполняемых за один такт.
    Т.к. рост частоты остановился, придется увеличивать количество исполняемых «за раз» инструкций.

    Включаем параллельность


    Как же увеличить количество инструкций, исполняемых за один такт?
    Очевидно, выполняя несколько инструкций за один раз, параллельно. Но как это сделать?
    Все сильно зависит от выполняемой программы.
    Если программа написана программистом как однопоточная, где все инструкции выполняются последовательно, друг за другом, то процессору (или компилятору) придется «думать за человека» и искать части программы, которые можно выполнить одновременно, распараллелить.

    Параллелизм на уровне инструкций


    Возьмем простенькую программу:
    a = 1
    b = 2
    c = a + b

    Первые две инструкции вполне можно выполнять параллельно, только третья от них зависит. А значит — всю программу можно выполнить за два шага, а не за три.
    Процессор, который умеет сам определять независимые и непротиворечащие друг другу инструкции и параллельно их выполнять, называется суперскалярным.
    Очень многие современные процессоры, включая и последние x86 — суперскалярные процессоры, но есть и другой путь: упростить процессор и возложить поиск параллельности на компилятор. Процессор при этом выполняет команды «пачками», которые заготовил для него компилятор программы, в каждой такой «пачке» — набор инструкций, которые не зависят друг от друга и могут исполняться параллельно. Такая архитектура называется VLIW (very long instruction word — «очень длинная машинная команда»), её дальнейшее развитие получило имя EPIC (explicitly parallel instruction computing) — микропроцессорная архитектура с явным параллелизмом команд)
    Самые известные процессоры с такой архитектурой — Intel Itanium.
    Есть и третий вариант увеличения количества инструкций, выполняемых за один такт, это технология Hyper Threading В этой технологии суперскалярный процессор самостоятельно распараллеливает не команды одного потока, а команды нескольких (в современных процессорах — двух) параллельно запущенных потоков.
    Т.е. физически процессорное ядро одно, но простаивающие при выполнении одной задачи мощности процессора могут быть использованы для выполнения другой. Операционная система видит один процессор (или одно ядро процессора) с технологией Hyper Threading как два независимых процессора. Но на самом деле, конечно, Hyper Threading работает хуже, чем реальные два независимых процессора т.к. задачи на нем будут конкурировать за вычислительные мощности между собой.

    Технологии параллелизма на уровне инструкций активно развивались в 90е и первую половину 2000х годов, но в настоящее время их потенциал практически исчерпан. Можно переставлять местами команды, переименовывать регистры и использовать другие оптимизации, выделяя из последовательного кода параллельно исполняющиеся участки, но все равно зависимости и ветвления не дадут полностью автоматически распараллелить код. Параллелизм на уровне инструкций хорош тем, что не требует вмешательства человека — но этим он и плох: пока человек умнее микропроцессора, писать по-настоящему параллельный код придется ему.

    Параллелизм на уровне данных


    Векторные процессоры

    Мы уже упоминали скалярность, но кроме скаляра есть и вектор, и кроме суперскалярных процессоров есть векторные.
    Векторные процессоры выполняют какую-то операцию над целыми массивами данных, векторами. В «чистом» виде векторные процессоры применялись в суперкомьютерах для научных вычислений в 80-е годы.
    По классификации Флинна, векторные процессоры относятся к SIMD — (single instruction, multiple data — одиночный поток команд, множественный поток данных).
    В настоящее время в процессорах x86 реализовано множество векторных расширений — это MMX, 3DNow!, SSE, SSE2 и др.
    Вот как, например, выглядит умножение четырех пар чисел одной командой с применением SSE:

    float a[4] = { 300.0, 4.0, 4.0, 12.0 };
    float b[4] = { 1.5, 2.5, 3.5, 4.5 };
    __asm {
    movups xmm0, a ; // поместить 4 переменные с плавающей точкой из a в регистр xmm0
    movups xmm1, b ; // поместить 4 переменные с плавающей точкой из b в регистр xmm1
    mulps xmm1, xmm0 ; // перемножить пакеты плавающих точек: xmm1=xmm1*xmm0
    movups a, xmm1 ; // выгрузить результаты из регистра xmm1 по адресам a
    };


    Таким образом, вместо четырех последовательных скалярных умножений мы сделали только одно — векторное.
    Векторные процессоры могут значительно ускорить вычисления над большими объемами данных, но сфера их применимости ограничена, далеко не везде применимы типовые операции над фиксированными массивами.
    Впрочем, гонка векторизации вычислений далеко не закончена — так в последних процессорах Intel появилось новое векторное расширение AVX (Advanced Vector Extension)
    Но гораздо интереснее сейчас выглядят

    Графические процессоры

    Теоретическая вычислительная мощность процессоров в современных видеокартах растет гораздо быстрее, чем в обычных процессорах (посмотрим знаменитую картинку от NVIDIA)

    Не так давно эта мощность была приспособлена для универсальных высокопроизводительных вычислений с помощью CUDA/OpenCL.
    Архитектура графических процессоров (GPGPU, General Purpose computation on GPU – универсальные расчеты средствами видеокарты), близка к уже рассмотренной SIMD.
    Она называется SIMT — (single instruction, multiple threads, одна инструкция — множество потоков). Так же как в SIMD операции производятся с массивами данных, но степеней свободы гораздо больше — для каждой ячейки обрабатываемых данных работает отдельная нить команд.
    В результате
    1) Параллельно могут выполняться сотни операций над сотнями ячеек данных.
    2) В каждом потоке выполняется произвольная последовательность команд, она может обращаться к разным ячейкам.
    3) Возможны ветвления. При этом, правда, параллельно могут выполняться только нити с одной и той же последовательностью операций.

    GPGPU позволяют достичь на некоторых задачах впечатляющих результатов. но существуют и принципиальные ограничения, не позволяющие этой технологии стать универсальной палочкой-выручалочкой, а именно
    1) Ускорить на GPU можно только хорошо параллелящийся по данным код.
    2) GPU использует собственную память. Трансфер данных между памятью GPU и памятью компьютера довольно затратен.
    3) Алгоритмы с большим количеством ветвлений работают на GPU неэффективно

    Мультиархитектуры-


    Итак, мы дошли до полностью параллельных архитектур — независимо параллельных и по командам, и по данным.
    В классификации Флинна это MIMD (Multiple Instruction stream, Multiple Data stream — Множественный поток Команд, Множественный поток Данных).
    Для использования всей мощности таких систем нужны многопоточные программы, их выполнение можно «разбросать» на несколько микропроцессоров и этим достичь увеличения производительности без роста частоты. Различные технологии многопоточности давно применялись в суперкомпьютерах, сейчас они «спустились с небес» к простым пользователям и многоядерный процессор уже скорее правило, чем исключение. Но многоядерность далеко не панацея.

    Суров закон, но это закон

    Параллельность, это хороший способ обойти ограничение роста тактовой частоты, но у него есть собственные ограничения.
    Прежде всего, это закон Амдала, который гласит
    Ускорение выполнения программы за счет распараллеливания её инструкций на множестве вычислителей ограничено временем, необходимым для выполнения её последовательных инструкций.

    Ускорение кода зависит от числа процессоров и параллельности кода согласно формуле



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

    Например, если выполнение последовательного кода занимает всего 25% от времени выполнения всей программы, то ускорить эту программу более чем в 4 раза не получится никак.
    Давайте построим график зависимости ускорения нашей программы от количества параллельно работающих вычислителей-процессоров. Подставив в формулу 1/4 последовательного кода и 3/4 параллельного, получим


    Грустно? Еще как.
    Самый быстрый в мире суперкомпьютер с тысячами процессоров и терабайтами памяти на нашей, вроде бы даже неплохо (75%!) параллелящейся задаче, меньше чем вдвое быстрее обычного настольного четырехядерника.
    Причем всё еще хуже, чем в этом идеальном случае. В реальном мире затраты обеспечение параллельности никогда не равны нулю и потому при добавлении все новых и новых процессоров производительность, начиная с некоторого момента, начнет падать.
    Но как же тогда используется мощь современных очень-очень многоядерных суперкомпьютеров?
    Во многих алгоритмах время исполнения параллельного кода сильно зависит от количества обрабатываемых данных, а время исполнения последовательного кода — нет. Чем больше данных требуется обработать, тем больше выигрыш от параллельности их обработки. Потому «загоняя» на суперкомп большие объемы данных получаем хорошее ускорение.
    Например перемножая матрицы 3*3 на суперкомпьютере мы вряд ли заметим разницу с обычным однопроцессорным вариантом, а вот умножение матриц, размером 1000*1000 уже будет вполне оправдано на многоядерной машине.
    Есть такой простой пример: 9 женщин за 1 месяц не могут родить одного ребенка. Параллельность здесь не работает. Но вот та же 81 женщина за 9 месяцев могут родить (берем максимальную эффективность!) 81 ребенка, т.е.получим максимальную теоретическую производительность от увеличения параллельности, 9 ребенков в месяц или, в среднем, тот же один ребенок в месяц на 9 женщин.
    Большим компьютерам — большие задачи!

    Мультипроцессор

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

    Системы с общей памятью

    В таких системах множество процессоров (и процессорных кэшей) имеет доступ к одной и той же физической оперативной памяти. Такая модель часто называется симметричной мультипроцессорностью (SMP). Доступ к памяти при таком построении системы называется UMA (uniform memory access, равномерный доступ) т.к. любой процессор может обратиться к любой ячейке памяти и скорость этого обращения не зависит от адреса памяти. Однако каждый микропроцессор может использовать свой собственный кэш.

    Несколько подсистем кэш-памяти процессоров, как правило, подключены к общей памяти через шину

    Посмотрим на рисунок.
    Что у нас хорошего?
    Любой процессор обращается ко всей памяти и вся она работает одинаково. Программировать для таких систем проще, чем для любых других мультиархитектур. Плохо то, что все процессоры обращаются к памяти через шину, и с ростом числа вычислительных ядер пропускная способность этой шины быстро становится узким местом.
    Добавляет головной боли и проблема обеспечения когерентности кэшей.

    Когерентность кэша

    Допустим, у нас есть многопроцессорный компьютер. Каждый процессор имеет свой кэш, ну, как на рисунке вверху. Пусть некоторую ячейку памяти читали несколько процессоров — и она попала к ним в кэши. Ничего страшного, пока это ячейка неизменна — из быстрых кэшей она читается и как-то используется в вычислениях.
    Если же в результате работы программы один из процессоров изменит эту ячейку памяти, чтоб не было рассогласования, чтоб все остальные процессоры «видели» это обновление придется изменять содержимое кэша всех процессоров и как-то тормозить их на время этого обновления.
    Хорошо если число ядер/процессоров 2, как в настольном компьютере, а если 8 или 16? И если все они обмениваются данными через одну шину?
    Потери в производительности могут быть очень значительные.

    Многоядерные процессоры

    Как бы снизить нагрузку на шину?
    Прежде всего можно перестать её использовать для обеспечения когерентности. Что для этого проще всего сделать?
    Да-да, использовать общий кэш. Так устроены большинство современных многоядерных процессоров.

    Посмотрим на картинку, найдем два отличия от предыдущей.
    Да, кэш теперь один на всех, соответственно, проблема когерентности не стоит. А еще круги превратились в прямоугольники, это символизирует тот факт, что все ядра и кэши находятся на одном кристалле. В реальной действительности картинка несколько сложнее, кэши бывают многоуровневыми, часть общие, часть нет, для связи между ними может использоваться специальная шина, но все настоящие многоядерные процессоры не используют внешнюю шину для обеспечения когерентности кэша, а значит — снижают нагрузку на нее.
    Многоядерные процессоры — один из основных способов повышения производительности современных компьютеров.
    Уже выпускаются 6 ядерные процессоры, в дальшейшем ядер будет еще больше… где пределы?
    Прежде всего «ядерность» процессоров ограничивается тепловыделением, чем больше транзисторов одновременно работают в одном кристалле, тем больше этот кристалл греется, тем сложнее его охлаждать.
    А второе большое ограничение — опять же пропускная способность внешней шины. Много ядер требуют много данных, чтоб их перемалывать, скорости шины перестает хватать, приходится отказываться от SMP в пользу

    NUMA

    NUMA (Non-Uniform Memory Access — «неравномерный доступ к памяти» или Non-Uniform Memory Architecture — «Архитектура с неравномерной памятью») — архитектура, в которой, при общем адресном пространстве, скорость доступа к памяти зависит от ее расположения Обычно у процессора есть " своя" память, обращение к которой быстрее и «чужая», доступ к которой медленнее.
    В современных системах это выглядит примерно так



    Процессоры соединены с памятью и друг с другом с помощью быстрой шины, в случае AMD это Hyper Transport, в случае последних процессоров Intel это QuickPath Interconnect
    Т.к. нет общей для всех шины то, при работе со «своей» памятью, она перестает быть узким местом системы.
    NUMA архитектура позволяет создавать достаточно производительные многопроцессорные системы, а учитывая многоядерность современных процессоров получим уже очень серьезную вычислительную мощность «в одном корпусе», ограниченную в основном сложностью обеспечения кэш-когерентности этой путаницы процессоров и памяти.
    Но если нам нужна еще большая мощность, придется объединять несколько мультипроцессоров в

    Мультикомпьютер


    Мультикомпьютер — вычислительная система без общей памяти, состоящая из большого числа взаимосвязанных компьютеров (узлов), у каждого из которых имеется собственная память. При работе над общей задаче узлы мультикомпьютера взаимодействуют через отправку друг другу сообщений.
    Современные мультикомпьютеры, построенные из множества типовых деталей, называют вычислительными кластерами.
    Большинство современных суперкомпьютеров построены по кластерной архитектуре, они объединяют множество вычислительных узлов с помощью быстрой сети (Gigabit Ethernet или InfiniBand) и позволяют достичь максимально возможной при современном развитии науки вычислительной мощности.
    Проблемы, ограничивающие их мощность, тоже немаленькие
    Это:
    1) Программирование системы с параллельно работающими тысячами вычислительных процессоров
    2) Гигантское энергопотребление
    3) Сложность, приводящая к принципиальной ненадежности

    Сводим все воедино


    Ну вот, вкратце пробежались почти по всем технологиям и принципам построения мощных вычислительных систем.
    Теперь есть возможность представить себе строение современного суперкомпьютера.
    Это мультикомпьютер-кластер, каждый узел которого — NUMA или SMP система с несколькими процессорами, каждый из процессоров с несколькими ядрами, каждое ядро с возможностью суперскалярного внутреннего параллелизма и векторными расширениями. Вдобавок ко всему этому во многих суперкомпьютерах установлены GPGPU — ускорители.
    У всех этих технологий есть плюсы и ограничения, есть тонкости в применении.
    А теперь попробуйте эффективно загрузить-запрограммировать всё это великолепие!
    Задача нетривиальная… но очень интересная.
    Что-то будет дальше?

    Источники информации

    Курс «Основы параллельных вычислений» Интернет-университета суперкомпьютерных технологий
    Классификация Флинна на сайте parallels.ru
    MultiProcessors, their Memory organizations and Implementations by Intel & AMD
    Многоядерность, как способ увеличения производительности вычислительной системы
    Википедия и Интернет

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

    Комментарии 43

      +2
      На работе сейчас пишу как раз ресурсоемкие приложения под специфические процессоры, часто приходится комбинировать как параллельное вычисление независимых команд (например, мои процессоры поддерживают одновременно 1 логическую операцию, 1 арифметическую и 2 операции с памятью), так и режим SIMD…

      К чему это я, не знаю :)
        +1
        А может напишете, если будет свободное время, статью про микрооптимизацию (лучне правда про не сильно специфичные, а, например, arm, atom, core)? Лично мне было бы интересно почитать.
          0
          Я думал об этом, но знаю очень мало — только умею и только для определённого процессора :) Саму теорию не изучал — параллельно учусь на оптика, программирование выросло из хобби, когда пришел на работу знал почти только самое общее про программирование на С — даже не С++, а дали список ассемблерных команд с описанием процессора и сказали — оптимизируй :)

          Могу на примере описать процедуру оптимизации, но у меня тут либо скучные — вычитание одного кадра из другого, либо специфичные — фильтрация изображения (честно говоря, я плохо понимаю, что он делает, только как)
        0
        Самый быстрый в мире суперкомпьютер с тысячами процессоров и терабайтами памяти на нашей, вроде бы даже неплохо (75%!) параллелящейся задаче, меньше чем вдвое быстрее обычного настольного четырехядерника.

        С этого места интересно по-подробнее.
          +1
          По графику — 4-ядерник выполнит чуть более, чем в 2 раза данный код, суперкомпьютер — не более, чем в 4 раза, делим «чуть меньше 4» на «чуть больше 2», получаем меньше 2 :)
          Но это для задачи, у которой 25% кода — последовательная :)
            0
            Принципиально однопоточный код увеличением количества процессоров/ядер ускорить нельзя. Никак, т.к. работает только одно ядро. Самый же быстрый на сегодняшний день суперкомп китайский Tianhe-1A построен на 14336 стандартных Intel Xeon и 7168 NVIDIA TESLA M2050. Тот же ксеон (один!) засовываем в настольный ящик, получаем практически такую же производительность (точнее — см. график)

              0
              А что это за задача, в которой последовательная часть составляет 25%? Ответ — сферическая задача в вакууме. Это я к тому, что на законе Амдала (1965 год) мир не остановился. Есть еще и законы Густавсона-Барсиса, метрика Карпа-Флатта и анализ изоэффективности (масштабируемости). Они дают другие, читай — оптимистичные оценки. И для многих задач — они более точно описывают ситуацию.

              Эх, тема параллельных вычислений для меня не равнодушна… скоро будут 128, 256-ядерные процессоры… Нам нужно будет с ними что-то делать. Так что, спасибо, что подняли этот вопрос на Хабре!
                0
                Да, но втиснуть их в обзор не получалось, потому ограничился Амдалом. Начальное понятие о принципиальных ограничениях он вполне дает.

                  0
                  Но вносит лишний пессимизм.
                    0
                    Но ведь они Амдалу не противоречат, последовательный код по любому закону ускорить не получится.
                      +1
                      Да, формальных противоречий нет. Но последовательная часть на практике не бывает фиксированной.
                      Конечно, закон Амдала очень важен для понимания параллелизма, но обязательно нужно описать его ограничения.
                        0
                        Спасибо за критику, подправил немного логику статьи. Правда, пока без графиков, на примере женщин, ну и пропущенную фразу про объем данных добавил.
                0
                >Принципиально однопоточный код увеличением количества процессоров/ядер ускорить нельзя. Никак, т.к. работает только одно ядро.

                Можно с помощью механизма предсказания вариантов.

                Скажем:

                  0
                  Ну, про суперскалярность в статье есть.
                  Речь ведь шла по ускорению суперкомпа по сравнению с настольным жужжащим ящиком.
                  Там и там одни и те же суперскалярные процессоры, так что все-таки ускорить не получится.
                    0
                    Случайно отправилось предыдущее, прошу не обращать внимания.

                    Если под однопоточным кодом имеется ввиду тот, к которому не применим механизм предсказания ветвлений, то конечно его ускорить невозможно.
                +4
                Спасибо, было интересно почитать. Получается, в итоге все равно все упирается в скорость выполнения последовательного кода. 9 женщин за 1 месяц ребенка не родят :)
                  +1
                  На самом деле, суперкомпьютеры не предназначены для решения маленьких задач, а с увеличением объемов данных последовательная часть как правило понижается. Таким образом можно добиться очень высокой эффективности. Так что суперкомпьютер — инструмент, и целесообразность его использования определяется для каждой конкретной задачи.

                  Статья написана сумбурно, желая покрыть сразу все, толком ни один аспект не описан как следует.
                    +1
                    Насчет больших задач я в статье прямо написал
                    «Во многих алгоритмах время исполнения параллельного кода сильно зависит от количества обрабатываемых данных, а время исполнения последовательного кода — нет.
                    Потому «загоняя» на суперкомп большие объемы данных получаем хорошее ускорение.
                    Например перемножая матрицы 3*3 на суперкомпьютере мы вряд ли заметим разницу с обычным однопроцессорным вариантом, а вот умножение матриц, размером 1000*1000 уже будет вполне оправдано на многоядерной машине.»

                    «Статья написана сумбурно, желая покрыть сразу все, толком ни один аспект не описан как следует.»
                    Ну, здесь на каждый аспект можно написать отдельную статью и не одну. Полных обзоров я на русском языке не видел. Мне интересно было как раз сделать общий текст, чтоб видна была связь, эволюция и ограничения технологий и было бы возможно копать глубже там, где конкретно нужно.
                    +7
                    зато 81 женщины смогут за 9 месяцев родить 81 ребёнка… Что значит в среднем и значит «9 женщин 1 ребёнка за месяц».
                    В этом-то и смысл параллельных вычислений.
                      0
                      Кстати, хороший пример, я про него забыл. Можно внести как иллюстрацию в статью?
                        +1
                        Конечно)
                    0
                    > 3) Сложность, приводящая к принципиальной ненадежности

                    С точностью до наоборот. Во-первых, мультикомпьютеры проще, а не сложнее (да, состоят из большого числа частей, но более простых, чем в больших мультипроцессорах). Отказоустойчивость мультикомпьютеров обеспечить намного проще и дешевле (так как не нужно специального оборудования: отказал узел, ну и ничего, задачи на него больше пакетная система не назначает).
                      0
                      Основываюсь здесь на докладе директора Т-Платформы (тех, кто наш Ломоносов делали) на ПАВТ-2011.
                      Начиная с некоторого количества узлов, они начинают ломаться непрерывно. Речь шла о проблеме петафлопа, именно для нее этот фактор становится принципиальным.
                      0
                      Интересно, а насколько реально повысится эффективность работы нейросетей (в частности задач по Data Minig) при использование ресурсов GPU? Я просто с этим не сталкивался еще, но вскоре предстоит.
                        +1
                        Все зависит, конечно, от свойств конкретной задачи. Но я бы грубо оценил ожидаемое ускорение от 10 до 30 раз. Причем, чем больше задача — тем больше и ускорение. В этом прелесть параллельных вычислений!
                          0
                          Будем знать в какую сторону смотреть :-)
                          +1
                          Сильно зависит еще от объема обрабатываемых данных и от возможности распараллелить по данным.
                          Можно посмотреть мою первую статью по OpenCL habrahabr.ru/blogs/hi/116579/ там я постарался про подводные камни написать.
                            0
                            От GPU зависит. У нас на HD4850 в 11 раз быстрее, чем на четырёхядерном Athlon II X4.
                            0
                            Вообще-то предел по частоте наверняка еще не выбран. При обычном уменьшении техпроцесса AMD уже подобралась к номиналу 3,7 ГГц — отсюда рукой подать до 4,0, которые не удалось взять в 2004 «кукурузе». Intel тоже не месте не сидит. Продолжаются также исследования новых материалов, архитектур и т. д. для обхода этих проблем в чуть более отдаленной перспективе, имеются одиночные прототипы на сотни ГГц, так что хоронить этот параметр явно рановато. Другое дело темпы, с которыми это все развивается. Если уже сейчас можно тупо умножать ядра на проце, процы в машине, машины в сети и сети в мире — то для получения максимального результата разумно будет задействовать все эти направления, т. е. параллелизм на уровне компиляции, программирования, архитектуры приложений, диверсификацию железа, затронутую в данной статье на примере видеокарт, а также и распределенные вычисления, которые затронуты не были, но тоже являются перспективной темой для подобных задач. Наверняка существуют или появятся еще задачи (кроме привычной графики, физики, звука — возможно, что-нибудь из биоинформатики, что обозначится по мере ее дальнейшего развития), для которых оптимально будет проектировать специализированные процессоры в железе. Скорее всего, такой подход будет все шире применяться при приближении к молекулярным масштабам с заменой кремния на что-то другое. Если посмотреть еще дальше и сравнить вычислительную систему с самым продвинутым ее природным аналогом — человеческим мозгом — необходимо будет обеспечить будущие процессоры или их составляющие возможностью динамически настраивать соединения между собой в зависимости от задачи. Перспективы квантовых компьютеров и всяческие теоретические спекуляции пока оставим за бортом:).
                              0
                              Да, ждем графеновых или молибденитовых процессоров. Если получится, будет чуть проще, но все равно сложность уже не уменьшится т.к. выкидывать на помойку уже разработанные параллельные архитектуры никто не будет.
                              Просто процессоры в них заменят.
                                0
                                Насколько я помню, теоретический предел вообще — 10 ГГц, на практике до 6 ГГц разгоняли вроде.
                                Гораздо интереснее смотреть на другие типы процессоров — оптические те же, правда они как-то неуверенно исследуются…
                                  0
                                  Я еще про ПЛИС не писал, там тоже интересно очень, но слишком мало знаю, чтоб делиться.
                                    +2
                                    Как курсовую сдам и если кармы хватит — напишу, я ими в НИВЦе МГУ занимаюсь.
                                      0
                                      На ПАВТ был интересный доклад про ПЛИС. Человек из Алмаз-Антей рассказывал, на таких схемах собрана логика нашего ПВО (С300 и компания)
                                        0
                                        Да, разработчики вот этой железки, которая стоит у нас, с удовольствием говорили, что «про большинство мы рассказать не можем, потому что воякам делали».
                                  0
                                  На самом деле, технологии позволяют уже сейчас 6 гигагерц получать на воздухе. У P4 некоторые блоки на такой частоте работали. Проблема только в том: а на кой они нужны? Сейчас основная проблема и бутылочное горлышко — это скорость доступа к памяти: ну будет процессор на своих 6 гигагерцах очень эффектно простаивать в ожидании данных, ну и кому оно такое надо, если вместо этого можно снизить энергопотребление?

                                  Тупо умножать ядра на процессоре тоже нельзя. Опять же та же самая проблема: перегруженность шин данных.

                                  То есть, основная польза от мультикомпьютеров — это как раз увеличение сумарной пропускной способности к функциональным блокам.
                                    0
                                    Но тогда как работают те же 4 ядерные процессоры? Они обмениваются данными с памятью вчетверо сильнее, чем одноядерный той же частоты, который, по вашим данным, простаивает.
                                    Да, начиная с пары четырехъядерных приходится городить NUMA, но до этого предела скорости памяти пока еще хватает.
                                    Соответственно, для 6 гигагерцового одноядерника точно должно хватить.
                                      0
                                      С чего это вдруг вчетверо сильнее? И в чём измеряется эта сила? Если речь о скорости, то Вы не правы. Четырёхкратное ускорение можно получить, если данные укладываются в кэши ядер, но при работе с большими массивами данных такого поведения кода добиться зачастую невозможно. Поэтому начинаются конфликты доступа к контроллерам памяти или к кэшу L3. И четырёхядерник, в среднем, эффективнее одноядерника той же архитектуры где-то в 2.5 раза.

                                      Так что, пропускной способности памяти не хватает. Но проблема вот ещё в чём, когда работает 4 потока, то они могут более плотно загружать каналы доступа к памяти в сравнении с тем, когда работает один 6GHz процессор. У него сценарий будет примерно такой: хопа, надо посчитать вот эти данные, ок, щаз как посчитаю, ррРрррРРр(ждём данные из памяти)ррРРРрРрр(дождался)аз(посчитал), о, блин, теперь я знаю, что надо считать вот это, щаз посчитаю, рррРРррРРрРРрраз. То есть, зависимости по данным не позволяют одновременно много запросов посылать в контроллеры памяти. Поэтому такой процессор и будет долго простаивать. При чём, что на параллельных нагрузках, что на последовательных — без разницы. Поэтому, как бы, многоядерники тут выглядят лучше, они лучше загружают контроллеры памяти, простаивают меньше, и, как итог, работают энергоэффективнее, что важно.
                                  +1
                                  По поводу GPGPU:
                                  технология сильно совершенствуется, и сейчас нет больших проблем ускорить код который имеет большое количество ветвлений, а трансфер из памяти в видеопамять работает со скоростью прямого доступа к оперативной памяти (как более медленной). Вот как раз сегодня на тему написал:
                                  habrahabr.ru/blogs/hi/119435/
                                    0
                                    Насчет ветвлений очень спорный вопрос. У меня были совсем другие результаты на Fermi gts 450.
                                    Но остальные аспекты очень интересны, спасибо за ссылку.
                                      +1
                                      У Вас там слишком примитивные ветвления, которые очень хорошо укладываются в предикаты к инструкциям. Вот если бы там были блоки инструкций по 20, и если бы ещё вложенные ветвления, то вот где бы радость началась — таков опыт из реальной жизни на Fermi.
                                      0
                                      Есть еще эффект «пилы»: когда при использовании четного числа процессоров задача выполняется немного быстрее, чем если процессоров на 1 больше.
                                        0
                                        Антинаучный бред. Это у оперативки dual channel бывает.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.