OSDev

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

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




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

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Yoda писал(а):
Прошу прощенья, а зачем отражать в синтаксисе? И каким образом?

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


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

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
Как понимаю, пришли к тому, что всю жизнь было в Аде (параметры in, out, inout -- а как именно передавать, является личным делом компилятора)?


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

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
pavia писал(а):
К примеру деление в ARM Cortex-M3 выполняется от 2 до 12 тактов. Но никак не сотни.

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

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

Пы.Сы. Лет 10 назад как-то провёл эксперимент. Взял какой-то тест, прилично грузящий процессор, странслировал его с помощью GCC, прогнал на двух машинах -- с интеловским и АМДшным процессором. Потом взял и перетранслировал его с помощью интеловского компилятора с максимальной оптимизацией под конкретный процессор. Понятно, что результат на интеловской машине получился много лучше, чем при трансляции с помощью GCC. Но что любопытно, результат этого же EXEшника сильно улучшился и на АМД (хоть и не в такой степени) -- хотя там, понятное дело, совершенно другая микроархитектура, поэтому далеко не все ухищрения компилятора были полезны, а что-то, возможно, попросту вредно. И да, этот тест никаких библиотек не использовал, т.е. прирост скорости здесь -- чисто работа компилятора.

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


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

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

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

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

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

Ну так продемонстрируйте нам подобное на паре С-ассемблер.
Yoda писал(а):
Что-то у меня серьёзные сомнения в том, что вы знакомы с байткодом Java.

Ну вот например здесь можно посмотреть про знания байткода.
Yoda писал(а):
Вы действительно полагаете, что там высокоуровневые конструкции? Может быть, ARM с появлением Jazelle сразу стал высокоуровневым процессором?

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

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

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

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

А вот в случае с JavaOS нет необходимости перекомпилировать весь свет, достаточно перекомпилировать скромный набор составляющих этой ОС, оставив все остальные программы неизменными. Как говорится - почувствуйте разницу в тяжести инерции. На мой взгляд разница простая и она напоминает разницу между состоянием вечного отсутствия прогресса и его наличием.
Yoda писал(а):
Компилятор не знает и не может знать, сколько наносекунд будет исполнятся команда - одна и та же команда в одном и том же месте может легко отличаться по времени выполнения в сотни раз.

Да не компилятор не знает, а производители процессоров его не допускают к управлению внутренностями. В знании времён выполнения операций нет ничего сакрального, это всё есть во внутренней документации Интела и прочих, но проблема в том, что компилятору эти знания ни как не помогут при текущей архитектуре процессоров, когда все внутренние решения принимаются неким железно прошитым способом, на который компилятор повлиять ну ни как не может. Поэтому и сложилась ситуация, когда большинство даже примерно не может оценить время выполнения и пользуются танцами и бубнами для реально напоминающей магическую оптимизации. Вот ведь до какого ужаса людей довели! Каменный век! Хоть и с высокотехнологичными силиконовыми камнями.
Yoda писал(а):
Возможно вы сильно удивитесь, но логика предсказания переходов (даже динамического) добавляет не более нескольких сотен гейтов. Посмотрите, например, сравнительную справочную информацию по серии процессорных ядер Nios II.

Посмотрел. Вижу 33% роста площади кристалла. То есть вместо 3-х условных вычислителей можно иметь 4 при отказе от MPU. Как бы вполне хороший рост производительности - 25%. Но к этому следует добавить ещё и грамотное управление кэшем со стороны компилятора, которому наконец дадут такую возможность. В целом рост может быть и больше 25%.


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

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

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

Вы указали на интересную в контексте нашего спора статейку. Там наглядно показано, как тупой процессор сливает умному компилятору. Обратите внимание на количество промахов при обращении к кэшу. И обратите внимание на количество тактов, которые придётся потратить впустую. Так это скромно предположу - с тыщонку тактов коту под хвост при выполнении программы в несколько ассемблерных строк. И вот подумайте - если компилятор знает структуру программы в объёме, большем чем десяток инструкций, которые знает процессор - ну разве он не увидит адрес первого же джампа ? Ну разве он не поглядит, что за метод (в случае Java) расположен по адресу ? Разве он не просмотрит всё тело метода ? И в результате вместо 1000 тактов впустую он предложит процессору сразу грузить данные с двух адресов прямо в регистры и далее их сложить и положить в нужное место в памяти. Все задержки составят тактов 200 до высвобождения процессора для других дел. Как бы разница в 5 раз ни на что не намекает ?


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

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

А почему вы согласны наделить "умом" процессор, но в случае "тупого" процессора отказываетесь наделить умом компилятор ? Игра в одни ворота, однако.


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

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
SII писал(а):
Как понимаю, пришли к тому, что всю жизнь было в Аде (параметры in, out, inout -- а как именно передавать, является личным делом компилятора)?

Вполне может быть, ибо PL/SQL -- это адаптация Ады под Oracle, и он оказал на меня влияние.


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

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
эмбрион писал(а):
А почему вы согласны наделить "умом" процессор, но в случае "тупого" процессора отказываетесь наделить умом компилятор ? Игра в одни ворота, однако.


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

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

Цитата:
Дело в том, что данные из памяти действительно грузятся за фиксированное время. И хотя это время достаточно большое (сотни тактов), но оно именно фиксированное. То же самое относится к загрузке данных из/в кэш


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


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

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
Действительно.
Если человек доказывает, что Джава быстрей ассемблера;
полагает, что switch, условные переходы, базовый набор арифметических и логических операций - признак высокоуровневости (вероятно, просто не знает, что это есть в любом современном процессоре);
уверен, что байткод здесь никто кроме него в глаза не видел;
совершенно не знает теорию и просит продемонстрировать полноту по Тьюрингу на связке Си/ассемблер;
объясняет, что несколько сотен гейтов - это 33% площади кристалла (примерно как превратить фразу "умер верблюд" в "пало 50% поголовья верблюдов");
не читает, что ему пишут и не понимает разницу между алгоритмической оптимизацией (функция компилятора) и оптимизацией выполнения (функция процессора) и абсолютно уверен, что компилятор может и должен взять на себя вторую часть;
пишет про фиксированное время загрузки из памяти;
...ну что ж. Я с ветряными мельницами сражаться не буду.

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

<<< OS Boot Tools. >>>


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

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

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

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

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

О да, это сильный аргумент ...


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

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


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

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


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

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