Jump to content

    

Recommended Posts

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

 

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

 

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

 

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

 

 

Пример вычислений где такая ядерность нужна:

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

 

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

Edited by Anticitizen1

Share this post


Link to post
Share on other sites

Это что, у Вас хобби такое, реконфигурируемые многоядерники сочинять?

Если это ОКР, то д.б. конкретное ТЗ.

Если Вы только сочиняете ТЗ, то успели ли задать себе вопросы типа "нахрена все это нужно?" и "кто за это готов заплатить?"

Если не успели, то поспешите, - ответы нынче суровые бывают... :)

 

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

 

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

Share this post


Link to post
Share on other sites

И не лишне будет подумать о том, как компилить подо все вот это?

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

 

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

Share this post


Link to post
Share on other sites

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

 

Если оставить в стороне вопрос производительности, для того чтобы изделие было конкурентно-способным, нужно

1) Поддержка софта - как минимум GCC+работоспособный Linux+основной софт. Для разваливающихся процессоров вы GCC допиливать будете годами.

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

 

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

 

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

Share this post


Link to post
Share on other sites
Это что, у Вас хобби такое, реконфигурируемые многоядерники сочинять?

Если это ОКР, то д.б. конкретное ТЗ.

Если Вы только сочиняете ТЗ, то успели ли задать себе вопросы типа "нахрена все это нужно?" и "кто за это готов заплатить?"

Если не успели, то поспешите, - ответы нынче суровые бывают... :)

 

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

 

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

 

Вы под реконфигурацией что понимаете переключение как у 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" здоровао сказано.))))

Edited by Anticitizen1

Share this post


Link to post
Share on other sites
Не... "банальность i7" здоровао сказано.))))

 

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

 

Теперь вы говорите про портативные устройства - причем тут тогда симуляция взрывов?

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites
Банальность 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 но в одной схеме.

Edited by Anticitizen1

Share this post


Link to post
Share on other sites
Дело в опимизации - при низком потреблении найти оптимальную производительность.

 

Воот. Тут мы приходим к вопросу, почему в коммуникаторы и прочие мобильные вещи ставят процессоры по 400-600Мгц, когда можно делать легко и 3Ггц с такой же площадью кристалла или поставить 2-х ядерный проц.

 

Энергопотребление. Для его снижения все пошли по пути специализированных сопроцессоров : дохлое CPU ядро + спец железо для распаковки видео (самая ресурсоемкая операция на мелких устройствах) + спец железо для 3D графики. Все, это конец - ускорять больше нечего, все операции выполняются в реальном времени с запасом, и более быстрое железо просто никому не нужно.

 

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

 

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

 

Да, с крутой архитектурой можно было бы обойтись центральным процессором на 200Мгц + спец сопроцессоры и получить чуть ниже потребление, но это будет сложная задача для маркетологов, убедить покупателей что эти 200Мгц жирнее чем 600 Мгц у конкурентов (как это было в своё время у AMD с их PR-рейтингом).

 

 

Fujitsu уже порвала в 2,5 раза превзойдя интеловский Nehalem (i7 в народе много ядерное чудище с 800 000 000 вентилей )

 

Я бы не назвал это "порвала". Обычный экстенсивный рост, в 2 раза больше ядер, в 2 раза площадь ядра (510 vs 263), в 10(а то и больше) раз выше цена :-)

 

Опять же, пишут что производительность 128млрд операций в секунду(непонятно каких и как измеренных), когда я чуть выше писал что i7 делает 160 single-precission или 80 dual-precission. Нет тут 2.5-кратного отрыва :-)

Share this post


Link to post
Share on other sites
Воот. Тут мы приходим к вопросу, почему в коммуникаторы и прочие мобильные вещи ставят процессоры по 400-600Мгц, когда можно делать легко и 3Ггц с такой же площадью кристалла или поставить 2-х ядерный проц.

 

Энергопотребление. Для его снижения все пошли по пути специализированных сопроцессоров : дохлое CPU ядро + спец железо для распаковки видео (самая ресурсоемкая операция на мелких устройствах) + спец железо для 3D графики. Все, это конец - ускорять больше нечего, все операции выполняются в реальном времени с запасом, и более быстрое железо просто никому не нужно.

 

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

 

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

 

Да, с крутой архитектурой можно было бы обойтись центральным процессором на 200Мгц + спец сопроцессоры и получить чуть ниже потребление, но это будет сложная задача для маркетологов, убедить покупателей что эти 200Мгц жирнее чем 600 Мгц у конкурентов (как это было в своё время у AMD с их PR-рейтингом).

 

 

 

 

Я бы не назвал это "порвала". Обычный экстенсивный рост, в 2 раза больше ядер, в 2 раза площадь ядра (510 vs 263), в 10(а то и больше) раз выше цена :-)

 

Опять же, пишут что производительность 128млрд операций в секунду(непонятно каких и как измеренных), когда я чуть выше писал что i7 делает 160 single-precission или 80 dual-precission. Нет тут 2.5-кратного отрыва :-)

 

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

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

 

Итак понятно что герцы низки для энергопотребления но не только число вентилей снижает герцы , ассиметрия архитектуры снижает - схема всегда дожидается самого медленного элемента (герцы это и есть частота самомого медленного простым языком).Выч блок (ALU точно,FPU не уверен)вообще можно до 5-6 ггц разогнать .Да я думаю для оптимизации есть пути.Интеловская архитектура это одна из тысяч выбранных и доведенных до рынка.Посмотрите сколько в интеле выч блоков - меньше или около процента от площади кристалла (мои оценки хотя) - все остальное кэш и всякие контроллеры(устр) работы с памятью.Но ведь проц изначально был выч логич устройством а не центром распределения ресурсов.

 

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

 

Мой проект нацелен на другое облегчение задч распарралеливания и желанием впихнуть в один кристал более универсальное усройство .Вы не обращали внимание чем видеокарта от процессора отличается?Кроме герц.

 

 

Под операциями понимаются операции над вещественными числами обычно.Да они не сообщили более точные данные но И uLTRA SPARC T2 ВСЕХ ДЕЛАЛ ДО ЭТОГО.Число вентилей у ultraspac t2 подобных 500млн вентилей у i7 800 млн.хотя ядер да согласен больше.Но они по другому работают принципу.

Share this post


Link to post
Share on other sites

Вобщем, не стану разводить тут троллоло :-)

Если бы у меня были лишние 20-100 млн $, я может быть тоже сделал какой-нить новый процессор с прорывной архитектурой, завидую я вам.

Share this post


Link to post
Share on other sites

Блин, какой же хренью люди мучают свои слабые мозги.

Вместо того, чтобы хотя бы научиться внятно излагать свои мысли и писать без ошибок.

Бросить всё, и в Урюпинск? :rolleyes:

Share this post


Link to post
Share on other sites
Блин, какой же хренью люди мучают свои слабые мозги.

Вместо того, чтобы хотя бы научиться внятно излагать свои мысли и писать без ошибок.

Бросить всё, и в Урюпинск? :rolleyes:

Что же мешает?Или не дает покоя желание научить мир жить.А то как же без вас?

Для меня важно научиться правильно и быстро отвечать на все возможные вопросы.А их будет много.

Edited by Anticitizen1

Share this post


Link to post
Share on other sites
Что же мешает?Или не дает покоя желание научить мир жить.А то как же без вас?

Судя по теме как раз вам и не дает. Без обид пожалуйста, просто вся рота не в ногу, один старшина в ногу.

 

Но все же, попробуйте дать более менее развернутый ответ на вопрос о программировании такого процессора. Вы же прекрасно понимаете что архитектура x86 жива и да здравствует за счет богатого программного прошлого. И для успешного применения вашего процессора нужно предложить маршрут перевода программ (читай компилятор), а, насколько я знаю, gcc фокусов с изменяемой разрядностью делать не умеет. А то так и получится: железо сделаем самое крутое на свете, а применить его не получится.

 

А если мучает несогласованнось конвеера с современных процессорах

Итак понятно что герцы низки для энергопотребления но не только число вентилей снижает герцы , ассиметрия архитектуры снижает - схема всегда дожидается самого медленного элемента (герцы это и есть частота самомого медленного простым языком).Выч блок (ALU точно,FPU не уверен)вообще можно до 5-6 ггц разогнать

то посмотрите в сторону самосинхронных схем.

Share this post


Link to post
Share on other sites
Что же мешает?Или не дает покоя желание научить мир жить.А то как же без вас?
Да, без нас никак. По меньшей мере, такие заявления, типа
Начал проект по разработке схемы с плавающей ядерностью то есть ядра...
"сечем на раз". И пытаемся помочь "фантастам" сберечь мозг для более приземленных задачек, которые были бы им по силам.

 

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

Хотя, если Вы действительно способны на

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

(в смысле, способны финансово, в первую очередь), то вряд ли кто-то сможет Вам помешать потратить несколько лимонов бяксов. Или десятков лимонов. Дело-то хозяйское.

 

Вы не обижайтесь, Вам тут не враги-ренегаты письма пишут.

Просто, Вы явно не смогли оценить свои возможности, энтузиазм вызывает литровые выбросы адреналина. Подумайте над вопросами, ответы на которые Вы должны знать точно перед началом столь длинного пути (см. пост 2).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this