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%.