OSDev

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

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




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

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
Вот вы зациклились, умным должен быть и компилятор и процессор. Подправить компилятор под новый процессор не велика проблема. В современных компиляторах оптимизация инструкций не зашита в коде компилятора, а описывается декларативно в текстовых скриптах.
PS. По-русски хинт - подсказка (такое слово употребляется в различной документации от MS).


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

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

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

Хотя если речь идёт о том, что "а надо ли париться ?", тогда да - пусть будет монополия и не будет прогресса, ведь нам плевать.


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

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
Давайте немного конкретики, каких данных вам не хватает. Я лично не вижу проблемы. Через MSR читается море информации о микроархитектуре процессора и кэша. Пусть там что-то и упустили из виду, но мне кажется доступно 99% данных, значимых для оптимизации.
Между тем я с вами согласен, что процессор не может оптимизировать алгоритмы программы, каким бы большим он не был. Процессор может быть умным только для себя (в части пакетного выполнения команд, и в части уменьшения собственных накладных расходов), но не для программы. Функциональных процессоров, выходящих за рамки элементарных арифметических операций, ещё не существует.


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

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
эмбрион писал(а):
Yoda писал(а):
эмбрион писал(а):
То есть в цепочке Java-текст - компилятор - байткод - декомпилятор - Java-текст имеем практически 100% сохранение информации.

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

Ну так продемонстрируйте нам подобное на паре С-ассемблер.

Шутки ради
mov -> =
mul -> *
div -> /
jz... -> if(...)
jmp -> goto
call -> function()


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

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
эмбрион писал(а):
Yoda писал(а):
Компилятор не знает и не может знать, сколько наносекунд будет исполнятся команда - одна и та же команда в одном и том же месте может легко отличаться по времени выполнения в сотни раз.

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

С помощью команды rdtsc можно примерно оценить длительность инструкции. Впрочем это не имеет ни какого смысла, т.к. команды с неопределённым количеством тактов не являются спариваемыми, они выполняются монопольно.
Какими внутренностями вы хотите управлять?


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

Зарегистрирован: 15 апр 2014, 14:13
Сообщения: 127
Himik писал(а):
Давайте немного конкретики, каких данных вам не хватает.

Ну вот смотрите, например у нас есть программа, которую можно распараллелить на два потока с вычислением двух значений по двум формулам. Как я могу сказать процессору, что бы он задействовал ровно столько внутренних вычислителей для выполнения каждого потока, сколько необходимо на каждый такт вычисления ? Для простоты пусть пример будет таким:
Код:
int a=x*y;
int b=x-y;

Здесь необходимо выполнить две загрузки из памяти или кэша или регистров (для x и y) - как я могу понять, где конкретно находятся x и y ? Как я могу сказать системе заранее закэшировать эти переменные (за 200 тактов до реального вычитания/умножения) и не трогать это место в кэше ? Как я могу понять, за сколько же на самом деле тактов я должен подсуетиться и прочитать переменные в кэш ? И это только вопросы по операции загрузки двух переменных.

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

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

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

Надеюсь возражения вроде:
Himik писал(а):
Я лично не вижу проблемы.
более не должны так легко озвучиваться :)


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

Зарегистрирован: 15 апр 2014, 14:13
Сообщения: 127
Himik писал(а):
Шутки ради
...
call -> function()

Шутки ради - а как будет выглядеть название function() ?


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

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
эмбрион писал(а):
И при всём при этом как я могу учесть наличие других задач, которые в виде обработчиков прерываний или в виде параллельных потоков потрут все мои кэши и похерят все мои ожидания ? То есть я хотел бы иметь возможность добавить в планировщик задач информацию о гарантированном хранении данных в течении заданного периода в заданном кэше - как я могу это сделать ?

Я считаю, что эти проблемы надуманы. Я полагаю, что в суперскалярных в процессорах используется упреждающее чтение в кэш, и это решает проблемы загрузки данных к нужному времени, точно в нужный момент.
Насчёт автоматического распараллеливания, за это вроде отвечают технологии типа OpenMP, которые уже внедрены в стандарты всех компиляторов. В случае выполнения всего двух вычислений, то компилятор эффективно использует спаривание инструкций в одном ядре, без использования многоядерной параллельности.
Если вам очень интересна тема оптимизации до самых тонкостей, то вам наверно будут интересны статьи небезызвестного Агнера Фога
http://www.agner.org/optimize/
Я давно ещё читал несколько старых статей первых выпусков, пока они ещё были в пределах понимания для рядового программиста. Из них я понял основные моменты и направление мысли, всё остальное - для специалистов, конкретно занимающихся изготовлением компиляторов, не стоит забивать голову.
эмбрион писал(а):
Himik писал(а):
Шутки ради
...
call -> function()

Шутки ради - а как будет выглядеть название function() ?

Можно сказать, что так же. Ассемблерный оператор proc имеет синтаксис сходный с Си - имеет параметры, локальный стек и локальные переменные на нём. По крайней мере так было в Borland Turbo Assembler с синтаксисом Ideal.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 июн 2014, 14:26 

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

Для решения "проблемы загрузки данных к нужному времени, точно в нужный момент" нужно иметь анализ входящих инструкций в количестве в разы большем, чем переваривается процессором за времени загрузки из обычной (медленной) памяти, то есть многие сотни инструкций. Современные же процессоры читают поток инструкций всего на несколько десятков вперёд. Ну и даже если бы читали на сотни, то всё равно бы не нашли те инструкции, которые "сыграют" через тысячу шагов. В общем компилятор здесь вне конкуренции.
Himik писал(а):
Насчёт автоматического распараллеливания, за это вроде отвечают технологии типа OpenMP, которые уже внедрены в стандарты всех компиляторов.

За распараллеливание отвечает только компилятор, а всяческие красивые названия технологий - это всего лишь чья-то реклама и продвижение собственных продуктов (Permanent members are vendors who have a long-term interest in creating products for OpenMP).
Himik писал(а):
Ассемблерный оператор proc имеет синтаксис сходный с Си - имеет параметры, локальный стек и локальные переменные на нём. По крайней мере так было в Borland Turbo Assembler с синтаксисом Ideal.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 02 июн 2014, 21:35 

Зарегистрирован: 31 окт 2011, 18:20
Сообщения: 230
эмбрион писал(а):
Сходный синтаксис не означает 100% конверсии. При компиляции часть информации безвозвратно теряется, поэтому ни кто из ассемблера не восстанавливает сишные тексты.

Так, к слову.
Если компилировать код на Си без использования оптимизации вообще, то декомпиляция будет относительно вменяемой назад в Си.
Если бы было возможно включить хорошую оптимизацию при транслировании кода на Java в байт-код, то восстановить это было бы не сильно проще, чем Си из ассемблера. Только разница в том, что ни один JAVA-компилятор (до байт-кода) не производит никакой толковой оптимизации (а многие компиляторы - никакой вообще). В первую очередь поэтому JAVA неплохо декомпилируется. Никаких специфических конструкций, помогающих в декомпиляции, в байткоде попросту нет. Самая обычная стековая машина, да еще и туповатая. Все условия и циклы, как и в обычном ассемблере, превращаются в связки goto с проверкой (только вместо проверки флага можно сразу проверить результат вычитания). Имена полей-методов - не аргумент в пользу декомпиляции, т.к. это не логика кода, это просто, так сказать, обязательная дебаг-информация (которая, к слову, может быть изменена в бессвязный бред с сохранением работоспособности программы).
В то же время я видел java-программы, которые сдекомпилировать было сложнее, чем многие сишные. Но их мало, т.к. никто не заморачивается с этим - зачем дважды оптимизировать (сначала байт-код, а потом еще и после компиляции в ассемблер). Не говоря о том, что даже для обычной скомпилированной без оптимизации жабы декомпиляторы иногда выдают в корне неверный (логически) код.


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

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


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

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


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

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