По поводу связей между SPE:

http://www-128.ibm.com/developerworks/power/library/pa-cellperf/

Там в районе таблицы 1. Цифры разные т.к. граф не полносвязный - за каждый такт SPE могут послать пакет соседу или получить в свой буффер пакет от соседа для дальнейшей передачи.

OldNick

Раскрывая мощь широкополосного движка CELL

предлагаю зачитать мой мегаперевод статьи для программеров CELL, ибо недопонимание с разных сторон
уже задолбало
==========================================

http://www-128.ibm.com/developerworks/power/library/pa-fpfunleashing/

Точка зрения модели программирования.

Уровень: начальный

Редакторы Power Architecture, developerWorks, IBM

16 Nov 2005

Эта статья с MPR Fall Processor Forum 2005 исследует модели программирования для Cell Broadband
Engine (CBE) Processor от простой к постепенно более продвинутой. Программирование для CBE с девятью
ядрами на одном кристалле не похоже на программирование ни одного из процессоров созданных ранее.
Читайте почему.

Cell Broadband Engine (CBE) Processor предлагает увеличенную призводительность для широкой области
приложений. Тем не менее получение теоретической производительности процессора требует хорошего
понимания его возможностей и выбора модели программирования совпадающей с архитектурой процессора.

В этой статье сделан обзор базовой архитектуры процессора и некоторых моделей программирования
хорошо соответствующих его дизайну.

Базовая архитектура CBE
=======================

Фиг 1. Блок-схема CBE

CBE процессор содержит один PowerPC® процессорный элемент, используемый как основной процессор и восемь
синергических процессорных элементов. Данная архитектура позволяет любому из синергических процессорных
элементов принять на себя управляющую роль если это необходимо. Эти процессорные элемент называются PPE
and SPEs соответственно (смотри врезку для акронимов сбоку). CBE процессор также обладает большой
пропускной способностью. Каждый SPE имеет 256КБайтное локальное хранилище для кода и данных и 128
128-битных регистров. Набор инструкций для SPE спроектирован в предпочтении к SIMD-обработке. SPE не
имеют хардверного кеша основной памяти. Близость каждого SPE к его 256КБ локального хранилища делает
его абстрактно схожим с кешем. Программисты SPE могут управлять локальным хранилищем (local storage - LS)
чтобы хранить часто используемые куски данных. Однако, с точки зрения железа это не одно и то же. Кеши
хранят временные копии основной памяти. LS каждого SPE не связано с некоторой областью основной памяти,
это частное некогерентное локальное хранилище. Данные могут бать переданы из LS одного SPE в LS другого
SPE напрямую без участия основной памяти. Внутренняя шина, называемая межэлементная шина (Element
Interconnect Bus - EIB), обладает пропускной способностью грубо 100ГБ/с, для получения доп информации
смотрите статью "Unleashing the Cell Processor: The Element Interconnect Bus".

Каждый SPE может взаимодействовать с PPE посредством "почтовых ящиков" (mailboxes), реализованных как
регистры доступные данному SPE и PPE. Этими тремя почтовыми ящиками являются: входной и выходной ящики
без прерываний и один выходной ящик с прерываниями. Эти прерывания позволяют уведомлять и
взаимодействовать быстрым и эффективным способом. 


Уровни параллелизма
===================

Несколько видов параллелизма доступны для разработки приложений под CBE. Для начинающих, все PPE и
SPEs обладают набором SIMD-инструкций, поэтому одной инструкцией возможно выполнить несколько операций
одновременно. Также они суперскалярны, способны выполнить до двух инструкций за такт. Этот уровень
параллелизма знаком разработчикам PowerPC по VMX/AltiVec инструкциям реализованным на последних PowerPC
процессорах.

Каждый процессорный элемент может выполнять собственную постоянную задачу, что делает возможным
параллелизм уровня задач. PPE выполняющее до двух тредов одновременно плюс 8 SPE позволяют выполнять
до 10 задач одновременно. Каждая задача модет использовать SIMD-инструкции для обработки больших объёмов
данных.

DMA-модули (MFCs) на каждом SPE могут пересылать данные во время обработки процессорными элементами. Это
отдельный компонент архитектуры, не требующий внимания процессорного элемента во время обработки уже
доступных ему данных. Таким образом CBE ядрам не требуется много времени для пересылки данных.

Наконец, возможно иметь несколько CBE в одной системе или несколько систем объединённых в кластер. Этот
уровень параллелизма очень хорошо извесиен и не специфичен для CELL. Для доп информации по когерентности
данных смотрите статью "Unleashing the Cell Processor: The Element Interconnect Bus".

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

Эта статья делает обзор обеих "малой" (под локальное хранилище) и "большой" (использующей внешний код
или данные) одно-SPE-шной модели программирования, так же как и много-SPE-шной параллельной модели.


Программирование SPE
====================

Перед описанием деталей программирования SPE вам необходимо понять роль PPE. PPE это 64-битный PoerPC
чип спроектированный для выполнения общецелевого кода и содействию SPEs. CESOF объектный формат
используется для хранения кусков кода передаваемых SPE. Каждое SPE-изображение связывается с
идентификатором используемым во время выполнения для загрузки кода на SPE. PPE управляет распределением
памяти и обработкой исключений, чтобы загружать код на SPEs и запускать/останавливать его выполнение.
В общем но не всегда планирование времени SPEs остаётся за PPE и сервисы операционной системы (например
файловый ввод/вывод) также выполяются на PPE.

Раскрывая мощь широкополосного движка CELL

Малые одно-SPE-шные модели
==========================

Простейший способ использовать один SPE заключается в загрузке одного куска кода на этот SPE вместе с
данными для обработки на нём и запуске этого куска. SPE обрабатывает только данные из своего LS без
доступа к основной памяти. Большой объём работы может быть сделан таким способом но код и данные вместе
должны уложиться в 256 килобайт.

В этой модели ввод и вывод всегда явные. SPE-программа принимает аргументы (как аргумента её
main-функции) и возвращает код возврата (exit status). Она также может взаимодействовать посредством
почтовых ящиков или системных вызовов. Эта модель может поддерживаться IDL. SPE-программы компилируются
и линкуются отдельно и затем встраиваются как данные только-для-чтения в PPE-программу используя CESOF
формат. (CESOF-объектник встраивается в секцию ELF-объектника для PPE-программы). Во время выполнения
PPE загружает и инициализирует SPE и затем запускает на этом SPE загруженный код.

Смотрите также статью "SPU Application Binary Interface Specification" перечисленную в списке Resources
ниже.

Нижеприведённый листинг показывает как это работает:


	/* spe_foo.c
	 * A C program to be compiled into an executable called "spe_foo"
	 */

	int main(unsigned long long speid, addr64 argp, addr64 envp)


	{
		int i;
		/* func_foo would be the real code */
		i = func_foo(argp);
		return i;
	}

	Listing 2:  A program to run another program on the SPE.

	/* spe_runner.c
	 * A C program to be linked with spe_foo and run on the PPE.
	 */

	extern spe_program_handle_t spe_foo;

	int main()
	{
		int rc, status = 0;
		speid_t spe_id;

		spe_id = spe_create_thread(0, &spe_foo, 0, NULL, -1, 0);

		rc = spe_wait(spe_id, &status, 0);

		return status;
	}

заметьте, что возвращаемое значение spe_wait и статусный код SPE-программы различны, если spe_wait
завершается успешно, то статус это значение возвращённое из SPE-программы. Взаимодействие между SPE
и PPE не нужно до конца выполнения. spe_wait блокирует выполнение до окончание SPE-программы.

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


Большие одно-SPE-шные модели
============================

Когда код и данные не могут уместиться в 256 килобайт вам необходимо использовать одну из "больших"
моделей. В этих моделях PPE резервирует области эффективного адресного пространства для использования
SPE-программой, которая доступается к ним посредством DMA. Распределение памяти на эффективное
адресное пространство даёт SPE вторичную память доступную через DMA-модуль (MFC).

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

В некоторых случаях эта же техника может быть использована и для кода, не только для данных. Основной
код загружаемый на SPE может использовать перекрывающиеся сегменты (overlays) в основной памяти как
нужно. Компилятор может генерить overlays автоматически для таких случаев. CESOF и вспомогательные
утилиты позволяют SPE-коду ссылаться на объекты в эффективном адресном пространстве.

Простая LS-резидентная мультизадачность возможная на одиночном SPE становится чем-то более гибким при
комбинировании с автоматической загрузкой кода и данных заданий. Небольшое ядро запущеное на данном SPE
может подгружать задания или менять их по блокировке или завершению, позволяя этому SPE работать с
многими заданиями из некоторой очереди заданий. Повторим ещй раз: мультизадачность ПРИНУДИТЕЛЬНАЯ.

Необходимо заметить, что использование DMA для перекрытия эффективной памяти SPE приводит к серьёзным
задержкам. Держа это в уме, предзагрузка (prefetching, известная также как двойная буферизация или
мультибуферизация в частности в программировании игрушек) становится важной техникой. Пока буфер N
обрабатывается, буфер N-1 выгружается и затем буфер N+1 зачитывается, процессорный элемент может
работать непрерывно, даже если время на пересылку данных составляет существенную долю (до половины)
времени на выполнение этой операции.


Много-SPE-шные модели программирования
======================================

Возсожно скомбинировать работу многих SPEs. Вопросом становится синхронизация. Возможности включают
команды атомарного изменения, почтовые ящики, сигнальные регистры уведомления SPE, события и
прерывания или даже опрос разделяемой памяти. Что касается больших одно-SPE-шных моделей, компилятор
(например OpenMP) может прозрачно управлять доступом к разделяемой памяти с соответствующим управлением
доступом к критическим секциям.

Модель очереди заданий популярная при программировании под CBE позволяет любому простаивающему SPE
быстро получить задание и обеспечивает автоматическую балансировку нагрузки. Один специальный случай
этой ситуации оптимизируемый особенно хорошо для очередных последовательных кусков это потоковая модель.
Один кусок данных может быть быстро обработан одним SPE, но обработку большой массив данных такого рода
лучше распараллелить на несколько SPEs, вытаскивающих новые блоки данных их FIFO очереди и обрабатывающих
их одновременно.

Другая возможность для организации потока это конвеер, в котором каждый SPE выполняет часть задачи,
обрабатывая вывод предыдущего SPE. Это может задействовать в полную силу прямое LS в LS DMA, не используя
основную память и уменьшая используемую пропускную способность. Это позволяет SPEs выполнять задания
которые требуют слишком много кода, не оставляющего места для эффективной работы с данными в LS, будучи
загруженного в LS одного SPE. Этот код может быть разделён среди нескольких SPEs, что позволяет данным
быстро проходить. Это хороший пример использования каналов DMA для посылки сообщений. С другой стороны,
балансировка нагрузки намного сложнее чем в ранее упомянутой потоковой моделью. Если данный кусок данных
не может быть быстро обработан одним из SPEs, overlays кода могут быть лучшим выбором.


Управление SPEs посредством операционной системы
================================================

ОС запущенная на PPE может управлять и выделять SPEs, обеспечивая произвольный доступ к ним. Такой
способ позволяет принудительной многозадачности запускать больше задач чем число SPEs. Запускаемые задачи
или треды могут быть отображены на SPEs, остановлены и выгружены, загружены снова и так далее. Вследствие
большой стоимости переключения контекста (целый 256 килобайтный LS, 128x128 регистровый файл и очередь
команд DMA), выполнять-до-окончания подход конечно сильно предпочтителен, но возможность прерывания
всё равно остаётся. Такая модель обеспечивает защиту памяти между задачами поскольку задача выгружается
целиком перед тем, как другая задача будет загружена на тот же самый SPE.

Раскрывая мощь широкополосного движка CELL

Разработка приложений
=====================

Всё что вы когда-либо слышали об оптимизации приложений применимо и к архитектуре CBE. Выбор алгоритма,
типа взаимодействия между алгоритмами и связанные вопросы критичны для эффективной разработки. Выделите
некоторое время для экспериментов, поделите алгоритм и программу, посмотрите как это работает и будьте
готовы повторить это снова. Начните с кода который будет работать на PPE, затем выгрузите специфичные
задачи в SPEs. Переключитесь на SIMD-код на этих SPEs если это нужно, но гарантируйте что общее деление
алгоритма работает, перед тем как потратить кучу времени на векторизацию, иначе её придётся переписать
заново.

Разработка под CBE процессор потребует заботы и о вычислениях и о пропускной способности. Есть куча и того
и другого, но полный объём вычислений может заполнить пропускную способность и большой объём передаваемых
данных может тормозить обработку. Если вы обнаружили нехватку пропускной способности поищите способы для
вычисления данных, а не их копирования, и поищите способы выполнить больше операций по обработке данных
перед их отсылкой. 

Поищите узкие места во время замеров производительности вашего кода. PPE может легко стать таким узким
местом если вы слишком сильно полагаетесь на предвычисления того что будет обрабатываться на SPEs. Если
обработка слишком тяжела для одного SPE, поделите эту работу на несколько.


Заключение
==========

Хороший выбор модели программирования и ясное понимание многих моделей возможных на архитектуре CBE может
уменьшить стоимость разработки и улучшить производительность. Абстракции, такие как потоковая обработка и
модель программирования посредством очереди заданий, и инструменты для разработки критичны для надёжной
и эффективной разработки. Не бойтесь смешивать модели программирования, вы можете обнаружить, что
наилучший дизайн имеет два SPE работающие по потоковой модели над общей задачей и четырёх-SPE-шный конвеер
обрабатывающий частную сложную задачу. Вам не нужно использовать все SPE единообразно. Новые приложения
могут требовать новых моделей программирования, выделяйте время на эксперименты. Потоковая модель может
эмулировать конвеер, хотя это требует дополнительных расходов.

Архитектура CBE делает довольно определённым, что небольшое усилие в разработке может привести к
значительному преимуществу в производительности над традиционной процессорной архитектурой. Но достижение
предельной производительности сложная задача.

Блаодарности
============
Эта статья является адаптацией сделанной Peter Seebach из оригинальной презентации "Unleashing the power
of Cell Broadband Engine: A programming model approach," представленной на MPR Fall Processor Forum 2005
by Alex Chow of IBM. Peter хотел бы поблагодарить Tim Kelly, Alex Chow, and Daniel Brokenshire за
технический и редакторский просмотр во время написания.

обшибка в разделе "Большие одно-SPE-шные модели", во втором абзаце снизу вместо "ПРИНУДИТЕЛЬНАЯ" следует читать "КООПЕРАТИВНАЯ"

>Где? В научных приложения винды не было, и не будет никогда. Есть конечно >быдлоНИИ, где её юзают, но там вычисления на уровне 2+2.

Анонимусы знают все лучше всех... От того такие тупые...

2Bozz_Bishop: а Вы лично на дебилизм проверялись??? По моему нет.

> Гы, в корпорациях. Они работают на вендах, потому что им манагеры сказали, а > манагеры - дебилы по определению - решили использовать венду потому что это > модно и стильно. Ну, и Get The Fuckts > Bozz_Bishop

Уж если кто и дебил по определению, то это Bozz_Bishop!!!

> Нечего равняться на компании - уровень их исследовательских контор гораздо > ниже академических и университетских.

Вы бы свой дебилизм хотя бы не в каждом посте демонстрировали... Хоть через раз... А то слишком очевидно...

Лефша использует венду для научных вычислений?

Лефше обидно что он дебил?

Не принимай это близко к сердцу, манагер ;)

> Физик+it специалист в одном флаконе, редкое надо заметить сочетание,

Хотел бы я знать с чего ты решил, что это редкое сочетание. На мой взгляд едва ли не половина хороший специалистов в it по совместительству физики. Примеры: Столлман, Торвальдс.

anonymous_incognito:

Дийкстра, однако...

А каким боком Линус к физике относится?

2lenin

> сопроцессоры Cell 1) не могут обращаться к оперативной памяти, только к своей 256 КИЛОбайт, словами по 128 разрядов, причёи этот блок 256 килобайт один на все SPE 2) не могут пользоваться системными вызовами ОС.

1) они могут обращатся ко всей памяти посредством встроенного MFC контроллера, издержки минимальные пропускная способность прекрасная

2) системными вызовами занимается PPE и они не являются главным потребителем ресурсов CPU, вызов принят -> отправлен на обработку в SPE -> получен результат, пока SPE занимается обработкой, PPE может принимать другие вызовы и переправлять данные на другие ядра

2lenin

> эти 256 килобайт в Cell - ОДИН на ВСЕ SPE. Блоками по 64К, кстати.

у каждого SPE свое LS размером в 256K

>Смотрите историю Amiga

Трупы не трожь, ни не своей смертью умерли

Да, твое интелопоклонничество просто умиляет. Зачем, говоришь SPE? А ты глянь, на интеловскую встроенную графику. Сначала на 81x, когда орали "T&L нах не надо". Потом на 915, и сравни с nforce. Интель, как уперся в позу "CPU наше фсе", так и будет прыгать на граблях до победного.

2gr_buza

> SPI могут друг другу передавать данные или нет?

да, могут

SPE может получать данные из основной памяти, от других SPE, от PPE и непосредственно от аппаратных девайсов через соответствующие каналы, у него имеется локальная память 256K и регистровый файл - массив из 128 128-битных регистров где могут содержаться любые данные и инструкции

2Tester

> ты плохо читал тред :) оперативка у них общая

нет, это lenin некомпетентен, зато вещает за десятерых :)

похоже мне тоже не помешает почитать даташиты :)

Вот полезный линк, с общим описанием, цветными схемами и конкретными бенчмарками Cell, как в операциях одинарной, так и двойной точности:

http://www-128.ibm.com/developerworks/library/pa-cellperf/

Все в общем довольно доступно и наглядно, после этих цифр и схем все ленинские бредни о тотальной ущербности Cell-ов будут выглядеть довольно смешно :) А дополнительную информацию по CBE можно найти тут:

http://www-128.ibm.com/developerworks/power/cell/articles.html

Если говорят о 256К локальной памяти то делают 2 распространенные ошибки: 1) считают её чем то вроде кэша; 2) считают что только с ней может работать SPU; то и другое неверно, хотя и содержит часть правды, а именно 1) в 256K LS можно при желании эмулировать кэш, фактически с этой памятью ядро работает напрямую, но в отличие от кэшей в обычных процессорах где сохранение часто используемых данных происходит автоматически в SPE это делается явно именно таким образом и по такой схеме, какую посчитает для себя удобной программист; 2) SPU действительно работает в диапазоне адресного пространства своего LS, но это не значит, что данные из главной памяти (Main Store - MS) для него недоступны, важной частью ядра является MFC (Memory Flow Controller) который выполняет множество инструкций по получению/отправке необходимых данных, причем он работает автономно, никак не мешает вычислительным блокам заниматься обработкой полезных инструкций. MFC получает и отрабатывает разного рода запросы, поддерживает почтовые ящики приема/отправки данных и ассоциированные с SPE каналы. То есть то, что делают обычные процессоры непосредственно обращаясь ко всему адресному пространству SPE делает через свой MFC контроллер. SPE через MFC может непосредственно работать с областями MS, либо получать информацию прямо в LS от PPE которое имеет прямой доступ к памяти всех вспомогательных ядер, или через почтовые ящики и каналы. Например, канал может быть связан с каким то адресом ввода/вывода устройства в основной памяти и таким образом через операции чтения-записи в канал ядро будет через MFC прозрачно работать с физическим девайсом. Так как операции MFC идут с учетом полномочий определяемых OS, то код в SPE будет таже получать доступ к физическим устройствам только посредством операционной системы и PPE на котором она исполняется.

Еще SPE не имеет доступа к системным командам и файловой системе, программа на SPE не может непосредственно писать или читать из какого то файла, но все это можно организовать посредством PPE и каналов, так что получая/отправляя данные программа на SPE будет фактически писать/читать из какого то файла на диске, и то же самое с сокетами.

В связи с предложенным вами материалом возник следующий вопрос:

Вот я распаралелил задачу, к примеру, на все 8 SPE... Но это одна задача, а в системе их, к примеру, крутиться пару сотен. Как происходит переключение контекста задачи? Да, можно на одном SPE зупускать несколько задач, но для этого придётся полностью выгружать память этого SPE, а так же переинициализировать DMA этого SPE. А если у меня задача крутиться на всех 8-ми SPE, то получается все остальные 7 SPE либо тормознуться, пока на первом выполняется другая задача, либо, что более вероятно, тоже сменят контекст и начнут крутить другие задачи. А если все 8 или 7 SPE начнут качать код из основной общей памяти, чтобы загрузить его в свои 256К, то это может, я думаю, прилично тормознуть всё это дело.

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

>А если все 8 или 7 SPE начнут качать код из основной общей памяти, чтобы загрузить его в свои 256К, то это может, я думаю, прилично тормознуть всё это дело.

8*256R=2M ~ размер кэша некоторых современных процов. Псп XDR RAM = 25,6 GB/sec. В общем, смена контекста задач для SPE-шек нектритична к производительности Cell. Другое дело, как все это дело вписать в ось. ИМХО, возможный вариант - написать некий SPEServer - по аналогии с X-сервером, который и будет управлять работой SPE-шек.

у меня в общем такое же мнение - переключение контекста быстро происходит лишь на PPE, SPE предназначены для достаточно длительного выполнения тяжелой работы, фактически в однозадачном режиме .. так что параллелить свою программу в расчете на все 8 ядер думаю не всегда имеет смысл, подразумевается, что Cell OS будет участвовать в распределении ресурсов свободных ядер как то балансируя нагрузку, но если каждая задача будет хотеть все 8 SPE, то может выйти так, что она их всех не получит и ей придется ждать пока другая задача не освободит достаточное количество SPE

> Другое дело, как все это дело вписать в ось.

в общем это входит в число задач Cell OS, а с учетом того что Cell BE поддерживается в Linux начиная с 2.6.16, то можно считать, что эта работа уже сделана :)

Учитывая, что контекст переключается довольно часто, да ещё надо регистры сохранять, да DMA состояние сохранять... Опять же не забываем, что это только затраты фактически на переключение контекста в самом процессоре, а ведь есть, я думаю, ещё и виртуализация памяти, таблицы страниц общей памяти процесса - это ещё в плюс. А лишних тактов не бывает. Всё же это думаю является некоторой проблемой.

В этом случае получается, что будут простые потоки (нити), которые ядро ОС будет раскладывать по SPE, внутреннние данные которых (нитей) будут храниться в личной памяти SPE. Это и программировать проще (по сути переучиваться не надо) и проблем с портированием меньше.

Но тогда все эти навороты с оптимизацией под cell становятся бессмысленными, а точнее ненужными, т.к. не будут использоваться в многозадачной ОС (если не учитывать обещанный доступ к SPE через /dev/). Т.е. нельзя будет выстраивать цепочки выполнения задачи по SPE вручную, т.к. распределением и управлением SPE будет заниматься ОС.

Получается вся эта мега-оптимизация и сложное программирование и распределение задач - это удел однозадачных телевизоров и может быть будущих графических ускорителей с целом на борту. А в реализации многопоточной ОС это будет выглядеть просто набором процессоров с простым и логичным аппаратным решением обмена результатами работы между друг другом.

Осталось дело за малым... Купить PC с cell-ом на борту :-)

> В этом случае получается, что будут простые потоки (нити), которые ядро ОС будет раскладывать по SPE, внутреннние данные которых (нитей) будут храниться в личной памяти SPE. Это и программировать проще (по сути переучиваться не надо) и проблем с портированием меньше.

> Но тогда все эти навороты с оптимизацией под cell становятся бессмысленными, а точнее ненужными, т.к. не будут использоваться в многозадачной ОС (если не учитывать обещанный доступ к SPE через /dev/). Т.е. нельзя будет выстраивать цепочки выполнения задачи по SPE вручную, т.к. распределением и управлением SPE будет заниматься ОС.

Тогда заведомо будет использоваться малая доля мощности CELL, поскольку SPEs будут использоваться как недо-CPU без учёта их особенностей. Я не знаю как это реализовано в линуксе сейчас, но по уму должен быть режим работы ОСи, в котором она полностью отдаёт планирование ресурсов некоторых или всех SPEs и EIB приложению на некоторое время. Я думаю динамическая оптимизация выполнения в зависимости от количества свободных SPEs задача вполне решаемая для разработчика приложения. В простейшем случае алгоритм должен разбиваться на части по приоритетам и наименее приоритетные части выгружаются из отобранных SPEs на PPE или наоборот наиболее приоритетные части выполняемые на PPE загружаются на освободившиеся SPEs, самое простой вариант для реализации этого способа - побить всё на треды. Динамическая смена модели программирования задача понятно гораздо более сложная, поскольку придётся писать несколько различных реализаций одного и того же алгоритма, делать это имеет смысл только для случаев заведомо перегруженной системы, ну это как всегда, что дешевле - докупить железо или оптимизировать софт - зависит от обстоятельств.

Так то есть мечта :)

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

Большой проблемы в однозадачности SPE не вижу. HPC обычно как раз и обрабатывают большие задачи в пакетном режиме, а пользователи PC запускают одновременно не более 2-3 ресурсоемких задач, к этому они уже давно приучены, в начале досом, затем кривой многозадачностью win9X, а затем общим дефицитом ресурсов - запускаем игрушку - остальное выключаем, пакуем большой файл, смотрим мувис, а остальное или вяло капает в фоновом режиме, или также выключается, почти всегда на десктопе или одна-две мегазадачи, которые жрут все ресурсы, либо куча утилит и сервисов, икон в трее, которые висят и почти ничего не делают - вся эта мишура также успешно может крутиться на PPE, тем более что программировать её не сложнее чем софт под PPC или x86, а вот главные задачи всегда будут иметь в распоряжении SPE ..

так что проблема Cell на десктопе скорее не в отсутствии оптимизации, а в том, чтобы сапожники каждую погремушку не наоптимимизировали без соображения, так чтобы каждый галимый чат клиент или калькулятор не требовал 8 сопроцессоров для своих глупых прибамбасов, а это может легко случиться - выпустят оптимизированные библиотеки для разработчиков, а те и начнут их линковать где надо и не надо, лишь для морального удовлетворения, что их поделие оптимизировано для Cell процессора, вместо того, чтобы прокрутить убогую анимацию на банере или кнопке по старинке на PPE, будут раскладывать секундный mpeg поток на 8 SPE ядер и радоваться

Кстати ваолне возможно - просто Just for fan :-)

А вообще, если так рассматривать задачу, то получается достаточно обычного распаралеливания, а уж "мега-задачи" будут напраямую управлять работой SPE через /dev. Т.е. игры и, допустим декодирование видео, компиляция и т.п. А если ещё выставить права на /dev/spe, то можно некоторые задачи запускать с доступом к сопроцессорам, а другие допускать к ним только когда они свободны (SPE) и ОС переложит туда один из потоков. В принцепе получается даже лучше, чем думал раньше - для обычных задач парадигма программирования не меняется, а для хитрых задач открывается простор для оптимизации...

P.S. Опять будет возможность человеку творчески поучаствовать в процессе оптимизации в том числе и на железном уровне.

> HPC обычно как раз и обрабатывают большие задачи в пакетном режиме,

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

> а пользователи PC запускают одновременно не более 2-3 ресурсоемких задач, к этому они уже давно приучены

человек к хорошему привыкает быстро, будет возможность запускать несколько одновременно полезных русурсоёмких задач, будут делать ;)

> чтобы сапожники каждую погремушку не наоптимимизировали без соображения, так чтобы каждый галимый чат клиент или калькулятор не требовал 8 сопроцессоров для своих глупых прибамбасов

не системный подход, нет у вас админского опыта на многоюзерных машинах ;), задача планирования ресурсов заключается в обеспечении их оптимального использования в разных случаях, а не в битье по рукам со словами "нельзя так делать!" ;), строить всех под одну гребёнку неразумно