Здравствуйте, Mr.Cat, Вы писали:
MC>Коллеги, подкиньте годных обзорных статей или книг по software transactional memory, наподобие вот этой: MC>James R. Larus and Ravi Rajwar. Transactional Memory. 2006. MC>То бишь хочется поглядеть на направления развития и мысли в stm.
Здравствуйте, Mr.Cat, Вы писали:
MC>Коллеги, подкиньте годных обзорных статей или книг по software transactional memory, наподобие вот этой: MC>James R. Larus and Ravi Rajwar. Transactional Memory. 2006. MC>То бишь хочется поглядеть на направления развития и мысли в stm.
Может тут найдёшь чего интересного, тут тусуются представители всей промышленности (Sun, Microsoft, Intel) и университетов, которые этим занимаются: http://groups.google.com/group/tm-languages
А из общих статей (не про реализацию) за последнее время больше всего понравилось это:
QuakeTM: Parallelizing a Complex Sequential Application Using Transactional Memory http://www.multicoreinfo.com/research/papers/2009/ics09-gajinov-quaketm.pdf
Если не украшая, то вывод такой: что бы использовать STM надо докуя времени лучших экспертов, и даже тогда получится полностью тормозная и немаштабируемая система.
Здравствуйте, Mr.Cat, Вы писали:
MC>Коллеги, подкиньте годных обзорных статей или книг по software transactional memory, наподобие вот этой: MC>James R. Larus and Ravi Rajwar. Transactional Memory. 2006. MC>То бишь хочется поглядеть на направления развития и мысли в stm.
В целом направление мысли для STM сейчас слудующее.
Снижение однопоточного оверхеда — все.
Достижение хорошей масштабируемости для хороших программ — SkySTM.
Интеграция в существующие языки — Intel C++ STM Compiler, Microsoft STM .NET, по-моему на днях Sun интергрировал в C++ Studio, ну и для Java есть работы.
Стандартизация — Intel STM ABI, Intel C++ Transactional Constructs.
Интеграция STM и HTM — в Sun много работ типа HyTM (Hybrid TM), PhTN (Phased TM).
Чисто HTM решения — AMD ASF, Sun Rock (это я имею в виду те, которые можно ожидать в ближайшие пару лет).
Если не найдёшь по ключевым словам, могу дать конкретные ссылки на это всё — сейчас просто лень все ссылки выискивать.
Здравствуйте, remark, Вы писали: R>А из общих статей (не про реализацию) за последнее время больше всего понравилось это: R>QuakeTM: Parallelizing a Complex Sequential Application Using Transactional Memory R>http://www.multicoreinfo.com/research/papers/2009/ics09-gajinov-quaketm.pdf R>Если не украшая, то вывод такой: что бы использовать STM надо докуя времени лучших экспертов, и даже тогда получится полностью тормозная и немаштабируемая система.
Да, интересная статья. Получается, взяв готовую непараллельную программу, можно за 10 человеко-месяцев можно переписать ее с использованием stm и получить сильные тормоза даже на мощной машине, либо за 15 человеко-месяцев (с участием разработчиков примерно той же квалификации?) "распараллелить" ее и получить (пусть небольшой, но) профит. То бишь на профит от stm можно надеяться, лишь разрабатывая приложение с нуля и проектируя его архитектуру прицельно под (конкретную имплементацию?) stm?
С другой стороны, если обратить внимание на распараллеленный на основе pthreads сервер — восемь потоков уменьшают веря обработки фрейма где-то на треть. Я так понял — большая часть времени уходит на работу с areanode-деревом: обработку движения и коллизий объектов, а поскольку игроки все-таки имеют тенденцию не разбегаться по карте, а искать друг друга и кучковаться (особенно когда их 16 на сравнительно небольших квейковских картах — хотя вот непонятно, по какому алгоритму действовали боты и были ли задействованы живые игроки вообще) — то действия игроков в рамках фрейма затрагивают одни и те же узлы дерева — и параллелить это дело сложно, какими средствами не пользуйся.
PS: Вспомнил школьные годы, пентиумы в компьютерном классе — и улыбнулся:
Both machines [клиент и сервер] are
PowerEdge 6850, with four dual-core 64-bit Intel® Xeon™
processors running at 3.2 GHz, with 16MB L3 cache memory per
processor unit, running SUSE LINUX 10.1.
Здравствуйте, Mr.Cat, Вы писали:
MC>Да, интересная статья. Получается, взяв готовую непараллельную программу, можно за 10 человеко-месяцев можно переписать ее с использованием stm и получить сильные тормоза даже на мощной машине, либо за 15 человеко-месяцев (с участием разработчиков примерно той же квалификации?) "распараллелить" ее и получить (пусть небольшой, но) профит. То бишь на профит от stm можно надеяться, лишь разрабатывая приложение с нуля и проектируя его архитектуру прицельно под (конкретную имплементацию?) stm?
Типа того
Надо ещё учитывать, кто эти люди. Это не совсем 10 человеко-месяцев среднестатистического разработчика, на которого рассчитаны STM.
Плюс попутно им пришлось разработать технику ReachPoints для анализа плохой производительности и оптимизации.
MC>С другой стороны, если обратить внимание на распараллеленный на основе pthreads сервер — восемь потоков уменьшают веря обработки фрейма где-то на треть. Я так понял — большая часть времени уходит на работу с areanode-деревом: обработку движения и коллизий объектов, а поскольку игроки все-таки имеют тенденцию не разбегаться по карте, а искать друг друга и кучковаться (особенно когда их 16 на сравнительно небольших квейковских картах — хотя вот непонятно, по какому алгоритму действовали боты и были ли задействованы живые игроки вообще) — то действия игроков в рамках фрейма затрагивают одни и те же узлы дерева — и параллелить это дело сложно, какими средствами не пользуйся.
Ну так с высоты птичьего полёта сложно сказать, можно его распараллелить или нет. Совсем идеально может и нельзя, но я думаю, что по-крайней мере значительно лучше, чем получилось у них с STM, — можно. Тем более, что в реальной игре с парой десятков игроков всё же не все прямо совсем рядом-рядом находятся.
Вообще они показали простой вариант, который не пытается достить производительности — изначальный однопоточный сервер. Полезно было бы так же поглядеть противоположный вариант — вариант, который ставит производительность превыше всего, а сложность кода уж такая какая получится. Тогда можно будет более объективно оценивать промежуточные варианты — например, такое-то увеличение сложности и одновременное такое-то повышение производительности это вообще насколько разумное соотношение? Пока не понятно.
Здравствуйте, remark, Вы писали: R>Плюс попутно им пришлось разработать технику ReachPoints для анализа плохой производительности и оптимизации.
Тут я, кстати, немного растерялся. Cперва они жалуются на высокий abort rate, рассказывают про false sharing, предлагают технику по выявлению мест, где транзакции откатываются — а потом заявляют, что оверхед от abort rate на самом деле сравнительно невелик. Или это все надо читать, как "нам тут пришлось повозиться, но мы-таки почти свели на нет оверхед от откатов"?
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали: R>>Плюс попутно им пришлось разработать технику ReachPoints для анализа плохой производительности и оптимизации. MC>Тут я, кстати, немного растерялся. Cперва они жалуются на высокий abort rate, рассказывают про false sharing, предлагают технику по выявлению мест, где транзакции откатываются — а потом заявляют, что оверхед от abort rate на самом деле сравнительно невелик. Или это все надо читать, как "нам тут пришлось повозиться, но мы-таки почти свели на нет оверхед от откатов"?
Я так это понял, что Да, указанной производительности, масштбаируемости и частоты абортов им удалось добиться после того, как они всё это пооптимизировали. Т.е. приведены только конечные результаты.
Но там всего 2 странички — меня ведь совесть замучает 
