Берегись Ил-Штурмовик!.....

[MUTbKA]

и так до тех пор, пока не получим ОДИН очень сложный процесс, для которого уже маловато вычислительных ресурсов. Вот тогда начинаем задумываться о том, как разбить этот процесс для обработки на нескольких процессорах, и выясняем, что те "подпроцессы", которые у нас получились очень тесно связаны между собой и требуют обмена огромным количеством информации между собой.

Не все так просто. Элементарный пример - предположим, захотели мы смоделировать такие "элементарый процессы" - скажем, поведение молекул в цилиндре с поршнем, исходя из представлений классической термодинамики. Для этого мы моделируем цилиндр и X молекул в нем, которые там "прыгают" и "отражаются" от стенок и друг от друга как идеальные мячики. И есть у нас 100 слабосвязанных процессоров. Дальше можно пойти двумя путями:

1. Пусть каждый проц обсчитывает "свой" 1% от общего числа молекул. Но тогда у нас возникает большая проблема - как обсчитывать столкновения? Заранее неизвестно, какие молекулы находятся хотя бы рядом. При большом X это и один процессор нагрузит, но когда процессоров много - они будут вынуждены передавать друг другу координаты ВСЕХ молекул, и КАЖДЫЙ процессор вынужден их помнить. Нагрузка на каналы связи очень высока.

2. Каждый проц обсчитывает свою область пространства внутри цилиндра. Если молекула улетает в "чужую" область, то этот проц "отдает" ее нужному, а сам про нее забывает. Но все равно - проблема столкновений на границе имеется, каналы связи нагружены передачей иноформации про уходящие молекулы, а главное - процессоры загружены неравномерно, каким-то может достаться на расчет заметно больше молекул, чем другим.

А самое любопытное, что заранее совершенное неясно, какой алгоритм эффективнее - все зависит от соотношения скорость процов/скорость каналов связи. Если оно высоко - выгоднее второй вариант (причем если это соотношение ОЧЕНЬ высоко, то выгоднее вообще собрать все на одном процессоре, а остальные даже и не включать), если низко - выгоднее первый.

При этом напомню, что нынешний уровень развития вычислительных средств как раз упирается в то, что процессоры у нас чрезвычайно производительны, а вот каналы связи - не очень... Хотел бы еще напомнить, что любой канал связи, передающий информацию "от многих к многим" - сам по себе очень сложен, со схемами арбитража, приоритизации и маршрутизации. И чем выше скорость - тем больше вычислительных ресурсов требуется, чтобы это разрулить. Современный гигабитный маршрутизатор внутри имеет ОЧЕНЬ неслабый процессор, и он совсем не простаивает.

На примере ИЛ2:
На карте 10 самолётов, 100 единиц наземки, 300 облаков, миллион листочков на деревьях( ), 10 миллионов волн на воде( ), 1000 единиц снарядов (которые выпустили те самолёты и наземка)...
И ВСЁ ЭТО мы пытаемся "пропихнуть" через один несчастный проц, причём не только то, что мы сейчас "видим", но и то, что происходит на другом конце карты (а вдруг через секунду нам захочется посмотреть что происходит там?)....

Во-первых, процов больше, чем один. Процессор современной видеокарты по мощи не уступает центральному. Во-вторых, расчет физики по сравнению с расчетом графики все равно нынче очень быстр, даже в Ил-2. У симуляторов есть особенность - они обязаны как-то рисовать то, что они считают. И чем детальнее считают - тем детальнее обязаны это рисовать, иначе это - просто глупая трата ресурсов. Например, зачем детально рассчитывать повреждения от снаряда, форму и размер дырок, и где именно сломался лонжерон, если все это визуально никак не отображается? Гораздо проще и эффективней ввести статистическую модель - эффект тот же, а геморроя намного меньше.

А если речь идет о рисовании, то опять же проблема тесно связанных вычислений - ты никогда заранее не можешь сказать, не заслонит ли вот этот листочек вон тут самолет, или нет. Требуются расчеты, пусть даже поначалу прикидочные, а это опять - сравнение всех со всеми, и перегрузка каналов связи, либо простой каких-то процессоров (самолеты в ИЛ-2 - не молекулы, и часто любят собираться все вместе в очень ограниченной области пространства, а где самолеты - там и пальба, и все такое ).

Есть алгоритмы рисования сцен, которые распараллеливаются отлично, и дают потрясающе реалистичную картинку (загляните за примерами на www.povray.org, особенно на картинки-победители месяца) - это трассировка лучей (raytracing). Но такие алгоритмы сами по себе чрезвычайно прожорливы, и даже с сотней современных процессоров не дадут картинку качества современных игр с приемлемым FPSом. Планка производительности и количества процессоров (и, разумеется, качества картинки), когда raytracing станет выгоднее нынешних алгоритмов 3D-визуализации - еще ОЧЕНЬ ДАЛЕКО.

[POP]

Не все так просто. Элементарный пример - предположим, захотели мы смоделировать такие "элементарый процессы" - скажем, поведение молекул в цилиндре с поршнем, исходя из представлений классической термодинамики. Для этого мы моделируем цилиндр и X молекул в нем, которые там "прыгают" и "отражаются" от стенок и друг от друга как идеальные мячики. И есть у нас 100 слабосвязанных процессоров. Дальше можно пойти двумя путями:

......
2. Каждый проц обсчитывает свою область пространства внутри цилиндра. Если молекула улетает в "чужую" область, то этот проц "отдает" ее нужному, а сам про нее забывает. Но все равно - проблема столкновений на границе имеется, каналы связи нагружены передачей иноформации про уходящие молекулы, а главное - процессоры загружены неравномерно, каким-то может достаться на расчет заметно больше молекул, чем другим.

... Хотел бы еще напомнить, что любой канал связи, передающий информацию "от многих к многим" - сам по себе очень сложен, со схемами арбитража, приоритизации и маршрутизации. И чем выше скорость - тем больше вычислительных ресурсов требуется, чтобы это разрулить. Современный гигабитный маршрутизатор внутри имеет ОЧЕНЬ неслабый процессор, и он совсем не простаивает.

А теперь, представьте себе, что у нас много процессоров (больше ста или нам достаточна точность, полученная обсчётом ста областей без учёта столкновений молекул в каждой(просто считаем каждую область "сосудом" без стенок, но с газом)) А при наличии огромного количества процессоров объём каждой зоны сравним с объёмом одной молекулы. Тогда нам достаточно иметь связь только с соседними областями. Да и вообще, при такой схеме решения этого достаточно, т.е "сильная" связь должна быть Только между процессорами, непосредственно обслуживающими примыкающие друг к другу области, через один она вообще не нужна.Чем больше процессоров, тем меньше поток передаваемой между ними информации и выше точность вычислений.
Связь всех со всеми- это то, как пытаются решить эту задачу на одном процессоре.

Во-первых, процов больше, чем один. Процессор современной видеокарты по мощи не уступает центральному. Во-вторых, расчет физики по сравнению с расчетом графики все равно нынче очень быстр, даже в Ил-2. У симуляторов есть особенность - они обязаны как-то рисовать то, что они считают. И чем детальнее считают - тем детальнее обязаны это рисовать, иначе это - просто глупая трата ресурсов. Например, зачем детально рассчитывать повреждения от снаряда, форму и размер дырок, и где именно сломался лонжерон, если все это визуально никак не отображается? Гораздо проще и эффективней ввести статистическую модель - эффект тот же, а геморроя намного меньше.

А если речь идет о рисовании, то опять же проблема тесно связанных вычислений - ты никогда заранее не можешь сказать, не заслонит ли вот этот листочек вон тут самолет, или нет. Требуются расчеты, пусть даже поначалу прикидочные, а это опять - сравнение всех со всеми, и перегрузка каналов связи, либо простой каких-то процессоров (самолеты в ИЛ-2 - не молекулы, и часто любят собираться все вместе в очень ограниченной области пространства, а где самолеты - там и пальба, и все такое ).

Есть алгоритмы рисования сцен, которые распараллеливаются отлично, и дают потрясающе реалистичную картинку (загляните за примерами на www.povray.org, особенно на картинки-победители месяца) - это трассировка лучей (raytracing). Но такие алгоритмы сами по себе чрезвычайно прожорливы, и даже с сотней современных процессоров не дадут картинку качества современных игр с приемлемым FPSом. Планка производительности и количества процессоров (и, разумеется, качества картинки), когда raytracing станет выгоднее нынешних алгоритмов 3D-визуализации - еще ОЧЕНЬ ДАЛЕКО.

Насчёт визуализации- это отдельный, и очень непростой разговор...
Но, с другой стороны, сейчас, играя онлайн мы уже вовсю используем распределение вычислений по визуализации, не передавая огромных потоков данных
Играя вдвоём, мы в результате имеем две картинки, с двух разных точек(а возможен вариант, что и с одной), т.е именно УДВАИВАЕМ производительность системы , подключив второй комп по очень узкому каналу.
Насчёт "быстрого" обсчёта физики... Вы это оффлайнщику скажите, у которого при большом числе объектов начинается слайдшоу (причём перегруз идёт не по видеокарте)
А насчёт raytracing...
Если Вы захотите получить ТАКУЮ картинку теми методами, которые используются сейчас, то , думаю, что ресурсов понадобится ещё больше (гораздо больше), потому, что при нынешних алгоритмах количество обрабатываемой информации растёт нелинейно с ростом детализации (связь всех со всеми), т.е. нынешнюю игровую картинку получить проще так, как сейчас, а вот ту - через raytracing. Когда наступит "равноправие" этих методов загадывать сложно, но то, что нынешние методы начиная с этого момента(а может быть и чуть раньше) будут неконкуретоспособны- это точно.