Yoda писал(а):
эмбрион писал(а):
Речь шла о требованиях, включающих и шифрование и универсальный процессор одновременно.
Мне кажется, что для решения этой задачи достаточно сделать ARM-ядро с необходимыми дополнительными аппаратными модулями. Будет гораздо дешевле.
Ну если совсем глобально - есть разные подходы. И вот разработчикам Эльбруса по каким-то причинам понравился VLIW-подход. Вот они и сделали такой процессор. И против вашего "ARM дешевле" они наверняка выложат свои мысли, которые определили выбор в пользу VLIW. И эти мысли (мне кажется) близки к подходу "всё для компилятора".
Yoda писал(а):
Я не спорю, может быть и можно создать суперкомпилятор, который будет генерить суперкод, но это как раз более сложная половина задачи, причём в лучших традициях "железо мы сделаем сейчас, а софт как-нибудь потом созреет".
Согласен, радикально улучшить производительность можно только начав с главного - с компилятора. И опять согласен - он гораздо сложнее. Но ведь в нашей попильной экономике далеко не всегда "как лучше" важнее чем "лишь бы хоть что-то".
Yoda писал(а):
1. Джава никогда не ставила целью бить рекорды эффективности, основная задача была - переносимость и мобильные приложения.
Изначально Гослинг (создатель Java) мыслил примерно так - есть нравящийся мне С, но у него есть много недостатков, я хочу его улучшить. И в результате получилась Java. То есть ставилась задача получить лучший чем С язык программирования. А к каким задачам применять этот язык - так же не было важно, как и при разработке языка С. Точнее круг задач просто оставался неизменным - программирование универсальных алгоритмов.
Yoda писал(а):
2. Радикальных отличий в синтаксисе и семантике языка между С и джавой нет, это языки, условно говоря, одной группы. Поэтому в джаве нет каких-то специфических выразительных средств, которые позволили бы лучше закодировать алгоритм.
Я уже вам говорил, что радикальным является уход от небезопасных конструкций вроде работы с указателями и разного рода наплевательства на структуры данных (от юнионов и до любых структур воспринимаемых как байты или ещё неизвестно что). Такое ограничение позволяет компилятору гораздо меньшими усилиями добиваться гораздо лучшей оптимизации. Потому что количество вариантов, которые нужно учесть в случае использования указателей, получается просто огромным (а если на самом деле по этому адресу не строка, а неизвестно что ?).
Yoda писал(а):
3. Для работы джавы используется двухстадийная компиляция - сначала в байткод, затем в код целевой машины. Такая двухстадийная компиляция по определению не может генерить код лучше, чем одностадийная сразу в целевой код. Тем более, что джава байт-код не содержит высокоуровневых мощных инструкций, это очень простая стековая машина, а значит JIT-компилятору также (помимо самого Java компилятора) необходимо иметь семь пядей во лбу, чтобы низкоуровневые операции закодировать высокоуровневыми, если таковые имеются в целевой машине и разобрать все зависимости данных.
На самом деле всё не так. Во первых - стадийность компиляции нужно отделить от байткода. Стадийность рассмотрим ниже. А вот байткод - это не "низкоуровневые операции", а код точно такого же уровня, что и исходный текст на Java. То есть в цепочке Java-текст - компилятор - байткод - декомпилятор - Java-текст имеем практически 100% сохранение информации. То есть теряются комментарии, некие конструкции могут выглядеть чуть по другому, но в целом - практически 100% исходного текста на Java сохраняется. И сравните теперь с такой же цепочкой для пары С - ассемблер. Поэтому для компилятора байткод является очень даже качественным входом, минимально ограничивающим разработчика компилятора.
Yoda писал(а):
высокая производительность джавы - миф!
Если хотите - давайте сравним достаточно сложную обработку на Java и С. Например работу парсера XML. Это довольно просто сделать, ведь подобные парсеры являются стандартными и распространёнными библиотеками.
Yoda писал(а):
5. Про оптимизацию и сбор мусора сразу вынесу сюда же. Нельзя быть немножко беременным. Либо мы смогли решить задачу освобождения, и тогда нет необходимости запускать сборщик мусора, либо мы обошлись полумерами типа аллокирования на стеке, тогда мусор неизбежен.
Ну так все достижения в мире делаются маленькими шагами - сначала в одном месте улучшат, потом в другом, чем откроют путь к третьему. В оптимизации работы с памятью всё именно так - она постепенно совершенствуется. Или вы ждёте чудесный компилятор, который на основании любой программы расскажет нам про все варианты состояния её данных ? Надеюсь вы согласитесь, что такое ожидание беспочвенно. И из этого сделаете вывод - только небольшими шагами и будет производиться улучшение компилятора.
Yoda писал(а):
эмбрион писал(а):
Ну вот сами подумайте - нет результата ни в чём, но тогда зачем вкладывать деньги в такой никчёмный продукт ? А ведь деньги вкладывают непрерывно с 2001 года.
Для меня самого это большая загадка.
Они делают шаги, видят цель, цель считается оправдывающей ожидания. Они просто движутся медленно, не кидают все ресурсы в эту область, ведь это бизнес - сначала нужно навариться на старых технологиях. Вот появится в этой области серьёзный конкурент (Эльбрус?) и тут же прогресс станет заметно интереснее.
Yoda писал(а):
во время выполнения только процессор может знать, действительно ли они готовы.
Я уже указывал ответ на такое возражение - процессор это тупой исполнитель алгоритма, а этот алгоритм ему можно давать в виде "прошивки" или в виде программы. Прошивка одна и неизменна, а программа может быть любой. И вот в такой ситуации при наличии хорошего компилятора он просто выдаст процессору наиболее подходящий для задачи алгоритм, в то время как процессор с прошивкой никогда не сможет "думать по другому", что гарантирует его проигрыш при отходе от одной единственной задачи, на которую оптимизирован прошитый алгоритм.
Yoda писал(а):
Первые RISC-процессоры ставили задачу упрощения логики, современные РИСКи вернулись к тому, от чего ушли - есть и предсказание переходов и даже out-of-order execution.
РИСКи это не VLIW. Первые ограничивают компилятор, а вторые дают возможность выбора оптимального (в неких пределах, разумеется) сочетания данных и их обработки. То есть RISC процессоры не вписываются в концепцию "всё для компилятора".
Yoda писал(а):
Хорошо, пусть VLIW-компилятор разложил нам всё по полочкам и сказал - "вот эти инструкции можно выполнять одновременно". А как быть с зависимостями между двумя последовательными блоками VLIW-инструкций? Казалось бы мы передали работу компилятору, но оказывается, что процессор всё равно на том же основании может оптимизировать работу и здесь. Так зачем же сначала его упрощали?
Так не может процессор, вот ведь в чём беда. Вы поймите простую вещь - что бы что-то там соптимизировать, нужны МОЗГИ, то есть сложный алгоритм плюс куча памяти плюс куча времени на работу алгоритма. Это всё есть у процессора ? Надеюсь ответ очевиден.
Yoda писал(а):
С другой стороны, мы рассчитываем, что в каком-то поколении инструкция XXX выполняется 20 тактов, а инструкция YYY 10 тактов, данные от обоих используются в третьей. Компилятор закладывает сначала инструкцию XXX, затем YYY. Проходит время, площадь кристалла стала больше, алгоритмы поменялись, и теперь инструкция XXX выполняется за 5 тактов, а процессор мы лишили возможности сменить порядок выполнения, отдав всё на откуп компилятору.
Когда делают новый процессор, обязательно сочиняют для него оптимизатор. Теперь представим другую ситуацию - когда делают процессор, сочиняют оптимизатор не для него, а просто допиливают компилятор, указывая ему на новые возможности процессора. Согласитесь, что затраты будут ни чуть не хуже случая для компилятора. А далее, что бы не перекомпилировать все на свете программы, мы просто используем виртуальную машину, в которой и заменяем её JIT компилятор на обновлённый. В результате имеем оптимальное выполнение задач на любом процессоре при помощи кросплатформенного байткода, компилируемого в оптимальный машинный код "на лету". Это и есть идеология Java.
Ну и добавим к этому JavaOS, что бы вы не ссылались на необходимость перекомпиляции бесконечного множества версий Линухов с Виндами.
По сути эта самая необходимость перекомпиляции всех программ и удерживает человечество в рамках порочного подхода с размещением оптимизатора в процессоре вместо компилятора. А JavaOS даёт нам возможность выйти из этого тупика.