(Начало статьи - смотрите в 1-ой части и во 2-ой части).
Другими словами, та проблема, которая перед нами стоит - это как эффективно использовать многоядерность процессоров и потоков данных. Потому что тактовые частоты процессоров уже почти не получается увеличивать, на данный день, чтобы обспечить этим основной прирост производительности. Вот я и предлагаю - перейти к асинхронной модели программирования на потоках. Взаимодействие между которыми - событийное. Это сразу решает большинство проблем, связанных с многопоточностью. Да и... а как оно в жизни то - один программист - прочитал 1 учебник за год, другое - 4 учебника. - Конечно их пути развития - асинхронны, их нельзя свести к одинаковой величине через год. И что нам тут мешает? - Да практически ничего. Организуем ветки, петли выполнения программ, на каждом потоке. Включая и то, что, популярное нынче "низкрогранулированное" "решение" построения фреймворков - представляет собой набор подсистем. Почему каждая из подсистем - не может "крутиться" в своем потоке, вот вы мне скажите? При событийной модели (и такие примеры, отличнейшие, правда пока без такой многопоточности) - уже есть - взять фреймворк JBoss Seam. - Типичнейший пример, с отличной системой генерации событий и "низкогранурированностью".
Значит проблемы нет? Раз уже есть "подходящие" фреймворки, которые могут задействовать сотни потоков одновременно.
Вы хотите сказать, что есть, например, такие высоконагруженные операции, как вывод графики, и как же тогда там? Что значит - "высоконагруженные операции графики" - вы ДЕКОМПОЗИРУЙТЕ задачу. На сотню отдельных составляющих. Каждая из которых будет крутиться в своем потоке. Нужно отрендерить "задний план", на картинке? - Пускай это сделает отдельный подузел. Если у нас есть 50 потоков для рендеринга заднего плана - декомпозируйте еще. Вплоть до обсчета 2x2 пикселя в левом верхнем углу одним из них.
Вы хотите сказать - а как же эффекты, как же - текстуры, накладываемые после, как же - шейдеры? - Блин, ну а как же организован конвейер на любом заводе? Есть 10-100 автоматов, каждый из которых - "существует в отдельном потоке" (в свою очередь каждый такой автомат - может состоять из еще - множества различных узлов его).
Какие-то операции, как делается сейчас - могут выполняться более-менее параллельно - например нам нужно 4 конвейера для выпуска одной легковой машины.
А если нужно преобразовать какой-то сигнал, то можно поделить его рабочую частоту - на кол-во доступных потоков, чтобы каждый "обсчитывал" свою часть.
Первое правило - декомпозиция, как метод борьбы со сложностью. Ну и запускайте каждый "декомпозированный" элемент - в отдельном потоке. Если у нас может быть, иногда, 25 потоков, для какой-то подсистемы, доступно, а может быть что и 450 потоков будет доступно (на каком-то там готовящемся к выходу процессоре) - пожалуйста - заложите в конструкцию, что если 25 потоков - то Система декомпозируется на 12 подсистем + еще 13 потоков можно "передать" на декомпозицию некоторым из них. Если у нас 450 потоков - тогда 12 подсистем (на деле, каждая из которых еще декомпозируется на сотни более мелких) - большинство из них получат свои потоки.
Тут уже и архитектура вырисовывается... новых фреймворков...
0 коммент.:
Отправить комментарий