Comments 49
Во время учебы, помню, так хотелось что бы это кто то объяснял… Сейчас уже давно в другой области.
Спасибо за статью! Не могли бы вы в следующей части рассказать о средствах распределения задачи по ядрам с учетом физической структуры сети?
Да хрень же ваши многопроцессорные архитектуры. Нет бы, скорость процессора и скорость шины к памяти повысили лучше.
Хорошо распараллеливаются только задачи типа потоковой обработки огромных массивов. Преимущество многопроцессорных систем будет, когда в процессорах будет хотя бы 64 ядра: пока ядра 2, от распараллеливания больше убытков, так как все библиотеки надо перекомпилировать под мульитрединг, там появляется куча блокировок, и оверхед от них больше выигрыша от паралелльности. Это ж надо было такую неэффективную систему придумать, как будто специально старались.
Ну и что касается нематематических и неигровых приложений, например массовые десктопные приложения, там тормоза из-за использования тяжелых программных сред типа Java/.NET, что касается баз данных — там тормозит диск обычно.
В общем, кроме узкоспециальных задач типа расчета прогнозов погоды, эти мультипроцессорные системы больше ниокму не нужны, а меньше всего они нужны разработчикам, которым и так головной боли хватает, делать больше нечего, как отлавливать трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего.
И кстати, что-то вроде SIMD-суперкомпьютера сейчас есть в большинстве ПК — это видеокарта с ее конвейерами.
Хорошо распараллеливаются только задачи типа потоковой обработки огромных массивов. Преимущество многопроцессорных систем будет, когда в процессорах будет хотя бы 64 ядра: пока ядра 2, от распараллеливания больше убытков, так как все библиотеки надо перекомпилировать под мульитрединг, там появляется куча блокировок, и оверхед от них больше выигрыша от паралелльности. Это ж надо было такую неэффективную систему придумать, как будто специально старались.
Ну и что касается нематематических и неигровых приложений, например массовые десктопные приложения, там тормоза из-за использования тяжелых программных сред типа Java/.NET, что касается баз данных — там тормозит диск обычно.
В общем, кроме узкоспециальных задач типа расчета прогнозов погоды, эти мультипроцессорные системы больше ниокму не нужны, а меньше всего они нужны разработчикам, которым и так головной боли хватает, делать больше нечего, как отлавливать трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего.
И кстати, что-то вроде SIMD-суперкомпьютера сейчас есть в большинстве ПК — это видеокарта с ее конвейерами.
Согласен. В статье написано, что хотели получить в теории, у Вас в комментарии написано что получилось на практике. Но у параллельных систем определённо есть будущее, ибо там простор для роста производительности практически неограниченный. Наращивать тактовую частоту самого процессора сейчас проблематично, т.к. дефицит качественных камней, а вот составить процессор из нескольких некачественных — легко. Основной затык сейчас в том, что имеется огромное наследие программ, библиотек и алгоритмов, не рассчитанных на параллельность. Но со временем ситуация должна улучшится.
Возмущен Вашей категоричностью!
Особенно в плане определения «узкоспециализированных задач».
Вычислители молятся на эту параллельность. Расчет теченя жидкостей в трубах, добычи нефти, ядерных реаторов, крыльев самолётов. Это малополезные задачи по сравнению с игровой индустрией или офисной работой? Если мы говорим только о количестве вовлеченных в процесс мозгов, то, пожалуй, да, если начнем хоть немного о качестве… то такую категоричнось по крайней мере стоит оставить в стороне, а если ещё и о полезном конечном результате, то и вовсе придется шепотом.
Ну да ладно, может и мой фанатизм вызван близким сопряжением с суперкомпьютерами. Тут тема (хрень-не хрень) сродни холивару. Однако всё же нельзя не признать, что отрасль популярная, бурно развивающаяся и приносящая свои плоды. Пусть хотя бы и прогноз погоды. Не зря же его каждый час по каждому каналу передают. Наверное, это кому-то нужно :)
Особенно в плане определения «узкоспециализированных задач».
Вычислители молятся на эту параллельность. Расчет теченя жидкостей в трубах, добычи нефти, ядерных реаторов, крыльев самолётов. Это малополезные задачи по сравнению с игровой индустрией или офисной работой? Если мы говорим только о количестве вовлеченных в процесс мозгов, то, пожалуй, да, если начнем хоть немного о качестве… то такую категоричнось по крайней мере стоит оставить в стороне, а если ещё и о полезном конечном результате, то и вовсе придется шепотом.
Ну да ладно, может и мой фанатизм вызван близким сопряжением с суперкомпьютерами. Тут тема (хрень-не хрень) сродни холивару. Однако всё же нельзя не признать, что отрасль популярная, бурно развивающаяся и приносящая свои плоды. Пусть хотя бы и прогноз погоды. Не зря же его каждый час по каждому каналу передают. Наверное, это кому-то нужно :)
На данный момент приложения справедливо поделились на две категории: те, которым хватает мощности одного современного ядра, и те, для которых актуален параллелизм. Ваши примеры с тормозами Java/.NET не более чем сотый раз цитирование мифа «Java тормозит». Что касается баз данных, то они с параллелизмом как раз хорошо дружат: помимо нагрузки на диск есть еще и нагрузка на cpu при выполнении запросов.
Да, и вы забыли про «маленькую» область — веб-приложения. Вообще сложно представить что-то более актуальное. Для создания высоконагруженных веб-приложений пользу от применения параллельных систем сложно недооценить.
Вот именно! Не будь параллельных и распределенных систем не видать нам гугла и твиттера.
Как в веб-приложениях используется параллельность? Я имею в виду именно само приложение, а не построение быстрого кластера из серверов, т.к. это хоть и играет важную роль, но к веб-приложению не относится.
На стороне клиента пока никак, но
а) последние пара десятков лет как раз идет возвращение к системе сильный сервер — тонкий терминал, так что все ок, и
б) с такими штуками как web workers некоторое подобие параллельных неблокирующих тредов в браузере можно уже сейчас устроить, а когда эта штука стандартизируется (или даже позволит через webcl юзать GPU клиентской машины!) — уф!
а) последние пара десятков лет как раз идет возвращение к системе сильный сервер — тонкий терминал, так что все ок, и
б) с такими штуками как web workers некоторое подобие параллельных неблокирующих тредов в браузере можно уже сейчас устроить, а когда эта штука стандартизируется (или даже позволит через webcl юзать GPU клиентской машины!) — уф!
Я имел в виду серверную часть приложения, т.е. всевозможные PHP/Django/Java и т.д. Сам код приложения сильно завязан на информации, посылаемой ему клиентом, и на запросы к БД (они как правило блокирующие), поэтому настоящее распараллеливание возможно только по принципу 1 поток = 1 клиент, но это не эффективно, т.к. понадобилось бы огромное число ядер/процессоров. Можно конечно и по-другому организовать параллельность, но скорость не оправдает сложности реализации (а она возрастёт в разы). Не знаю как вам, но мне кажется, что веб-приложения — это неудачный пример использования параллельности. В основном она там используется потому, что позволяет увеличить скорость, а не потому, что упрощает реализацию.
В веб приложениях специфика такая, что в большинстве случае параллельность почти скрыта от разработчика и реализована на уровне веб-серверов. Но это никак не отменяет того факта, что запросы выполняются параллельно и параллельная архитектура системы позволяет добиться большой производительности. То есть параллельные вычисления там есть.
Насчет неэффективности модели 1 клиент = 1 поток: во-первых такая модель часто достаточно эффективна, во-вторых существуют приемлемые решения, см. gevent, stackless python и т.п.
Насчет неэффективности модели 1 клиент = 1 поток: во-первых такая модель часто достаточно эффективна, во-вторых существуют приемлемые решения, см. gevent, stackless python и т.п.
То, что она там есть, не делает веб-приложения удачным примером. Можно придумать гораздо более подходящую архитектуру под веб-приложения, вопрос лишь в нужности этой архитектуры для других областей. Параллельность подразумевает максимальное использование всех юнитов (ядер, процессоров, серверов), т.е. ни один из них не должен простаивать, пока работает другой — нагрузка должна быть распределена между ними. В случае с веб-приложениями разные запросы могут выполняться разное время, а заранее определить «вес» запроса, чтобы послать его на менее нагруженный юнит, тоже невозможно. Я думаю очевидно, что преимущества параллельности в веб-приложениях не используются в полной мере.
Такая модель никогда не эффективна. Будет огромный оверхед на создание потоков и переключения между ними. Даже если заранее создать пул потоков, то при большой нагрузке процесс рискует превысить лимит ОС на количество потоков. Про огромное потребление ресурсов и говорить не буду. Для примера — Apache, который без фронтенда при большом количестве одновременных запросов начинает отжирать всю память и валится.
Решения приемлемые, но асинхронность != параллельность.
Насчет неэффективности модели 1 клиент = 1 поток: во-первых такая модель часто достаточно эффективна
Такая модель никогда не эффективна. Будет огромный оверхед на создание потоков и переключения между ними. Даже если заранее создать пул потоков, то при большой нагрузке процесс рискует превысить лимит ОС на количество потоков. Про огромное потребление ресурсов и говорить не буду. Для примера — Apache, который без фронтенда при большом количестве одновременных запросов начинает отжирать всю память и валится.
во-вторых существуют приемлемые решения, см. gevent, stackless python и т.п.
Решения приемлемые, но асинхронность != параллельность.
>Для примера — Apache, который без фронтенда при большом количестве одновременных запросов начинает отжирать всю память и валится.
Точно, а в это время у nginx, который на поток не создает по треду, расход памяти практически не меняется
Точно, а в это время у nginx, который на поток не создает по треду, расход памяти практически не меняется
Хм. А может быть дело в том, что Apache криво написан? У меня друг писал web-сервер, я ему советовал делать как-нибудь на poll/select'ах, ибо производительность. А он взял и сделал всё на нитях. У него сервер держал по миллиону одновременных соединений с небольшим расходом памяти. Было лучше, чем у Lighttpd.
Так что… Это штука такая — правильно пользоваться нитями тоже надо уметь. Обычно, просто переписать однопоточное приложение, которым был apache изначально, с целью превратить его в параллельное не всегда получается. Реентерабельность блиблиотек опять же. Поэтому, при таком подходе, обычно, возникает аналог Big Kernel Lock.
А если проектировать сразу с учётом параллельности, то вполне неплохо может получиться. Контекст целочисленной нити — это не так уж и много, на самом деле. И затраты на его переключение могут быть скомпенсированы упрощением кода работы с клиентом.
Поэтому нельзя утверждать однозначно, что
Такая модель никогда не эффективна.
Она неэффективна, когда человек не ведает, что творит и пихает 10 мьютексов на один экран кода.
Так что… Это штука такая — правильно пользоваться нитями тоже надо уметь. Обычно, просто переписать однопоточное приложение, которым был apache изначально, с целью превратить его в параллельное не всегда получается. Реентерабельность блиблиотек опять же. Поэтому, при таком подходе, обычно, возникает аналог Big Kernel Lock.
А если проектировать сразу с учётом параллельности, то вполне неплохо может получиться. Контекст целочисленной нити — это не так уж и много, на самом деле. И затраты на его переключение могут быть скомпенсированы упрощением кода работы с клиентом.
Поэтому нельзя утверждать однозначно, что
Такая модель никогда не эффективна.
Она неэффективна, когда человек не ведает, что творит и пихает 10 мьютексов на один экран кода.
>Хм. А может быть дело в том, что Apache криво написан?
Да, apache криво написан, но это совсем другая тема :) Главная проблема кроется в другом.
>У меня друг писал web-сервер, я ему советовал делать как-нибудь на poll/select'ах, ибо производительность.
Что бы не создавать на каждого клиента по треду в первую очередь нужно что бы сам запрос выполнялся неблокируемо. А большинство библиотек работы с БД написаны блокирующими. Но например в питоне можно подхачить и сделать, что бы сокет при вызове отдавал управление.
Nginx не создает на каждый клиент по треду, так как обработка запроса (а именно обработка ввода-вывода вроде отдачи статики или проксирования запроса) выполняется неблокируемо. В принципе, можно писать приложение в виде модуля к nginx на Си с использованием неблокирующих драйверов доступа к БД, но это не самый удобный способ разработки :)
Да, apache криво написан, но это совсем другая тема :) Главная проблема кроется в другом.
>У меня друг писал web-сервер, я ему советовал делать как-нибудь на poll/select'ах, ибо производительность.
Что бы не создавать на каждого клиента по треду в первую очередь нужно что бы сам запрос выполнялся неблокируемо. А большинство библиотек работы с БД написаны блокирующими. Но например в питоне можно подхачить и сделать, что бы сокет при вызове отдавал управление.
Nginx не создает на каждый клиент по треду, так как обработка запроса (а именно обработка ввода-вывода вроде отдачи статики или проксирования запроса) выполняется неблокируемо. В принципе, можно писать приложение в виде модуля к nginx на Си с использованием неблокирующих драйверов доступа к БД, но это не самый удобный способ разработки :)
> А он взял и сделал всё на нитях. У него сервер держал по миллиону одновременных соединений с небольшим расходом памяти. Было лучше, чем у Lighttpd.
Мне кажется, вы уже зашли в область фантастики, причем далеко. Расскажите-ка мне, какая операционная система позволяет организовать и шедулить миллион потоков. И сколько памяти уйдет толкьо на стеки для этих потоков?
Мне кажется, вы уже зашли в область фантастики, причем далеко. Расскажите-ка мне, какая операционная система позволяет организовать и шедулить миллион потоков. И сколько памяти уйдет толкьо на стеки для этих потоков?
>Параллельность подразумевает максимальное использование всех юнитов
Параллельность подразумевает физически одновременное выполнение инструкций за счет использования нескольких аппаратных блоков. Простаивание нежелательно, но это опять же не отменяет того факта, что веб сервер выполняет запросы параллельно, а не последовательно.
>Такая модель никогда не эффективна.
Ошибаетесь. Если БД отвечает достаточно быстро (OLTP система, к примеру), то потоки будут блокироваться на очень небольшое время, так что рабочих потоков понадобится немногим больше, чем ядер.
>то при большой нагрузке процесс рискует превысить лимит ОС на количество потоков.
Извините, но вы видимо с данной темой знакомы только по наслышке. Почти всегда существует лимит на максимальное количество рабочих потоков.
>Про огромное потребление ресурсов и говорить не буду.
Если потоков не слишком много (см. выше), то огромного потребления ресурсов на переключение контекстов не будет.
>Решения приемлемые, но асинхронность != параллельность.
Ассинхронность в таком случае используется вместе с параллельностью. В идеале есть N рабочих потоков, где N — количество ядер и каждый поток асинхронно обслуживает сразу нескольких клиентов.
Параллельность подразумевает физически одновременное выполнение инструкций за счет использования нескольких аппаратных блоков. Простаивание нежелательно, но это опять же не отменяет того факта, что веб сервер выполняет запросы параллельно, а не последовательно.
>Такая модель никогда не эффективна.
Ошибаетесь. Если БД отвечает достаточно быстро (OLTP система, к примеру), то потоки будут блокироваться на очень небольшое время, так что рабочих потоков понадобится немногим больше, чем ядер.
>то при большой нагрузке процесс рискует превысить лимит ОС на количество потоков.
Извините, но вы видимо с данной темой знакомы только по наслышке. Почти всегда существует лимит на максимальное количество рабочих потоков.
>Про огромное потребление ресурсов и говорить не буду.
Если потоков не слишком много (см. выше), то огромного потребления ресурсов на переключение контекстов не будет.
>Решения приемлемые, но асинхронность != параллельность.
Ассинхронность в таком случае используется вместе с параллельностью. В идеале есть N рабочих потоков, где N — количество ядер и каждый поток асинхронно обслуживает сразу нескольких клиентов.
Извините, но вы видимо с данной темой знакомы только по наслышке. Почти всегда существует лимит на максимальное количество рабочих потоков.
Не важно, на уровне приложения или на уровне ОС этот лимит. Важно, что он всегда есть и приложение не сможет обработать клиентов больше этого лимита (1 поток = 1 клиент).
Ошибаетесь. Если БД отвечает достаточно быстро (OLTP система, к примеру), то потоки будут блокироваться на очень небольшое время, так что рабочих потоков понадобится немногим больше, чем ядер.
Ок, убедили, иногда параллельность используется удачно. Но, опять же, очень много проблем с блокировками, за всем этим нужно внимательно следить, чтобы либо не блокировалось, либо блокировалось с маленькой задержкой. Такие проблемы возникают из-за того, что конкретную задачу пытаются вписать в рамки параллельности, вместо того, чтобы найти более подходящую модель. Поэтому я считаю, что веб-приложения — это неудачный пример использования параллельности, т.к. она здесь используется скорее как костыль, чем как реально подходящая модель.
>т.к. она здесь используется скорее как костыль, чем как реально подходящая модель.
Параллельность всегда используется ради одной цели — утилизировать работу нескольких вычислительных юнитов и всегда приводит к усложнению кода.
А насчет более удачной модели да, 1 клиент — 1 поток не самое удачное решение. Но N рабочих потоков (или процессов), каждый из которых работает в неблокирующем режиме + пул потоков для долгих (хоть и неблокирующих) операций практически панацея.
Параллельность всегда используется ради одной цели — утилизировать работу нескольких вычислительных юнитов и всегда приводит к усложнению кода.
А насчет более удачной модели да, 1 клиент — 1 поток не самое удачное решение. Но N рабочих потоков (или процессов), каждый из которых работает в неблокирующем режиме + пул потоков для долгих (хоть и неблокирующих) операций практически панацея.
>Это ж надо было такую неэффективную систему придумать, как будто специально старались.
А как сделать лучше?
А как сделать лучше?
>В общем, кроме узкоспециальных задач типа расчета прогнозов погоды, эти мультипроцессорные системы больше ниокму не нужны, а меньше всего они нужны разработчикам, которым и так головной боли хватает, делать больше нечего, как отлавливать трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего.
Те же самые «трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего» отлично себя чувствуют не только в мультипроцессорных системах, но и в однопроцессорных (и даже одноядерных), если в программе больше одного потока.
Ура-а-а, даёшь однопоточные программы!
Те же самые «трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего» отлично себя чувствуют не только в мультипроцессорных системах, но и в однопроцессорных (и даже одноядерных), если в программе больше одного потока.
Ура-а-а, даёшь однопоточные программы!
К вопросу об узкоспециализированности: www.phoronix.com/scan.php?page=news_item&px=OTc5OQ Даже в GiMP добавляют поддержку. В науке же сейчас вообще всё моделирование делается на суперкомпьютерах. В промышленности почти все инженерные расчёты делаются на суперкомпьютерах.
Даже Flash видео проигрывает, нагружая все имеющиеся ядра в процессоре. Иначе были бы существенные тормоза.
Так что. Ну очень сложно назвать эту тему узкоспециализированной
Даже Flash видео проигрывает, нагружая все имеющиеся ядра в процессоре. Иначе были бы существенные тормоза.
Так что. Ну очень сложно назвать эту тему узкоспециализированной
И чего все так любят про эти SIMD и MIMD рассказывать? Вот ни разу не ощутил практической и теоретической пользы от классификации Флинна. Эх. Лучше бы точнее описали системы с общей памятью, ибо на картике у Вас нарисованы кэши у Pentium-ов, а в рассказе сказано, что процессоры просто берут данные из общей памяти.
И у читателя создаётся неверное впечатление, что общая память — это просто, а пересылка сообщений — сложно. Реальная же ситуация обратно противоположная. Да даже и исторически, сначала были транспьютеры, а потом только пришли SMP-машины.
И у читателя создаётся неверное впечатление, что общая память — это просто, а пересылка сообщений — сложно. Реальная же ситуация обратно противоположная. Да даже и исторически, сначала были транспьютеры, а потом только пришли SMP-машины.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Продолжение вот habrahabr.ru/blogs/hi/127007/
Про Линукс не понял…
Про Линукс не понял…
UFO just landed and posted this here
Спасибо за интересную статью.
Вначале только исправьте опечатку
дизайнерам и разработчикам приходится еще думать о том, его заставить работать
Вначале только исправьте опечатку
дизайнерам и разработчикам приходится еще думать о том, его заставить работать
Интересно, но изображения пропали, похоже.
Sign up to leave a comment.
Введение в параллельные вычисления