Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

Напоминаем о том, что на сообщения новых участников распространяется действие системы премодерации сообщений.

Вот куда Чубайс наши денежки припрятал....

Наши-то нанотехнологи в луже сидят, а ему отчитываться чем-то надо...
Помню как он гордо демонстрировал светодиодную лампочку фирмы Филлипс со словами "Вот, это мы сделали!". Я со смеху чуть не лопнул тогда.
А может Интель с АМД от этих новостей шевелиться начнут?! Хотелось бы верить...

у меня три вопроса:
1. насколько сложный набор команд и как это отразиться на компиляторах (все помнят чем закончился влив?).
2. насколько потребуется адаптировать ос под эти камни (опять же пример специфичных архитектур)?
3. на каком программном решении были проведены тесты?

... вообще мне кажется что это полностью нишевой продут под очень узкий круг задач. при этот меньше 200лямов инвестиций когда разработка игры стоит 30+ лямов намекает насколько пока все в "зачаточном" состоянии.

Пишут, «лёгкий программный слой».

ЗЫ Сейчас нет времени искать, никто не помнит, сколько Эльбрус сжирает на трансляцию? Годсоны, помню, от 20% до 60 % производительности.

1. Влив не показал результатов в десктопных приложениях вовсе не из-за сложного набора команд. Компилятор и документацию они должны будут выкатить, когда начнут продавать.
2. Судя по прошлой презентации они запускают ведроид и линуксы, так что никому ничего адаптировать не придется.
3. Очевидно, что не винда, а какие-то линуксы.

Насколько я понял, это сильно продвинутый програмно-аппаратный вариант QEMU? Звучит довольно заманчиво.

Убийца Интела?

GreenCo это точно не ко мне вопрос )))

ApocaLeXX влив как раз токи из за команд и не поплыл - сложность компиляторов зарешала. плюсом если "ядро" линукса не нужно оптимизировать под команды железа - считай еще от 10-35% осядет на трансляции. ведь ядро посылает скажем х86 команду ее нужно перевести "виртуальной средой" в понятную процессору команду и на выходе отдать опять х86. не может процессор работать не на родном наборе команд и ядро всяко нужно оптимизировать под этот родной набор команд - как тот же линукс который работает на эльбрусах.

Не люблю рыжего Толика, но вы реально считаете, что вкладывая деньги в НИОКР, тем более зарубежной компании, можно сильно нажиться?


Примеры в студию! У меня вот например есть примеры обратного. Тссс...Mapper Litography погуглите.


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



Эмм..не совсем корректное сравнение. Лучше наверное найти стоимость разработки одного ARM ядра. У меня таких сведений нет.

Компиляторы для vliw действительно гораздо сложнее, они должны изыскивать параллелизм, чтобы максимально утилизировать командное слово. Но что делать, если пользовательский софт не предполагает распараллеливание?
>плюсом если "ядро" линукса не нужно оптимизировать под команды железа - считай еще от 10-35% осядет на трансляции
Что такое "оптимизировать под команды железа"? Изменять размеры структур, чтобы лучше влезали в кеш или что? И при чем тут проценты оверхеда трансляции?
>ведь ядро посылает скажем х86 команду ее нужно перевести "виртуальной средой" в понятную процессору команду и на выходе отдать опять х86.
Бинарная трансляция работает несколько иначе.
>и ядро всяко нужно оптимизировать под этот родной набор команд - как тот же линукс который работает на эльбрусах.
Можно подробнее про то, что вы подразумеваете под оптимизацей ядра ОС под конкретные архитектуры?
Ядро линуксов в эльбрусе допиливали исходя из других предпосылок, насколько мне известно.

Слезали идею с Эльбруса, по-другому о ней рассказали и вот ВАУ ИННОВАЦИИ.

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

это тоже самое что выпуск armv8 ядра линукса при наличии ядра на армв7. то есть все от регистров кешей и тд

причем тут "бинарная" - visc по сути "виртуальный процессор" те трансляция команд так и так есть от "виртуально - физический ядер".

мне хватает то что ванильное ядро линукса не поддерживает эльбрус а значит не совместима с ним.

А МЦСТ, надо полагать, спионерили идею у трансметы. Так?
А трансмета спионерила идею у яббла, которые транслировали mk68k в ppc.
И так далее.

Добавлено спустя 6 минут 54 секунды:
>там проблема не параллелизме а в том что длинную инструкцию в ед времени почти всегда нечем забить и получается возможностей много а толку ноль.
А чем забивать командное слово как не командами, способными исполняться параллельно? Для этого этот самый параллелизм надо находить.
>и поэтому х86 это нифига не сиск а все же "риск подобное ядро с внешнем преставлением команд как сиск".
И при чем тут х86 циск-риск? х86 это OoO суперскаляр в первую очередь, именно это определяет, как на нем исполняются инструкции.
>это тоже самое что выпуск armv8 ядра линукса при наличии ядра на армв7. то есть все от регистров кешей и тд
Собрать ванильное ядро новым тулчейном для армв8 это оптимизация ядра под железо?
>причем тут "бинарная" - visc по сути "виртуальный процессор" те трансляция команд так и так есть от "виртуально - физический ядер".
Работаете в софтмашинс?
>мне хватает то что ванильное ядро линукса не поддерживает эльбрус а значит не совместима с ним.
Свежее ванильное ядро линукса не поддерживает, скажем, платы на rk3188.
Давайте различать портирование линукса на аппаратную платформу и оптимизацию кода под платформу.

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


да чем угодно не? ))) и параллелизм тут не совсем к месту те им конечно можно достичь достаточной плотности (объединение простых операций в одну большую команду - так это и без влив уже решено на уровне симд команд на любой архитектуре. те не все команды поддаются такому) в данном конкретном вопросе я говорю об исполнение "последовательного" кода и объем его очень часто короче влив инструкции. влив хорош на векторном коде тот же целочисленный он переваривает в разы хуже arm или х86.

вопрос а какие по вашей версии процессоры не суперсколярные сейчас?

лол вы точно хотите это сказать? вы реально думаете что пересобрать х32 код х64 компилятором выйдет 64 программа?

этот вопрос я даже не понял.

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

>да чем угодно не? )))
Ну давайте забивать нопами, почему нет. А еще можно факториал считать по фану и не делать полезную работу.

>и параллелизм тут не совсем к месту те им конечно можно достичь достаточной плотности (объединение простых операций в одну большую команду - так это и без влив уже решено на уровне симд команд на любой архитектуре.
SIMD == single instruction multiple data, это совсем из другой оперы. Расскажите, пожалуйста, как вы с помощью симда можете одновременно исполнить add r1, r2, r3 и ld r4, 0x100500, а vliw может.
Влив(как и эпик) разрабатывался с прицелом на то, чтобы исполнять максимальное количество независимых инструкций параллельно.

>те не все команды поддаются такому) в данном конкретном вопросе я говорю об исполнение "последовательного" кода и объем его очень часто короче влив инструкции.
Поэтому компилятор должен находить/делать код максимально параллелизированным.
>влив хорош на векторном коде тот же целочисленный он переваривает в разы хуже arm или х86.
Влив хорош там, где можно много всего выполнять параллельно. Будь то векторный код или целочисленный код.

>вопрос а какие по вашей версии процессоры не суперсколярные сейчас?
Я бы сказал, что старые атомы(с учетом того, что SMT не считать за суперскалярность), arm v5, R4000.

>причем тут "бинарная" - visc по сути "виртуальный процессор" те трансляция команд так и так есть от "виртуально - физический ядер".
Судя по этому утверждению вы знаете, как устроен visc внутри, вот я и интересуюст откуда. Может работаете в soft machines?

>а чем блин отличается то? в данном конкретном случаи нет ядра виск а значит его нужно "сделать" понятно что код с нуля писать не будут - оптимизировать или портировать да хоть изнасиловать смысла не поменяет.
Если для вас оптимизация это наложить патчи и собрать ядро уже готовым тулчейном, то окей. Если soft machines будут как-либо продавать свой продукт, им придется отдавать вместе с продуктом линукс, тулчейн и документацию. Возможно со временем они заморочаются и вмержатся в апстрим ядра, кто ж знает.

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


пускай у вас будет:

мы оказывается о конкретных процессорах а не архитектуре да? *сарказм*


настолько интересная тема что я только сегодня узнал о их существовании и увидел "блок схему исполнения".

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

>те в данном конкретном случаи говорим о том что если что то нельзя исполнить как одну инструкцию нужно это же исполнить за 2 3 ... н инструкций. проблема влив в том что она конечно "могет" только нафига?
В данном примере на vliw эти 2 инструкции будут готовы(утрированно считаем, что операция с памятью отработает за 1 такт) за 1 цикл, в то время как на суперскаляре это может занять 2.

>мы оказывается о конкретных процессорах а не архитектуре да?
Раз пошла такая пьянка, то давайте различать архитектуру и микроархитектуру. Core I7 и Atom имеют одну и ту же архитектуру(ISA) - x86, но разную микроархитектуру. Я привел примеры микроархитектур(пускай и не совсем актуальных, но встречающихся) с single issue.

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

Да пожалста! Наши нанотехнологи 65нм техпроцесс допилили только в прошлом году. А то, что Mapper Litography запустила в Москве линию по производству элементов электронной оптики на основе МЭМС - это заслуга НЕ наших нанотехнологов.
Вот когда у нас будет свой процессор и своя операционка - тогда я возьму свои слова назад.

какие в жопу циклы? может такты?

что блин за цикл?

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

мне ткнуть носом с чего все началось или сами?