OSDev

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

Как понимаю, пришли к тому, что всю жизнь было в Аде (параметры in, out, inout -- а как именно передавать, является личным делом компилятора)?

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

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

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

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

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

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

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

Ну вот например здесь можно посмотреть про знания байткода.

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

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

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

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

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

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

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

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

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

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

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

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

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



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

Действительно.
Если человек доказывает, что Джава быстрей ассемблера;
полагает, что 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. >>>

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

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

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