Я пишу суперскалярный процессор на языке verilog. Решился выпустить старую версию кода под лицензией GPL v2. Если хотите, можете поддержать.
Старая версия может выполнять до 6 инструкций за такт, имеетса вне-очередное выполнение с полу-раздельными диспечерами (по одному на 2 инструкции).
Пока работает только ALU и переходы, нет инструкций памяти, но есть порты для памяти на диспечерах.
https://www.kickstarter.com/projects/678823173/heptane-cpu-old-version-release-as-gpl
Горан,
а почему выбрана система команд от x86/64 (как я понимаю, с внутренней трансляцией в "родную" RISC)?
Вообще-то, процессор будет поддерживать и свою RISC систему комманд, и x86/64 через трансляцию. Ето потому, что под x86/64 много софтуера. Разумеетса, x86/64 будет работать медленнее чем нативная система комманд. Своя архитектура такая, что при трасляции не надо жонглировать флагами.
Понятно.
То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?
В планах развивать старый, у которого до 6 инструкций за такт или тот, у которого до 9?
Я, конечно, не всё знаю - но может быть вместо встроенной в чип динамической трансляции было бы лучше написать, помимо статического двоичного транслятора, скажем, бэкенд для LLVM (http://llvm.org/docs/WritingAnLLVMBackend.html), чтобы в итоге под Heptane компилировались исходники C/C++ (и какие там ещё языки под LLVM есть), а не только готовые x86/64? Просто их промежуточный язык (LLVM IR) аналогичен ассемблеру, по сути это [строго типизированный] RISC. :)
Ну еще есть планы на порт GCC или LLVM, но я не знаю насколько ето сложно. Наверно не так уж, если взять за основу какойто другой RISC процессор. Правда FPU я планирую довольно необычный, чтоб изпользовать все возможности надо будет много мучитьса с GCC. работа идет над 9. должен работать на 45нм и меньше.
А есть какие-нибудь подробности о новом варианте процессора (9-issue)? Как я понимаю, 9 - это пиковое значение IPC... И ещё: сколько стадий у нового конвейера?
Цитироватьsvmich пишет:
То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?
В планах развивать старый, у которого до 6 инструкций за такт или тот, у которого до 9?
Что-то мне это сильно напоминает. Предлагаю название - Арарат.
ps: хотя само начинание вполне благое. Разве что с верификацией вопросы.
Ну вообще-то свобождать старую версию пока отказался. По новой версии есть сайт. http://www.heptane.co.uk
Там есть диаграма integer back-end.
Стадий 10, цена перехода при простом сложении или вычитании гдето 13-14, если посложнее - может быть гораздо больше.
Нащет верификации - можно было бы разделить на несколько FPGA когда будет работать, но такие платы стоят очень дорого.
А сколько логических элементов оно примерно стоит?
Елементов не так много, старая версия была гдето 120000. Но ето только синтез. Беда в том, что реестры с многими портами и диспечеры жрут много провода, и ето ведет к тому что нельзя упользотворить все логические елементы. Ну, в принцыпе, если сделать с менше портов и делать переклююение по времени (т е один логический цыкл - несколько физических), тогда может и войдет в один high-end FPGA. Только без последнего уровня кеша, конечно. Ну тогда надо будет отдельно тестировать диспечеры и реестры. И конечно нельзя будет отладит последний уровень кеша и многоядерность.
Забыл посмотреть на параметры софременных FPGA. Похоже, что уже и два ядра может быть вместятса на одну.
http://www.xilinx.com/support/documentation/selection-guides/ultrascale-fpga-product-selection-guide.pdf#VU
xvcu190 Наверно хватит и на двух ядерный с кешем.
Интересно, конечно... Но хоть основное бы узнать. Архитектура набора команд (ISA) у нового процессора - регистр-регистр? Все регистры - общего назначения? Что такое AGU? Какая разрядность по адресу и данным? Переключение между двумя нитями не подорвёт эффективность кэша? Какая организация и размер кэша данных первого уровня?
Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти.
Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.
а причем здесь новости космонавтики ?
Цитироватьgoran d пишет:
Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти.
Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.
Т.е. при чтении из DRAM сохраняется контекст блокированной нити и загружается контекст для другой? А сколько конвейеров (ядер)?
Кэш данных L1, как я понимаю, 4К * 8 * 64 бит?
ЦитироватьAlfred пишет:
а причем здесь новости космонавтики ?
Центральный компонент современной системы управления ступенью ракеты-носителя или космического аппарата.
Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре. Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный. :(
Цитироватьgoran d пишет:
Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре. Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный. :(
Для начала пойдёт. А вообще - зачем двоичная совместимость с x86, почему компиляции мало? Т.е. ради чего так "связывать себе руки"?
del
Отказался от RISV. Оказываетса, переделавать x86_64 target для gcc не так уж и сложно. Уже добился отсуствия операндов с памятью для сложения.
дел
А в чем собственно новизна проекта ?
Чуть больше конвейеров... чуть больше инструкций исполняемых за такт ...
Экстнесив !
Мне кажется будущее за чипами с изменяемой архитектурой !
Лет десять назад читал о проекте финской команды пилившей современную видео карту на "программируемый логике" (не знаю что у них в результате получилось но чисто технических проблем вроде у них не было )...
Еще читал о гибридном чипе российской разработки переключающегося из обычного "процессорного режима" в режим аппаратной эмуляции нейросетей ...
(Кажется 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
А вот это в принципе не новость, но..представьте стандартное ПО такого рода, доступное под любые ПК и ОС для решения не графических задач - не правда ли, многим хозяевам рынка это не понравится..
ЦитироватьКубик пишет:
стандартное ПО такого рода, доступное под любые ПК и ОС для решения не графических задач
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 все может быть гораздо веселее )
ЦитироватьАлексей Кириенко пишет:
Интересно, а неросети с применениемGPU строить можно ?
Можно.
ЦитироватьАлексей Кириенко пишет:
Интересно, а неросети с применением GPU строить можно ? (Главное узкое место в моделях нейросетей в невозможности эмулировать реальный параллелизм для каждого нейрона, а с "виртуальными вычислительными боками" современных GPU все может быть гораздо веселее )
Можно, и строят, причем весьма эффективные. Фокус в том, чтобы выбирать минимальную разрядность чисел: восьми или даже четырех разрядов обычно достаточно для весовой функции "нейрона". На такой разрядности GPU дают максимальную производительность.
ЦитироватьNot пишет:
ЦитироватьАлексей Кириенко пишет:
Интересно, а неросети с применением GPU строить можно ? (Главное узкое место в моделях нейросетей в невозможности эмулировать реальный параллелизм для каждого нейрона, а с "виртуальными вычислительными боками" современных GPU все может быть гораздо веселее )
Можно, и строят, причем весьма эффективные. Фокус в том, чтобы выбирать минимальную разрядность чисел: восьми или даже четырех разрядов обычно достаточно для весовой функции "нейрона". На такой разрядности GPU дают максимальную производительность.
Никак не оспаривая применимость и эффективность GPU для нейросетей...
Всё-таки 4 разряда - это должна быть какая-то очень специфичная сеть. Не представляю себе практической задачи, где этого было бы достаточно.
ЦитироватьТатарин пишет:
Всё-таки 4 разряда - это должна быть какая-то очень специфичная сеть. Не представляю себе практической задачи, где этого было бы достаточно.
Достаточно для сетей применяемых в Deep Learning. Например здесь (https://arxiv.org/pdf/1201.6255.pdf).
высокоуровневые языки для работы с GPU позволяют эффективно работать с полубайтовыми коэффициентами? Скажем даже шире - с менее, чем четверьтьрегистрами?
Цитироватьdmdimon пишет:
высокоуровневые языки для работы с GPU позволяют эффективно работать с полубайтовыми коэффициентами?
Зачем если однобайтовые то-же канают?
так вот же выше - 4 разряда типа для эффективности?
off/ я просто кой-чего оптимизировал под GPU и все оказалось очень нетривиально. В разы буквально зависимо от оптимизации под абсолютно конкретное железо - количество вычислительных ядер, ширина шины, размеры очередей, организация памяти, задержки, накладные расходы - в общем, полная опа. И вот неаккуратная работа с разрядностью памяти и шины - была просто атас как заметна.
Разрядность для неросети вообще-то не очень актуальна ... Её относительно легко можно подкрутить увеличением числа входов упростив вплоть до "однобитовых нейрон" ... А там все же аж 4 бита и каждое "виртуальное ядро"(как я понял вычислительный блоки в современном GPU могут иметь довольно непрямое отношение к ядрам физическим ) может "чуть" по больше чем отдельно взятый "искусственный нейрон" . (То есть может эмулировать целый небольшой кластер нейросети ).
не вопрос. Я говорю о том, что (из моего опыта) при нехорошей разрядности данных производительность падает в разы, а выше написано, что 4 бита - для производительности. Меня это сильно смущает.
Цитироватьdmdimon пишет:
не вопрос. Я говорю о том, что (из моего опыта) при нехорошей разрядности данных производительность падает в разы, а выше написано, что 4 бита - для производительности. Меня это сильно смущает.
Все верно, использование битовых операций "в лоб" ухудшает производительность, поэтому для числа бит меньше чем 32 используют упаковку двух и более чисел в одно. Очевидно, что программирование усложняется, но производительность при этом растет линейно от количества упакованных чисел.
/offtop это само собой. Но в данном конкретном случае упаковать предлагается мультипликативные коэффициенты. Плюс писать все-таки желательно не на асме - иначе и так призрачная аппаратная независимость прикажет долго жить... Имхо результирующий гимор себя не оправдает. Но сугубое имхо.
фокус в специальных оптимизациях, например в запутывании (http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter35.html):
Цитировать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)