Ждём Ваших отзывов о материале.
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!

Ну, почему же бестолку? Если в игре использовать не параллелизм задач, а параллелизм данных, то толк очень даже есть. Т.е. вместо "ядро для обработки звука, ядро для обработки физики, ядро для рендеринга и т.д." будет "расчёт физики для 50 осколков разбитого стекла на 50 ядрах и т.д.".

Это Ваше представление или мечты?
Больше похоже на второе.
Впрочем, о чем ещё могут мечтать фанаты интела?..

Давайте посмотрим, какие задачи требуется ускорять приростами потоков.
1. Архивирование. Тут и тысяча потоков - не проблема, легко расширяется.
2. Аудио и видео. См. пункт 1.
3. Прочая обработка изображений (фотошоп, 3д студия...) - сложнее, ибо надо оптимизировать каждый отдельный
фильтр, но тоже вполне возможно.
4. Работа с базами данных. Не очень хорошо масштабируется, но очень давно оптимизируется(благо запускаются такие задачи в основном на серверах), поэтому с 16-тью потоками всё будет в порядке.
5. Научные расчёты. 50/50 - некоторые легко распараллелить по самое не хочу, другие больше одного потока не приемлют.
6. Игры, главный сегодняшний пожиратель производительности и главная проблема такого метода, ибо создаются они достаточно короткое время, большая часть которого уходит на то, чтобы "ента бандурина зафурычила и не бажила", и оптимизация даже на два потока даётся с трудом. И если лицензируемые движки и вторые, третьи и последующие части игр ещё будут успевать оптимизировать, то для новых оригинальных игрушек ситуация достаточно плачевна.

Тим Суини, который пишет Unreal Engine 4 (уже больше 2 лет) говорил, что движок будет поддерживать до 64 процессоров... правда он и выйдет только к 2010 году...
Так что это зависит от прямоты рук софто-игро-писателей....

При расчете 50 осколков разбитого стекла на 50 ядрах. Хотел бы я увидеть как ты его эфективно распараллелишь. Ведь для расчета траектории каждого осколка мы должны знать данные о других 49. Следовательно есть какая либо критическая секция. И пока одно ядро в нее пишет - остальные ждут (могут только читать)
Добавлено спустя 5 минут, 2 секунды

+1
Сам работаю в этой области - у нас все обстоит именно так

сначала хотя бы ознакомился с этим http://overclockers.ru/hardnews/24205.shtml

panela +2
я работаю в области электроники , а не в программирования , но хочу вас расстроить - у всех это так
так что не ждите чудес от новых процессоров, их тоже люди делают

Так есть же уже Intel C++ Compiler

H(CHCl11B11)

Я читал, но это все маркетинговые фантазии на уровне слайдов пока. Если даже брать Fusion, как нечто заявленное в roadmap-е на 2009-й, то кто-нибудь видел прототип? Да ладно, фиг с ним с прототипом, ну хотя бы - сколько ядер у него будет, какие частоты?

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

оптимизация - это конечно круто, но закон Амдала никто не отменял.. так что 16-ядер это ТОЛЬКО маркетинг. приемущество 16-ядерников на 4-ядерниками будут ничтожными.
Добавлено спустя 8 минут, 14 секунд

Как раз наоборот.. Оптимизировать что-то чтобы оно лучше параллелилось сложно. Легче с нуля написать. Так что единственная надежда на новые игровые движки. Производители процов должны будут оооочень убедительно уговаривать игрописателей уделять внимание параллелизму.

в своё время виндовс NT смогли заставить нормально работать на на 30-ти процессорной машине (sequent) Цитата: "Ядро виндовс NT позволяет полностью поддерживать управление и распределение потоков на таких системах. И Вам не придётся делать что-то особенное в своём коде, что бы задействовать преимущества многопроцессорной машины." (Джефри Рихтер, "Виндовс для проффессионалов", ISBN 5-7502-0010-8 , 1995 год)
А когда в америке было модно заниматься мат моделированием, то там выпускались компы содержащие более сотни цпу, и ничего...В играх так вообще многопоточность благо и во всю используется, каждый монстр своим потоком идёт независимым от других...т.е. убил его, и игре не надо ниче делать, кроме как закрыть поток который считал убитого монстра...
в вычислениях в принципе вообще давно известно, что производительность (мегафлопы) растёт как натуральный логарифм от кол-ва цпу..., так что для математики больше 4-х ядер нафик не нужно)
имхо

Да пожалуй только это они и смогут сделать.. Будет тонна монстров бегать.. И что? Между собой то они взаимодействовать вообще не смогут.. Скорее всего будут вообще друг через друга проходить
Ни о каком увеличении интеллекта вообще речь не идёт.

Где ж ты такую игру видел ?

Да, а еще как минимум обработать список квестов/миссий/... , плюс граф. движок (чистка лишних текстур и т.д).
Если б все было так красиво, как ты пишешь, уже давно в играх прирост от двухядерности был 80-90% (если конечно видео позволяет). А то вот в Q4 (движок которого писали далеко не самые галимые программеры ), прирост от 2 ядер чуть менее 50% всего-то

Параллелизм данных!? Хм, когда я предложил будучи студентом приглашенным на заседание науного совета в РАН, я думал меня уже ни кто не пригласит Нет в исключительных случаях такое возможно (ну очень большие массивы с примитивными алгоритмами обработки), но крайне мало таких задач.

Да как сказать. Многие "чистые вычисления" хрен распараллелишь. Задача ведь не только разбить задачу на несколько потоков. Это ещё худо бедно посильно. Сложно их между собой согласовать. Они и выполняются за разное время, требуют разное количество ресурсов, избежать конфлитов уменьшающих, а не увеличивающих производительность ой как не легко.

UT2007

Cell - тоже ?? Али, все уже известно?

если вы дочитали мой предыдущий пост до конца, то там как раз об этом и написано, прирост от двух ядер и должен быть средний чуть менее 50% (идеальный случай ln(2) = 0.7 прироста) великолепный результат, кто сможет пусть попробует сделать больше

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



это самый плохой способ синхронизации многопоточности (когда один поток пишет в критическую секцию, ни один другой поток не только не может писать в неё же, но и читать оттудова), есть другие более эффективные и быстрые способы...

Прикол в том, что от 2-х кратного роста частоты, приросто тоже не 100% и взависимости от роста абсалютных значений всё меньше и меньше. Нет понятно, что что через какое-то время нас ждут тысячи ядер в одной настольной системе и сотни в таблетках. Альтернативы пока не видно, но путь это не многим "прямее", чем задирание частот. Жаль, но такова жизнь

Я ж о том же. И толку от 16 ядер тогда ?
А на серверах при множестве примитивных запросов к данным можно получить зависимость, близкую к линейной.
А для десктопов - макс 4-8 ядер. И постоянно гнать электронщиков: пусть придумывают как наращивать частоты, либо архитектуру меняют - ато опять застой будет.

В общем - да, но это еще немного не тот уровень/объем вычислений...

http://www.top500.org/static/lists/2006 ... Poster.png
Тут ядер/процессоров/нод побольше, тем не менее, такое существует и явно не "для мебели"