Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 84
Если сделать ставку на что-то очень сложное, то можно потерять много денег.
Если реализация проблем может в себя включать несколько параллельных вычислений логическим образом, то все будет ОК, а если же нет, то зачем ломать себе мозги, разпараллеливая процесс...
Радость веб разработчикам - их это не трогает )))
Если реализация проблем может в себя включать несколько параллельных вычислений логическим образом, то все будет ОК, а если же нет, то зачем ломать себе мозги, разпараллеливая процесс...
Радость веб разработчикам - их это не трогает )))
Радость веб разработчикам - их это не трогает )))
Вот как раз таких программистов intel призывает учиться, учиться и учиться.
Дополню свой ответ модным нынче на хабре примером языка Ruby.
http://www.rubycentral.com/book/tut_thre…
http://www.rubycentral.com/book/tut_thre…
Немного не согласен. Вызов нового потока очень ёмкая задача. Для приложений, которые выполняются в вебе это скорее всего недопустимо. Я не говорил, что этого нельзя сделать. Можно, только нужно ли?
Представьте себе: сервер и так скорее всего запустит скрипт в новом потоке. Если умножить на количество пользователей. А теперь нам придётся умножить на количество потоков в нашем скрипте. Пусть у нас модный сервер на котором 16 ядер. Процессов значительно больше чем ядер, поэтому никакого выигрыша в производительности мы не получим - только впустую потраченное время\ресурсы на создание дополнительных потоков + головная боль с синхронизацией, разпаралелливанием задач и нерегулярными нетривиальными глюками...
Представьте себе: сервер и так скорее всего запустит скрипт в новом потоке. Если умножить на количество пользователей. А теперь нам придётся умножить на количество потоков в нашем скрипте. Пусть у нас модный сервер на котором 16 ядер. Процессов значительно больше чем ядер, поэтому никакого выигрыша в производительности мы не получим - только впустую потраченное время\ресурсы на создание дополнительных потоков + головная боль с синхронизацией, разпаралелливанием задач и нерегулярными нетривиальными глюками...
Выигрыш будет огромный, даже на однопроцессорных системах, паралельные потоки давали прирост производительности, что уж говорить о многопроцессорных. Единственная проблема это правильное раскидывание данных и кода на несколько процессоров, что не так то и просто с учетом того какие сейчас пошли программисты. А все глюки исключительно из-за кривых рук.
Единственная проблема это правильное раскидывание данных и кода на несколько процессоров…В вузе есть такая дисциплина «Системный анализ и принятие решений». Она как раз решает такие задачи.
Очень интересно - как распараллеливание задачи даёт прирост производительности на одинственном процессоре? (Если конечно не брать в расчет частный случай ожидания ввода-вывода.)
Эээ вы вообще понимаете зачем оно выполняется ?
Если под "оно" имеется в виду распараллеливание - то в случае в ожидания ВВ в отдельном потоке - да, понимаю.
Во всех остальных случаях - нет.
Во всех остальных случаях - нет.
Ожидание ввода вывода это одна из частностей. К примеру в случае наличия двух ядер. Один из потоков может что-то считать пока вы что-то еще делаете.
Два ядра - это всё таки уже не "единственный процессор".
Распараллеливание иначе не будет иметь смысла. На одном ядре оно имеет как раз в случае ожидания ввода-вывода.
Так я это и имел в виду :)
Просто, в оригинальном сообщении речь шла о том, что "даже на однопроцессорных системах, паралельные потоки давали прирост производительности"
Просто, в оригинальном сообщении речь шла о том, что "даже на однопроцессорных системах, паралельные потоки давали прирост производительности"
Все просто, потоки имеют разный приоритет, даже если в данный момент все потоки приложения чем-то заняты, путем расстановки приоритета можно выиграть время. Хотя конечно случай с ожиданием ввода-вывода дает больший выигрыш.
Т.е., к примеру, есть два потока - один считает 2*2, другой - 3*3, если первому поставить приоритет больший - он посчитается быстрее, допустим вместо 10 секунд - за 8 (второй, соответственно, вместо 10 - за 12). Но если последовательно посчитать сначала 2*2, а потом - 3*3, то 2*2 мы расчитаем за 5 сек., и еще за 5 - 3*3. И где здесь выигрыш времени?
У Джоэла это описано подробнее и с картинками.
У Джоэла это описано подробнее и с картинками.
Приведу пример:
0 поток работает с пользователем
1 поток что-нибудь принимает с порта.
2 поток обрабатывает эти данные.
3 посылает в инет обработанные данные
Все это работает достаточно медленно, но работает. Если все это делать линейно то пользователь будет несколько не доволен.
А вообще если у Вас однопроцессорная система, можем провести эксперимент.
0 поток работает с пользователем
1 поток что-нибудь принимает с порта.
2 поток обрабатывает эти данные.
3 посылает в инет обработанные данные
Все это работает достаточно медленно, но работает. Если все это делать линейно то пользователь будет несколько не доволен.
А вообще если у Вас однопроцессорная система, можем провести эксперимент.
…Можно, только нужно ли? Представьте себе: сервер и так скорее всего запустит скрипт в новом потоке…Спорить не буду. Но думаю что на всяких майспейсах на всяких там аспнетах работают не тривиальные алгоритмы. Что и призывает делать intel, быть умнее. А для домашних страничек, да, многопоточность не нужна.
Вызов нового потака в руби нефига не емкая задача. Патамучта green threads.
Пусть у нас модный сервер с 64 ядрами.
Считать надо не процессы, а активные процессы (вы часто видете L/A == 64?). Выигрыш в производительности - если вам надо опрасить 10 серверов и на каждый запрос уходит 0.1 - 0.2 c то что будет лучше - держать 1 активный поток 1-2 секунды или 10 по 0.1 - 0.2? Сплошной FUD.
Пусть у нас модный сервер с 64 ядрами.
Считать надо не процессы, а активные процессы (вы часто видете L/A == 64?). Выигрыш в производительности - если вам надо опрасить 10 серверов и на каждый запрос уходит 0.1 - 0.2 c то что будет лучше - держать 1 активный поток 1-2 секунды или 10 по 0.1 - 0.2? Сплошной FUD.
Да - и ещё один нюанс веба: от количества потоков канал шире не станет. Делая 2 запроса одновременно мы получим почти тоже самое что подряд.
Это не проблема параллельного программирования. Это проблема каналов связи, маршрутизатора, хостинга...
На самом деле это сильно зависит от. Допустим, время вычисления ответа занимает 5 секунд, а пересылка результата - 0.1 секунду. При этом пусть даже канал способен эффективно пропускать только один результат. Тогда в параллельном задании запроса мы получим общее время ответа <= 5 + 0.1 * 2 = 5.2, при последовательном - (5 + 0.1) * 2 = 10.2. ИМХО это большая разница.
В Ruby сейчас как и в питоне - GIL. Поэтому тредься или что ещё - труъ многопоточности не будет. А форкаться - дорого и не всегда удобно.
Нового процесса — да, ёмкая. Нового потока — нет. На однопроцессорной системе выигрыша не будет, а вот уже на 2-хпроцессорных появится. А сейчас речь идёт о том, что через 2-5 лет на всех офисных и домашних машинах будут многоядерные машины.
Хм... Наврядли.
Думаю, стоит отметить что статья о программировании в параллельных процессах (потоках) а не о виде экстремального кодинга.
Мы готовы!
Эх, вспомнились лабораторные работы на 5-м курсе, по параллельным вычислениям на 4-хпроцессорном кластере. А мы считали, что это бред. Ан нет - будующее.
Эх, вспомнились лабораторные работы на 5-м курсе, по параллельным вычислениям на 4-хпроцессорном кластере. А мы считали, что это бред. Ан нет - будующее.
Параллельное программирование - практически полезная вещь. Но разработчики, как народ ленивый, сами не начнут его использовать.
А написать приложение в несколько потоков - не так уж и сложно. Главное - было бы желание, а скорее, требование архитектора.
А написать приложение в несколько потоков - не так уж и сложно. Главное - было бы желание, а скорее, требование архитектора.
Написать не сложно, а вот отладить, да ещё чтобы оно потом работало, да ещё чтобы так как было задумано... ;)
Мне приходилось писать довольно объемные приложения в 3-4 потока, с разными механизмами обмена и синхронизации. Дело лишь на первый взгляд страшное. Отладка немногим сложнее. Главное - четко понимать, что пишешь, т.к. запутаться тут в разы сложнее, все идет ведь не последовательно и нужно в голове прорабатывать всю схему в деталях.
Пожелать бы еще этой самой Майкрософт сделать _удобный_ API для параллелизма...Хотя, наверное, я необъетивен.
А чего не хватает в WinApi для разработки "паралельных" проектов?
Если интересно, то посмотрите в MSDN начиная с функции CreateThread, или просто с раздела "About Processes and Threads", или о синхронизации, тоже в MSDN.
Также очень удобными классами в MFC я считаю все что наследуются от CSyncObject. Все это я довольно долго и успешно использую на практике.
Написанное относится к С++. Думаю это будет легче в .NET, но его я не шарю (
Если интересно, то посмотрите в MSDN начиная с функции CreateThread, или просто с раздела "About Processes and Threads", или о синхронизации, тоже в MSDN.
Также очень удобными классами в MFC я считаю все что наследуются от CSyncObject. Все это я довольно долго и успешно использую на практике.
Написанное относится к С++. Думаю это будет легче в .NET, но его я не шарю (
В .NET неплохой API. Вот, на RSDN неплохая статья на русском языке (перевод): http://rsdn.ru/article/dotnet/CSThreadin…
Возникла задача написать прототип сервера для многопользовательской игры. Особых требований не было, но в какой-то момент прозвучала цифра 10 000 клиентов одновременно. Полистав интернет и пару книжек по теме, я выбрал самый простой вариант: выделить отдельный поток для каждого клиентского соединения. Через несколько дней прототип заработал и, к моему удивлению, потянул эти 10 тыс. клиентов на 3-х гигагерцовом процессоре.
Внимание вопрос: можно ли считать что я выполнил пожелание старших братьев на много лет вперед, или я просто не успел прочитать что так не делают? ))
Внимание вопрос: можно ли считать что я выполнил пожелание старших братьев на много лет вперед, или я просто не успел прочитать что так не делают? ))
Нет, нельзя. Ты ведь полистал интернет и книги чтобы придумать это ;)
Серверы очень давно пишут таким образом...
Серверы очень давно пишут таким образом...
Как раз наоборот, почитав интернет, я нашел очень сложные примеры, которые призваны сократить количество потоков ))
У Вас взаимодействие между этими нитями есть? Такое ощущение, что вряд ли. Вот когда появится, когда встанут проблемы синхронизации, когда планировщик начнёт у Вас бросать эти нитки по процессорам с большими кэшами, как попало, тогда и увидите все прелести многопоточного программирования.
P.S. Маленький вопрос: процессор в 3 гигагерца - это же pentium 4 не самый новый, то есть 32 битный процессор. Если Вы писали под Windows, то для приложения доступное виртуальное адресное пространство составляет 2 гигабайта. А для каждой нити отводится по умолчанию по мегабайту стека, меньшие же стеки опасны, обычно. Как вы умудрились запустить одновременно 10 тысячь нитей, работающих с сетью через динамические библиотеки, требования к объёмам стеков у которых заранее не известны?
P.S. Маленький вопрос: процессор в 3 гигагерца - это же pentium 4 не самый новый, то есть 32 битный процессор. Если Вы писали под Windows, то для приложения доступное виртуальное адресное пространство составляет 2 гигабайта. А для каждой нити отводится по умолчанию по мегабайту стека, меньшие же стеки опасны, обычно. Как вы умудрились запустить одновременно 10 тысячь нитей, работающих с сетью через динамические библиотеки, требования к объёмам стеков у которых заранее не известны?
Взаимодействие между нитями конечно есть. Нити обращаются к общим структурам данных. Тут помогло пространственное разделение и рид-райт локи.
Стек конечно пришлось уменьшить, но я использую небольшое количество алгоритмов внутри обработчика каждого клиента, так что проблем с этим не было. Точнее тестирование пока не выявило таких проблем ))
Кстати под win32 запуск такого количества нитей оказался небыстрой процедурой. А под линукс наоборот, запускаются быстро, но в целом работает медленнее (я использую pthread).
Стек конечно пришлось уменьшить, но я использую небольшое количество алгоритмов внутри обработчика каждого клиента, так что проблем с этим не было. Точнее тестирование пока не выявило таких проблем ))
Кстати под win32 запуск такого количества нитей оказался небыстрой процедурой. А под линукс наоборот, запускаются быстро, но в целом работает медленнее (я использую pthread).
Если у программиста хорошее образование, он и так это знать должен. Интелу может не нравится что большинство думает что двухъядерный проц работает как два одноядерных?
По-моему, яйца начинают учить курицу.
Сначала появляется задача, потом программист думает, как он ее будет решать. И если будет появляться достаточно задач которые будут легче (быстрее, проще, дешевле) решаться многопоточным программированием, девелоперы быстренько его освоят.
А тут откровенно хотят подсадить на иглу и удивляются, почему клиенты не спешат этого делать. Да потому что задачи пока с успехом решаются традиционными способами.
А ларчик просто открывается. Если будут программировать для нескольких потоков, то старые одноядерные процы будут не нужны и начнется новый виток развития процессоров, которые уже давно обеспечивают избыточную производительность.
Микрософт же - главный скрытый партнер Intel в этом вопросе. Понимая, что с новым компом будут покупать и новую ОС, MS намеренно каждую новую систему старается делать так, чтобы повысить нагрузку на железо и вынудить пользователя сделать апгрейд. Реально Vista не привнесла ничего нового, кроме того, что вычислительные ресурсы железа стали использоваться на полную катушку, вынуждая доверчивых юзеров подумывать о новом компе.
Короче, сговор это. Причем явный.
Хорошо, что есть AMD, Linux и Apple. :)
Сначала появляется задача, потом программист думает, как он ее будет решать. И если будет появляться достаточно задач которые будут легче (быстрее, проще, дешевле) решаться многопоточным программированием, девелоперы быстренько его освоят.
А тут откровенно хотят подсадить на иглу и удивляются, почему клиенты не спешат этого делать. Да потому что задачи пока с успехом решаются традиционными способами.
А ларчик просто открывается. Если будут программировать для нескольких потоков, то старые одноядерные процы будут не нужны и начнется новый виток развития процессоров, которые уже давно обеспечивают избыточную производительность.
Микрософт же - главный скрытый партнер Intel в этом вопросе. Понимая, что с новым компом будут покупать и новую ОС, MS намеренно каждую новую систему старается делать так, чтобы повысить нагрузку на железо и вынудить пользователя сделать апгрейд. Реально Vista не привнесла ничего нового, кроме того, что вычислительные ресурсы железа стали использоваться на полную катушку, вынуждая доверчивых юзеров подумывать о новом компе.
Короче, сговор это. Причем явный.
Хорошо, что есть AMD, Linux и Apple. :)
Многопоточности лет 30 точно есть. И никто никого не подсаживает, она была сделана для того, что бы избавиться от тяжелого переключения контекста в мультипроцессном варианте, и от ядерности проца это не зависит. Мультизадачность, во многих задачах решение необходимое, просто мало кто хочет заморачиватся над её реализацией, и с умыслом или без делают изначально тормозные продукты. А если процессор специально заточен на мультипоточность, то просто глупо этим не пользоваться. Хотя политика Интела конечно хороша - сначала процессор позиционируется как удвоитель скоростей по умолчанию, а потом, когда все купят, обнаруживается что надо ещё и всё переписать заново.
Как это не подсаживает? Судя по этой статье буквально заставлять собираются.
И когда перепишут для этого проца, эти же программы будут работать так же эффективно на старых процах?
И когда перепишут для этого проца, эти же программы будут работать так же эффективно на старых процах?
Вы видимо меня не поняли =) Распараллеливание во многих случаях просто необходимо. Нити(ну мне так привычней) были придуманы ещё давно, когда о куче ядер речь не шла. Теперь есть многоядерные процессоры, которые с задачей нитей справляются лучше чем одноядерные, и если раньше отсутствие нитей на загрузке процессора ни как не сказывалось, то теперь отсутствие нитей там, где их просто не захотели делать просто не даёт использовать процессор на полную мощность. По-моему это глупо.
Я как раз понимаю Вас. Но одно дело иметь возможность переписать при необходимости, а другое дело чуть ли не принудительное обучение и использование этой возможности.
Смысл моего поста не в том, что не нужно использовать возможности процессора, а в том, что это должно быть обосновано с точки зрения бизнеса. Если обучение и работа квалифицированного программиста дороже наращивания мощности железа, то, естественно, вместо того, чтобы переписывать код, нужно покупать железо.
Смысл моего поста не в том, что не нужно использовать возможности процессора, а в том, что это должно быть обосновано с точки зрения бизнеса. Если обучение и работа квалифицированного программиста дороже наращивания мощности железа, то, естественно, вместо того, чтобы переписывать код, нужно покупать железо.
Ну, переключение контекста у тредов и у процессов различается очень и очень немного - в основном это установка MMU. По моим измерениям, если поток/процесс делает что-то полезное, разницу в скорости переключения заметить очень и очень сложно. ИМХО основная(и при этом самая полезная/опасная) разница между процессами и тредами - общее адресное пространство у последних. Это конечно очень удобно(для всякого рода кешэй), но одновременно и очень опасно. Поэтому(например в случае написания большой системы большим коллективом разработчиков), многопроцессная парадигма может быть более оправдана.
Большинство программистов смотрят на параллельное программирование
через призму ущербных языков c++/java и т.п.
Трэды - ИМХО, тупик. Очень высокий оверхид на запуск/синхронизацию, поддержание стейта, несовершенная система планирования.
Более правильный путь - асинхронные task-based системы. На уровне железа.
Правда, с существующей инфраструктурой, это пока что извращённый мазохизм.
через призму ущербных языков c++/java и т.п.
Трэды - ИМХО, тупик. Очень высокий оверхид на запуск/синхронизацию, поддержание стейта, несовершенная система планирования.
Более правильный путь - асинхронные task-based системы. На уровне железа.
Правда, с существующей инфраструктурой, это пока что извращённый мазохизм.
Наш путь - erlang и OS Inferno %)
Ну вообще-то асинхронные task-based системы сами не начнут использовать больше одного проца. Их тоже надо парралетить... хотя оверхэд в любом случае меньше на порядок.
И в чём же его правильность? Какая по большому счёту разница: task/не task? Если у Вас вытесняющая многозадачность (multitasking), то состояние и планирование так или иначе нужны. Если многозадачность, например, кооперативная, или пакетная, или ещё какая-нибудь древняя, то система будет убиваться хакерами на счёт 'раз'.
От синхронизации тоже никуда не сбежать. Если файловая система одна, то 10 задач (tasks) работать с ней без синхронизации в каком-либо виде не смогут. Хоть синхронно, хоть (и даже тем более) асинхронно. Поддержка этого всего может быть аппаратной или не аппаратной, но проблемы с потерями производительности на ожидания и со сложностью протоколов взаимодействия она не решит.
Менять надо сам способ описания параллельных программ, а не механизмы поддерживающие работу многозадачных систем. Кстати, в любом современном процессоре есть куча примитивов для поддержки именно многозадачности: начиная с прерываний, режима ядра, специальных инструкций, вроде cmpxchgl, регистров (регистры на самом деле - это именно средства поддержки многозадачности. Существуют процессоры без регистров и на них с многозадачностью довольно туго), заканчивая алгоритмами синхронизации кэшей. Разве этого мало?
От синхронизации тоже никуда не сбежать. Если файловая система одна, то 10 задач (tasks) работать с ней без синхронизации в каком-либо виде не смогут. Хоть синхронно, хоть (и даже тем более) асинхронно. Поддержка этого всего может быть аппаратной или не аппаратной, но проблемы с потерями производительности на ожидания и со сложностью протоколов взаимодействия она не решит.
Менять надо сам способ описания параллельных программ, а не механизмы поддерживающие работу многозадачных систем. Кстати, в любом современном процессоре есть куча примитивов для поддержки именно многозадачности: начиная с прерываний, режима ядра, специальных инструкций, вроде cmpxchgl, регистров (регистры на самом деле - это именно средства поддержки многозадачности. Существуют процессоры без регистров и на них с многозадачностью довольно туго), заканчивая алгоритмами синхронизации кэшей. Разве этого мало?
>>И в чём же его правильность?
При условии правильной реализации, таски можно запускать десятки-сотни тысяч раз в секунду.
Т.о. можно параллелить каждый чих.
Сейчас затраты на создание трэда в сотни раз больше чем нужно.
Хотя подобный планировщик можно построить и на существующих системах,
но он утонет в синхронизации.
>> Если файловая система одна
А если я параллелю внутренний вычислительный цикл? Мне не нужен ни TLS, ни, возможно, даже стек.
>>Менять надо сам способ описания параллельных программ,
>>а не механизмы поддерживающие работу многозадачных систем.
Про первое я и говорю, со вторым не согласен. Сколько вы на запорожце не пишите F1 pro street racing он от этого быстрее не побежит.
Про регистры не понял. Какое отношение они имеют к многозадачности?
Наоборот, с ними проблем больше - надо сохранять/восстанавливать.
При условии правильной реализации, таски можно запускать десятки-сотни тысяч раз в секунду.
Т.о. можно параллелить каждый чих.
Сейчас затраты на создание трэда в сотни раз больше чем нужно.
Хотя подобный планировщик можно построить и на существующих системах,
но он утонет в синхронизации.
>> Если файловая система одна
А если я параллелю внутренний вычислительный цикл? Мне не нужен ни TLS, ни, возможно, даже стек.
>>Менять надо сам способ описания параллельных программ,
>>а не механизмы поддерживающие работу многозадачных систем.
Про первое я и говорю, со вторым не согласен. Сколько вы на запорожце не пишите F1 pro street racing он от этого быстрее не побежит.
Про регистры не понял. Какое отношение они имеют к многозадачности?
Наоборот, с ними проблем больше - надо сохранять/восстанавливать.
При условии правильной реализации, таски можно запускать десятки-сотни тысяч раз в секунду.
Т.о. можно параллелить каждый чих.
Сейчас затраты на создание трэда в сотни раз больше чем нужно.
Хотя подобный планировщик можно построить и на существующих системах,
но он утонет в синхронизации.
Если запустить две задачи, то на одном процессоре каждая из них будет работать в два раза медленней, плюс затраты на переключение контекстов, которые растут линейно от количества задач. Осмысленно ли в этих условиях параллелить каждый чих?
Кроме того, существует техника создания пуллов нитей или процессов, которые способны очень быстро начинать исполнение указанной работы. При этом используется такая логика: выделили вычислительные ресурсы, затем начали их использовать, без повторных выделений и уничтожений. Скорость создания перестаёт быть критичной.
А это хорошо, потому что создание новой задачи - это не такая уже простая операция - как эффективно её не программируй, но нужно выделять память под контекст и под стек ядра, инициализировать некоторые служебные структуры, ставить задачу в очередь исполнения и так далее. Можно сделать очень эффективно, гораздо эффективнее, чем в Linux или Windows, но это будет всё-равно медленней, чем заказ задаче из пула произвести вычисление.
Про регистры не понял. Какое отношение они имеют к многозадачности?
Наоборот, с ними проблем больше - надо сохранять/восстанавливать.
Как раз это и гарантирует то, что можно сохранить состояние вычисления и перейти к другому вычислению. То есть, организовать многозадачность.
Про первое я и говорю, со вторым не согласен. Сколько вы на запорожце не пишите F1 pro street racing он от этого быстрее не побежит.
Аналогия неверная. Скорее так: и Porsche, и Запорожец состоят из примитивных деталей, работающих по одинаковым принципам. Чем шестерёнки в Porsche концептуально лучше шестерёнок в Запорожце? Другое дело, как эти примитивые собрать и какой к ним приложить интерфейс.
Т.о. можно параллелить каждый чих.
Сейчас затраты на создание трэда в сотни раз больше чем нужно.
Хотя подобный планировщик можно построить и на существующих системах,
но он утонет в синхронизации.
Если запустить две задачи, то на одном процессоре каждая из них будет работать в два раза медленней, плюс затраты на переключение контекстов, которые растут линейно от количества задач. Осмысленно ли в этих условиях параллелить каждый чих?
Кроме того, существует техника создания пуллов нитей или процессов, которые способны очень быстро начинать исполнение указанной работы. При этом используется такая логика: выделили вычислительные ресурсы, затем начали их использовать, без повторных выделений и уничтожений. Скорость создания перестаёт быть критичной.
А это хорошо, потому что создание новой задачи - это не такая уже простая операция - как эффективно её не программируй, но нужно выделять память под контекст и под стек ядра, инициализировать некоторые служебные структуры, ставить задачу в очередь исполнения и так далее. Можно сделать очень эффективно, гораздо эффективнее, чем в Linux или Windows, но это будет всё-равно медленней, чем заказ задаче из пула произвести вычисление.
Про регистры не понял. Какое отношение они имеют к многозадачности?
Наоборот, с ними проблем больше - надо сохранять/восстанавливать.
Как раз это и гарантирует то, что можно сохранить состояние вычисления и перейти к другому вычислению. То есть, организовать многозадачность.
Про первое я и говорю, со вторым не согласен. Сколько вы на запорожце не пишите F1 pro street racing он от этого быстрее не побежит.
Аналогия неверная. Скорее так: и Porsche, и Запорожец состоят из примитивных деталей, работающих по одинаковым принципам. Чем шестерёнки в Porsche концептуально лучше шестерёнок в Запорожце? Другое дело, как эти примитивые собрать и какой к ним приложить интерфейс.
>> Если запустить две задачи, то на одном процессоре каждая
>> из них будет работать в два раза медленней
А не надо запускать 2 штуки на 1 ядре.
Под "задачей" подразумевается некая последовательность операций,
достаточно короткая для того, чтобы не делать её принудительное вытеснение,
либо делать его редко.
Параллелить имеет смысл только то, что можно запараллелить =)
Через несколько лет 16+ ядерные процессоры будут на каждом столе. Niagara вон уже 32 аппаратных треда запускает, а Rock - 64.
>> существует техника создания пуллов нитей или процессов
Это довольно стандартная практика. Кардинальной разницы нет.
>> Как раз это и гарантирует то, что можно сохранить состояние
>> вычисления и перейти к другому вычислению.
>> То есть, организовать многозадачность.
Это фейк, иллюзия одновременного исполнения.
Если у нас есть несколько реальных ядер/аппаратных трэдов, надобность в прерывании работы может и не понадобится.
>> из них будет работать в два раза медленней
А не надо запускать 2 штуки на 1 ядре.
Под "задачей" подразумевается некая последовательность операций,
достаточно короткая для того, чтобы не делать её принудительное вытеснение,
либо делать его редко.
Параллелить имеет смысл только то, что можно запараллелить =)
Через несколько лет 16+ ядерные процессоры будут на каждом столе. Niagara вон уже 32 аппаратных треда запускает, а Rock - 64.
>> существует техника создания пуллов нитей или процессов
Это довольно стандартная практика. Кардинальной разницы нет.
>> Как раз это и гарантирует то, что можно сохранить состояние
>> вычисления и перейти к другому вычислению.
>> То есть, организовать многозадачность.
Это фейк, иллюзия одновременного исполнения.
Если у нас есть несколько реальных ядер/аппаратных трэдов, надобность в прерывании работы может и не понадобится.
В теории 4 ядра по 2 ггц будут явно медленнее одного на 8 (ограничения хотя бы на дублирующиеся кеши процессора). Однако 8ггц процессор будет в несколько дороже чем 4 ядра 2ггц.
Отсюда вывод что в теории создавать оооочень большое количество ядер - будет дешевле.
Предположим сервер. Например с 2 ядрами. Сейчас большинство PHP (например) программистов легко могут их занять. А теперь представьте сервер с 128 ядрами (а ведь будут массово). Чтобы эффективно их все использовать и не тратить до 30% времени на всякую чепуху (парсинг require в том же пхп) нужно использовать распределённую память и проч. Думаю огромный процент программистов высокоуровневых языков явно охренеет когда первый раз словит race condition. Начнёт читать про семафоры и подумает - что программист он не ахти какой оказывается.
А как заюзать многопоточность в высокоуровневых языках? PHP - вариант только с колво_ядер+1 поток при fastcgi + такое же кол-во потоков управляющего веб-сервера. Ну либо огромная куча форков апача с PHP как модулем (причём затраты на создание форка - кака). И каждый чертов PHP будет делать сотни две stat вызовов в фс, даже если стоит APC при каждом запросе.. (типичная ситуация для пользователей фреймворков а-ля ZendFramework). Уже абсурд. Питон. Есть потоки, после загрузки в основном только бизнес-логика работает. Но есть чёртов Global Interpreter Lock, который не позволяет-таки эффективно грузить много ядер (ну +20-30% будет максимум). Опять же питон придётся форкать. Появятся сложности с распределённой памятью (либо необходимый размер ОЗУ для работы вырастет в количестве форков, либо нужно добавлять ещё один хрупкий (при недостаточной сообразительности программиста) элемент такой как - отдельный распределённый кеш (который может создать массу race condition сложно уловимых). Как вариант - си с pthreads в который засовывать питон. Но это требует уже оочень высокой квалификации иначе есть угроза отстутствия прироста скорости вообще :).
Помимо всего прочего современный разработчик обязан делать софт не только многопоточным, но ещё и с возможонстью кластеризации. Два сервера с 4 ядрами явно лучше чем 1 с восемью.
Разрабатывать такие приложения очень сложно. Как правило требуется тратить огромное количество усилий на документирование и ТЗ иначе следующий или просто новый программист ничего не сможет понять.
Отчасти это причина почему у Java программистов обычно зарплата качественно выше чем PHP и находится на уровне Python/C.
Остаётся конечно возможность реализации совсем сложных решений - kernel-space многопоточников распределяющих задачи над user-space софтом... Это не под силу 99% разработчикам (я не понтуюсь - тоже вхожу пока в их число :)).
В идеале смысл многопоточности состоит в общении потоков между друг другом. Т.е. когда один поток говорит другому "о, коллега, у меня тут запрос пришёл и кое-что обновилось - обнови ка и у себя это". mayevski выше сказал - мол, если есть куча процессов - нафиг городить многопоточность.. а вот представьте себе 128 ядер. И у них есть общая настроечка такая - скажем счётчик посещений. Вы только представьте сколько можно сэкономить буквально на этой мелкой штуке если использовать распределённую память. Только при этом особый выигрыш будет при традиционной shmem и pthreads и, как следствие, Си. В других же случаях, тот же APC у пхп при обслуживании 128 потоков грозит быть затычкой для них всех (т.к. лочить будет).
В общем тема животрепещущая, на мой взгляд. Кто использовал Linux Virtual Server - скажите он серьёзно может делать 1 логическую вычислительную единицу даже из нескольких компов, не то чтобы ядер?
Отсюда вывод что в теории создавать оооочень большое количество ядер - будет дешевле.
Предположим сервер. Например с 2 ядрами. Сейчас большинство PHP (например) программистов легко могут их занять. А теперь представьте сервер с 128 ядрами (а ведь будут массово). Чтобы эффективно их все использовать и не тратить до 30% времени на всякую чепуху (парсинг require в том же пхп) нужно использовать распределённую память и проч. Думаю огромный процент программистов высокоуровневых языков явно охренеет когда первый раз словит race condition. Начнёт читать про семафоры и подумает - что программист он не ахти какой оказывается.
А как заюзать многопоточность в высокоуровневых языках? PHP - вариант только с колво_ядер+1 поток при fastcgi + такое же кол-во потоков управляющего веб-сервера. Ну либо огромная куча форков апача с PHP как модулем (причём затраты на создание форка - кака). И каждый чертов PHP будет делать сотни две stat вызовов в фс, даже если стоит APC при каждом запросе.. (типичная ситуация для пользователей фреймворков а-ля ZendFramework). Уже абсурд. Питон. Есть потоки, после загрузки в основном только бизнес-логика работает. Но есть чёртов Global Interpreter Lock, который не позволяет-таки эффективно грузить много ядер (ну +20-30% будет максимум). Опять же питон придётся форкать. Появятся сложности с распределённой памятью (либо необходимый размер ОЗУ для работы вырастет в количестве форков, либо нужно добавлять ещё один хрупкий (при недостаточной сообразительности программиста) элемент такой как - отдельный распределённый кеш (который может создать массу race condition сложно уловимых). Как вариант - си с pthreads в который засовывать питон. Но это требует уже оочень высокой квалификации иначе есть угроза отстутствия прироста скорости вообще :).
Помимо всего прочего современный разработчик обязан делать софт не только многопоточным, но ещё и с возможонстью кластеризации. Два сервера с 4 ядрами явно лучше чем 1 с восемью.
Разрабатывать такие приложения очень сложно. Как правило требуется тратить огромное количество усилий на документирование и ТЗ иначе следующий или просто новый программист ничего не сможет понять.
Отчасти это причина почему у Java программистов обычно зарплата качественно выше чем PHP и находится на уровне Python/C.
Остаётся конечно возможность реализации совсем сложных решений - kernel-space многопоточников распределяющих задачи над user-space софтом... Это не под силу 99% разработчикам (я не понтуюсь - тоже вхожу пока в их число :)).
В идеале смысл многопоточности состоит в общении потоков между друг другом. Т.е. когда один поток говорит другому "о, коллега, у меня тут запрос пришёл и кое-что обновилось - обнови ка и у себя это". mayevski выше сказал - мол, если есть куча процессов - нафиг городить многопоточность.. а вот представьте себе 128 ядер. И у них есть общая настроечка такая - скажем счётчик посещений. Вы только представьте сколько можно сэкономить буквально на этой мелкой штуке если использовать распределённую память. Только при этом особый выигрыш будет при традиционной shmem и pthreads и, как следствие, Си. В других же случаях, тот же APC у пхп при обслуживании 128 потоков грозит быть затычкой для них всех (т.к. лочить будет).
В общем тема животрепещущая, на мой взгляд. Кто использовал Linux Virtual Server - скажите он серьёзно может делать 1 логическую вычислительную единицу даже из нескольких компов, не то чтобы ядер?
Ну если говорить реально, то на самом деле создание больших систем очень и очень сложно. Потому что обычно это одновременно и кластер высокой доступности и распарралеливание нагрузки. И там сложности начинаются с правильной организации аппаратной части. И вот если аппаратура установлена непродуманно, то никакой софт софт вам уже не поможет, как бы качественно он не был сделан.
По поводу GIL в Python - тут единственный приемый вариант объезда, это создание нескольких процессов и поднятие event-dispatcher'а между ними. Внутри процессов можно например гонять так называемые невесомые нити.
По поводу GIL в Python - тут единственный приемый вариант объезда, это создание нескольких процессов и поднятие event-dispatcher'а между ними. Внутри процессов можно например гонять так называемые невесомые нити.
В идеале смысл многопоточности состоит в общении потоков между друг другом. Т.е. когда один поток говорит другому "о, коллега, у меня тут запрос пришёл и кое-что обновилось - обнови ка и у себя это". mayevski выше сказал - мол, если есть куча процессов - нафиг городить многопоточность.. а вот представьте себе 128 ядер. И у них есть общая настроечка такая - скажем счётчик посещений. Вы только представьте сколько можно сэкономить буквально на этой мелкой штуке если использовать распределённую память. Только при этом особый выигрыш будет при традиционной shmem и pthreads и, как следствие, Си. В других же случаях, тот же APC у пхп при обслуживании 128 потоков грозит быть затычкой для них всех (т.к. лочить будет).
Чтобы сделать общий счётчик на общей памяти, нужно будет устраивать синхронизацию. А теперь представьте, что у вас 128 нитей выполнят lock и будут ждать друг дружку довольно долго. И простаивать. Зачем тогда 128 ядер и нитей? Да и вообще, 128 ядер с общей памятью - это несколько безумно. Узкое место современных систем - это совсем не скорость работы процессоров, а скорость работы памяти. Шины кое как с двумя ядрами справляются, а тут их в 64 раза больше. Зачем вся эта лишняя электроника, если она будет сама себя тормозить при каждом обращении в память?
Вообще говоря, SUN проводила исследования того, насколько масштабируются аппаратура с общей памятью и приложения с нитями, и оказалось, что даже при 32 процессорах расходы на различную синхронизацию составляют 20% процессорного времени. Не так уж и мало.
Поэтому, если в системе, вдруг, появляется общий счётчик у 128 задач, то это какая-то явная ошибка в проектировании.
Чтобы сделать общий счётчик на общей памяти, нужно будет устраивать синхронизацию. А теперь представьте, что у вас 128 нитей выполнят lock и будут ждать друг дружку довольно долго. И простаивать. Зачем тогда 128 ядер и нитей? Да и вообще, 128 ядер с общей памятью - это несколько безумно. Узкое место современных систем - это совсем не скорость работы процессоров, а скорость работы памяти. Шины кое как с двумя ядрами справляются, а тут их в 64 раза больше. Зачем вся эта лишняя электроника, если она будет сама себя тормозить при каждом обращении в память?
Вообще говоря, SUN проводила исследования того, насколько масштабируются аппаратура с общей памятью и приложения с нитями, и оказалось, что даже при 32 процессорах расходы на различную синхронизацию составляют 20% процессорного времени. Не так уж и мало.
Поэтому, если в системе, вдруг, появляется общий счётчик у 128 задач, то это какая-то явная ошибка в проектировании.
вы знаете сколько тактов CPU уходит на lock? На саму по себе операцию? Ожидание - да. Но это в тысячи раз быстрее чем традиционный метод PHP-программистов - счетчик в бд/файле.
А теперь представьте веб-приложение качественно нового уровня. Заходит юзер. Авторизуется. Какой-то поток берёт данные из бд. И таких юзеров в какой-то времени, допустим, тысяча. А теперь представьте что один юзер из авторизованных пишет сообщение другому. Традиционный вариант - каждый раз смотреть где-либо (в бд, скажем) есть новые сообщения или нет. А тут один поток просто говорит другому, мол "нью мессадж". И всё.
Конечно, всё не так просто. Конечно, это потом достаточно проблематично распределить на более чем 1 сервер. Но event-driven программирование явно шустрая штука.
Локи локами, но тут уже гораздо большее влияние на производительность оказыывает программист и архитектура приложения в целом.
А теперь представьте веб-приложение качественно нового уровня. Заходит юзер. Авторизуется. Какой-то поток берёт данные из бд. И таких юзеров в какой-то времени, допустим, тысяча. А теперь представьте что один юзер из авторизованных пишет сообщение другому. Традиционный вариант - каждый раз смотреть где-либо (в бд, скажем) есть новые сообщения или нет. А тут один поток просто говорит другому, мол "нью мессадж". И всё.
Конечно, всё не так просто. Конечно, это потом достаточно проблематично распределить на более чем 1 сервер. Но event-driven программирование явно шустрая штука.
Локи локами, но тут уже гораздо большее влияние на производительность оказыывает программист и архитектура приложения в целом.
Вы забыли о том, что http вобще не держит соединений. Ваши пользователи обмениваются сообщениями через БД потому, что процессы, которые их обслуживают могут просто не пересечься во времени.
Сложно забыть, что http это stateless протокол ;). Тем не менее есть а) keepalive и b) - кто мешает рассматривать запрос (в частности, куки) в момент парсинга запроса? Висит, например, поток юзера где-то и приходит запрос который каким-либо образом считается именно запросом _данного_ пользователя. И переправляется потоку. Потоки убивать как сессии - 20 мин неактивности. Я уже использовал такую схему и результат настолько замечателен как я его и расписал ;).
Вот с момента "Висит, например, поток юзера где-то" и начинается неприятное. Хранить в памяти такого зомби в надежде что пользователь ещё не закрыл страницу этого сервера не только расточительно по ресурсам, но и наивно по сути.
Кстати для поддержания соединения существует метод CONNECT, но его оправданность применительно к вэб настолько мала, что и рассматривать стоит лишь в исключительных ситуациях.
Кстати для поддержания соединения существует метод CONNECT, но его оправданность применительно к вэб настолько мала, что и рассматривать стоит лишь в исключительных ситуациях.
хм.. затраты на созднание потока гораздо выше чем на его поддержку. Особенно учитывая то что при инициализации юзера отрабатывает некоторое количество бизнес-логики, что уже совсем намного более ресурсоемко чем голая работа с потоками. При этом все Anonymous-запросы отдельного потока, конечно, не требуют.
Господа, учите язык Т++ и не парьтесь!
www.opents.net
www.opents.net
Рядового программиста это никак не касается, имхо. Параллелизм должен быть на уровне ОС: в идеале - каждому процессу по ядру. Нажмите Ctl+Alt+Del или введите ps -A (как это делается под Mac OS?) сколько у вас процессов? Уж больше 16 - точно. Разве что в играх это нужно будет специальным образом программировать и в других очень ресурсоемких приложениях. Но таких наверно не больше 10%.
Пока менеджеры будут видеть, что задачи решают обычными программистами, они не будут покупать/обучать многопоточных, которые к тому же напишут более сложный и менее поддерживаемый код.
Об "увеличении скорости" и необходимости учиться.
То, что вам никто не говорил о многозадачности в Windows
То, что вам никто не говорил о многозадачности в Windows
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программирование параллельных процессов — это слишком сложно?