OSDev

для всех
Текущее время: 16 окт 2018, 06:18

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




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

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

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

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

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

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

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

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


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

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 945
Откуда: Дагоба
эмбрион писал(а):
Yoda писал(а):
несмотря на всю открытость архитектуры (в статье прямо говорится, что весь комплекс ПО передаётся заказчику в исходных текстах, а значит и компиляторы), она опять получается сплошь закрытая, в лучших традициях свободного ПО.

Просветите пожалуйста, что не так с лучшими традициями открытого ПО ? Что там закрыто ?

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

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

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

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

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

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

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

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

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

эмбрион писал(а):
А с другой стороны (сторона ЯВУ) вытанцовывается язык, ориентированный на передачу общего алгоритма без указания мелких деталей реализации... И с этой точки зрения Java является хорошим шагом в сторону наращивания возможностей связки процессор-компилятор-ЯВУ.

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

эмбрион писал(а):
Yoda писал(а):
В разделе "безопасность" находим достаточно спорные утверждения типа "защита типа Execute Disable Bit в процессорах Intel (или его аналог – No eXecute Bit в процессорах AMD) обходится «на раз-два»" с отсылкой к интернету.

И снова хочется вставить упоминание Java и OS на её основе - там просто нет подобного рода уязвимостей как класса.

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

эмбрион писал(а):
Yoda писал(а):
В описании защиты Эльбрус есть указание, что "работа в нём происходит только с инициализированными данными".

В Java на уровне спецификации языка прописано такое требование - зачем нам иметь его ещё и в железе ?

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

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

<<< OS Boot Tools. >>>


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

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 945
Откуда: Дагоба
pavia писал(а):
при сравнение архитектур обязательно стоит учитывать наличия специальных команд для ЦОС.
Убрав блок DSP они убрали команды для выполнения ЦОС.

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

pavia писал(а):
Я знаю что стандартный размер блока ГОСТ 64 бит, но как ещё объяснить размер регистров в 84 бита? Как кроме идеи о том что они используются при шифровании.

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

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

<<< OS Boot Tools. >>>


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

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

В Java на уровне спецификации языка прописано такое требование - зачем нам иметь его ещё и в железе ?

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


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

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

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

эмбрион писал(а):
Речь шла о требованиях, включающих и шифрование и универсальный процессор одновременно.

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

эмбрион писал(а):
в процессор включили DSP. Почему убрали в последней версии - не знаю.

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

эмбрион писал(а):
До какого-то момента любую идею можно назвать "мнимым ожиданием". Но когда-то идеи реализуются и, сколько бы их не называли "мнимыми", начинают работать.

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

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

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

эмбрион писал(а):
Ну вот сами подумайте - нет результата ни в чём, но тогда зачем вкладывать деньги в такой никчёмный продукт ? А ведь деньги вкладывают непрерывно с 2001 года.

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

эмбрион писал(а):
Оптимизация на уровне процессора заведомо проигрывает оптимизации компилятором из-за наличия у компилятора неограниченных ресурсов памяти и времени.

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

эмбрион писал(а):
Вот как раз данный случай показывает недостаток процессора - в системе ориентированной на компилятор такой процессор будет содержать заведомо незадействуемую функциональность.

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

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

<<< OS Boot Tools. >>>


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

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1089
Цитата:
Ничего подобного! Компилятор и процессор как правило решают разные задачи оптимизации!

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

Цитата:
С другой стороны, мы рассчитываем, что в каком-то поколении инструкция XXX выполняется 20 тактов, а инструкция YYY 10 тактов, данные от обоих используются в третьей. Компилятор закладывает сначала инструкцию XXX, затем YYY. Проходит время, площадь кристалла стала больше, алгоритмы поменялись, и теперь инструкция XXX выполняется за 5 тактов, а процессор мы лишили возможности сменить порядок выполнения, отдав всё на откуп компилятору. Результат: код работает менее эффективно, чем мог бы, если бы мы оставили оптимизацию на кристалле.
Скорость команд меняется редко. Хотя примерно такое можно наблюдать на АРМ когда хитрый оптимизатор не учитывает что в проце деление стало выполняться 10 такта вместо 150 и подсовывает код который делает за 90-120 тактов.

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


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

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
эмбрион писал(а):
компилятор определяет, что некий объект существует только в пределах данного метода и переносит место его хранения в стек. Это называется escape analysis, применяется весьма давно и многими разработчиками компиляторов.

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

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

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


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

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1346
Откуда: Зеленоград
Yoda писал(а):
Но это отдельная тема для холивара.


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

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

Не-не-не, джава - плохой пример.


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

Цитата:
эмбрион писал(а):
Ну вот сами подумайте - нет результата ни в чём, но тогда зачем вкладывать деньги в такой никчёмный продукт ? А ведь деньги вкладывают непрерывно с 2001 года.

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


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

эмбрион писал(а):
Вот как раз данный случай показывает недостаток процессора - в системе ориентированной на компилятор такой процессор будет содержать заведомо незадействуемую функциональность.


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


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

Зарегистрирован: 10 апр 2012, 23:19
Сообщения: 277
не прошло и тысячелетия,
наши наконец то свой процессор сделали,
а на что он нужен такой, уже весь рынок занят круче интела уже ничего не будет.


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

Зарегистрирован: 15 апр 2014, 14:13
Сообщения: 127
Yoda писал(а):
эмбрион писал(а):
Речь шла о требованиях, включающих и шифрование и универсальный процессор одновременно.

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

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

Согласен, радикально улучшить производительность можно только начав с главного - с компилятора. И опять согласен - он гораздо сложнее. Но ведь в нашей попильной экономике далеко не всегда "как лучше" важнее чем "лишь бы хоть что-то".
Yoda писал(а):
1. Джава никогда не ставила целью бить рекорды эффективности, основная задача была - переносимость и мобильные приложения.

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

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

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

Если хотите - давайте сравним достаточно сложную обработку на Java и С. Например работу парсера XML. Это довольно просто сделать, ведь подобные парсеры являются стандартными и распространёнными библиотеками.
Yoda писал(а):
5. Про оптимизацию и сбор мусора сразу вынесу сюда же. Нельзя быть немножко беременным. Либо мы смогли решить задачу освобождения, и тогда нет необходимости запускать сборщик мусора, либо мы обошлись полумерами типа аллокирования на стеке, тогда мусор неизбежен.

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

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

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

Я уже указывал ответ на такое возражение - процессор это тупой исполнитель алгоритма, а этот алгоритм ему можно давать в виде "прошивки" или в виде программы. Прошивка одна и неизменна, а программа может быть любой. И вот в такой ситуации при наличии хорошего компилятора он просто выдаст процессору наиболее подходящий для задачи алгоритм, в то время как процессор с прошивкой никогда не сможет "думать по другому", что гарантирует его проигрыш при отходе от одной единственной задачи, на которую оптимизирован прошитый алгоритм.
Yoda писал(а):
Первые RISC-процессоры ставили задачу упрощения логики, современные РИСКи вернулись к тому, от чего ушли - есть и предсказание переходов и даже out-of-order execution.

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

Так не может процессор, вот ведь в чём беда. Вы поймите простую вещь - что бы что-то там соптимизировать, нужны МОЗГИ, то есть сложный алгоритм плюс куча памяти плюс куча времени на работу алгоритма. Это всё есть у процессора ? Надеюсь ответ очевиден.
Yoda писал(а):
С другой стороны, мы рассчитываем, что в каком-то поколении инструкция XXX выполняется 20 тактов, а инструкция YYY 10 тактов, данные от обоих используются в третьей. Компилятор закладывает сначала инструкцию XXX, затем YYY. Проходит время, площадь кристалла стала больше, алгоритмы поменялись, и теперь инструкция XXX выполняется за 5 тактов, а процессор мы лишили возможности сменить порядок выполнения, отдав всё на откуп компилятору.

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

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

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


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

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


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

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


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

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