OSDev

для всех
Текущее время: 17 ноя 2018, 03:04

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




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

Зарегистрирован: 15 апр 2014, 14:13
Сообщения: 127
Freeman писал(а):
под новаторские процессоры нужен не только компилятор, но и средство адаптации исходников с поточного выполнения на кусочно-независимое "фрактальное", выполняемое под контролем человека.

Это средство обычно называют хинтами. Распространённый способ реализации - аннотации. А в С это прагмы. Но аннотации универсальнее и красивее.


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

Зарегистрирован: 15 апр 2014, 14:13
Сообщения: 127
SII писал(а):
приличную скорость работы жаба-приложения демонстрируют как раз на процессорах традиционной архитектуры, IA-32, например, а отнюдь не на VLIWах.

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

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


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

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

Это в каких задачах SIMD бесполезны? В строках SIMD выигрывает. А сейчас большинство информации текстовая. Матрицы и вектора выигрывают. Обработка изображений выигрывают. Звук выигрывают. Рендеринг выигрывают.
По поводу матриц на домашнем ПК. С появлением векторных шейдеров(Лет 15 назад) большинство матриц считается на GPU.
Что касается заточки процессора против универсального. Да с этим согласен. Но всё же думаю можно покрыть большинство задач если сделать так:
Взять GPU и добавить туда несколько логических процессоров для обработки так называемого мажеритоарного кода это не проблема. Производительности должно хватить. Самый простой процессор весит 700 логических элементов. 8086 весил около 8000. Так что спроектировать специальный процессор на 1 000 000 вполне несложно. А это менее 0.1% от текущих кристаллов.
При этом думаю будет проще заточить один специальный процессор чем универсальный.

SII Надеюсь Вы не сильно на меня обиделись за прошлые сообщения.


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

Зарегистрирован: 15 апр 2014, 14:13
Сообщения: 127
pavia писал(а):
можно покрыть большинство задач если сделать так:
Взять GPU и добавить туда несколько логических процессоров для обработки так называемого мажеритоарного кода это не проблема.

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


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

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 946
Откуда: Дагоба
Freeman писал(а):
эмбрион писал(а):
компилятор определяет, что некий объект существует только в пределах данного метода и переносит место его хранения в стек...

...У меня эта фишка предусмотрена архитектурно и отражена в синтаксисе языка.

Прошу прощенья, а зачем отражать в синтаксисе? И каким образом?

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

<<< OS Boot Tools. >>>


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

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

Я выделил жирным шрифтом ключевое слово в цитате. Изменения в джаве касаются именно безопасности, а не производительности. Остальные рассуждения по поводу оптимизации притянуты за уши. Если "на самом деле по этому адресу не строка, а неизвестно что", то компилятор должен верить сказанному и смело оптимизировать обращение как к строке, а проверки безопасности и сомнения компилятора наоборот снижают скорость.
По поводу радикальных отличий в синтаксисе и семантике языка. То, что Джава бьёт по рукам ограничивает программиста - не есть выразительные средства языка. Чтобы понять, о чём я говорю, сравните Джаву с MatLab/R, Occam, Chapel, огромной группой функциональных языков. В Джаве ничего принципиально нового/важного по сравнению с С++ не добавлено (кроме многократно обсуждавшегося сбора мусора).

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

Да ладно!!!

эмбрион писал(а):
То есть в цепочке Java-текст - компилятор - байткод - декомпилятор - Java-текст имеем практически 100% сохранение информации.

Ну в этом не может быть сомнений, любые тьюринг-полные языки взаимно конвертируемы.

эмбрион писал(а):
То есть теряются комментарии, некие конструкции могут выглядеть чуть по другому, но в целом - практически 100% исходного текста на Java сохраняется. И сравните теперь с такой же цепочкой для пары С - ассемблер.

Что-то у меня серьёзные сомнения в том, что вы знакомы с байткодом Java. Вы действительно полагаете, что там высокоуровневые конструкции? Может быть, ARM с появлением Jazelle сразу стал высокоуровневым процессором? Или picoJava? А если вы полагаете, что сходная аппаратная стековая машина позволяет называть машинный код высокоуровневым, то отмечу, что стековые микропроцессоры (транспьютеры) компании Inmos производились ещё в 80-х годах и никто не называл их высокоуровневыми. Или вот цитата из википедии, прямо сравнивающая байткод с ассемблером: "как следует из публикации в журнале IBM developerWorks, «понимание байт-кода и понимание механизмов его генерации компилятором Java помогает Java-программисту так же, как и знание языка ассемблера помогает программисту, пишущему на Си или C++»."

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

Да вы шутите, - он вообще убогий! Там даже поддержки циклов нет! Уж не говоря про десятки других операций, поддерживаемых современными процессорами и отсутствующих в Java bytecode.
http://docs.oracle.com/javase/specs/jvm ... vms-6.html
Также промолчу, что операции, традиционно занимающие одну инструкцию почти во всех архитектурах, нужно переводить в несколько команд для стековой машины.

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

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

Вот вы (и pavia с его нерусским языком), похоже, заблуждаетесь одинаково. И мой намёк "во время выполнения только процессор может знать, действительно ли они готовы" как-то пролетел мимо сознания. Вы полагаете, что оптимизация со стороны процессора заключается в титанических усилиях по анализу кода и гениальных выводах отдельного блока оптимизации. Возможно, процессоры, которые транслируют поток инструкций во внутреннее представление (Intel/AMD), что-то и делают в таком роде. Однако для реализации внеочередного выполнения инструкций ничего этого не надо. Достаточно иметь теневые регистры, очереди в функциональные блоки и блокировки на регистры. Компилятор не знает и не может знать, сколько наносекунд будет исполнятся команда - одна и та же команда в одном и том же месте может легко отличаться по времени выполнения в сотни раз. Однако, процессор без "блоков гениальной оптимизации" может начать выполнение следующей инструкции после застопорившейся, а если есть зависимость данных, то он это без труда определит и возобновит выполнение уже в следующем такте, как появится возможность.

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

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

Блин, да что вы чушь несёте? Почитайте наконец теорию, чтобы предметно говорить, хотя бы для начала две статьи в википедии - внеочередное исполнение инструкций и алгоритм Томасуло. А лучше книгу Хеннеси и Паттерсона "Архитектура компьютеров".

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

Возможно вы сильно удивитесь, но логика предсказания переходов (даже динамического) добавляет не более нескольких сотен гейтов. Посмотрите, например, сравнительную справочную информацию по серии процессорных ядер Nios II.

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

<<< OS Boot Tools. >>>


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

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1092
Цитата:
Достаточно иметь теневые регистры, очереди в функциональные блоки и блокировки на регистры

Вы сами согласились что есть блокировки. А у VLIW их нет. По поводу операций переменного времени исполнения. Их можно сделать фиксированным с очень маленькой задержкой к примеру 1 такт. Тогда ничего не будет мешать оптимизатору.


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

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 946
Откуда: Дагоба
pavia писал(а):
Вы сами согласились что есть блокировки. А у VLIW их нет.

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

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

Далее...
pavia писал(а):
По поводу операций переменного времени исполнения. Их можно сделать фиксированным с очень маленькой задержкой к примеру 1 такт.

А вот это прочли?:
Yoda писал(а):
Компилятор не знает и не может знать, сколько наносекунд будет исполнятся команда - одна и та же команда в одном и том же месте может легко отличаться по времени выполнения в сотни раз.

Поэтому фиксированными задержки вы никак не сделаете.

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

<<< OS Boot Tools. >>>


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

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1092
Yoda писал(а):
Далее...
pavia писал(а):
По поводу операций переменного времени исполнения. Их можно сделать фиксированным с очень маленькой задержкой к примеру 1 такт.

А вот это прочли?:
Yoda писал(а):
Компилятор не знает и не может знать, сколько наносекунд будет исполнятся команда - одна и та же команда в одном и том же месте может легко отличаться по времени выполнения в сотни раз.

Поэтому фиксированными задержки вы никак не сделаете.

У вас причинно-следственность нарушенна. Еще раз я делаю все команды равными 1 такту. Я могу это сделать, так как нет на это запрета. И оптиимизатор мне не может этого запретить. Когда я это сделал, то компилятор точно будет знать что инструкции выполняются ровно 1 такт.
Почему это можно сделать? Да потому что для всех командах: деление, sin/cos, корень, экспонента существуют ряды которые сходятся за конечное число интераций. Т.е все эти итерации можно закодировать в железе.
К примеру деление в ARM Cortex-M3 выполняется от 2 до 12 тактов. Но никак не сотни.


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

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

Объясните мне, пожалуйста, как вы собираетесь грузить за фиксированное время (тем более за один такт) данные из памяти.

pavia писал(а):
Да потому что для всех командах: деление, sin/cos, корень, экспонента существуют ряды которые сходятся за конечное число интераций. Т.е все эти итерации можно закодировать в железе.
К примеру деление в ARM Cortex-M3 выполняется от 2 до 12 тактов.

Вот вы сами пишете - от 2 до 12 тактов и говорите при этом про фиксированное время. Вы сами себе не противоречите? А то, что скорость сходимости функций зависит от аргумента, знаете?

pavia писал(а):
Но никак не сотни.

"Секреты кэш-памяти, или как потратить 1000 тактов на 10 команд".
"Разработка на PC и производительность — Memory Latency".
Из второй статьи: латентность памяти на современном десктопе более 200 тактов, что означает, что промах кеша стоит на порядки больше даже самых тяжелых инструкций процессора.

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

<<< OS Boot Tools. >>>


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

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


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

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


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

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