Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Во время учебы, помню, так хотелось что бы это кто то объяснял… Сейчас уже давно в другой области.
Спасибо за статью! Не могли бы вы в следующей части рассказать о средствах распределения задачи по ядрам с учетом физической структуры сети?
Да хрень же ваши многопроцессорные архитектуры. Нет бы, скорость процессора и скорость шины к памяти повысили лучше.
Хорошо распараллеливаются только задачи типа потоковой обработки огромных массивов. Преимущество многопроцессорных систем будет, когда в процессорах будет хотя бы 64 ядра: пока ядра 2, от распараллеливания больше убытков, так как все библиотеки надо перекомпилировать под мульитрединг, там появляется куча блокировок, и оверхед от них больше выигрыша от паралелльности. Это ж надо было такую неэффективную систему придумать, как будто специально старались.
Ну и что касается нематематических и неигровых приложений, например массовые десктопные приложения, там тормоза из-за использования тяжелых программных сред типа Java/.NET, что касается баз данных — там тормозит диск обычно.
В общем, кроме узкоспециальных задач типа расчета прогнозов погоды, эти мультипроцессорные системы больше ниокму не нужны, а меньше всего они нужны разработчикам, которым и так головной боли хватает, делать больше нечего, как отлавливать трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего.
И кстати, что-то вроде SIMD-суперкомпьютера сейчас есть в большинстве ПК — это видеокарта с ее конвейерами.
Хорошо распараллеливаются только задачи типа потоковой обработки огромных массивов. Преимущество многопроцессорных систем будет, когда в процессорах будет хотя бы 64 ядра: пока ядра 2, от распараллеливания больше убытков, так как все библиотеки надо перекомпилировать под мульитрединг, там появляется куча блокировок, и оверхед от них больше выигрыша от паралелльности. Это ж надо было такую неэффективную систему придумать, как будто специально старались.
Ну и что касается нематематических и неигровых приложений, например массовые десктопные приложения, там тормоза из-за использования тяжелых программных сред типа Java/.NET, что касается баз данных — там тормозит диск обычно.
В общем, кроме узкоспециальных задач типа расчета прогнозов погоды, эти мультипроцессорные системы больше ниокму не нужны, а меньше всего они нужны разработчикам, которым и так головной боли хватает, делать больше нечего, как отлавливать трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего.
И кстати, что-то вроде SIMD-суперкомпьютера сейчас есть в большинстве ПК — это видеокарта с ее конвейерами.
Согласен. В статье написано, что хотели получить в теории, у Вас в комментарии написано что получилось на практике. Но у параллельных систем определённо есть будущее, ибо там простор для роста производительности практически неограниченный. Наращивать тактовую частоту самого процессора сейчас проблематично, т.к. дефицит качественных камней, а вот составить процессор из нескольких некачественных — легко. Основной затык сейчас в том, что имеется огромное наследие программ, библиотек и алгоритмов, не рассчитанных на параллельность. Но со временем ситуация должна улучшится.
Возмущен Вашей категоричностью!
Особенно в плане определения «узкоспециализированных задач».
Вычислители молятся на эту параллельность. Расчет теченя жидкостей в трубах, добычи нефти, ядерных реаторов, крыльев самолётов. Это малополезные задачи по сравнению с игровой индустрией или офисной работой? Если мы говорим только о количестве вовлеченных в процесс мозгов, то, пожалуй, да, если начнем хоть немного о качестве… то такую категоричнось по крайней мере стоит оставить в стороне, а если ещё и о полезном конечном результате, то и вовсе придется шепотом.
Ну да ладно, может и мой фанатизм вызван близким сопряжением с суперкомпьютерами. Тут тема (хрень-не хрень) сродни холивару. Однако всё же нельзя не признать, что отрасль популярная, бурно развивающаяся и приносящая свои плоды. Пусть хотя бы и прогноз погоды. Не зря же его каждый час по каждому каналу передают. Наверное, это кому-то нужно :)
Особенно в плане определения «узкоспециализированных задач».
Вычислители молятся на эту параллельность. Расчет теченя жидкостей в трубах, добычи нефти, ядерных реаторов, крыльев самолётов. Это малополезные задачи по сравнению с игровой индустрией или офисной работой? Если мы говорим только о количестве вовлеченных в процесс мозгов, то, пожалуй, да, если начнем хоть немного о качестве… то такую категоричнось по крайней мере стоит оставить в стороне, а если ещё и о полезном конечном результате, то и вовсе придется шепотом.
Ну да ладно, может и мой фанатизм вызван близким сопряжением с суперкомпьютерами. Тут тема (хрень-не хрень) сродни холивару. Однако всё же нельзя не признать, что отрасль популярная, бурно развивающаяся и приносящая свои плоды. Пусть хотя бы и прогноз погоды. Не зря же его каждый час по каждому каналу передают. Наверное, это кому-то нужно :)
Вот именно! Не будь параллельных и распределенных систем не видать нам гугла и твиттера.
Как в веб-приложениях используется параллельность? Я имею в виду именно само приложение, а не построение быстрого кластера из серверов, т.к. это хоть и играет важную роль, но к веб-приложению не относится.
На стороне клиента пока никак, но
а) последние пара десятков лет как раз идет возвращение к системе сильный сервер — тонкий терминал, так что все ок, и
б) с такими штуками как web workers некоторое подобие параллельных неблокирующих тредов в браузере можно уже сейчас устроить, а когда эта штука стандартизируется (или даже позволит через webcl юзать GPU клиентской машины!) — уф!
а) последние пара десятков лет как раз идет возвращение к системе сильный сервер — тонкий терминал, так что все ок, и
б) с такими штуками как web workers некоторое подобие параллельных неблокирующих тредов в браузере можно уже сейчас устроить, а когда эта штука стандартизируется (или даже позволит через webcl юзать GPU клиентской машины!) — уф!
Я имел в виду серверную часть приложения, т.е. всевозможные PHP/Django/Java и т.д. Сам код приложения сильно завязан на информации, посылаемой ему клиентом, и на запросы к БД (они как правило блокирующие), поэтому настоящее распараллеливание возможно только по принципу 1 поток = 1 клиент, но это не эффективно, т.к. понадобилось бы огромное число ядер/процессоров. Можно конечно и по-другому организовать параллельность, но скорость не оправдает сложности реализации (а она возрастёт в разы). Не знаю как вам, но мне кажется, что веб-приложения — это неудачный пример использования параллельности. В основном она там используется потому, что позволяет увеличить скорость, а не потому, что упрощает реализацию.
То, что она там есть, не делает веб-приложения удачным примером. Можно придумать гораздо более подходящую архитектуру под веб-приложения, вопрос лишь в нужности этой архитектуры для других областей. Параллельность подразумевает максимальное использование всех юнитов (ядер, процессоров, серверов), т.е. ни один из них не должен простаивать, пока работает другой — нагрузка должна быть распределена между ними. В случае с веб-приложениями разные запросы могут выполняться разное время, а заранее определить «вес» запроса, чтобы послать его на менее нагруженный юнит, тоже невозможно. Я думаю очевидно, что преимущества параллельности в веб-приложениях не используются в полной мере.
Такая модель никогда не эффективна. Будет огромный оверхед на создание потоков и переключения между ними. Даже если заранее создать пул потоков, то при большой нагрузке процесс рискует превысить лимит ОС на количество потоков. Про огромное потребление ресурсов и говорить не буду. Для примера — 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 мьютексов на один экран кода.
> А он взял и сделал всё на нитях. У него сервер держал по миллиону одновременных соединений с небольшим расходом памяти. Было лучше, чем у Lighttpd.
Мне кажется, вы уже зашли в область фантастики, причем далеко. Расскажите-ка мне, какая операционная система позволяет организовать и шедулить миллион потоков. И сколько памяти уйдет толкьо на стеки для этих потоков?
Мне кажется, вы уже зашли в область фантастики, причем далеко. Расскажите-ка мне, какая операционная система позволяет организовать и шедулить миллион потоков. И сколько памяти уйдет толкьо на стеки для этих потоков?
Извините, но вы видимо с данной темой знакомы только по наслышке. Почти всегда существует лимит на максимальное количество рабочих потоков.
Не важно, на уровне приложения или на уровне ОС этот лимит. Важно, что он всегда есть и приложение не сможет обработать клиентов больше этого лимита (1 поток = 1 клиент).
Ошибаетесь. Если БД отвечает достаточно быстро (OLTP система, к примеру), то потоки будут блокироваться на очень небольшое время, так что рабочих потоков понадобится немногим больше, чем ядер.
Ок, убедили, иногда параллельность используется удачно. Но, опять же, очень много проблем с блокировками, за всем этим нужно внимательно следить, чтобы либо не блокировалось, либо блокировалось с маленькой задержкой. Такие проблемы возникают из-за того, что конкретную задачу пытаются вписать в рамки параллельности, вместо того, чтобы найти более подходящую модель. Поэтому я считаю, что веб-приложения — это неудачный пример использования параллельности, т.к. она здесь используется скорее как костыль, чем как реально подходящая модель.
>Это ж надо было такую неэффективную систему придумать, как будто специально старались.
А как сделать лучше?
А как сделать лучше?
>В общем, кроме узкоспециальных задач типа расчета прогнозов погоды, эти мультипроцессорные системы больше ниокму не нужны, а меньше всего они нужны разработчикам, которым и так головной боли хватает, делать больше нечего, как отлавливать трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего.
Те же самые «трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего» отлично себя чувствуют не только в мультипроцессорных системах, но и в однопроцессорных (и даже одноядерных), если в программе больше одного потока.
Ура-а-а, даёшь однопоточные программы!
Те же самые «трудновоспроизводимые баги из-за гонок, кривой синхронизации и прочего» отлично себя чувствуют не только в мультипроцессорных системах, но и в однопроцессорных (и даже одноядерных), если в программе больше одного потока.
Ура-а-а, даёшь однопоточные программы!
К вопросу об узкоспециализированности: www.phoronix.com/scan.php?page=news_item&px=OTc5OQ Даже в GiMP добавляют поддержку. В науке же сейчас вообще всё моделирование делается на суперкомпьютерах. В промышленности почти все инженерные расчёты делаются на суперкомпьютерах.
Даже Flash видео проигрывает, нагружая все имеющиеся ядра в процессоре. Иначе были бы существенные тормоза.
Так что. Ну очень сложно назвать эту тему узкоспециализированной
Даже Flash видео проигрывает, нагружая все имеющиеся ядра в процессоре. Иначе были бы существенные тормоза.
Так что. Ну очень сложно назвать эту тему узкоспециализированной
И чего все так любят про эти SIMD и MIMD рассказывать? Вот ни разу не ощутил практической и теоретической пользы от классификации Флинна. Эх. Лучше бы точнее описали системы с общей памятью, ибо на картике у Вас нарисованы кэши у Pentium-ов, а в рассказе сказано, что процессоры просто берут данные из общей памяти.
И у читателя создаётся неверное впечатление, что общая память — это просто, а пересылка сообщений — сложно. Реальная же ситуация обратно противоположная. Да даже и исторически, сначала были транспьютеры, а потом только пришли SMP-машины.
И у читателя создаётся неверное впечатление, что общая память — это просто, а пересылка сообщений — сложно. Реальная же ситуация обратно противоположная. Да даже и исторически, сначала были транспьютеры, а потом только пришли SMP-машины.
Продолжение вот habrahabr.ru/blogs/hi/127007/
Про Линукс не понял…
Про Линукс не понял…
Спасибо за интересную статью.
Вначале только исправьте опечатку
дизайнерам и разработчикам приходится еще думать о том, его заставить работать
Вначале только исправьте опечатку
дизайнерам и разработчикам приходится еще думать о том, его заставить работать
Интересно, но изображения пропали, похоже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в параллельные вычисления