Плавающая ядерность Опции

[Anticitizen1]

Начал проект по разработке схемы с плавающей ядерностью то есть ядра - из стандартных блоков вычслений распадаются на ядра с более мелкими разрядами и наоборот.Это своего рода аналог VLIW процессора но с архитектурой плавающей ядерности. Ядра процессора управляемые специальными дескрипторами в специальных сегментах кода будут распадаться на множество мелких ядер (меньшая разрядность и меньшее число блоков процессора) и собираться в большие ядра с большой разрядностью и полным набором блоков работы с памятью и вычислениями. Данный процессор сможет входить в режим графических вычислений без использования видеокарт и прочего графического оборудования.Предполагается исследование возможности ускоренной обработке зависимых частей программ путем слияния отдельных блоков ядер- формирования общих переносов к примеру .

Данный проект нацелен на проблему простоя вентилей у многоядерных процессоров и процессоров с VLIW архитетурой.

Мы предполагаем использование Ultra Sparc T2 как базовый - заложенная многопоточность позволит несколько у простить задачу.Но есть проблема "резки" управляющих сигналов и меж разрядых переносов в вычислениях.В Ultra Sparc резать придется FPU.Мы бы хотели помножить блоки и потом вставить между ними управляющие ядерностью сигналы.С памятью таких проблем меньше так она в целом более симетричная.

АЛУ режется вообще без проблем но АЛУ считается устаревшим.Хотелось бы узнать мнение.Помимо резки проблемы будут и с симуляцией так как слияния и разделения надо учесть во всех возможных комбинациях.Поэтому и стремлюсь не нарушить симметрию элементов.


Пример вычислений где такая ядерность нужна:
происходит взрыв и программа моделирует поведениен множества незавиимых/зависимых процессов.Ядра разбиваются на множество низкоразрядных.В следующий момент взрыв передается на плиту и потребуется вычисление большого среднего значения большого числа частиц воздействия на объект- ядра собираются и разрядность вырастает.Возможные иные комбинации в случае зависмых множественных процессов.

В дальнейшем хотим пустить по 65 нм процессу.Сейчас моделирование типа Cadence Virtuoso позволяет до 45 нм вообще с RTL сразу под сканер идти вроде как.

Сообщение отредактировал Anticitizen1 - Mar 24 2010, 06:42

[zzzzzzzz]

Это что, у Вас хобби такое, реконфигурируемые многоядерники сочинять?
Если это ОКР, то д.б. конкретное ТЗ.
Если Вы только сочиняете ТЗ, то успели ли задать себе вопросы типа "нахрена все это нужно?" и "кто за это готов заплатить?"
Если не успели, то поспешите, - ответы нынче суровые бывают...

И вообще, в чем, собственно, вопрос?

Сорри, напомнило классическое "мы тут подумали немного и собрались Интелов с Паккардами порвать на куски..."

[Anticitizen1]

Это что, у Вас хобби такое, реконфигурируемые многоядерники сочинять?
Если это ОКР, то д.б. конкретное ТЗ.
Если Вы только сочиняете ТЗ, то успели ли задать себе вопросы типа "нахрена все это нужно?" и "кто за это готов заплатить?"
Если не успели, то поспешите, - ответы нынче суровые бывают...

И вообще, в чем, собственно, вопрос?

Сорри, напомнило классическое "мы тут подумали немного и собрались Интелов с Паккардами порвать на куски..."

Вы под реконфигурацией что понимаете переключение как у FPGA programmable interconnect ? Если так то не верно управление сигналом вызывает деление на ядра как например сигнал переключения с логич операций на арифметические.Да это задание которое взял в рамках одного проекта.Но пока не знаем JAVA процессор может лучше но он как то сырым кажется.ULTRA SPARC лучше отлажен хотя огромное число разных блоков и сложный слишком процессор.Да я не только сочиняю довольно много подбирал архитектур для этого.Я не интелы рвать собираюсь а архитектуру апробировать для портативок.
Идея зародилась с техники программирования.
Ну представте себе комп игру - где много разных событий приходится обрабатывать - логические переходы, подсчет большого числа парралельных явлений событий.Чем больше процесссов тем больше потоков обработки надо но при меньшей разрядности. Кодирование большого числа событий происходящих в перспективе можно осуществить меншей разрядностью.

И не лишне будет подумать о том, как компилить подо все вот это?
Второе: не проще ли будет такое сделать в духе Intel Larrabee - на маленьких, но гордых процессорах? Кстати, все к этому и идет.

PS. На словах, "происходит взрыв", ушки сделали стойку.

Да взрыв это просто наглядный пример для того что бы показать необходимость увеличения числа потоков.Ну не взрыв а например другой многопоточный процесс с взаимозавиимыми и нет явлениями - да сколько угодно.Я вообще рань на ассемблере писал еще задавался такими вопросами.Насволько можно оптимально вентили использовать.

Эх, мечты, мечты...

Если оставить в стороне вопрос производительности, для того чтобы изделие было конкурентно-способным, нужно
1) Поддержка софта - как минимум GCC+работоспособный Linux+основной софт. Для разваливающихся процессоров вы GCC допиливать будете годами.
2) Тираж. Нет, даже ТИРАЖ. Чем ниже тираж - тем выше стоимость 1 чипа. Вы сможете продавать 10млн чипов в год при цене 300$ штука? Кто вам сделает это на 65нм по нормальной цене (при которой вы сможете хоть как-то конкурировать с банальными i7)?



Larabee делать не нужно, уже есть серийные супер-дешевые GPU для таких целей. 3 терафлопа за 400$ - это вам не шубу в трусы заправлять :-)

1)Про софт я понимаю.Но вы перепрыгнули через стадии до софта еще надо довести.Я думал посоветуют как резать чтобы на этапах симуляции не затрять.Софт не должен в небеса улететь если не сильно с архитектурой изголяться.Я повторяю в рамках одного элементарного разбиения-адресация , основные наборы инструкций для всех видов операций теже , регистры общего пользования и специализированные остантся теми же дополнительные адреса добявятся и инструкции( сигналы) разбиений- как же это по вашему должно поменять софт - сильно или нет?Здесь будут проблемы с оборудованием серьезные
2) банальный i7?Да прямо уж банальный)).Помимо интел есть много других архитетур.Я хочу архитектуру опробовать а не с интел бороться.Помимо интел есть и куча других архитектур.Мы предполагаем для портативных устройств делать.


3) Проблемы будут с такой вещью как инструкции условного перехода- если прыжки делать в одно и тоже "устройство" а разрядность не рассчитать.

4)Другая проблема. Излишня вентильная загруженность - 10-20 %.американцы разгоняли ядро бьщееся на 2 или 3(проект 2003-2004 годов) и получили рост в 2 и 3 раза то мне кажется вещь себя оправдывает.Более того могу предположить что рост производительности должен быть пропорционален числу разбиений.


Не... "банальность i7" здоровао сказано.))))

Сообщение отредактировал Anticitizen1 - Mar 25 2010, 06:58

[BarsMonster]

Не... "банальность i7" здоровао сказано.))))

Банальность i7 в том, что его себестоимость производства порядка 50$(а то и меньше), тиражи семизначные, а производительность на SIMD инструкциях - до 160 млрд вещественных операций в секунду. Собственно, это ваше разделение там в некотором роде и реализовано - в одном SSE блоке можно делать или 2 64-х битных операции, или 4 32-х битных, и т.д.

Теперь вы говорите про портативные устройства - причем тут тогда симуляция взрывов?
В большинстве портативных устройств стоят процессоры даже без FPU - это же не спроста.

ИМХО производителям портативных устройств продать что-то не-ARM совместимое невозможно, пусть оно и будет в 2 раза быстрее и 2 раза дешевле. Стоимость внедрения отличается на порядки. А с АРМом - склепали платку, накатили стандартный софт - и можно китайцам отдавать на штамповку.

[Anticitizen1]

Банальность i7 в том, что его себестоимость производства порядка 50$(а то и меньше), тиражи семизначные, а производительность на SIMD инструкциях - до 160 млрд вещественных операций в секунду. Собственно, это ваше разделение там в некотором роде и реализовано - в одном SSE блоке можно делать или 2 64-х битных операции, или 4 32-х битных, и т.д.

Теперь вы говорите про портативные устройства - причем тут тогда симуляция взрывов?
В большинстве портативных устройств стоят процессоры даже без FPU - это же не спроста.

ИМХО производителям портативных устройств продать что-то не-ARM совместимое невозможно, пусть оно и будет в 2 раза быстрее и 2 раза дешевле. Стоимость внедрения отличается на порядки. А с АРМом - склепали платку, накатили стандартный софт - и можно китайцам отдавать на штамповку.

Да о SIMD MIMD и VLIW я знаю c незапамятных времен.SSSE3 и предыдущие помоему только на два делятся формата .Эволюцию процессоров я еще на первом курсе прошел.Про эти преобразования разноразрядных форматов я знаю они и в Sparc были и есть - и там даже больше .Есть вещи интереснее форматов .Зачем тогда ядра создают вообще люди - делать вот нечего? Делали бы разновформатные инструкции и все.


Если бы я хотел порвать интел я бы Ultra SParc взял бы и доводил бы его.Fujitsu уже порвала в 2,5 раза превзойдя интеловский Nehalem (i7 в народе много ядерное чудище с 800 000 000 вентилей ) 2,5 гц в 2, 4 раза на базе ultra sparc T1.

До 160 млрд вещественных операций в секунду ?? Ну специализированные MIMD кластеры и больше делают.Мой то проект при чем?Да на спец системах и 1 трлн опер в сек можнро добиться только они никому не нужны ни - кто эту прогу создаст?Дело в опимизации - при низком потреблении найти оптимальную производительность.Вы понимаете что значит под ету ерунду многоядерную интеловскую проги резать в миллионы строк каждую, прослеживать все зависымые блоки все вычисления ?.Думаете дальше 4 ядер уйдет дело?На ядра прогу резать не рыбу ловить .Да можно хоть 100 ядер сделать (уже делают) - но зачем , кто запрограммирует ЭТО? Есть закон адамаля - увлеичение числа ядер имеет свой предел - даже график есть.Дальше оптимизация - манипуляции с данными устоявшимися архитектурами.

Продать портативное не ARM не Cortex сложно я знаю - это действительно проблема.Но куда более сложно получить результат от проектов типа 80 ядерный процессор.К тому же изменение форматов инструкций предполагается минимальное.Их можно будет легко конвертировать.Были в свое время и куда более амбициозные проекты.

а чем эта идея лучше/отличается от SIMD (векторной обработки) - всяческих MMX/SSE AltiVec NEON и т.д. ?

кажется, что "разбивания" ядер возможно только на уровне датапасов - то есть в инструкции указывается как трактовать ну например 256 разрядное слово - 32 байта ... 4 дабла

ну а исполнения потоков (идея SPARC T1/T2) чтоб ядра не простаивали - в теории выглядит хорошо, а на практике не встречал (последняя станция с 1.5ГГц Sparc IIIi, которую "трогал" вживую, тормозила безбожно)

Это скорее похоже на MIMD-to-SIMD но в одной схеме.

Сообщение отредактировал Anticitizen1 - Mar 25 2010, 12:52