эмбрион писал(а):
Я уже вам говорил, что радикальным является уход от небезопасных конструкций вроде работы с указателями и разного рода наплевательства на структуры данных (от юнионов и до любых структур воспринимаемых как байты или ещё неизвестно что). Такое ограничение позволяет компилятору гораздо меньшими усилиями добиваться гораздо лучшей оптимизации. Потому что количество вариантов, которые нужно учесть в случае использования указателей, получается просто огромным (а если на самом деле по этому адресу не строка, а неизвестно что ?).
Я выделил жирным шрифтом ключевое слово в цитате. Изменения в джаве касаются именно безопасности, а не производительности. Остальные рассуждения по поводу оптимизации притянуты за уши. Если "на самом деле по этому адресу не строка, а неизвестно что", то компилятор должен верить сказанному и смело оптимизировать обращение как к строке, а проверки безопасности и сомнения компилятора наоборот снижают скорость.
По поводу радикальных отличий в синтаксисе и семантике языка. То, что Джава
бьёт по рукам ограничивает программиста - не есть выразительные средства языка. Чтобы понять, о чём я говорю, сравните Джаву с 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.
Вход
Регистрация
FAQ
Поиск
) ). В то же время, если говорить о "настоящих научных" вычислениях, где матрицы имеют большую размерность, для их эффективной реализации нужен уже полноценный векторный процессор -- почему графические процессоры на таких задачах и обходят обычные универсальные с очень большим отрывом. Однако скрестить то и другое эффективным образом не получится: то, что в вектором процессоре отводится под огромные кэши данных и 100500 весьма примитивных АЛУ, в универсальном процессоре должно отводиться под очень сложную логику, обеспечивающую суперскалярность, предсказание переходов и т.д. и т.п. Ну а число транзисторов ограничено -- вот и приходится выбирать или то, или другое. (Нет, можно теоретически увеличить площадь кристалла в несколько раз и впихнуть туда и то, и то -- но это резко поднимет его цену, в то время как он всё равно будет проигрывать на любой специализированной задаче процессору с той же площадью и ценой, но заточенному именно под эту задачу).