Здравствуйте, gear nuke, Вы писали:
R>>лоадбалансер? т.е. ты предлагаешь мне купить домой несколько компьютеров и объединить лоадбалансером?
GN>Нет конечно Но для ряда задач это вполне приемлимое решение. И, главное, железо стоит дешевле, чем что-то переделывать.
Ну это зависит. Допустим сделать "медленный" сервер у меня займёт 2 месяца, а сделать "быстрый" сервер у меня займёт 3 месяца. Итого имеем 1 месячную зарплату программиста против стоимости 9 дополнительных железяк + администрирование + электроэнергия.
И вообще скажи это Гуглу, у которого несколько футбольных полей рэков с плотно-плотно напиханными блейд-серверами
Что бы они сказали на то, что им необходимо в 10 раз больше железа? Или на то, что есть возможность снизить кол-во железа хотя бы в 2 раза?
Это больше вопрос философии и принципа, потому что с опытом время разработки "быстрого" сервера и "медленного" сервера стремится практически к одной величине. На Java это философия — мы делаем медленный софт, но он хорошо масштабируется. Мой коллега, программист на С, говорит — надо держать 50000 соединений, значит буду писать, что б держало 50000 соединений. Я думаю, у него даже не было мысли покупки 10 железяк. Да и ставить их не куда. Да и администрить их всем лень.
R>>Вообще, я говорил не о HPC, не о гипер-кубах замешанных с тета-нотацией. Я говорил об обычных прикладных/системных программистах, которым надо создавать серверное ПО, клиентское ПО, stand-alone ПО, GUI ПО, игры, графические редакторы и т.д.
GN>Я хотел примерно о том же, но абстрагировался через чур. Чему учат в школе? ИМХО проблема даже не в слабой изученности lock-free алгоритмов.
lock-free алгоритмы — это не о производительности и масштабируемости, это исключительно о гарантиях системного прогресса. lock-free алгоритмы зачастую бывают медленнее lock-based алгоритмов. Это как best-effort против QoS, или не real-time против real-time. QoS и real-time всегда медленнее, зато дают дополнительные гарантии.
GN>А в том, что, например, с точки зрения теории сложности вычислений, увеличение количества ядер ничего не даёт! Нужна какая-то исправленная теория, которая будет учитывать количество ядер...
Ну почему не даёт! HPC товарищи любят рассматривать решение задачи размера N на системе с N процессорами
Вот сейчас только книжку дочитал — там все задачи рассматриваются либо на системах с N процессорами, либо на N^(1/2), либо на крайний случай с log(N)
GN>Вот например, если ОС будет давать определённые гарантии, то можно без локов обходиться.
Падение масштабируемости не в локах!!! Падение масштабируемости в разделении данных! А тут никакая ОС не поможет.
GN>Возьмём определение Дейкстры:
Семафор — объект, позволяющий войти в заданный участок кода не более чем n потокам
Тут не сказано о внутреннем устройстве, поэтому некоторые начинают крутить спинлок или вызывают сервис ОС (суть планировщик). А между тем, для компилятора элементарная операция — создать в исполняемом модуле таблицы (подобные как для С++ исключений) с адресами участков защищенного кода, а планировщик посмотрит туда и решит, нужно ли переключать контекст. Но это фантаситка
Ну зачем же так сложно. Всё уже украдено до нас. В некоторых Unix'ах (Solaris/Irix) есть замечательный системный вызов schedctl(2). С его помощью можно из юзер-спейса давать хинт планировщику, что типа "я сейчас в критическом участке кода — не прерывай меня пожалуйста здесь". Всё сводится банально к установке/сбросу флажка.
GN>Или вспомнить упомянутое здесь отсутствие в IRPе поля affinity...
Да... есть такое дело... я потом ещё спрашивал на форумах MSDN... похоже они даже не думали о таких вопросах.
Ну ничего, вот когда интегрированные сетевые карты начнут закачивать трафик прямо в кэш конкретного ядра, ситуация изменится к лучшему
Здравствуйте, remark, Вы писали:
R>Ну это зависит. Допустим сделать "медленный" сервер у меня займёт 2 месяца, а сделать "быстрый" сервер у меня займёт 3 месяца.
Конечно зависит. Например есть старый софт, который уже не удовлетворяет запросы заказчика. Мне кажется, такая ситуация более распространена, и не всегда есть возможность переделать всё.
R>На Java это философия — мы делаем медленный софт, но он хорошо масштабируется.
Хм, как раз сейчас с такими работаем, видимо попал под дурное влияние
R>HPC товарищи любят рассматривать решение задачи размера N на системе с N процессорами
Надо более обобщенно, задачи размера N на системе с K процессорами. Даже не так... а что бы ты всем уши прожужжал и целое поколение выросло на этом.
R>Падение масштабируемости не в локах!!! Падение масштабируемости в разделении данных!
Которые разделяются выставлением сигнала #LOCK на шину
R>Всё уже украдено до нас. В некоторых Unix'ах (Solaris/Irix) есть замечательный системный вызов schedctl(2).
Такая уж она замечательная? Конечно избавились от оверхеда на постоянные вызовы, но — как раз то о чем ты полфорума исписал — запись и чтение в разделяемую память.
Вот в С++ есть 2 подхода к исключениям: MSVC (32бит) создает SEH фреймы в рантайме, а GCC строит таблицы, в которые при необходимости заглянет хендлер (см. TR18015).
Сейчас и MSVC 64 строит таблицы для поддержки исключений, плюс таблицы для раскрутки стека — так что ничего сверхсложного в этом способе нет. Конечно, для гибкости надо оставить и schedctl(2)
R>Ну ничего, вот когда интегрированные сетевые карты начнут закачивать трафик прямо в кэш конкретного ядра, ситуация изменится к лучшему
Кстати, фрагмент NDIS_MINIPORT_BLOCK
//
// This is the processor number that the miniport's
// interrupt DPC and timers are running on.
//
UCHAR AssignedProcessor;
Если я правильно понял, сейчас все запросы с одного интерфейса обрабатываются одним и тем же ядром. И так должно быть везде, ведь NDIS кросплатформ.
ИМХО действительно может измениться к лучшему, если языки и компиляторы будут как-то поддерживать существующую многоуровневую архитектуру памяти. Сейчас все абстрактные машины расматривают память как прозрачную стуктуру, хотя реально роль традиционного ОЗУ выполняет кеш, а память — по сути своп.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, remark, Вы писали:
R>>Ну это зависит. Допустим сделать "медленный" сервер у меня займёт 2 месяца, а сделать "быстрый" сервер у меня займёт 3 месяца.
GN>Конечно зависит. Например есть старый софт, который уже не удовлетворяет запросы заказчика. Мне кажется, такая ситуация более распространена, и не всегда есть возможность переделать всё.
Полностью согласен.
R>>Падение масштабируемости не в локах!!! Падение масштабируемости в разделении данных!
GN>Которые разделяются выставлением сигнала #LOCK на шину
Нет. Никакого #LOCK. Просто обычные сохранения и загрузки.
R>>Всё уже украдено до нас. В некоторых Unix'ах (Solaris/Irix) есть замечательный системный вызов schedctl(2).
GN>Такая уж она замечательная? Конечно избавились от оверхеда на постоянные вызовы, но — как раз то о чем ты полфорума исписал — запись и чтение в разделяемую память.
Это не разделяемая память, это локальная для потока переменная.
GN>Вот в С++ есть 2 подхода к исключениям: MSVC (32бит) создает SEH фреймы в рантайме, а GCC строит таблицы, в которые при необходимости заглянет хендлер (см. TR18015).
GN>Сейчас и MSVC 64 строит таблицы для поддержки исключений, плюс таблицы для раскрутки стека — так что ничего сверхсложного в этом способе нет. Конечно, для гибкости надо оставить и schedctl(2)
Компилятор не сможет это правильно отследить в случаях более сложных, чем использование только критических секций, и при этом таких, о которых осведомлен компилятор.
И от необходимости синхронизации это всё равно не спасает. Т.к. это будет не более, чем хинт. No silver bullet!
R>>Ну ничего, вот когда интегрированные сетевые карты начнут закачивать трафик прямо в кэш конкретного ядра, ситуация изменится к лучшему
GN>Кстати, фрагмент NDIS_MINIPORT_BLOCK GN>
GN> //
GN> // This is the processor number that the miniport's
GN> // interrupt DPC and timers are running on.
GN> //
GN> UCHAR AssignedProcessor;
GN>
GN>Если я правильно понял, сейчас все запросы с одного интерфейса обрабатываются одним и тем же ядром. И так должно быть везде, ведь NDIS кросплатформ.
Для начала это уже не плохо. Но где работают более верхние уровни (например, TCP/IP)? И как этом можно воспользоваться пользователю?
Конечная цель — как писать программу в юзер-спейс, что бы по возможности *вся* работа с данными шла на одном процессоре. Как при отправке, так и при приёме.
GN>ИМХО действительно может измениться к лучшему, если языки и компиляторы будут как-то поддерживать существующую многоуровневую архитектуру памяти. Сейчас все абстрактные машины расматривают память как прозрачную стуктуру, хотя реально роль традиционного ОЗУ выполняет кеш, а память — по сути своп.
Там внизу есть ссылки на научные работы, часть из них как раз рассматривает возможности автоматического "улучшения" программ для таких языков как Java/C#.
Здравствуйте, remark, Вы писали:
R>Для начала это уже не плохо. Но где работают более верхние уровни (например, TCP/IP)? И как этом можно воспользоваться пользователю? R>Конечная цель — как писать программу в юзер-спейс, что бы по возможности *вся* работа с данными шла на одном процессоре. Как при отправке, так и при приёме.
Кстати, твоё желание исполнено в Линуксе: http://lwn.net/Articles/169961/ Вся работа, по возможности, выполняется на самом близком CPU.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, remark, Вы писали:
R>>Для начала это уже не плохо. Но где работают более верхние уровни (например, TCP/IP)? И как этом можно воспользоваться пользователю? R>>Конечная цель — как писать программу в юзер-спейс, что бы по возможности *вся* работа с данными шла на одном процессоре. Как при отправке, так и при приёме.
C>Кстати, твоё желание исполнено в Линуксе: http://lwn.net/Articles/169961/ Вся работа, по возможности, выполняется на самом близком CPU.
Они сделали почти всё. Но одна передача данных с процессора на процессор остаётся, т.к. номер процессора, на котором было обработано аппаратное прерывание, и номер процессора, на котором приложение обработало данные, никак не связаны.
Т.е. я хочу сказать, что для того, что бы всё было "идеально" либо приложение должно следовать какому-то "паттерну использования" сокетов, либо должно быть какое-то явное АПИ — например что-то типа SetSocketAffinityMask(), либо что бы вместе с пачкой евентов от механизма демультиплексирования (select, epoll, GetQueuedCompletionStatusEx) для каждого евента было указано, на каком процессоре по возможности желательно обрабатывать это евент.
Кстати похоже, что это Van Jacobson читал мой пост "Многопоточность сегодня"
И кстати показательный пример — при запуске на 2 процессорах система не ускорилась, а замедлилась в 1.5. раза. После "грамотной" переработки с учётом многопроцессорности производительность поднялась в 5 раз. И главное скорее всего поднялась и масштабируемость, жаль он не замерил для 4 и 8 ядер. Было бо интересно поглядеть на динамику цифр.
Насколько я помню, McKenney репортил цифру — *500-кратное* ускорение на 32-процессорной машине после доработки какой-то системы ядра с помощью RCU.
Здравствуйте, remark, Вы писали:
C>>Кстати, твоё желание исполнено в Линуксе: http://lwn.net/Articles/169961/ Вся работа, по возможности, выполняется на самом близком CPU. R>Они сделали почти всё. Но одна передача данных с процессора на процессор остаётся, т.к. номер процессора, на котором было обработано аппаратное прерывание, и номер процессора, на котором приложение обработало данные, никак не связаны.
А это уже совсем никак — аппаратное прерывание может приходить только на один процессор. Кроме того, за одно прерывание может быть получено несколько пакетов (для разных процессоров).
В теории, для аппаратного ускорителя TCP можно было бы и этот шаг перенести в железо сетевушки. На практике, пока для потоков в 10Гб и этого решения хватает.
R>Т.е. я хочу сказать, что для того, что бы всё было "идеально" либо приложение должно следовать какому-то "паттерну использования" сокетов, либо должно быть какое-то явное АПИ — например что-то типа SetSocketAffinityMask(), либо что бы вместе с пачкой евентов от механизма демультиплексирования (select, epoll, GetQueuedCompletionStatusEx) для каждого евента было указано, на каком процессоре по возможности желательно обрабатывать это евент.
А оно так и есть. Когда ты создаёшь сокет — оно по умолчанию привяжется к создавшему потоку (и процессору, соответственно). Потом при необходимости оно в нужный поток переместится.
R>Кстати похоже, что это Van Jacobson читал мой пост "Многопоточность сегодня"
Van Jacobson — это вообще известный хакер. Один только "Van Jacobson hack" с предсказанием заголовков в TCP чего стоит.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, remark, Вы писали:
C>>>Кстати, твоё желание исполнено в Линуксе: http://lwn.net/Articles/169961/ Вся работа, по возможности, выполняется на самом близком CPU. R>>Они сделали почти всё. Но одна передача данных с процессора на процессор остаётся, т.к. номер процессора, на котором было обработано аппаратное прерывание, и номер процессора, на котором приложение обработало данные, никак не связаны.
C>А это уже совсем никак — аппаратное прерывание может приходить только на один процессор. Кроме того, за одно прерывание может быть получено несколько пакетов (для разных процессоров).
Ну так смотри ниже.
Управлять процессором, обработавшим прерывание, не обязательно. Но пусть хоть мне (прикладному программисту) скажут, на каком процессоре этот пакет был обработан.
R>>Т.е. я хочу сказать, что для того, что бы всё было "идеально" либо приложение должно следовать какому-то "паттерну использования" сокетов, либо должно быть какое-то явное АПИ — например что-то типа SetSocketAffinityMask(), либо что бы вместе с пачкой евентов от механизма демультиплексирования (select, epoll, GetQueuedCompletionStatusEx) для каждого евента было указано, на каком процессоре по возможности желательно обрабатывать это евент.
C>А оно так и есть. Когда ты создаёшь сокет — оно по умолчанию привяжется к создавшему потоку (и процессору, соответственно). Потом при необходимости оно в нужный поток переместится.
Мммм. Не понял. Если все прерывания от сетевой карты приходят на один процессор, то что означает привязка сокетов?
R>>Кстати похоже, что это Van Jacobson читал мой пост "Многопоточность сегодня" C>Van Jacobson — это вообще известный хакер. Один только "Van Jacobson hack" с предсказанием заголовков в TCP чего стоит.
Здравствуйте, remark, Вы писали:
C>>А это уже совсем никак — аппаратное прерывание может приходить только на один процессор. Кроме того, за одно прерывание может быть получено несколько пакетов (для разных процессоров). R>Ну так смотри ниже. R>Управлять процессором, обработавшим прерывание, не обязательно. Но пусть хоть мне (прикладному программисту) скажут, на каком процессоре этот пакет был обработан.
Так это есть В этом и весь смысл van jacobson channels.
C>>А оно так и есть. Когда ты создаёшь сокет — оно по умолчанию привяжется к создавшему потоку (и процессору, соответственно). Потом при необходимости оно в нужный поток переместится. R>Мммм. Не понял. Если все прерывания от сетевой карты приходят на один процессор, то что означает привязка сокетов?
В контексте прерывания берутся полученые пакеты, и указатели на них передаются в каналы (даже копирования содержимого не происходит). Так что непараллелизуемым остаётся только это небольшой кусок диспетчеризации полученых пакетов по каналам.
А затем уже сетевой стек на каждом канале уже на своём процессоре разбирается что с ними там дальше делать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, remark, Вы писали:
C>>>А это уже совсем никак — аппаратное прерывание может приходить только на один процессор. Кроме того, за одно прерывание может быть получено несколько пакетов (для разных процессоров). R>>Ну так смотри ниже. R>>Управлять процессором, обработавшим прерывание, не обязательно. Но пусть хоть мне (прикладному программисту) скажут, на каком процессоре этот пакет был обработан.
C>Так это есть В этом и весь смысл van jacobson channels.
Как это может быть возможно? Ведь никто никак не может управлять на каких потоках пользователь вызывает recv(). Т.е. прерывание выполняется на фиксированном процессоре, а recv() вызывается на произвольном процессоре. Я не вижу, каким образом они будут всегда совпадать.
После беглого прочтения я понял, что убрали все промежуточные звенья. Осталось только аппаратное прерывание и пользовательский вызов. И по поводу них никаких гарантий нет. И как раз для компенсации этого ввели cache-friendly circular buffer для передачи данных.
C>>>А оно так и есть. Когда ты создаёшь сокет — оно по умолчанию привяжется к создавшему потоку (и процессору, соответственно). Потом при необходимости оно в нужный поток переместится. R>>Мммм. Не понял. Если все прерывания от сетевой карты приходят на один процессор, то что означает привязка сокетов?
C>В контексте прерывания берутся полученые пакеты, и указатели на них передаются в каналы (даже копирования содержимого не происходит). Так что непараллелизуемым остаётся только это небольшой кусок диспетчеризации полученых пакетов по каналам...
... который выполняется на процессоре никак не связанном с процессором, на котором выполняется основной код канала
?
C>А затем уже сетевой стек на каждом канале уже на своём процессоре разбирается что с ними там дальше делать.
Безусловно это намного лучше, чем было. Я просто пытаюсь понять, это предел или можно сделать ещё что-то.
[]
GN>>Я хотел примерно о том же, но абстрагировался через чур. Чему учат в школе? ИМХО проблема даже не в слабой изученности lock-free алгоритмов.
R>lock-free алгоритмы — это не о производительности и масштабируемости, это исключительно о гарантиях системного прогресса. lock-free алгоритмы зачастую бывают медленнее lock-based алгоритмов. Это как best-effort против QoS, или не real-time против real-time. QoS и real-time всегда медленнее, зато дают дополнительные гарантии.
боюсь просить, почему медленнее и о каких гарантиях идет речь
Здравствуйте, remark, Вы писали:
C>>Так это есть В этом и весь смысл van jacobson channels. R>Как это может быть возможно? Ведь никто никак не может управлять на каких потоках пользователь вызывает recv(). Т.е. прерывание выполняется на фиксированном процессоре, а recv() вызывается на произвольном процессоре. Я не вижу, каким образом они будут всегда совпадать.
А они и не будут.
R>После беглого прочтения я понял, что убрали все промежуточные звенья. Осталось только аппаратное прерывание и пользовательский вызов. И по поводу них никаких гарантий нет. И как раз для компенсации этого ввели cache-friendly circular buffer для передачи данных.
Да, просто раньше оно почти всё выполнялось на одном процессоре (в контексте прерывания). Из-за этого, на 10Гб всё торррмозилло.
C>>В контексте прерывания берутся полученые пакеты, и указатели на них передаются в каналы (даже копирования содержимого не происходит). Так что непараллелизуемым остаётся только это небольшой кусок диспетчеризации полученых пакетов по каналам... R>... который выполняется на процессоре никак не связанном с процессором, на котором выполняется основной код канала R>?
Да.
C>>А затем уже сетевой стек на каждом канале уже на своём процессоре разбирается что с ними там дальше делать. R>Безусловно это намного лучше, чем было. Я просто пытаюсь понять, это предел или можно сделать ещё что-то.
Больше уже вряд ли. Нужно тогда делать поддержку в аппаратуре.
Здравствуйте, Константин Л., Вы писали:
GN>>>Я хотел примерно о том же, но абстрагировался через чур. Чему учат в школе? ИМХО проблема даже не в слабой изученности lock-free алгоритмов.
R>>lock-free алгоритмы — это не о производительности и масштабируемости, это исключительно о гарантиях системного прогресса. lock-free алгоритмы зачастую бывают медленнее lock-based алгоритмов. Это как best-effort против QoS, или не real-time против real-time. QoS и real-time всегда медленнее, зато дают дополнительные гарантии.
КЛ>боюсь просить, почему медленнее и о каких гарантиях идет речь
ну вот как раз там-то все не очень очевидно, что касается скорости. если мы постоянно проваливаемся в ядро на lock-based, то, очевидно, lock-free при куче своих atomic* будет все-таки быстрее.
R>
Здравствуйте, remark, Вы писали:
GN>>А в том, что, например, с точки зрения теории сложности вычислений, увеличение количества ядер ничего не даёт! Нужна какая-то исправленная теория, которая будет учитывать количество ядер...
R>Ну почему не даёт! HPC товарищи любят рассматривать решение задачи размера N на системе с N процессорами R>Вот сейчас только книжку дочитал — там все задачи рассматриваются либо на системах с N процессорами, либо на N^(1/2), либо на крайний случай с log(N)
А я думал, что это только российская академическая наука такое рожает. Читал лет пять назад какой-то из вестников СО РАН, так там на полном серьезе тётенька писала, что, дескать, получен новый алгоритм умножения матриц размера N*N не за O(N^3), а за O(N^2). Вчитавшись, я обнаружил, что речь идет о векторном процессоре, который нативно поддерживает операцию перемножения двух векторов. Ну, то есть задача решена для N <= V, где V — фиксированная длина вектора, который жрет этот процессор. Прочитав, смеялся до слез. Потому как если фиксировать верхнюю границу N, то можно любой алгоритм свести к O(1).
R>Да... есть такое дело... я потом ещё спрашивал на форумах MSDN... похоже они даже не думали о таких вопросах. R>Ну ничего, вот когда интегрированные сетевые карты начнут закачивать трафик прямо в кэш конкретного ядра, ситуация изменится к лучшему
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
КЛ>ну вот как раз там-то все не очень очевидно, что касается скорости. если мы постоянно проваливаемся в ядро на lock-based, то, очевидно, lock-free при куче своих atomic* будет все-таки быстрее.
Architecting Parallel Software интересная презентация на 264 слайда, расказывающая о различных архитектурных подходах при разработке программ с высоким уровнем параллелизма (PDF, ~5.9Mb).
Ok, so...why is this interesting? Consider: the present state of parallel programming looks a lot like that of object-oriented programming in the early 1990s -- a small number of practioners understand and use it, but the overall profession looks on with anxiety. The Design Patterns approach helped to shove OO into the mainstream; could it do so again for parallel programming?
To test this premise, a project has been launched to build up an integrated, coherent set of patterns useful for exposing high-level constructs to concurrency -- a pattern language, as opposed to a collection of patterns. Kurt and Tim have proposed a layer of structural and computational patterns, integrating to one or more an underlying layers of concurrency patterns. We presented a detailed snapshot of this view at the recent ICCAD; slides from that tutorial are here: Architecting Parallel Software.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Architecting Parallel Software интересная презентация на 264 слайда, расказывающая о различных архитектурных подходах при разработке программ с высоким уровнем параллелизма (PDF, ~5.9Mb).
Представляю вам свой ответ на многопоточность. Ознакомится можно здесь http://groups.google.com/group/asynclib?hl=en
В кратце библиотека представляет из себя микс между TBB (где работа task'ифицируется через интеловские примитивы и выполняется на фиксированном количетсве рабочих потоков) и windows threads (где каждый поток имеет свой контектс, который OS в любой момент может сменить на контекст другого потока). В терминологии создателя данной темы получается «многопоточность с кооперативной многозадачностью».
Другими словами, вы вашу работу разбиваете на задачи (чтение из файла/сокета, обработка чего-либо другого — без ограничений здесь), чем меньше гранулярность, тем лучше (поскоку распаллелизовываться будет лучше). Тело задачи не имеет ограничений, кроме одного условия — необходимо использовать примитивы синхронизации предоставленные библиотекой (использование стандартных примитивов не воспрещается). Далее, когда рабочий поток выполняя одну из ваших задач натыкается на блокирующее условие (например — мутекс залочен другой задачей, или ввод/вывод еще не закончился) рабочий поток автоматически переключается на следующую задачу из вашего списка задач, обеспечивая тем самым максимальный throughput ваших задач на заданном количестве рабочих потоков.
Из плюсов данного подхода можно отметить следующие:
— автоматическое скалирование на многоядерных машинах
— уменьшение времени синхронизации задач (так как происходит смена более легковесного контекста задачи, в отличие от контекста потока) и уменьшение contention'а ваших данных (поскоку в любой момент выполняется количество задач не большее чем количество рабочих потоков)
— в целом классе задач отпадает необходимость писать стейтмашины (в данном случае стейт сохраняется вместе с контекстом вашей задачи)
— более легковесные примитивы синхронизации чем нативные (самый маленький примитив занимает 2 бита)
Eсли есть вопросы, пишите.
Здравствуйте, remark, Вы писали:
R>Уже достаточно давно программисты экстенсивно применяют многопоточность при реализации систем. При этом многопоточность применялась в основном для таких вещей как упрощение модели программирования, маскирование латентности блокирующих операций и т.д. И так же это всё происходило в подавляющем большинстве в контексте одного ядра/процессора. Соотв. распространены следующие принципы и подходы: R> — Можно завести любое кол-во потоков. Иимеется в виду любое в пределах сотни. Т.е. кол-во потоков определяется исключительно потребностью архитектуры, но не аппаратной платформой. R> — Можно произвольным образом распределить работу по потокам. Т.к. всё равно всё выполняется на одном ядре, то это не имеет значения. R> — Можно и нужно экстенсивно применять мьютексы для синхронизации. Т.к. всё выполняется на одном ядре, то это практически не влияет на производительность и масштабируемость. R> — Можно произвольным образом разделять данные между потоками. Т.к. процессор один, то это никак не влияет на производительность и масштабируемость. Фактически система работает так, как будто поток один, просто он выполяет то одну функцию, то другую.
R>Всё это я называю «многопоточность на одном ядре». Фактически система, построенная по таким принципам, образно является «однопоточной с кооперативной многозадачностью».
R>И всё это становится кардинально не верным с появлением массовых многоядерных процессоров. Во второй половине следующего года Intel намерена выпустить процессор с 16 аппаратными потоками: здесь
R>И через 5 лет они собираются выпустить процессор с 80 ядрами! (Представть свои программы на 80 ядрах! Есть идеи как их использовать?)
R>Что бы эффективно использовать новые аппаратные платформы, нужны совершенно новые принипы и подходы. Нужна «многопоточность на множестве ядер». Под эффективностью я подразумеваю, что бы программа на 8 ядрах выполнялась хотя бы не медленнее, чем на одном. Шутка шуткой, а на форумах посвящённым многопоточности сейчас один из самых распространённых вопросов «Почему моя программа, которая делает Х, на 4-ёх ядерной машине работает медленнее, чем на 1-ядерной?»
R>Потому что старые принципы многопоточности патологически не работают в новом контексте! Я уверен, что значительная часть многопоточных систем «старой школы» будут быстрее работать на многоядерном процессоре, если банально привязать все потоки программы к одному ядру! Т.к. синхронизация всё равно убивает потенциальный параллелизм, а разделение данных вносит коллосальные пенальти. R>Некоторое время назад я был свидетелем следующей ситуации. Серверное ПО запустили на двух-процессорной машине (в надежде, что оно будет работать в 2 раза быстрее. ха-ха). Оно стало работать в 10 (!) раз медленнее (как потом оказалось причиной было постоянное разделение модифицируемых данных между двумя потоками).
R>Сейчас наиболее общий рецепт выглядит примерно следующим образом: R> — Создать кол-во потоков по кол-ву аппаратных потоков. Как следствие — кол-во потоков не должно быть «зашито» в программу, т.к. она может выполняться на разных платформах. И как второе следствие – управление кол-вом потоков не должно быть заботой прикладного программиста (ну по крайней мере того же программиста, но когда он играет роль прикладного ). R> — Работа должна быть распределена по потокам [примерно] равномерно. Соотв. это тоже не получится зашивать в программу и поручать прикладному программисту, т.к. кол-во потоков и кол-во и содержание работы меняться. R> — Нельзя экстенсивно применять мьютесы/синхронизацию/блокировки. Т.к. это фактически заставит систему сериализоваться и выполняться «на одном ядре». Ни о какой масштабируемости тут не может быть и речи. R> — По возможности надо элиминировать разделяемые данные. Совместная работа над одними модифицируемыми данными сейчас работает ооочень медленно и становится одним из важнейших новых боттлнеков аппаратной платформы, на ряду с тактами ядра, шиной к памяти, диском, сетью. И никаких изменений в лучшую сторону тут не предвидится. Только в худшую. (Это не относится к константным данным, их можно и нужно разделять между потоками)
R>Если выразить это более кратко: *каждое* ядро должно быть обеспечено *своей* работой и *своими* данными, и работать над ними *независимо*. R>К сожалению пока никто не придумал как приготовить этот рецепт в общем виде... Т.е. что бы программист был занят только прикладными задачами, а всё остальное происходило как-то само собой.
R>Естественно могут иметь место и частные случаи. Например, приложение по обработке изображений или CAD/CAM/CAE/CASE. Тут скорее всего имеет смысл эффективно распараллеливать только одну основную функцию, например, обработку изображения, или рассчёт параметров модели (все остальные функции — графический интерфейс, фоновые задачи — по прежнему могут быть реализованы по старым принципам). Тут сейчас ситуация обстоит немного лучше. Тут (и только тут) на помощь могут придти такие средства как OpenMP, RapidMind, Intel TBB, Java Fork/Join и тд.: R>www.openmp.org R>www.rapidmind.com R>osstbb.intel.com R>gee.cs.oswego.edu/dl/papers/fj.pdf R>К сожалению все эти средства подходят для очень ограниченного круга задач, и не подходят для реализации более общих и не типовых задач. И всё равно они не снимают с программиста основной задачи — что конкретно и как конкретно должно быть распараллелено. Это по прежнему должен решать программист, и он по прежнему должен обеспечить достаточное кол-во потенциального параллелизма, возможность для независимой работы потоков без разделяемых данных и т.д.
R>Есть ещё 2 вещи стоящие упоминания в данном контексте: готовые высокооптимизированные библиотеки и автоматическое распараллеливание кода.
R>Для решения типовых задач имеется ряд высокооптимизированных библиотек. Например можно посмотреть на: R>Intel Integrated Performance Primitives (IPP): R>http://www.intel.com/cd/software/products/asmo-na/eng/219767.htm R>И AMD Performance Library (APL): R>http://developer.amd.com/apl.jsp R>Задачи, которые они могут решать включают: R> — обработка/кодирование/декодирование видео R> — обработка/кодирование/декодирование изображений R> — обработка/кодирование/декодирование аудио R>- операции над матрицами/векторами/строками R>и т.д. R>Понятно, что на общее решение такие библиотеки не тянут. Однако, если решаемая задача укладывается в возможности библиотеки, то имеет большой смысл применять такую библиотеку (Intel — платная, AMD — бесплатная).
R>Автоматическое распараллеливание кода. R>Здесь не на что смотреть! Проходите, не задерживаетесь! R>Сейчас автоматические распараллеливатели могут очень мало и очень конкретного. И вам всё равно придётся убеждаться, что распараллелилось то, что надо, так, как надо, и оно не ломается при последующих модификациях кода (напоминает борьбу с оптимизатором БД ). Фактически правильнее считать, что автоматического распараллеливания кода *нет*. Сейчас и в ближайшую декаду. Если кто-то утверждает обратное, то он либо не разбирается в вопросе, либо хочет вам что-то продать R>За подробностями смотрите интервью с Джеем Хоефлингером, который занимается автоматическим распараллеливанием с середины 80: R>http://www.thinkingparallel.com/2007/08/14/an-interview-with-dr-jay-hoeflinger-about-automatic-parallelization/
R>Подытожу. Мы сейчас находимся на перегибе развития. Что бы поспеть за развитием, а не попасть в кювет, надо многое переосмыслить и смотреть на вещи по новому. Новые принципы и подходы только формируются, ни у кого пока нет *универсальных* решений. Всё, что сейчас выдают за таковые, за универсальные решения для многоядерности (OpenMP, RapidMind, Intel TBB) — маркетинг. Ну, возможно, это лишь строительные блоки, но ни как не решение. Сейчас всё зависит исключительно от компетентности конкретного программиста, разрабатывающего конкретную систему.
Но для ряда задач это вполне приемлимое решение. И, главное, железо стоит дешевле, чем что-то переделывать.
или вызывают сервис ОС (суть планировщик). А между тем, для компилятора элементарная операция — создать в исполняемом модуле таблицы (подобные как для С++ исключений) с адресами участков защищенного кода, а планировщик посмотрит туда и решит, нужно ли переключать контекст. Но это фантаситка 
