Здравствуйте, a7d3, Вы писали:
A>Отсюда у VLIW получается сразу несколько преимуществ.
С другой стороны, у планировщика в процессоре есть реальная свеженькая статистика исполнения того кода, который в данный момент исполняется, а у компилятора ее нет.
В те времена, когда идеи VLIW обрели популярность, никто в страшном сне не мог себе представить, насколько сложные штуки научатся делать в железе всего через пару-тройку десятков лет. А вот идея возложить всю сложность на программу (на компилятор) смотрелась вполне разумно.
Re[5]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>А с питоном, джавой и т.д. как ?
Питон должен запуститься прямо из коробки. Ему-то что, интерпретатор байт-кода перекомпилирут, а сам байт-код от CPU не зависит.
Что до явы, придется переписать JIT-компилятор. Или первое время жить без него, в режиме интерпретации байт-кода. В ужерб производительности, естественно.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, a7d3, Вы писали:
A>>Отсюда у VLIW получается сразу несколько преимуществ.
Pzz>С другой стороны, у планировщика в процессоре есть реальная свеженькая статистика исполнения того кода, который в данный момент исполняется, а у компилятора ее нет.
Pzz>В те времена, когда идеи VLIW обрели популярность, никто в страшном сне не мог себе представить, насколько сложные штуки научатся делать в железе всего через пару-тройку десятков лет. А вот идея возложить всю сложность на программу (на компилятор) смотрелась вполне разумно.
В железе как раз таки делать и не научились. Все это у x86 является не аппаратным решением, это программное внутри микрокода (firmware), загружаемом при инициализации ЦПУ — зашифрованный и подписанный блоб, содержимое которого известно лишь вендору.
Анализ динамического исполнения, для предсказывания переходов, в реальности представляет собой агрессивные спекулятивные исполнения различных веток глубиной в несколько операторов условного перехода. Реализация подобных вещей есть в VLIW, получается она гораздо проще и дешевле.
Касаемо полезности динамического анализа для реордеринга операций — в эльбрусах это решили компенсирующим кодом. Для того чтобы спокойно обыгрывать коллизии с зависимостях между отдельными load/store операциями, относительно которых компилятор не был уверен. Такой подход получился опять же проще и дешевле чем в x86.
САД>>Не так, зачем нужен ваз, если есть другие нормальные марки?
Pzz>Чтобы не получилось так, что далекий Трамп в своейн далекой Америке подписал на досуге бумажку, и к твоей машине тормозные колодки вдруг стало не купить.
Американский закон на японское авто с расходниками из Германии? Ну ты ещё тот фантазер
Нет времени на раскачку!
Re[6]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>А с питоном, джавой и т.д. как ?
Pzz>Питон должен запуститься прямо из коробки. Ему-то что, интерпретатор байт-кода перекомпилирут, а сам байт-код от CPU не зависит.
Pzz>Что до явы, придется переписать JIT-компилятор. Или первое время жить без него, в режиме интерпретации байт-кода. В ужерб производительности, естественно.
Во первых и интерпретатор работать не будет в джаве. Да и как ты ее запустишь? Тоже надо собрать на своем СС. Во вторых поддержаивать и все это включая джит тоже всю жизнь придется. Не знаю точно про питон. Но думаю, что много чего поддеживать надо.
CAF>>А что потом то? И зачем оборонке своя архитектуры. Ну вот сделали Байкал — понимаю, свой завод — понмаю. Все железо — да. Но Эльбрус то зачем?
Gt_>что бы не грустить потом как хуавей, с его байкалом. упаковать арм ядра может и хуавей, но нужен то всем полноценный проц, а не еще один байкал.
Зачем нужна своя VLIW архитектура?
Re[3]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, LaptevVV, Вы писали:
CAF>>>Попрошу воздержаться от совсем уж говносрача, особенно, с политичекским уклоном. (Ну да я наивен, но все же.) S>>Этим самым ты отметаешь единственную причину: госбезопасность. Хотите вы этого или нет, но в продукции западных контор часто находят "закладки". Прямо в железе. S>>Не знаю как тебе, но мне очень не хочется иметь в стране бессильную в реальной войне армию. LVV>Наши пацаны, которые служили в околокомпьютерных сферах, говорили, что там у нас ВСЕ свое.
Да элементная база середины 80х.
Re[2]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится. CAF>>Если я правильно понимаю, то надо поддерживать линейку компиляторов и всего инструментария для них. При чем разница в архитектуре с RISC/CISC значительная. Закрытый код вообще не портировать. CAF>>Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что CAF>>Вроде сверхзадач перед Эльбрусами не ставится, а вот затраты — огромные. Это вообще экономичски обоснованный проект? Есть идеи? CAF>>Доредактировал: CAF>>Если есть не экономически обоснованный смысл — то озвучьте. Именно использования столь нестандартной архитектуры без поддержки существующего ПО. Про трансляцию с х86 известно. CAF>>По цифрам — вроде вложили 600млн, и стоит 1 комп 500К денег. Да еще кучу бабла потратили с 70-х годов, но его уже потратили, нет смысла сейчас обсуждать.
CAF>>Попрошу воздержаться от совсем уж говносрача, особенно, с политичекским уклоном. (Ну да я наивен, но все же.) S>Этим самым ты отметаешь единственную причину: госбезопасность. Хотите вы этого или нет, но в продукции западных контор часто находят "закладки". Прямо в железе. S>Не знаю как тебе, но мне очень не хочется иметь в стране бессильную в реальной войне армию.
Вы лично как армии помогаете? Срочную службу хотя бы прошли?
Gt_>>>потому то x86 на серьезные задачи не проектировался. у интел уже лет 8 скорость ядра уперлась в потолок, при этом архитектра дубова и не в состоянии защитить данные в облачной инфраструктуре (meltdown всяукие не вылечить в принипе). Gt_>>>а вот архитектра эльбруса и память защищает и много больше задач за такт выполняет. только вот сыро там все, начиная с компилятора. понятно что отдел за десятком сотрудников такой проект не потянет. нужны посерьезней вложения.
CAF>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
Gt_>вложений не было. пацанам пиво поставили, они за пиво прототип свояли. сначала нужны вложения, и не в деревянных. на 2.5ghz ядро эльбруса вполне потягается с современным ядром xeon gold. перевести всякие ораклы на бесплатные хадупы на контролиремой архитектуре и китайцы хотят и индусы. но нужен продукт, а не прототип за пивко.
Пацаны, пивко, ты о чем?
И причем здесь ораклы и хадупы? Переведут где угодно. (Правда на Эльбрусе нет джавы) И почем китайцы и индусы захотят эльбрус? Что им можно предложить. Для наших хоть независимость от других стран в теории.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, pagid, Вы писали:
P>>Это по затратам на уровне поддержания не самого сложного программного продукта. И апдейт чего? GCC? там же наверно компилятор это кодогенератор для него.
LS>насколько я знаю, нет. LS>там какой-то другой компилятор переделан. LS>но на нём собирается весь альт линукс, включая ядро, так что компилятор достаточно зрел.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
A>Вот ниже видео, таймкод 20:15, довольно много деталей по тому что может этот ЦПУ. A>Фактически там есть режим работы с аппаратным valgrind'ом (таймкод 33:50). Т.е. хороша и современна не только VLIW-архитектура, но и ряд других вещей в этой железке. Такой вариант построения процессоров это технологический прогресс, а не какой-то самостийный колхоз A>https://www.youtube.com/watch?v=rVrUtqhsxvE&t=1215
Это все конечно хорошо. Но непонятно насколько реально полезно. Большинство ПО сейчас пишут в для язков в которых уже нет прямых указателей. Там всxе тоже защищено.
И как на этом планируют деньги заработать? Вот в чем вопрос. Дешевле свой гипервизор сделать, который эмулирует x86 на x86 со всеми проверками доступа памяти.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Ты как-то не понял мою мысль. Можно было сделать что-то RISC — ARM подобное, что бы не надо было поддерживать свою архитектуру. И запускать ARM скомпилированный код. Сейчас же есть режим поддержки x86. Зачем для всего этого новую, причем совершенно другую аркхитектуру городить?
Ты точно программист?
Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
Кстати, а вот зачем нужен этот самый Intel? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
Если я правильно понимаю, то надо поддерживать линейку компиляторов и всего инструментария для них. При чем разница в архитектуре VLIW/IA-64/EPIC с RISC/CISC значительная. Закрытый код вообще не портировать.
Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что
Вроде сверхзадач перед Интелями не ставится, а вот затраты — огромные. Это вообще экономичски обоснованный проект? Есть идеи?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Во первых и интерпретатор работать не будет в джаве. Да и как ты ее запустишь? Тоже надо собрать на своем СС. Во вторых поддержаивать и все это включая джит тоже всю жизнь придется. Не знаю точно про питон. Но думаю, что много чего поддеживать надо.
Ну так интерпретатор явы написан на Ц/Ц++. Чего б ему не работать? JIT, да, ему надо научиться понимать архитектуру, в которую он компилирует.
Re[8]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Во первых и интерпретатор работать не будет в джаве. Да и как ты ее запустишь? Тоже надо собрать на своем СС. Во вторых поддержаивать и все это включая джит тоже всю жизнь придется. Не знаю точно про питон. Но думаю, что много чего поддеживать надо.
Pzz>Ну так интерпретатор явы написан на Ц/Ц++. Чего б ему не работать? JIT, да, ему надо научиться понимать архитектуру, в которую он компилирует.
Нет. Все не так. JIT компилятор кстати тоже написан почти весь на с++ и даже на джава. Но генерят они код для целевой плтформы оба. Интерпретатор тоже генерит код. Хоть и попроще.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
A>Чем не устраивает ответ "как обычно"?
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Ты как-то не понял мою мысль. Можно было сделать что-то RISC — ARM подобное, что бы не надо было поддерживать свою архитектуру. И запускать ARM скомпилированный код. Сейчас же есть режим поддержки x86. Зачем для всего этого новую, причем совершенно другую аркхитектуру городить?
A>Ты точно программист? A>Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
Не понял. Ты думаешь, что поддерживать свою архитектуру проще чем реализовать чужую?
