The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Представлен 8-ядерный отечественный микропроцессор Эльбрус-8С, opennews (ok), 02-Июл-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


10. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +3 +/
Сообщение от вои и аноним подкрался (?), 02-Июл-14, 18:37 
там архитектура wliv . так что нет производительность там точно не маленькая. да и что все уперлись в эти интелл, они уперлись в предел разгона процев и их сегодняшние процы это почти что предел как по тактовой частоте, так и по чисто предел минимизации чипов( нанометры). там действительно именно то что говорят. вот только производительность может и отличаться. он действительно по некоторым типам вычислений может отставать, а по другим наоборот сильно превосходить. при этом есть еще большой запас по производительности как в разгоне , так и в производительности самой платформы. жаль только что это пока не для всех. ну хотя бы обеспечить нацбезопасность и то хорошо.
Ответить | Правка | Наверх | Cообщить модератору

17. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  –2 +/
Сообщение от SunXE (ok), 02-Июл-14, 18:45 
Вот и я говорю, нужно на IBM Power8 ориентироваться)
Ответить | Правка | Наверх | Cообщить модератору

19. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от вои и аноним подкрался (?), 02-Июл-14, 18:49 
не power7 это  risc вроде а тут wliv. разница существенная. у риск короткое командное слово а у влив наоборот длинное. не уверен на счет риск, а вот влив это точно что там длинное командное слово. так что я даже не знаю с чем этот проц сравнивать.
Ответить | Правка | Наверх | Cообщить модератору

33. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +3 +/
Сообщение от Archer73 (ok), 02-Июл-14, 19:26 
С Itanium и ATI R600. Оба в итоге стали тупиковой ветвью развития. Архитектура VLIW предъявляет слишком высокие требования к качеству оптимизации компилятора.
Ответить | Правка | Наверх | Cообщить модератору

36. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от вои и аноним подкрался (?), 02-Июл-14, 19:35 
тупиковой они стали не потому что архитектура не работала, а потому что программных продуктов не было. а наши позаботились об этом. есть линукс и есть поддержка трансляции х86 в архитектуру эльбрус. при этом падение производительности где то 20%. помоему это уже довольно неплохо и продвинуто. я тут читал по их системам статью . так вот они когда взялись разрабатывать архитектуру об этом в первую очередь и задумались. так что все не та как с итаниум.
Ответить | Правка | Наверх | Cообщить модератору

43. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от rob pike (?), 02-Июл-14, 19:44 
> а потому что программных продуктов не было

Было. Только тормозное. Про оптимизацию и компиляторы товарищ выше всё верно изложил.

Ответить | Правка | Наверх | Cообщить модератору

135. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от Анонимemail (133), 03-Июл-14, 09:10 
>> а потому что программных продуктов не было
> Было. Только тормозное. Про оптимизацию и компиляторы товарищ выше всё верно изложил.

Ну так компиляторы есть куда развивать, а вот частоту x86 уже некуда

Ответить | Правка | Наверх | Cообщить модератору

143. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  –1 +/
Сообщение от rob pike (?), 03-Июл-14, 09:55 
> Ну так компиляторы есть куда развивать, а вот частоту x86 уже некуда

Теория и практика совпадают в теории, но различаются на практике.
Сравните насколько за последние 5-10 лет выросла производительность x86 с той же частотой и насколько - эффективность кодогенераторов современных компиляторов.

Ответить | Правка | Наверх | Cообщить модератору

236. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 03-Июл-14, 21:46 
>> Ну так компиляторы есть куда развивать, а вот частоту x86 уже некуда
> Теория и практика совпадают в теории, но различаются на практике.
> Сравните насколько за последние 5-10 лет выросла производительность x86 с той же
> частотой и насколько - эффективность кодогенераторов современных компиляторов.

если теория не подтверждается практикой, то теория эта ложная
исключительная очевидность

Ответить | Правка | Наверх | Cообщить модератору

296. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от Аноним (-), 05-Июл-14, 02:45 
> если теория не подтверждается практикой, то теория эта ложная
> исключительная очевидность

Исключительно самоуверенная неграмотность.

Бозон Хиггса искали с 64 года, может и не надо было? Не смогли сразу же найти, значит теория о его существовании ложная, так получается?
Теории часто появляются задолго до их подтверждения практикой. Если их все сразу записывать в ложные только потому, что они еще не подтверждены, то и подтверждения "ложных" теорий искать смысла нет, и где была бы сейчас наука.

Ответить | Правка | Наверх | Cообщить модератору

332. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Michael Shigorinemail (ok), 30-Ноя-18, 12:57 
>> Ну так компиляторы есть куда развивать, а вот частоту x86 уже некуда
> Теория и практика совпадают в теории, но различаются на практике.
> Сравните насколько за последние 5-10 лет выросла производительность x86 с той же
> частотой и насколько - эффективность кодогенераторов современных компиляторов.

Теоретик Вы всё же, зря Пайка будили.  И обобщаете избыточно.

По e2k на сейчас есть приличный запас роста как по железу (техпроцесс, вылизывание физраскладки кэша), так и по софту.

На _практике_ lcc 1.21 заметно -- на десятки процентов по моим наблюдениям над десктопным Э-401 -- прибавил относительно 1.20; сейчас перебираемся на 1.23, коллеги из МЦСТ говорят, что опять плотней оптимизировать стал; и на 1.24 виды уже тоже хорошие.

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

Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

331. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Michael Shigorinemail (ok), 30-Ноя-18, 12:53 
>> а потому что программных продуктов не было

Ещё потому, что винды не было.  Точнее, критичных кусков вроде драйверов печати.

> Было. Только тормозное. Про оптимизацию и компиляторы товарищ выше всё верно изложил.

Ну не шмогли у интела, бывает (disclaimer: общался с разработчиками как icc/ia64 -- нижегородскими -- так и lcc/e2k).

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

71. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +3 +/
Сообщение от Аноним (-), 02-Июл-14, 23:03 
> тупиковой они стали не потому что архитектура не работала, а потому что
> программных продуктов не было. а наши позаботились об этом. есть линукс

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

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

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

81. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от Orduemail (ok), 02-Июл-14, 23:20 
> Исторически это загнуло и итаника (плохая производительность по конской цене) и R600,
> которых заменили на GCN, где, грубо говоря, донавесили нечто типа планировщика и что там
> еще, так что к компилеру требования несколько ниже стали как раз.

Разрешите поинтересоваться в целях повышения образованности (c)

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

Ответить | Правка | Наверх | Cообщить модератору

83. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +2 +/
Сообщение от Аноним (-), 02-Июл-14, 23:32 
> А что мешает этот планировщик привесить к компилятору, в качестве завершающей фазы
> оптимизации, проводимой после этапа кодогенерации?

Теоретически - ничего! Даже можно как бы лучше сделать - в софт можно более сложные алгоритмы оптимизации запихать, которые в железо пихать обломно.

Практически - в этом мире есть несколько выводков компиляторов. Они проектировались и делались давно. Поэтому про VLIW они знают чуть менее чем ничего. Особенно эпичен тут продолб LLVM - супер-пупер архитектура делалась не так давно. Но про VLIW почему-то тоже ничего не знает. Хотя имели все шансы учесть. Но видимо рассказывать форумными эпплоботами про крутую архитектуру LLVM проще чем нанять вменяемого архитекта в проект.

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

На примере амд: они 2 года долблись чтобы просто выжать валидную кодогенерацию для своих VLIW из LLVMного гуано. После двух лет долботни оно наконец смогло генерит шейдеры ... лишь немного тормознее чем самопальный кодогенератор, который написали сто лет назад а про оптимизацию никто и не задумывался даже. И после этого там море глюков в этом LLVM. По сей день. В аллокации регистров оно обсиpaется постоянно. Оптимальность кода - ниже всякой критики. Оно вообще понятия не имеет о такой фигне как взаимозависимости команд. Поэтому LLVM выдает что может, а отдельная фаза за ним - костылирует код, переставляя команды, до состояния когда поток станет хотя-бы технически-валидным (т.е. учитывающим взаимозависимости как указано в спеках).

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

Ответить | Правка | Наверх | Cообщить модератору

89. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от rob pike (?), 02-Июл-14, 23:42 
> LLVM - супер-пупер архитектура делалась не так давно. Но про VLIW почему-то тоже ничего не знает

Особое удивление вызывают софтоваятели из AMD, которые взялись лабать прогрессивный варез для R600 и ВНЕЗАПНО обнаружили этот факт. Но не сразу. Но и это их не поколебало в их прогрессивности.

Ответить | Правка | Наверх | Cообщить модератору

111. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от Аноним (-), 03-Июл-14, 02:43 
> для R600 и ВНЕЗАПНО обнаружили этот факт. Но не сразу. Но
> и это их не поколебало в их прогрессивности.

Им "внезапно" эту мысль высказал Vadim Girlin, повертев пальцем у виска и сообщив что 2 гоад въе без user-visible результата и с существенным усложнением/подъемом порога вхождения (LLVM в отличие от местечкового кодогенератора сложный) - как-то не особо эпичный результат. Впрочем, перец не растерялся и сделал универсальный бэкэнд оптимизатора который код оптимизит что после самопала, что после LLVM. Профит в обоих случаях.

А за LLVM - желание поддерживать OpenCL, самолично писать почти полный парсер си их не улыбает. А интел таки пишет beignet сам. И вообще, разработчики из интела очень невысокого мнения насчет LLVM. Они несколько раз рассматривали оный и всегда оказывалось что это настолько сложно и геморно что проще самим сделать.

Ответить | Правка | Наверх | Cообщить модератору

139. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +2 +/
Сообщение от Анонимemail (133), 03-Июл-14, 09:14 
> А за LLVM - желание поддерживать OpenCL, самолично писать почти полный парсер
> си их не улыбает. А интел таки пишет beignet сам. И
> вообще, разработчики из интела очень невысокого мнения насчет LLVM. Они несколько
> раз рассматривали оный и всегда оказывалось что это настолько сложно и
> геморно что проще самим сделать.

Практически всё что делается под одну конкретную задачу при наличии ресурсов проще сделать самим.

Ответить | Правка | Наверх | Cообщить модератору

153. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 03-Июл-14, 11:01 
>> А за LLVM - желание поддерживать OpenCL, самолично писать почти полный парсер
>> си их не улыбает. А интел таки пишет beignet сам. И
>> вообще, разработчики из интела очень невысокого мнения насчет LLVM. Они несколько
>> раз рассматривали оный и всегда оказывалось что это настолько сложно и
>> геморно что проще самим сделать.
> Практически всё что делается под одну конкретную задачу при наличии ресурсов проще
> сделать самим.

Валяй. Жги. Много саксесс сториз?

Ответить | Правка | Наверх | Cообщить модератору

261. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 04-Июл-14, 05:59 
> Валяй. Жги. Много саксесс сториз?

Интел как-то так и делает. Получая довольно хороший результат (выжимая из довольно деpьмoвенького GPU по максимуму).

Ответить | Правка | Наверх | Cообщить модератору

239. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от defcewfde (?), 03-Июл-14, 22:57 
> А интел таки пишет beignet сам. И вообще, разработчики из интела очень невысокого мнения насчет LLVM. Они несколько  раз рассматривали оный и всегда оказывалось что это настолько сложно и геморно что проще самим сделать.

http://www.freedesktop.org/wiki/Software/Beignet/
Beignet is an open source implementation of the OpenCL specification - a generic compute oriented API.
Note that the compiler depends on LLVM (Low-Level Virtual Machine project). Right now, the code has been compiled with LLVM 3.3/3.4. It will not compile with anything older.

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

262. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 04-Июл-14, 06:02 
> Note that the compiler depends on LLVM (Low-Level Virtual Machine project). Right
> now, the code has been compiled with LLVM 3.3/3.4. It will

Хз что они под этим имеют в виду, но в зависимостях beignet нет LLVM и они сами же и говорили что используют местечковый кодогенератор, т.к. все попытки использовать LLVM приводили к большим граблям.


Ответить | Правка | Наверх | Cообщить модератору

294. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от екпекп (?), 05-Июл-14, 02:05 
> Хз что они под этим имеют в виду, но в зависимостях beignet нет LLVM

Environment variables are used all over the code. Most important ones are:
OCL_OUTPUT_GEN_IR (0 or 1). Output Gen IR (scalar intermediate representation) code
OCL_OUTPUT_LLVM (0 or 1). Output LLVM code after the lowering passes
OCL_OUTPUT_LLVM_BEFORE_EXTRA_PASS (0 or 1). Output LLVM code before the lowering passes

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

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

VLIW Packetizer
In a Very Long Instruction Word (VLIW) architecture, the compiler is responsible for mapping instructions to functional-units available on the architecture. To that end, the compiler creates groups of instructions called packets or bundles. The VLIW packetizer in LLVM is a target-independent mechanism to enable the packetization of machine instructions.

вот и нвидия тоже свой бэкэнд к ллвм написала и что?

The NVPTX code generator under lib/Target/NVPTX is an open-source version of the NVIDIA NVPTX code generator for LLVM. It is contributed by NVIDIA and is a port of the code generator used in the CUDA compiler (nvcc). It targets the PTX 3.0/3.1 ISA and can target any compute capability greater than or equal to 2.0 (Fermi). This target is of production quality and should be completely compatible with the official NVIDIA toolchain.

Ответить | Правка | Наверх | Cообщить модератору

297. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 05-Июл-14, 03:03 
>> и они сами же и говорили что используют местечковый  кодогенератор, т.к. все попытки использовать LLVM приводили к большим граблям.
> Вот вы опять требуете от ллвм чего то не того. Ессно если хочется кодогенерировать для экзотической архитектуры то придется поработать самому, да. Как раз в принципе то поддержка влив заложена, но конечно добиться чтоб она нормально работала придется самим заинтересованным лицам, кому же еще то.

Так никто сам поработать не отказывается. И от LLVM никто ничего не требует, просто констатировали тот факт, что для VLIW он не особо подходит. Он заточен под типичные свойства более распространенных архитектур. Поэтому попытки его заставить эффективно работать еще и для "нестандартных" архитектур типа VLIW не поломав при этом все остальное могут означать куда больше работы, чем просто сделать всё самому без LLVM.

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

> вот и нвидия тоже свой бэкэнд к ллвм написала и что?

Он к VLIW вообще никакого отношения не имеет, к тому же он генерирует не окончательный машинный код, что тоже позволяет избежать многих сложностей с LLVM связанных с "нестандартностью" архитектуры GPU.

Ответить | Правка | К родителю #294 | Наверх | Cообщить модератору

242. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от defcewfde (?), 03-Июл-14, 23:25 
> Особенно эпичен тут продолб LLVM - супер-пупер архитектура делалась не так давно. Но про VLIW почему-то тоже ничего не знает. Хотя имели все шансы учесть.

Зачем учитывать несуществующие архитектуры? От них отказываются даже там где они были

AMD Graphics Core Next: Out With VLIW, In With SIMD. With AMD Graphics Core Next, VLIW is going away in favor of a non-VLIW SIMD design.

> На примере амд: они 2 года долблись чтобы просто выжать валидную кодогенерацию
> для своих VLIW из LLVMного гуано. После двух лет долботни оно

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

Beignet Is Now Friendly With LLVM/Clang 3.5
Published on 11 February 2014 01:02 PM EST
Written by Michael Larabel in Intel
Intel's Beignet open-source OpenCL implementation for their Linux graphics driver now switches to LLVM/Clang 3.5 as its preferred version

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

333. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Michael Shigorinemail (ok), 30-Ноя-18, 12:58 
> А что мешает этот планировщик привесить к компилятору, в качестве завершающей фазы
> оптимизации, проводимой после этапа кодогенерации?

Например, отсутствие в промежуточном представлении необходимой для такого оптимизатора информации о структуре циклов в исходнике.

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

125. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от Yaisisemail (?), 03-Июл-14, 07:25 
"У VLIW достаточно долбанутые заморочки по взаимозависимости команд."

Думаю нельзя говорить о всех VLIW одинаково. Зависит от конкретной реализации архитектуры.

Изначально VLIW - это широкое командное(ШК) слово, которое теоретически можно набрать из определённого количества разных команд, но естественно в целях экономии ресурсов могут чем-то пожертвовать. Например(насколько помню), в видеокартах AMD ШК слово могло состоять максимум из 5 команд и только одна пятая команда могла выполнять сложные операции. Например все 5 могли производить сложения, а операцию синус могла делать только пятая.

Мне неизвестно, как в Эльбрусе устроено ШК слово, но именно от его возможностей и будет зависеть сложность его программирования. Например, если все 25 команд могут быть произвольными и аппаратно независимыми, тогда сложность программирования падает, а задача компилятора просто для каждого такта попытаться набрать как можно больше независимых во времени команд в это слово. Но так же и возрастает сложность архитектуры в таком случае.

У разработчиков Эльбруса свои компиляторы и они хорошо знают устройство своего процессора. И насколько я знаю, сам процессор разрабатывался с учётом на высокоуровневые языки программирования.

Они портировали некоторые программы и ядро линукс тоже. Так что было на чём тестировать

А ещё по сравнению с предыдущей версией процессора они увеличили ШК слово на 2 инструкции - не просто же так они это сделали. Если бы у них были трудности с заполнением 23 инструкций, то стали бы они добавлять ещё 2 ?

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

290. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +2 +/
Сообщение от Аноним (-), 04-Июл-14, 17:45 
> Изначально VLIW - это широкое командное(ШК) слово,

И во всех виденных вариантах это подавалось в блоки выполнения, которые не являются 100% независимыми и самодостаточными. Что и вызывало заморочки по части кодогенерации.

> максимум из 5 команд и только одна пятая команда могла выполнять сложные операции.

Да, это так называемый VLIW5. Потом некоторые относительно новые GPU 6000-й серии "оптимизировали", с аргументацией "все-равно все 5 блоков редко кто может прогрузить", обрубив до VLIW4 (аналогично по смыслу, но лишь 4 команды). Это сократило площадь чипа и удешевило оный. Сие пофиг играм (они и правда редко могут), но воздалось в сильно параллелящихся задачах. Не в лучшую сторону.

А еще кроме математики есть например управление ходом выполнения программы. Оно сделано по остаточному принципу и там какие-то отдельные ограничения, достаточно невкусные. Эта штука нацелена на массовое однотипное применение математики к большим массивам данных, без резких разворотов. Это хорошо работает для графики, но AMD же хочется GPGPU. Не надо быть академиком чтобы понять что упомянутая архитектура разборчива в алгоритмах и произвольно взятый алгоритм вовсе не обязан там работать хорошо. Оптимизация под такую штуку - отдельный и нишевой гемор, хоть и творит чудеса, когда програмер смог придро^W к странному стилю написания алгоритмов, где много математики которая хорошо параллелится и минимум execution flow control. Как несложно понять - это весьма специфичные простынки, не сильно похожие на обычные реализации алгоритмов, где програмер явным образом подыгрывает странноватой природе этой штуки. Все это стало мотивом к созданию GCN, который несколько улучшает ситуацию. Конечно если алгоритм напрочь не параллелится - GPU ему не поможет, но тем не менее, GCN имеет все шансы вести себя лучше на произвольно впиханых в него алгоритмах.

> Например все 5 могли производить сложения, а операцию синус
> могла делать только пятая.

Там вроде еще какие-то взаимозависимости  есть, на предмет того какие команды в слове могут соседствовать. А управление ходом выполнения вообще все люто нагибает и есть куча ограничений. Отдельный SIMD-элемент не может такое делать независисмо.

> Мне неизвестно, как в Эльбрусе устроено ШК слово, но именно от его
> возможностей и будет зависеть сложность его программирования.

Вон итаник тоже VLIW был. И тоже страдал от подобных проблем.

> и возрастает сложность архитектуры в таком случае.

Именно. Так получается "честный 25-ядерник", а VLIWовость ему как-то и не очень требуется: можно "узкие" команды в каждый блок независимо толкать. Это, конечно, удобно программировать, но сложно произвести с разумным размером кристалла и потреблением. А если довести до абсолюта, как в GPU - пара тысяч упрощенных ALU  в определенных задачах сильно вставляет десятку обычных ядер при той же площади кристалла и потреблении. Но как проц общего назначения - ни о чем. Вот и появляются гетерогенные вещицы типа APU, где есть и нормальный проц и такой вот акселератор к нему. Как раз APU смотрятся очень логично, давая возможности использовать плюсы обоих архитектур: то что плохо ложится на пачку простых ALU - на обычный проц, то что хорошо - на акселератор.

И кстати раз уж это доперло и до амд и до интеля и до много кого еще (ARM и то уже заикается про OpenCL) - не очень понятно почему местные тупят. В порядке инженерного бреда: взять ARM64 системным процом, а нечто VLIW-образное упростить/перемасштабировать/затвикать как амд с GCN, получив GPU/акселератор.

> У разработчиков Эльбруса свои компиляторы и они хорошо знают
> устройство своего процессора.

Свои компиляторы - это звиздато, но что ими компилить? Линь вон например без приключений собирается только gcc. Еще есть какие-то эксперименты насчет шланга, но там уже не без проблем. При том оба про VLIW знают чуть менее чем ничего. А проц без софта и/или с хреновенькой эмуляцией х86... вот все и приходит к тому что дубовое и тормозное страшило с "правильным", "отечественным" - даже не включают, поставив в темный угол. Так что по документам все как бы замечательно. А задачи ворочает по факту обычный х86 писюк с американским процом и виндовсом. При том такая фигня даже в критичных применениях.

> И насколько я знаю, сам процессор разрабатывался с учётом на высокоуровневые
> языки программирования.

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

> Они портировали некоторые программы и ядро линукс тоже. Так что было на
> чём тестировать

При том я могу себе представить результаты этих тестов и насколько не доставляет соотношение цена/производительность в типовых задачах.

> А ещё по сравнению с предыдущей версией процессора они увеличили ШК слово
> на 2 инструкции - не просто же так они это сделали.

А вон амдшники сперва обрубили размер слова (VLIW5 -> VLIW4), а потом и вовсе донавесили добавочных блоков и оно стало несколько больше смахивать на более традиционные процы (GCN). Интел и трансмета вообще забили по сути.

> Если бы у них были трудности с заполнением 23 инструкций, то
> стали бы они добавлять ещё 2 ?

Не знаю. Я их процов не видел даже на картинке (что косвенно намекает об "успешности" и "всеобщей востребованности" архитектуры) и поэтому мне сложно это оценить напрямую. Говоря за амдшные GPU, чтобы они нормально считали, алгоритм должен быть скроен совершенно не так как скроена типичная ОС или программа. Это должна быть большая простыня математики, с абсолютным минимумом перетурбаций в ходе выполнения. Это мягко говоря не похоже на типичный код программ. И хотя оно "тоже си", но сами простынки оптимизнутые на скорость выполнения - выглядят очень специфично.

Ответить | Правка | Наверх | Cообщить модератору

124. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от Yaisisemail (?), 03-Июл-14, 06:50 
Уж компиляторам легче заполнить VLIW слово, чем выбирать код для заполнения всяких MMX, SSE, AVX и т.д. Потому что VLIW - это MIMD архитектура, т.е. много инструкций, много данных. А, например SSE - это SIMD, т.е. одна инструкция, много данных.

"Оба в итоге стали тупиковой ветвью развития."

Если кто-то не осилил, то это не значит, что и кто-то другой не осилит. В Эльбрусе такая архитектура была с версии 3, а Интел стал делать Итаниум, чтобы тоже попробовать нечто подобное и у него получилась фигня, насколько я знаю.

Кстати у AMD были хорошие графические процессоры на VLIW архитектуре.

Лучше когда есть возможность выполнить 25 разных инструкций над разными данными(VLIW), чем когда возможно выполнить только одну инструкцию над кучей данных(SSE, AVX).

Я считаю, что под VLIW легче программировать и писать компиляторы и оптимизаторы, чем под x86 c его разбухшей системой команд и кучей расширений, которые только отъедают транзисторы на кристалле.

А VLIW - это универсальный блок, который имеет базовые команды и которые при этом могут выполняться параллельно, т.е. уже не нужны никакие расширения. На VLIW можно сымитировать и MMX, и SSE, и AVX. И вообще можно построить произвольную комбинацию инструкций, которые будут выполнятся параллельно, а у x86 не будет похожего расширения.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

184. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от rob pike (?), 03-Июл-14, 15:51 
> Уж компиляторам легче заполнить VLIW слово, чем выбирать код для заполнения всяких
> MMX, SSE, AVX

Только есть один нюанс.
Объективная реальность, данная нам в ощущениях, с вами категорически несогласна.

Ответить | Правка | Наверх | Cообщить модератору

243. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 03-Июл-14, 23:26 
> Только есть один нюанс.
> Объективная реальность, данная нам в ощущениях, с вами категорически несогласна.

а это может все-таки это проблема бывших реализаций, а не архитектуры?

Ответить | Правка | Наверх | Cообщить модератору

62. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от bOOsteremail (?), 02-Июл-14, 21:49 
RISC - Фиксированное командное слово длиной разрядности процессора.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

74. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 02-Июл-14, 23:08 
> RISC - Фиксированное командное слово длиной разрядности процессора.

Совершенно не обязательно. А как насчет ARM? А если он смесь ARM + Thumb кода выполняет, тогда как?

Деление на RISC и CISC достаточно плавное и в какой-то мере условное. А VLIW - ни то ни другое в чистом виде. Это нечто типа CISC которому оборвали uCode ROM и вывесили блоки выполнения команд напрямую програмеру. Это чем-то похоже на несколько RISCов состыкованных параллельно, но для экономии ряд блоков используется совместно. По этому поводу появляются взаимозависимости команд - что можно прожевать в одной группе инструкций, а что нельзя. И вот с этой заковывкой большинсво компиляторов не очень хорошо дружат.

Ответить | Правка | Наверх | Cообщить модератору

37. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от ями (?), 02-Июл-14, 19:35 
> ну хотя бы обеспечить нацбезопасность и то хорошо.

Ок. За безопасность спокоен. А о людях? О людях когда подумают? ;)

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

42. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от вои и аноним подкрался (?), 02-Июл-14, 19:43 
для людей будет другой проект микрочипа на арм. т.е. его спроектируют наши с задействованием инструкций арм, но это будет наш микрочип. и этот уже будет для всего и для гражданки тоже. недавно проскакивала статья на опеннете , архив глянь.
Ответить | Правка | Наверх | Cообщить модератору

45. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от rob pike (?), 02-Июл-14, 19:47 
> и для гражданки тоже

Гражданка задохнулась от счастья.

Ответить | Правка | Наверх | Cообщить модератору

47. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +6 +/
Сообщение от Fomalhaut (?), 02-Июл-14, 20:04 
Большинству на гражданке глубоко пофиг, Ынтель, АМд, АРМ, БЭСМ-6 или Cray-9LX - лишь бы пасьянс раскладывался.
Ответить | Правка | Наверх | Cообщить модератору

48. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от rob pike (?), 02-Июл-14, 20:19 
Вы забыли про цену.
Гражданка задохнулась от счастья именно по этому поводу.
Покупать отечественные АРМы в 10-100 раз дороже нормальных, когда заставят - это ведь такая удача.
Ответить | Правка | Наверх | Cообщить модератору

50. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +2 +/
Сообщение от вои и аноним подкрался (?), 02-Июл-14, 20:41 
с чего ты решил что заставят. сам побежишь. я например не откажусь от системы созданной нашими. и спокойно приобрету себе на замену амд которая у меня дома сейчас. к тому же они пойдут несколько иным путем нежели эльбрус. тут будет массовое производство, а значит и цена другая. да вындовс может и откажется все это держать из-за санкций или еще чего, но линукс никуда не делся то. так что для гражданки перспектива ничего просматривается. а на чем работать народу пофиг, хоть арм , хоть интелл. а стим для игр и в линухе есть.))
Ответить | Правка | Наверх | Cообщить модератору

75. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 02-Июл-14, 23:11 
> я например не откажусь от системы созданной нашими.

Даже после того как обнаружишь что ее цена в 5 раз выше при параметрах в несколько раз хуже? Как-то исторически процы от МЦСТ не отличались ни симпатичной ценой, ни доступностью в ближайшем ларьке. По этому поводу было бы лучше если бы было поменьше красивых сказок на ночь и побольше осязаемой продукции в магазинах.

Ответить | Правка | Наверх | Cообщить модератору

90. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от вои и аноним подкрался (?), 02-Июл-14, 23:44 
а кто тебе сказал что это мцст делать будет. у них 2 архитектуры - эльбрус и самосборная на основе спарк9. а арм это не мцст. тут новость недавно была , пошарь в архиве. на прошлой неделе что ли.
Ответить | Правка | Наверх | Cообщить модератору

109. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от Аноним (-), 03-Июл-14, 02:09 
> Даже после того как обнаружишь что ее цена в 5 раз выше при параметрах в несколько раз хуже?

С чего бы она вдруг будет в 5 раз выше, после того как наладят серийное производство? Многая российская высокотехнологичная продукция, например всякие самолеты с ракетами, гораздо дешевле западных аналогов. Да и всякие телевизоры с машинами тоже не в 5 раз дороже импортных. Если будут производить только в России, то конечно будет стоить слегка дороже, чем если бы это все производилось где-нибудь в Китае, но в любом случае не в 5 раз.

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

115. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  –1 +/
Сообщение от Аноним (-), 03-Июл-14, 02:57 
> С чего бы она вдруг будет в 5 раз выше,

Вон тут павлин утверждает про 35000. Не знаю насколько врет, но если не сильно - что-то такой уровень цен совсем не радует.

Ответить | Правка | Наверх | Cообщить модератору

119. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +3 +/
Сообщение от Аноним (-), 03-Июл-14, 03:36 
> Вон тут павлин утверждает про 35000. Не знаю насколько врет, но если не сильно - что-то такой уровень цен совсем не радует.

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

Ответить | Правка | Наверх | Cообщить модератору

154. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 03-Июл-14, 11:02 
>> Вон тут павлин утверждает про 35000. Не знаю насколько врет, но если не сильно - что-то такой уровень цен совсем не радует.
> Ну так не зря же в предыдущем комменте было уточнение: "после того
> как наладят серийное производство". Стоимость опытных образцов обычно отличается от стоимости
> при налаженном серийном производстве.

Ховди, серийное производство - и насыщенный рынок - две оференные разницы. Чуешь?

Ответить | Правка | Наверх | Cообщить модератору

212. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 03-Июл-14, 18:13 
> Ховди, серийное производство - и насыщенный рынок - две оференные разницы. Чуешь?

Ну да, это вообще разные понятия. А кто-то здесь утверждал обратное, или ты просто со своим внутренним голосом решил поспорить?

Ответить | Правка | Наверх | Cообщить модератору

244. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +1 +/
Сообщение от Аноним (-), 03-Июл-14, 23:30 
> Ховди, серийное производство - и насыщенный рынок - две оференные разницы. Чуешь?

а еще понятия насыщенный рынок и наыщение рынка тоже разнятся, что делать теперь будем?

Ответить | Правка | Наверх | Cообщить модератору

103. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от linecommander (ok), 03-Июл-14, 01:43 
>> ну хотя бы обеспечить нацбезопасность и то хорошо.
> Ок. За безопасность спокоен. А о людях? О людях когда подумают? ;)

ойинеумоляйте их подумать о людях!..

потому как закончится всё грустно

как в весёлом анекдоте

"душ по 200, думаю, будет в самый раз!.."

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

58. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от rshadow (ok), 02-Июл-14, 21:21 
Да интел в итоге сильно проиграли с тем что так тесно на микрософт завязались. Щас бы строгали не совместимые с 86 архитектуры под разные задачи. И линукс им в помощь. Но зонд уже глубоко...
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

67. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +5 +/
Сообщение от t28 (?), 02-Июл-14, 22:31 
> там архитектура wliv . так что нет производительность там точно не маленькая.

WLIV такой WLIV...

Wery Long Instruction Vord, однако, да.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

73. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +2 +/
Сообщение от pavlinux (ok), 02-Июл-14, 23:07 
Wery Vong Lord Instruction
Ответить | Правка | Наверх | Cообщить модератору

77. "Представлен 8-ядерный отечественный микропроцессор Эльбрус-8..."  +/
Сообщение от Аноним (-), 02-Июл-14, 23:12 
> Wery Long Instruction Vord, однако, да.

Сколько тут выпускников МГИМО.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру