OSDev

Yoda
Всё не хватает время вам ответить полно и развёрнута. Куча мелких дел. А для ответа требуется много написать.
На самом деле у меня сейчас достаточно большой список на чтение. И интересы сместились со стороны ОС в сторону ПЛИС.

То что мои заявления противоречат "Programming Massively Parallel Processors" вполне возможно. Так как книжка тупая я её даже не пробовал читать, а сразу отправил в корзину. Придётся достать её оттуда.

Но советую вам не сомневаться в том о чём я пишу. Так как я эту тему активно прорабатываю не только умственные изыскания, но и сборка материалов. Во-вторых я уже писал что это Ноу-Хау, поэтому пока не хочу раскрывать секреты и отчасти описания туманные. Да не всё так хорошо, как хотелось бы. Повысить производительность процессора в несколько раз, для любого типа кода - возможно.

По поводу того что NVidia не имеет открытой документации. Я уже писал в соседней ветке. Что реверс инженерия драйверов NVidia завершена. А то что не смогли NVIdia согласилась раскрыть. NVidia я пока не изучал детально в виду того что у меня не было их видео карты. Буквально полмесяца назад появилась. Так что возможно более детально займусь видео картами.


Важная часть архитектуры это то какие команды позволяет выполнять процессор. Более того в большинстве случаев под архитектурой имеются именно набор команд. Так вот поэтому при сравнение архитектур обязательно стоит учитывать наличия специальных команд для ЦОС.
Убрав блок DSP они убрали команды для выполнения ЦОС.
Я знаю что стандартный размер блока ГОСТ 64 бит, но как ещё объяснить размер регистров в 84 бита? Как кроме идеи о том что они используются при шифровании. Под словом ГОСТ я имел в виду отечественное шифрование. А не имя собственное шифра.

Речь идёт о том, что разработчики свободного ПО обычно считают, что уже сам факт открытых исходников является лучшей документацией, поэтому вообще не считают необходимым готовить какую бы то ни было документацию. Однако, в статье Николая Безрукова показано, что этот фактор парадоксально хорошо работает в качестве "сокрытия" информации.


Нет, я всего лишь хотел оценить архитектуру.


Для шифрования не нужен новый процессор. Это делается гораздо проще и дешевле.


Вот я часто сталкиваюсь с подобной ошибкой, как со стороны разработчиков, так иногда и со стороны потребителей. Я её называю "мнимыми ожиданиями". Обычно это выглядит так: "вот мы сейчас сделаем XXX, а потом кому-то останется сделать YYY и всё будет в шоколаде". Например, покупатель берёт компьютерную железку производителя "А", у которого софт из рук вон плох, расчитывая, что производитель конечно же выпустит обновления софта. 5-10 лет ждёт, а потом выясняет, что производитель даже не собирается выпускать драйвер для железки под новую ОС, а про софт вообще молчим. В случае компилятора для ожиданий должны быть предпосылки, что такой компилятор возможен, по силам, и вообще кто-то будет им заниматься. Также, неплохо бы изучить имеющийся опыт классических VLIW-систем. Но, к сожалению для Эльбруса, даже при монструозной сложности компиляторов, таких как Open64, заточенных под Итаник, этот Итаник не показывает выдающихся результатов ни в чём, несмотря на значительные усилия по продвижению со стороны Intel и на то, что процессоры серийно выпускаются с 2001 года.


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


К сожалению, даже самый умный компилятор не способен решить довольно простые (в плане формулировки) задачи. Сложность систем с элементарными правилами легко может расти экспоненциально, а большинство задач оптимизации как раз NP-сложные. Давайте для примера хотя бы вспомним, что Java-компилятор не способен самостоятельно определить, где именно можно освободить объект (хотя мог бы, в соответствии с вашим доводом), поэтому решает задачу в лоб - сборщиком мусора.


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


Затем, что мы обсуждаем достоинства/недостатки процессора, а не джавы/ЯВУ.

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

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


Объяснить можно примерно так же, как и 82-битные регистры в Итанике. Таков там формат плавающей точки.

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

Да, отсутствие документации сильно портит любую сложную систему. Правда сообщество ПО с открытым кодом вполне осознало такой факт и давно сформулировало и реализует обязательность тщательного документирования. Хотя возможно тот же Линух до сих пор находится в крайне убогом состоянии в плане документации. И тем не менее - не отличающиеся кардинально по уровню документированности системы с открытым и закрытым кодом отличаются кардинально по возможности их доработки и использования.
Речь шла о требованиях, включающих и шифрование и универсальный процессор одновременно. Такой подход наложил отпечаток на готовый продукт. Так же видимо обязательным было наличие расширенных возможностей по обработке сигналов, поэтому в процессор включили DSP. Почему убрали в последней версии - не знаю.
До какого-то момента любую идею можно назвать "мнимым ожиданием". Но когда-то идеи реализуются и, сколько бы их не называли "мнимыми", начинают работать. Не стоит отвергать идеи на основе неудач других идей, ибо конечный результат такого подхода - запрет всех идей.
Ну возьмём ту же Java - от чистого интерпретатора она дошла до весьма совершенного JIT компилятора, выдающего код с производительностью кода на С. И это динамический компилятор, который сильно ограничен временем выполнения и доступной памятью. То есть на возражение о возможности компилятора я вам отвечаю работающим примером. На возражение "по силам" - привожу тот же пример. На возражение "кто-то будет им заниматься" отвечаю - этим занимаются такие конторы, как Oracle, Microsoft, IBM, Google, Intel, AMD и куча других. Развитие компиляторов есть крайне важная составляющая стратегии развития платформ, на которых упомянутые конторы делают деньги.
Ну вот сами подумайте - нет результата ни в чём, но тогда зачем вкладывать деньги в такой никчёмный продукт ? А ведь деньги вкладывают непрерывно с 2001 года.
Оптимизация на уровне процессора заведомо проигрывает оптимизации компилятором из-за наличия у компилятора неограниченных ресурсов памяти и времени. Единственный плюс процессора - наличие информации в момент выполнения программы о её конкретном текущем состоянии. Но и такая информация опять же обрабатывается простеньким процессорным алгоритмом со всеми соответствующими ограничениями (память, время). Компилятор может просто заменять зависящий от информации времени выполнения алгоритм на более подходящий в зависимости от задачи, а вот процессор так делать никогда не сможет.
Не так. Java компилятор давно умеет самостоятельно определять, где именно можно освободить объект, но он не умеет это определять всегда и для всех случаев. Поэтому для обеспечения работоспособности во всех случаях используется сборщик мусора. Но в частных случаях давно и эффективно оптимизируются задачи выделения и освобождения памяти. Простой пример - вместо стандартного выделения памяти в куче мест программы просто увеличивается стек данных ровно на величину требуемого нового объекта, а по выходу из метода стек автоматически освобождается от всего связанного с методом. То есть компилятор определяет, что некий объект существует только в пределах данного метода и переносит место его хранения в стек. Это называется escape analysis, применяется весьма давно и многими разработчиками компиляторов. Замечу, что для С подобный финт ушами получится гораздо более сложным, поэтому в сишных компиляторах наверняка такая фича мало распространена.
Архитектура здесь вряд ли важна, ведь любая архитектура просто экранируется интерфейсом Java. Ну а взаимодействие с другим кодом для ОС на Java не столь актуально. Хотя вполне возможно из Java формировать сишный стек, выделять некий регион в памяти и передавать управление процедуре, скомпилированной из исходников на С.
Вот как раз данный случай показывает недостаток процессора - в системе ориентированной на компилятор такой процессор будет содержать заведомо незадействуемую функциональность.

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


Мне кажется, что для решения этой задачи достаточно сделать ARM-ядро с необходимыми дополнительными аппаратными модулями. Будет гораздо дешевле.


В статье сказано - потому что его "немножко сложно программировать".


Нет, совсем не любую. Для мнимого ожидания необходима двухфакторность, - разбиение задачи на две части, бросание сил на одну часть и забивание на вторую. Когда мы говорим про "идею", подразумевается, что она выводит нас к решению всей проблемы. В случае VLIW/EPIC как раз ситуация отложенного решения второй части. Я не спорю, может быть и можно создать суперкомпилятор, который будет генерить суперкод, но это как раз более сложная половина задачи, причём в лучших традициях "железо мы сделаем сейчас, а софт как-нибудь потом созреет".


Не-не-не, джава - плохой пример.
1. Джава никогда не ставила целью бить рекорды эффективности, основная задача была - переносимость и мобильные приложения.
2. Радикальных отличий в синтаксисе и семантике языка между С и джавой нет, это языки, условно говоря, одной группы. Поэтому в джаве нет каких-то специфических выразительных средств, которые позволили бы лучше закодировать алгоритм.
3. Для работы джавы используется двухстадийная компиляция - сначала в байткод, затем в код целевой машины. Такая двухстадийная компиляция по определению не может генерить код лучше, чем одностадийная сразу в целевой код. Тем более, что джава байт-код не содержит высокоуровневых мощных инструкций, это очень простая стековая машина, а значит JIT-компилятору также (помимо самого Java компилятора) необходимо иметь семь пядей во лбу, чтобы низкоуровневые операции закодировать высокоуровневыми, если таковые имеются в целевой машине и разобрать все зависимости данных.
4. Да, конечно, за годы своего существования джава смогла на некоторых задачах приблизиться по эффективности к С, но ставить знак равенства между ними никак нельзя. Что-то никто не оценивает производительность архитектуры, замеряя секундомером время работы сжатия данных, цифровой фильтрации сигнала, шифрования ГОСТ, реализованных на Джаве. Точно также, никто не гоняет джаву на суперкомпьютерах для моделирования погоды, физических процессов, аэродинамики и пр. Почему? Да потому что пропагандируемая адептами и изрядно набившая оскомину высокая производительность джавы - миф!
5. Про оптимизацию и сбор мусора сразу вынесу сюда же. Нельзя быть немножко беременным. Либо мы смогли решить задачу освобождения, и тогда нет необходимости запускать сборщик мусора, либо мы обошлись полумерами типа аллокирования на стеке, тогда мусор неизбежен. Мы только немножко облегчили сборщику работу.
Для ясности - джава создавалась для других целей и "натягивать" её на несвойственные для неё задачи не стоит. Тем более универсализировать.


Для меня самого это большая загадка.


Ничего подобного! Компилятор и процессор как правило решают разные задачи оптимизации!
Компилятор выбирает нужные инструкции, процессор их только выполняет.
Компилятор минимизирует взаимозависимости между данными, но во время выполнения только процессор может знать, действительно ли они готовы.
Компилятор может предполагать статистику переходов, но только процессор имеет рантайм-информацию.
По поводу зависимости оптимизации от технологического уровня. Первые RISC-процессоры ставили задачу упрощения логики, современные РИСКи вернулись к тому, от чего ушли - есть и предсказание переходов и даже out-of-order execution. Хорошо, пусть VLIW-компилятор разложил нам всё по полочкам и сказал - "вот эти инструкции можно выполнять одновременно". А как быть с зависимостями между двумя последовательными блоками VLIW-инструкций? Казалось бы мы передали работу компилятору, но оказывается, что процессор всё равно на том же основании может оптимизировать работу и здесь. Так зачем же сначала его упрощали?
С другой стороны, мы рассчитываем, что в каком-то поколении инструкция XXX выполняется 20 тактов, а инструкция YYY 10 тактов, данные от обоих используются в третьей. Компилятор закладывает сначала инструкцию XXX, затем YYY. Проходит время, площадь кристалла стала больше, алгоритмы поменялись, и теперь инструкция XXX выполняется за 5 тактов, а процессор мы лишили возможности сменить порядок выполнения, отдав всё на откуп компилятору. Результат: код работает менее эффективно, чем мог бы, если бы мы оставили оптимизацию на кристалле.
Мне думается, что попытки отдать всё на откуп умному компилятору неперспективны.
Тут два важных момента:
1. Задачи оптимизации чаще всего разные.
2. Компилятор предполагает (как оно будет работать), но знать (что происходит прямо сейчас) может только процессор.


Ну если бы Эльбрус позиционировался для джавы, то да. Хотя подобное предположение вызывает у меня .

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

По этому вопросу я согласен с Эмбрионом. Дело в том что если отдать оптимизацию процессору, то из за физической реализации. Мы имеем то что задержка от которых невозможно избавиться. В любом конвеере есть слоты задержки. Когда как в VLIW их не.
Поэтому доводы о состояние рантайм не уместны.

Скорость команд меняется редко. Хотя примерно такое можно наблюдать на АРМ когда хитрый оптимизатор не учитывает что в проце деление стало выполняться 10 такта вместо 150 и подсовывает код который делает за 90-120 тактов.

Как раз подгонка P-coda под данный процессор решает эту проблему. Можно выделить два подхода JIT или хранение кода после одного раза оптимизации. Эльбрус использует второй подходи и в ихней области где софт заточен под конкретную платформу это подходит. Но не для ARM где один софт вынужден крутиться на разных процессорах.

Большое спасибо за термин! Теперь буду знать, что это так называется. У меня эта фишка предусмотрена архитектурно и отражена в синтаксисе языка.

Раз уж всё равно пишу, кратенько выскажусь по теме. У меня тоже создалось впечатление, что обсуждаемая тут программная неэффективность "Эльбруса" проистекает как раз из-за несовершенства компиляторов под него. Они же не переписывают код, адаптируя под процессор и компилятор, а берут исходники открытых проектов? Открытые проекты в большинстве своем пишутся под вполне конкретный компилятор, создать эффективный аналог которого, боюсь, будет сложнее, чем сделать процессор. Судьба "Итаниума" на это косвенно намекает.

Если же не решать проблему в лоб, а применить хитрость, то под новаторские процессоры нужен не только компилятор, но и средство адаптации исходников с поточного выполнения на кусочно-независимое "фрактальное", выполняемое под контролем человека. Без этого придется или всё переписывать, или давиться недостаточной оптимизацией. А железячники старались, им обидно.

Слушал я вас долго и внимательно и, наконец, понял: дураки вы все (с) ))



Добавлю: приличную скорость работы жаба-приложения демонстрируют как раз на процессорах традиционной архитектуры, IA-32, например, а отнюдь не на VLIWах. Так что "работающего примера" именно для VLIW показано пока что не было. Ну а что до скорости жабы... Sun как-то демонстрировала её -- но в качестве противника выбирался исключительно GCC, а не Visual Studio или тем более интеловский компилятор.



Ну дык сначала думали, что продукт очень даже кчёмный, а теперь приходится поддерживать уже проданное. Ведь не безделушки продавали, а серверы, причём для серьёзных компаний.



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

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

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

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

Изначально Гослинг (создатель Java) мыслил примерно так - есть нравящийся мне С, но у него есть много недостатков, я хочу его улучшить. И в результате получилась Java. То есть ставилась задача получить лучший чем С язык программирования. А к каким задачам применять этот язык - так же не было важно, как и при разработке языка С. Точнее круг задач просто оставался неизменным - программирование универсальных алгоритмов.

Я уже вам говорил, что радикальным является уход от небезопасных конструкций вроде работы с указателями и разного рода наплевательства на структуры данных (от юнионов и до любых структур воспринимаемых как байты или ещё неизвестно что). Такое ограничение позволяет компилятору гораздо меньшими усилиями добиваться гораздо лучшей оптимизации. Потому что количество вариантов, которые нужно учесть в случае использования указателей, получается просто огромным (а если на самом деле по этому адресу не строка, а неизвестно что ?).

На самом деле всё не так. Во первых - стадийность компиляции нужно отделить от байткода. Стадийность рассмотрим ниже. А вот байткод - это не "низкоуровневые операции", а код точно такого же уровня, что и исходный текст на Java. То есть в цепочке Java-текст - компилятор - байткод - декомпилятор - Java-текст имеем практически 100% сохранение информации. То есть теряются комментарии, некие конструкции могут выглядеть чуть по другому, но в целом - практически 100% исходного текста на Java сохраняется. И сравните теперь с такой же цепочкой для пары С - ассемблер. Поэтому для компилятора байткод является очень даже качественным входом, минимально ограничивающим разработчика компилятора.

Если хотите - давайте сравним достаточно сложную обработку на Java и С. Например работу парсера XML. Это довольно просто сделать, ведь подобные парсеры являются стандартными и распространёнными библиотеками.

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

Они делают шаги, видят цель, цель считается оправдывающей ожидания. Они просто движутся медленно, не кидают все ресурсы в эту область, ведь это бизнес - сначала нужно навариться на старых технологиях. Вот появится в этой области серьёзный конкурент (Эльбрус?) и тут же прогресс станет заметно интереснее.

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

РИСКи это не VLIW. Первые ограничивают компилятор, а вторые дают возможность выбора оптимального (в неких пределах, разумеется) сочетания данных и их обработки. То есть RISC процессоры не вписываются в концепцию "всё для компилятора".

Так не может процессор, вот ведь в чём беда. Вы поймите простую вещь - что бы что-то там соптимизировать, нужны МОЗГИ, то есть сложный алгоритм плюс куча памяти плюс куча времени на работу алгоритма. Это всё есть у процессора ? Надеюсь ответ очевиден.

Когда делают новый процессор, обязательно сочиняют для него оптимизатор. Теперь представим другую ситуацию - когда делают процессор, сочиняют оптимизатор не для него, а просто допиливают компилятор, указывая ему на новые возможности процессора. Согласитесь, что затраты будут ни чуть не хуже случая для компилятора. А далее, что бы не перекомпилировать все на свете программы, мы просто используем виртуальную машину, в которой и заменяем её JIT компилятор на обновлённый. В результате имеем оптимальное выполнение задач на любом процессоре при помощи кросплатформенного байткода, компилируемого в оптимальный машинный код "на лету". Это и есть идеология Java.

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

По сути эта самая необходимость перекомпиляции всех программ и удерживает человечество в рамках порочного подхода с размещением оптимизатора в процессоре вместо компилятора. А JavaOS даёт нам возможность выйти из этого тупика.