OSDev

для всех
Текущее время: 14 дек 2017, 01:32

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 56 ]  На страницу 1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: 20 май 2014, 11:19 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
Часть 1.
Часть 2.
Часть 3.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 май 2014, 13:24 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
К сожалению, немного популистски-квасной цикл статей. Не хотелось бы ругать Эльбрус, но статьи могли бы быть и посодержательней. В данном случае опять получается минимум технической информации, так что очень тяжело сделать какие-то выводы самостоятельно. К сожалению, несмотря на всю открытость архитектуры (в статье прямо говорится, что весь комплекс ПО передаётся заказчику в исходных текстах, а значит и компиляторы), она опять получается сплошь закрытая, в лучших традициях свободного ПО. В статье приводятся таблицы, которые и так доступны на сайте МЦСТ. Внятного описания архитектуры практически нет нигде, открытой "фирменной" технической документации вообще не существует в природе.
Во второй части узнаём кое-какие детали - 256 84-битных регистров, отдельный банк из 32 предикатов, 6 несимметричных каналов исполнения и какие-то совершенно мутные (опять же, без претензий к Эльбрусу, претензии к описанию) устройства вроде "асинхронного устройства предварительной подкачки данных со встроенным буфер объемом 4 кБ" или "контроллер когерентных сообщений, анализирующий запросы от коммутатора и передающий их нужным ядрам". За неименеем более внятного описания у меня складывается впечатление, что AAU должно конкурировать с MMU за доступ к памяти.
В разделе "безопасность" находим достаточно спорные утверждения типа "защита типа Execute Disable Bit в процессорах Intel (или его аналог – No eXecute Bit в процессорах AMD) обходится «на раз-два»" с отсылкой к интернету. Я бы всё же хотел узнать, как на "раз-два" обходится такая защита?
Также видим фразу "неразделяемый стек – вообще ахиллесова пята всех AMD/Intel систем". К счастью, чуть дальше по тексту разъясняется, что такое "неразделяемый стек" (это когда адреса возвратов хранятся вместе с локальными данными), а то я бы не понял. Но вот вопрос - если стек и данные помечены как non-executable, возможна ли атака, которая показала бы преимущества раздельного стека?
В описании защиты Эльбрус есть указание, что "работа в нём происходит только с инициализированными данными". Однако, такая защита элементарно осуществляется софтово и не требует специальных аппаратных средств, единственный её минус - накладные расходы на очистку выделенной страницы памяти. Неужели Эльбрус очищает память как-то специально аппаратно? И насколько такая инициализация работает быстрей?
Вот эта фраза мне вообще непонятна: "Практически весь существующий в среде open source код написан так, что использует приёмы программирования, не регламентированные стандартом языка Си. Поэтому запустить ядро ОС или приложения типа LibreOffice полностью в защищённом режиме пока что невозможно". Если кто понял, разъясните, пожалуйста.
Однако, уже в первой части видим признанные недостатки архитектуры Эльбрус: "Справедливости ради заметим, что из-за некоторой трудоёмкости программирования встроенного DSP он не снискал большой популярности, поэтому в модели следующего поколения от него решено было отказаться." Заметим, что вся архитектура VLIW (рассматривающаяся как перспективная) подвержена "некоторой :D трудоёмкости программирования", т.е. сложности разработки оптимизирующего компилятора под такую архитектуру, что явилось одним из факторов коммерческой неудачи Итаника. Также не рассматривается фактор "холостой затраты энергии" на коде, который не удалось оптимизировать, т.к. загружать из памяти и интерпретировать поток всё равно нужно. Таким образом, энергоэффективность архитектуры VLIW у меня также вызывает сомнения. Результаты же сравнения с Интел в третьей части достаточно красноречивы. А фраза "работая на той же частоте, что и процессор Intel, «Эльбрус» смог бы его обойти!" вызывает у меня искреннее недоумение - ведь в первую очередь не тактовая частота ограничивает скорость работы, а внутренняя архитектура и тех-процесс. Тактовая частота всегда выбирается максимально возможной (т.е. что удалось "выжать" из комбинации архитектура/тех-процесс). Поэтому эти сравнения весьма умозрительны и лично у меня ассоциируются с русской поговоркой "ах если бы, да кабы..."
В целом, моё резюме - туман в квадрате. Но повторюсь, я не хочу обругать Эльбрус, я просто хотел бы видеть больше технической ясности, чтобы можно было обсуждать Эльбрус более предметно.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 20 май 2014, 20:46 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1057
В интернете видел статьи которые описывали как обходить Execute Disable Bit. Но в подробности не лез. Суть в том что в срыве стека меняют указатель данные. Тем самым получают возможность писать данные по нужному адресу, не обязательно через срыв стека стек. Выбирают адрес к примеру в какой нибудь мало используемой DLL, т.е. в участке с заведомо разрешенным доступом. Туда по байтно загоняется зло.код А потом меняется адрес возврата на адрес зло.кода.

Про эльбрус. Я бы купил. Только покупать кота в мешке неохото. Во-вторых Эльбрус-4С только завершил этап ОКР, т.е нет серийного производства. А покупать 10 летний процессор неохото. Не говоря уже о том что СПО надо будет адаптировать под него.

Цитата:
В описании защиты Эльбрус есть указание, что "работа в нём происходит только с инициализированными данными". Однако, такая защита элементарно осуществляется софтово и не требует специальных аппаратных средств, единственный её минус - накладные расходы на очистку выделенной страницы памяти. Неужели Эльбрус очищает память как-то специально аппаратно? И насколько такая инициализация работает быстрей?
Инициализация данных может осуществляться только программно. Так как только программист знает какую константу можно забить. А вот обнуление можно сделать аппаратным. Быстрее не будет, так как аппаратно запись идёт синхронно. Т.е за такт не более порции данных в размере шины данных. Конечно за счёт параллельности аппаратно можно выиграть.
Через 5-10 лет можно будет это выяснить если они свою ОС сертифицируют по более высокому классу безопасности от НСД. Требования как бы у ФСБ/ФАПСИ прописаны, не думаю что они что-то сверх необходимого делают.

Цитата:
Вот эта фраза мне вообще непонятна: "Практически весь существующий в среде open source код написан так, что использует приёмы программирования, не регламентированные стандартом языка Си. Поэтому запустить ядро ОС или приложения типа LibreOffice полностью в защищённом режиме пока что невозможно". Если кто понял, разъясните, пожалуйста.

100% Враньё. Так как всего лишь 10% кода(считая по файлам) open source используют специфичный код заточенный под GCC. И то с появлениям Clang ядро линукса чистилось.Конечно и Clang тоже поддерживает особенности GCC. Что касается LibreOffice не знаю, но судя потому что Clang научился его компилировать позже чем ядро линукса, то видимо процент больше.

Энерго эффективность зависит от числа переключений. В VLIW если не распарсел, то как следствии не задействует блоки и как следствие экономит на электричестве. По поводу того что быстрее. Ну сравнение не корректное, они не пишат на каких задачах.
Суть в том что VLIW как и потоковые процессоры достигают высокой производительности за счёт своей энергоэффективности. Добиваются они это тем что не тратят энергию на декодирование команд и смены состояний АЛУ, на доступ к памяти. Поэтому GPU выигрывают у CPU в более 10 раз.
Стоит сказать что x86 тоже ориентирован на общие задачи. А Эльбрус что раньше с DSP что и сейчас без DSP позиционирует себя как число дробилка.

А вот как бы я сделал свой процессор. Лучше всего было бы разделить процессор на несколько. Несколько ядер общего назначения(софт-процессор). Не менее 4 лучше 16. Один или два из них выполняет функции ядра, т.е Ring0. Другие прикладного ПО и драйверов. Число регистров мало 12 штук. Простой набор команд. Одновременное исполнение до 6 команд(чтение из ОЗУ, запись в ОЗУ, умножение, сложение, загрузка константы ). Т.е y:=R0*x+R1; R0=66; должна выполняться за 1 такт. Возможно VLIW или аппаратная группировка команд. Также несколько ядер мультимедийной обработки. Число регистров велико. Универсальный или потоковый, тот который в результате разработке покажет лучшую энерго эффективность в 3D играх.
Блок авто распараллеливания кода(без комментариев, НОУ-ХАУ). Блок энергосбережения отключающий не заарестованные ядра и балансирующий энерго нагрев.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 май 2014, 14:10 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
pavia писал(а):
Суть в том что в срыве стека меняют указатель данные. Тем самым получают возможность писать данные по нужному адресу, не обязательно через срыв стека стек.

Русски не русски трава хорошо срыв стека? :D
Очень сложно было распарсить зацитированное. Тем не менее, озадачившись вопросом, я поискал и нашёл. Вот замечательная статья мыщъха, детально освещающая этот вопрос. Осеписателям и процессоростроителям обязательно надо её прочитать. Я думаю так: да, DEP в теории повышает защищённость системы, однако, это надо делать не через ж... так, как всё делается у Майкрософт, а с другой стороны, лазейка всё равно остаётся. И, да, самое главное - действительно, раздельный стек в комбинации с DEP, похоже, полностью закрывает эту уязвимость. Наконец удалось найти реальное преимущество и уяснить, что да, Эльбрус более защищён и на x86 от этой атаки полностью защититься невозможно, т.к. утратится архитектурная совместимость. Эльбрус approved!!!

pavia писал(а):
Выбирают адрес к примеру в какой нибудь мало используемой DLL, т.е. в участке с заведомо разрешенным доступом. Туда по байтно загоняется зло.код А потом меняется адрес возврата на адрес зло.кода.

Не, так не получится. Чтобы загнать вредоносный код в какой-то участок памяти, нужно чтобы процессор уже выполнял другой вредоносный код. Точка атаки всё равно должна как-то пролегать через стек и манипуляции адресами возврата.

pavia писал(а):
Про эльбрус. Я бы купил.

Продаётся. 50 тыр за ноутбук. Дороговато.

pavia писал(а):
Во-вторых Эльбрус-4С только завершил этап ОКР, т.е нет серийного производства. А покупать 10 летний процессор неохото. Не говоря уже о том что СПО надо будет адаптировать под него.

Так ведь речь как раз о том, что он выпускается серийно, хотя и лихорадочно (крышек не тех понаделали, с количеством ядер определились в последний момент :D). И СПО они уже сами адаптировали.

pavia писал(а):
Инициализация данных может осуществляться только программно. Так как только программист знает какую константу можно забить.

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

pavia писал(а):
Энерго эффективность зависит от числа переключений. В VLIW если не распарсел, то как следствии не задействует блоки и как следствие экономит на электричестве.

Да, но энергия всё равно тратится на подкачку пустых команд из памяти, прокидывание их через кэши всех уровней, а также через декодирование инструкции (instruction prefetch and decode) даже несмотря на то, что выполнять нечего. И эти расходы могут оказаться немаленькими, - к примеру если из шести заложенных инструкций работает только одна. Вот о чём я.

pavia писал(а):
По поводу того что быстрее. Ну сравнение не корректное, они не пишат на каких задачах.

Почему же? Как раз пишут, - на третьей странице третьей части. И по прочтении слегка отвисает челюсть возникают странные мысли. Так, по цифровой фильтрации сигнала, которая ну ОООЧЕНЬ хорошо кладётся во VLIW, Эльбрусы сливают. Но по шифрованию ГОСТ, которое не имеет явных преимуществ с точки зрения архитектуры VLIW перед фильтрацией, имеют двукратный перевес. Либо шифрование ГОСТ поддержано аппаратно, либо оптимизировано вручную. Ни то, ни другое мне откровенно не нравится (с позиции оценки производительности). И почему тестировали менее распространённый ГОСТ, а не AES? Вероятно, по тем же причинам.

pavia писал(а):
Суть в том что VLIW как и потоковые процессоры достигают высокой производительности за счёт своей энергоэффективности. Добиваются они это тем что не тратят энергию на декодирование команд и смены состояний АЛУ, на доступ к памяти.

Ну всё же не за счёт энергоэффективности. Очень упрощённо, VLIW можно представить себе как RISC с одновременным выполнением инструкций. Т.е. несколько (в случае Эльбруса, надо понимать, 6) тесно связанных и частично специализированных исполнительных устройств (RISC-ядер с общим банком регистров) одновременно получают несколько (6) потоков инструкций. Но это всё же не поток микрокода, как некоторые считают, хотя и декодировать его, конечно, существенно проще, в лучших традициях RISC. Таким образом, для грубой оценки энергоэффективности следует брать несколько RISC-ядер и считать, что какая-то доля ядер постоянно выполняет поток NOP-ов. Доля меняется в зависимости от алгоритма и от того, насколько эффективно компилятор справился с трансляцией.

pavia писал(а):
Поэтому GPU выигрывают у CPU в более 10 раз.
Стоит сказать что x86 тоже ориентирован на общие задачи. А Эльбрус что раньше с DSP что и сейчас без DSP позиционирует себя как число дробилка.

Ну GPU выигрывают не только потому что они VLIW.
По поводу "числодробилок"... Обычно это из категории универсальных терминов, которые "всё сразу проясняют", но на самом деле ровным счётом ничего не объясняют. "XXX порвал в клочья YYY? А, ну так это же просто числодробилка!". Почему же тогда до сих пор никто не сделал "просто универсальную числодробилку", которая рвёт в клочья всех остальных? Ведь это же так просто - сделаем на кристалле стопитсот умножителей и все дела.
Эльбрус - это просто процессор общего назначения, т.е. неспециализированный. Хорошо, есть определённые узкие классы задач, обладающие свойствами регулярности, внутренне присущего параллелизма и большого кол-ва арифметических операций (собс-но, то, что неформально обычно и подразумевают под числодробизмом). Но вот загадка... если Эльбрус - VLIW и числодробилка, почему же он тогда просирает не только GPU, но даже и классическим CISC на САМОЙ приятной для числодробизма задаче - цифровой фильтрации сигнала???

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 май 2014, 19:59 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1057
Цитата:
Не, так не получится. Чтобы загнать вредоносный код в какой-то участок памяти, нужно чтобы процессор уже выполнял другой вредоносный код.

Ошибаетесь, нужна всеголишь уязвимость. Для этого даже есть термин эксплоит.
http://ru.wikipedia.org/wiki/%DD%EA%F1%EF%EB%EE%E9%F2
Цитата:
Точка атаки всё равно должна как-то пролегать через стек и манипуляции адресами возврата.

Необязательно. Эксплоит может работать и на срыве указателей.

Цитата:
Продаётся. 50 тыр за ноутбук. Дороговато.
Так не себе, а по работу. И 50 т.р это не дорого. ЭВМ индустриальная стоит 70-90 т.р. Защищенный ноутбук стоит 150 тыс. р. С военной приемкой цена в 1.5-2 раза выше.

Цитата:
Так ведь речь как раз о том, что он выпускается серийно, хотя и лихорадочно (крышек не тех понаделали, с количеством ядер определились в последний момент ). И СПО они уже сами адаптировали.

Может быть вы не в теме. Но судя по всему вы поддались на домыслы журналистов или фантазии разработчиков.
Придётся рассказать. Дело в том что на процессор эльбрус-4С менее 2 месяцев завершился окр с присвоением литеры О1. О1 - означает одно из двух:
1. Либо само серийное производство;
2 либо одобрение к серийному производству.
Что-бы получить О1 достаточно что-бы производство было готово к серийному производству на 30-80%. Далее после ОКР идет этап подготовки производства к серийному выпуску изделия. Это отдельные деньги и время.
1. Так вот за 2 месяца никак нельзя наладить серийное производство.
2. У нас нет завода способного выпускать Эльбрус-4С по технологии 65 нанометров. На хабре был ряд статья по русским заводам микроэлектроники. Правда про мой родной неточность - у нас обновление до 180 нм.
3. Насколько я помню Эльбрус-4С не совместим с предыдущим поколением по входам. А следовательно нужна материнская плата и южный мост, а их пока нет.
4. Процессор Эльбрус-2 выпустили 10 лет назад а ноутбуки на нём появились только 3 года назад.
Хочу сказать что то что в вашей статье тоже врут. Там показывают на картинках ноутбуки. Но это именно те которые с Эльбрус-2. А с Эльбрус-4С пока нету. Думаю также появятся только через 3-7 лет.


Цитата:
Да, но энергия всё равно тратится на подкачку пустых команд из памяти, прокидывание их через кэши всех уровней, а также через декодирование инструкции (instruction prefetch and decode) даже несмотря на то, что выполнять нечего. И эти расходы могут оказаться немаленькими, - к примеру если из шести заложенных инструкций работает только одна. Вот о чём я.

Дело в том что современные универсальные процессоры очень похожи. Что Intel что ARM что Эльбрус.
Во всех есть несколько вычислителей: умножитель, сумматор, блок логики, порт для доступа к памяти. В некоторых их не по одному а по несколько. К VLIW архитектуре отношу у тех которые можно запрограммировать одной командой. Но intel и ARM не сильно отличаются там есть тот же VLIW на уровне микрокоманд. Поясню имею ввиду то что исполняется за такт несколько микро команд. Intel тратит энергию на аппаратную перетасовку команд, когда как у Эльбрус-2 это отсутствует. И плюс к тому аппаратная оптимизация не полноценная. Хотя стоит сказать что у intel это оптимизация скажем гибридная. Поэтому Эльбрус-4 ну никак не может обгонять Intel x86. Но вот лет 15-20 назад Эльбрус обгонял Intel x86, так как там архитектура была другой.

VLIW можно сделать ещё более энерго эффективным. Если не декодировать команды на каждом такте а загрузить в регистр одну ну очень большую команду и крутить её в счётчике команд. Именно таким занимается NVIdia в своём GPU. Для 3D без смены команды в среднем исполняется до 8х8x4=256 циклов. А то и по более.


Цитата:
Почему же тогда до сих пор никто не сделал "просто универсальную числодробилку", которая рвёт в клочья всех остальных? Ведь это же так просто - сделаем на кристалле стопитсот умножителей и все дела.

Как это не сделали? Современный ATI GPU имеет 4096 умножителей и каждый год увеличивают. Умножители с сумматором поэтому производительность в 2 раза выше. Почему не сделали больше? Ну так больше не влезает в кристалл, так как по мимо умножителей есть, нужны другие блоки. Для 3D ещё sin cos, корень тоже надо считать по хорошему за 1 такт.

Цитата:
о вот загадка... если Эльбрус - VLIW и числодробилка, почему же он тогда просирает не только GPU, но даже и классическим CISC на САМОЙ приятной для числодробизма задаче - цифровой фильтрации сигнала???
Ну так DSP из Эльбруса-4С убрали. Размер регистров они дурной выбрали видимо под шифрование ГОСТ затачивали, поэтому на ЦОС он и ложаит. На самом деле это поправимо. С небольшим изменением, но нужно время на проработку. В следующей версии можно будет исправить вот только через сколько лет эта следующая будет?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 май 2014, 20:53 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1057
http://corp.cnews.ru/news/top/index.sht ... /19/561160
А завод оказывается на 65нм тоже скоро будет. :ugeek: Есть повод над чем подумать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 21 май 2014, 23:52 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
Yoda писал(а):
Ну GPU выигрывают не только потому что они VLIW.


Графические процессоры -- не VLIW, они имеют как раз короткие, а не "очень длинные" команды. Высокая производительность -- из-за того, что это векторные процессоры, а не скалярные. Но, есно, реализуется это лишь на задачах, хорошо поддающихся векторизации. На каких-нибудь задачах управления оборудованием (где основная масса команд сводится к проверке/установки битов и условным переходам) они будут безнадёжно проигрывать обычному процессору, особенно по критерию производительность/цена (толку от 100500 АЛУ в составе процессора, если при решении задачи работает только одно? А деньги за все платить приходится).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 май 2014, 13:30 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
pavia писал(а):
Ошибаетесь, нужна всеголишь уязвимость. Для этого даже есть термин эксплоит.
...
Необязательно. Эксплоит может работать и на срыве указателей.

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

pavia писал(а):
Может быть вы не в теме. Но судя по всему вы поддались на домыслы журналистов или фантазии разработчиков.

Нет, я просто невнимательно прочёл, действительно, тестируется не серийный, а опытный образец Эльбрус-4С.

pavia писал(а):
3. Насколько я помню Эльбрус-4С не совместим с предыдущим поколением по входам. А следовательно нужна материнская плата и южный мост, а их пока нет.

Их можно сделать на FPGA.

pavia писал(а):
Дело в том что современные универсальные процессоры очень похожи. Что Intel что ARM что Эльбрус.
Во всех есть несколько вычислителей: умножитель, сумматор, блок логики, порт для доступа к памяти. В некоторых их не по одному а по несколько. К VLIW архитектуре отношу у тех которые можно запрограммировать одной командой. Но intel и ARM не сильно отличаются там есть тот же VLIW на уровне микрокоманд.

Ну вы даёте. С таким же успехом можно утверждать, что все животные похожи, потому что у всех есть конечности, глаза, сердце, мозг и другие органы. Между RISC и CISC есть довольно важное внутреннее отличие - RISC как правило обходится без микрокода (собс-но, в этом и была основная идея создателей концепции). У ARM нет "VLIW на уровне микрокоманд", т.к. это идёт вразрез с концепцией RISC. Теоретически, конечно, ничего не мешает сделать ARM с микрокодом, но смысла в этом не много. Что там (в рассмотрении остались CISC) на уровне микрокода VLIW - не играет никакой роли, т.к. под "архитектурой" подразумевают архитектуру, видимую программистом (ISA или Big Architecture).

pavia писал(а):
VLIW можно сделать ещё более энерго эффективным. Если не декодировать команды на каждом такте а загрузить в регистр одну ну очень большую команду и крутить её в счётчике команд. Именно таким занимается NVIdia в своём GPU. Для 3D без смены команды в среднем исполняется до 8х8x4=256 циклов. А то и по более.

Это вообще не в тему. VLIW = параллельное выполнение инструкций. Одну команду можно "крутить" только в том случае, если всё тело цикла удалось запараллелить, что редко удаётся. Я сомневаюсь, что вы знаете в деталях, чем занимается NVidia в своём GPU, т.к. на графические процессоры также не существует открытой документации. Но ваше видение явно не соответствует видению профессоров иллинойсского университета David Kirk и Wen-mei Hwu, изложенному в их книге "Programming Massively Parallel Processors". Эта книга как раз посвящена расчётам GPGPU на NVidia.

pavia писал(а):
Цитата:
Почему же тогда до сих пор никто не сделал "просто универсальную числодробилку", которая рвёт в клочья всех остальных? Ведь это же так просто - сделаем на кристалле стопитсот умножителей и все дела.

Как это не сделали? Современный ATI GPU имеет 4096 умножителей и каждый год увеличивают. Умножители с сумматором поэтому производительность в 2 раза выше. Почему не сделали больше? Ну так больше не влезает в кристалл, так как по мимо умножителей есть, нужны другие блоки. Для 3D ещё sin cos, корень тоже надо считать по хорошему за 1 такт.

Ну вы юморист :). Опять у вас всё просто получается, как и выше с процессорами - "все одинаковые потому что блок регистров, АЛУ и декодер команд". Однако же вот вопрос, почему Illiac IV, - одна из первых систем с массовым параллелизмом (SIMD), - показывала хорошие пиковые результаты, но довольно посредственные средние? Потому что недостаточно регистров, умножителей, сумматоров, синусов и косинусов. Потому что ГЛАВНАЯ разница между ними - архитектура.

pavia писал(а):
Цитата:
о вот загадка... если Эльбрус - VLIW и числодробилка, почему же он тогда просирает не только GPU, но даже и классическим CISC на САМОЙ приятной для числодробизма задаче - цифровой фильтрации сигнала???

Ну так DSP из Эльбруса-4С убрали. Размер регистров они дурной выбрали видимо под шифрование ГОСТ затачивали, поэтому на ЦОС он и ложаит.

Причём здесь наличие или отсутствие блока DSP, когда речь идёт об оценке архитектуры? В этом смысле как раз правильно НЕ использовать специализированные блоки DSP, ГОСТ, AES и любые другие с жёсткой алгоритмической привязкой. ГОСТ, кстати, имеет стандартный размер блока 64 бит, никакой связи с 84-битными регистрами нет.

Лично я в результатах на цифровой фильтрации вижу приговор VLIW и Эльбрусу.

SII писал(а):
Yoda писал(а):
Ну GPU выигрывают не только потому что они VLIW.

Графические процессоры -- не VLIW, они имеют как раз короткие, а не "очень длинные" команды.

Ну тут в свете отсутствия документации действительно сложный вопрос, поэтому я оговорился - "не только". Википедия, например, считает, что некоторые GPU имеют архитектуру VLIW:
Wikipedia писал(а):
VLIW также получила хорошее распространение на рынке GPU, так, видеопроцессоры AMD/ATI Radeon начиная с R600 и до современных имеют VLIW архитектуру. Начиная с Southern Islands (первый квартал 2012) компания AMD/ATI отошла от подхода VLIW.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 май 2014, 15:24 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1057
http://www.x.org/docs/AMD/old/R600_Inst ... ecture.pdf
Берйм доки на AMD открытые. Смотрим формат инструкции, стр 22. Цитату не привожу, так как защита на документе лень снимать.
Инструкция состоит от 2-х до 4 микроинструкций разного назначения. Микрокоманда условных переходов, АЛУ команда, команда чтения текстурного блока и команда чтения векторного блока.
Ниже смотрим.
Групповые инструкции для АЛУ.

Однозначно сказать VLIW это или нет трудно. Думаю что все соглосятся, что нет в виду наличия термина "OpCode"


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 22 май 2014, 16:17 

Зарегистрирован: 15 апр 2014, 14:13
Сообщения: 127
Yoda писал(а):
несмотря на всю открытость архитектуры (в статье прямо говорится, что весь комплекс ПО передаётся заказчику в исходных текстах, а значит и компиляторы), она опять получается сплошь закрытая, в лучших традициях свободного ПО.
Просветите пожалуйста, что не так с лучшими традициями открытого ПО ? Что там закрыто ?
Yoda писал(а):
Внятного описания архитектуры практически нет нигде, открытой "фирменной" технической документации вообще не существует в природе.
Здесь кроется философская проблема - вы копаете непонятно откуда. Вот представим есть у вас "фирменная" техническая документация - и что ? Вы сможете написать софт, показывающий лучшее время на тех задачах, что разработчики представили в виде рекламы собственной разработки ? Они скорее всего затачивали свой процессор под задачи военных, которые являются основными покупателями товара, под эти же задачи и писали свои примеры - то же гостовое шифрование вот выставили как достижение. И в таких условиях что-то там серьёзно вытянуть на самом низком уровне уже скорее всего не получится.

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

И вот в этом направлении VLIW-архитектура ближе к идеалу, поскольку позволяет компилятору выбирать варианты исполнения более гибко, с меньшими ограничениями, чем налагаемые внутренними декодером и оптимизатором CISC процессора. Но VLIW тем не менее далеко не идеал, потому что и он не даёт компилятору полной свободы, ограничивает своими рамками, хотя и немного расширенными.

А с другой стороны (сторона ЯВУ) вытанцовывается язык, ориентированный на передачу общего алгоритма без указания мелких деталей реализации. Потому что методы оптимизации компилятора применяются обязательно, а вот ручная оптимизация программистом на уровне ассемблера - это исключение из общей практики разработки ПО. И с этой точки зрения Java является хорошим шагом в сторону наращивания возможностей связки процессор-компилятор-ЯВУ. Хотя и Java не идеальна, но однозначно лучше С с указанных позиций (за что ожидаю коллективную ненависть всех С-разработчиков). :)
Yoda писал(а):
В разделе "безопасность" находим достаточно спорные утверждения типа "защита типа Execute Disable Bit в процессорах Intel (или его аналог – No eXecute Bit в процессорах AMD) обходится «на раз-два»" с отсылкой к интернету.
И снова хочется вставить упоминание Java и OS на её основе - там просто нет подобного рода уязвимостей как класса. Ведь всё, что делается на уровне железа и его битов включения/выключения защиты охраняется невозможностью использования указателей в Java. Хотя и здесь возможны хитрые ходы, но по сравнению с С их просто в огромное количество раз меньше.
Yoda писал(а):
В описании защиты Эльбрус есть указание, что "работа в нём происходит только с инициализированными данными".
В Java на уровне спецификации языка прописано такое требование - зачем нам иметь его ещё и в железе ?
Yoda писал(а):
"Практически весь существующий в среде open source код написан так, что использует приёмы программирования, не регламентированные стандартом языка Си. Поэтому запустить ядро ОС или приложения типа LibreOffice полностью в защищённом режиме пока что невозможно".
Действительно непонятно - что за "полностью" защищённый режим ? x86 Protected Mode имеет к нему какое-то отношение ?
Yoda писал(а):
Заметим, что вся архитектура VLIW (рассматривающаяся как перспективная) подвержена "некоторой :D трудоёмкости программирования", т.е. сложности разработки оптимизирующего компилятора под такую архитектуру, что явилось одним из факторов коммерческой неудачи Итаника.
Ну Итаник всё же живёт, хоть и только в серверной нише. А "некоторая" сложность разработки компилятора определит победителей в битве за производительность - кто со сложностью справится лучше - тот и победит.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 56 ]  На страницу 1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB