Мой процессор

[goran d]

Я пишу суперскалярный процессор на языке verilog.  Решился выпустить старую версию кода под лицензией GPL v2. Если хотите, можете поддержать.

Старая версия может выполнять до 6 инструкций за такт, имеетса вне-очередное выполнение с полу-раздельными диспечерами (по одному на 2 инструкции).
Пока работает только ALU и переходы, нет инструкций памяти, но есть порты для памяти на диспечерах.

https://www.kickstarter.com/projects/678823173/heptane-cpu-old-version-release-as-gpl

[svmich]

Горан,
а почему выбрана система команд от x86/64 (как я понимаю, с внутренней трансляцией в "родную" RISC)?

[goran d]

Вообще-то, процессор будет поддерживать и свою RISC систему комманд, и x86/64 через трансляцию. Ето потому, что под x86/64 много софтуера. Разумеетса, x86/64 будет работать медленнее чем нативная система комманд. Своя архитектура такая, что при трасляции не надо жонглировать флагами.

[svmich]

Понятно.
То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?

В планах развивать старый, у которого до 6 инструкций за такт или тот, у которого до 9?

Я, конечно, не всё знаю - но может быть вместо встроенной в чип динамической трансляции было бы лучше написать, помимо статического двоичного транслятора, скажем, бэкенд для LLVM, чтобы в итоге под Heptane компилировались исходники C/C++ (и какие там ещё языки под LLVM есть), а не только готовые x86/64? Просто их промежуточный язык (LLVM IR) аналогичен ассемблеру, по сути это [строго типизированный] RISC. 

[goran d]

Ну еще есть планы на порт GCC или LLVM,  но я не знаю насколько ето сложно. Наверно не так уж, если взять за основу какойто другой RISC процессор. Правда FPU я планирую довольно необычный, чтоб изпользовать все возможности надо будет много мучитьса с GCC. работа идет над 9. должен работать на 45нм и меньше.

[svmich]

А есть какие-нибудь подробности о новом варианте процессора (9-issue)? Как я понимаю, 9 - это пиковое значение IPC... И ещё: сколько стадий у нового конвейера?

[Theoristos]

svmich пишет:
То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?

В планах развивать старый, у которого до 6 инструкций за такт или тот, у которого до 9?

Что-то мне это сильно напоминает. Предлагаю название - Арарат.

ps: хотя само начинание вполне благое. Разве что с верификацией вопросы.

[goran d]

Ну вообще-то свобождать старую версию пока отказался. По новой версии есть сайт. http://www.heptane.co.uk
Там есть диаграма integer back-end.
Стадий 10, цена перехода при простом сложении или вычитании гдето 13-14, если посложнее - может быть гораздо больше.
Нащет верификации - можно было бы разделить на несколько FPGA когда будет работать, но такие платы стоят очень дорого.

[Theoristos]

А сколько логических элементов оно примерно стоит?

[goran d]

Елементов не так много, старая версия была гдето 120000. Но ето только синтез. Беда в том, что реестры с многими портами и диспечеры жрут много провода, и ето ведет к тому что нельзя упользотворить все логические елементы. Ну, в принцыпе, если сделать с менше портов и делать переклююение по времени (т е один логический цыкл - несколько физических), тогда может и войдет в один high-end FPGA. Только без последнего уровня кеша, конечно. Ну тогда надо будет отдельно тестировать диспечеры и реестры. И конечно нельзя будет отладит последний уровень кеша и многоядерность.

[goran d]

Забыл посмотреть на параметры софременных FPGA. Похоже, что уже и два ядра может быть вместятса на одну.
http://www.xilinx.com/support/documentation/selection-guides/ultrascale-fpga-product-selection-guide.pdf#VU

xvcu190 Наверно хватит и на двух ядерный с кешем.

[svmich]

Интересно, конечно... Но хоть основное бы узнать. Архитектура набора команд (ISA) у нового процессора - регистр-регистр? Все регистры - общего назначения? Что такое AGU? Какая разрядность по адресу и данным? Переключение между двумя нитями не подорвёт эффективность кэша? Какая организация и размер кэша данных первого уровня?

[goran d]

Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти.
Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.

[Alfred]

а причем здесь новости космонавтики ?

[svmich]

goran d пишет:
Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти.
Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.

Т.е. при чтении из DRAM сохраняется контекст блокированной нити и загружается контекст для другой? А сколько конвейеров (ядер)?
Кэш данных L1, как я понимаю, 4К * 8 * 64 бит?

Alfred пишет:
а причем здесь новости космонавтики ?

Центральный компонент современной системы управления ступенью ракеты-носителя или космического аппарата.

[goran d]

Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре.  Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный.

[svmich]

goran d пишет:
Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре. Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный.  

Для начала пойдёт. А вообще - зачем двоичная совместимость с x86, почему компиляции мало? Т.е. ради чего так "связывать себе руки"?

[goran d]

del

[goran d]

Отказался от RISV. Оказываетса, переделавать x86_64 target для gcc не так уж и сложно. Уже добился отсуствия операндов с памятью для сложения.

[goran d]

дел

[Алексей Кириенко]

А в чем собственно новизна проекта ?
Чуть больше конвейеров... чуть больше инструкций  исполняемых за такт ...
Экстнесив !

Мне кажется будущее   за чипами с изменяемой архитектурой !

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

Еще читал о гибридном чипе российской разработки переключающегося из обычного "процессорного режима"  в режим аппаратной эмуляции нейросетей  ...
(Кажется NeuroMatrix http://studopedia.ru/3_174439_neyroprotsessor-NeuroMatrix-NM.html
                       http://www.pcweek.ru/pc/article/detail.php?ID=56946)

То есть   технология изменяемой архитектуры уже реально применяется . И я думаю именно за ней будущее !

[Кубик]

http://vistanews.ru/science/63101  ,  http://ria.ru/science/20160628/1453742744.html
А вот это в принципе не новость, но..представьте стандартное ПО такого рода, доступное под любые ПК и ОС для решения не графических задач - не правда ли, многим хозяевам рынка это не понравится..

[Kap]

Кубик пишет:
стандартное ПО такого рода, доступное под любые ПК и ОС для решения не графических задач

CUDA.

[Алексей Кириенко]

Кубик пишет:

http://vistanews.ru/science/63101 , http://ria.ru/science/20160628/1453742744.html
А вот это в принципе не новость, но..представьте стандартное ПО такого рода, доступное под любые ПК и ОС для решения не графических задач - не правда ли, многим хозяевам рынка это не понравится..

http://www.nvidia.ru/object/cuda-parallel-computing-ru.html

Увы, далеко не все расчеты можно ускорить подобным образом .... но всевозможное моделирование вполне потянет да и просто разрядность шины с частотами памяти в GPU разумеется опережает обычные CPU   ...
GPU
Интересно, а неросети с применением  GPU строить можно ? (Главное узкое место в моделях нейросетей в невозможности эмулировать реальный параллелизм для каждого нейрона, а с "виртуальными вычислительными боками" современных GPU  все может быть гораздо веселее   )

[Kap]

Алексей Кириенко пишет:
Интересно, а неросети с применениемGPU строить можно ?

Можно.

[Not]

Алексей Кириенко пишет:

Интересно, а неросети с применением GPU строить можно ? (Главное узкое место в моделях нейросетей в невозможности эмулировать реальный параллелизм для каждого нейрона, а с "виртуальными вычислительными боками" современных GPU все может быть гораздо веселее )

Можно, и строят, причем весьма эффективные. Фокус в том, чтобы выбирать минимальную разрядность чисел: восьми или даже четырех разрядов обычно достаточно для весовой функции "нейрона". На такой разрядности GPU дают максимальную производительность.

[Татарин]

Not пишет:

Алексей Кириенко пишет:

Интересно, а неросети с применением GPU строить можно ? (Главное узкое место в моделях нейросетей в невозможности эмулировать реальный параллелизм для каждого нейрона, а с "виртуальными вычислительными боками" современных GPU все может быть гораздо веселее )

Можно, и строят, причем весьма эффективные. Фокус в том, чтобы выбирать минимальную разрядность чисел: восьми или даже четырех разрядов обычно достаточно для весовой функции "нейрона". На такой разрядности GPU дают максимальную производительность.

Никак не оспаривая применимость и эффективность GPU для нейросетей... 
Всё-таки 4 разряда - это должна быть какая-то очень специфичная сеть. Не представляю себе практической задачи, где этого было бы достаточно.

[Not]

Татарин пишет:
Всё-таки 4 разряда - это должна быть какая-то очень специфичная сеть. Не представляю себе практической задачи, где этого было бы достаточно.

Достаточно для сетей применяемых в Deep Learning. Например здесь.

[dmdimon]

высокоуровневые языки для работы с GPU позволяют эффективно работать с полубайтовыми коэффициентами? Скажем даже шире - с менее, чем четверьтьрегистрами?

[Kap]

dmdimon пишет:
высокоуровневые языки для работы с GPU позволяют эффективно работать с полубайтовыми коэффициентами?

Зачем если однобайтовые то-же канают?

[dmdimon]

так вот же выше - 4 разряда типа для эффективности?


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

[Алексей Кириенко]

Разрядность для неросети вообще-то  не очень актуальна ... Её относительно легко можно подкрутить увеличением числа входов упростив  вплоть до "однобитовых нейрон" ...  А там все же  аж 4 бита и каждое "виртуальное ядро"(как я понял вычислительный блоки в современном GPU могут иметь  довольно непрямое отношение к ядрам физическим  ) может "чуть" по больше чем отдельно  взятый "искусственный нейрон" . (То есть может эмулировать целый небольшой кластер нейросети ).

[dmdimon]

не вопрос. Я говорю о том, что (из моего опыта) при нехорошей разрядности данных производительность падает в разы,  а выше написано, что 4 бита - для производительности. Меня это сильно смущает.

[Not]

dmdimon пишет:
не вопрос. Я говорю о том, что (из моего опыта) при нехорошей разрядности данных производительность падает в разы, а выше написано, что 4 бита - для производительности. Меня это сильно смущает.

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

[dmdimon]

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

[Not]

фокус в специальных оптимизациях, например в запутывании:

35.2.4 The Swizzle Operator
An easily overlooked or underutilized feature of GPU programming is the swizzle operator. Because all registers on the GPU are four-vectors but not all instructions take four-vectors as arguments, some mechanism for creating other-sized vectors out of these four-vector registers is necessary. The swizzle operator provides this functionality. It is syntactically similar to the C concept of a structure member access but has the additional interesting property that data members can be rearranged, duplicated, or omitted in arbitrary combinations, as shown in the following example:
 
float4 f = float4(1.0f, 2.0f, 3.0f, 4.0f);
float4 g = float4(5.0f, 6.0f, 7.0f, 8.0f);
float4 h = float4(0.1f, 0.2f, 0.3f, 0.4f);// note that h.w is syntactically equivalent to h.wwww
float4 out = f.xyyz * g.wyxz + h.w; // одна инструкция!
// multiply-and-accumulate again.
// result: out is (8.4f, 12.4f, 10.4f, 21.4f)