Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится. CAF>Если я правильно понимаю, то надо поддерживать линейку компиляторов и всего инструментария для них. При чем разница в архитектуре с RISC/CISC значительная. Закрытый код вообще не портировать. CAF>Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что CAF>Вроде сверхзадач перед Эльбрусами не ставится, а вот затраты — огромные. Это вообще экономичски обоснованный проект? Есть идеи? CAF>Доредактировал: CAF>Если есть не экономически обоснованный смысл — то озвучьте. Именно использования столь нестандартной архитектуры без поддержки существующего ПО. Про трансляцию с х86 известно. CAF>По цифрам — вроде вложили 600млн, и стоит 1 комп 500К денег. Да еще кучу бабла потратили с 70-х годов, но его уже потратили, нет смысла сейчас обсуждать.
CAF>Попрошу воздержаться от совсем уж говносрача, особенно, с политичекским уклоном. (Ну да я наивен, но все же.)
Этим самым ты отметаешь единственную причину: госбезопасность. Хотите вы этого или нет, но в продукции западных контор часто находят "закладки". Прямо в железе.
Не знаю как тебе, но мне очень не хочется иметь в стране бессильную в реальной войне армию.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
Например, Transmeta пыталась делать VLIW-процессоры, но опередила время и рухнула из-за недостатка ресурсов и не совсем корректно позиционировала их. Сейчас VLIW хорошо себя показали на видеокартах и появилась прослойка людей привыкших к вычислениям и работе с такими архитектурами.
Плюс стали более очевидны пределы x86, превратившийся в множество RISC-ядер + двоичный транслятор CISC-инструкций управляемый firmware (все это идет под маркой одного ядра x86 ЦПУ).
x86-код исполняют на Эльбруса через двоичный транслятор, работающий в реальном времени и кэширующий транслируемое на отдельный SSD (раньше на CompactFlash).
Вот ниже видео, таймкод 20:15, довольно много деталей по тому что может этот ЦПУ.
Фактически там есть режим работы с аппаратным valgrind'ом (таймкод 33:50). Т.е. хороша и современна не только VLIW-архитектура, но и ряд других вещей в этой железке. Такой вариант построения процессоров это технологический прогресс, а не какой-то самостийный колхоз https://www.youtube.com/watch?v=rVrUtqhsxvE&t=1215
LVV>>Ну, зачем нужен Мерседес, если есть ВАЗ? LVV>>Или Рено — если есть опель? САД>Не так, зачем нужен ваз, если есть другие нормальные марки?
Именно!
Зачем нужен этот гуано Интел, если есть нормальные марки: Эльбрус, pdp-11 ...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
Мне люди из мира электроники говорили неоднократно, что фронтенд (система команд) — дело второстепенное. Будет надо — сделают ARM, или еще там чего. Важно, чтобы оно внутри там себя все правильно вычисляло, распараллеливало и конвеирозовало.
И еще важно, какая задача ставилась. Потому что сделать электроплитку с топовой производительностью — это одно, сделать малопотребляющий, но достаточно производительный, процессор для сотового телефона — это другое, а сделать нечто очень дешевое в производстве — это третье. А военные могут и дополнительных непростых задач подкидывать. Например, сделать устойчивость к радиации выше среднего.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Здравствуйте, alpha21264, Вы писали:
A>>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
A>>Чем не устраивает ответ "как обычно"?
CAF>А обычно это как?
Как всегда.
Сейчас ты идёшь в магазин и покупаешь компьютер.
И хотя ты в магазине платишь рубли,
с каждого купленного компьютера Россия теряет,
а США приобретают примерно тысячу долларов.
В случае российского компьютера эту штуку баксов
будут получать русские инженеры и рабочие.
Даже если русский компьютер будет в десять раз дороже,
Россия в целом станет на эту штуку баксов богаче.
Вот потому так истерят наши США-нские (хотел сказать коллеги) оппоненты.
Здравствуйте, Privalov, Вы писали:
P>Ее в самом деле сильно хвалили, но в чем там фишка, не рассказывали.
Там очень простая, но универсальная система команд. Восемь регистров, практически равноценных, за исключением, того, предпоследний это указатель стека, а последний указатель команд. Все методы адресации применимы практически ко всем командам и операндам.
P>Это как? Разве не через стек шла передача аргументов?
Видимо не аргументы, а операнды
LVV>>Методы адресации — единообразные. P>И этого не понял. Во все времена адресация была прямая, непосредственная, несколько типов косвенной. Я что-то пропустил?
С автоинкрементом и автодекрементом
Вот это
*(p++) = *(s++)
компилируется в одну машинную команду
потому то x86 на серьезные задачи не проектировался. у интел уже лет 8 скорость ядра уперлась в потолок, при этом архитектра дубова и не в состоянии защитить данные в облачной инфраструктуре (meltdown всяукие не вылечить в принипе).
а вот архитектра эльбруса и память защищает и много больше задач за такт выполняет. только вот сыро там все, начиная с компилятора. понятно что отдел за десятком сотрудников такой проект не потянет. нужны посерьезней вложения.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Но в общем это путь в никуда. Это хорошо поддержать своих, но в разумных пределах. И вопрос не в том, зачем Рос компьютер, а зачем своя архитектура. Ведь там даже gcc нет. Нужно свой компилятор поддерживать, и все им собирать. Об остальных языках я вообще молчу.
A>>Вот потому так истерят наши США-нские (хотел сказать коллеги) оппоненты.
CAF>Вообще-то я в США живу ныне. А мы не в политике, и разговор именно как о перспективах техники. Я же сразу написал, и не раз повторял. Свой процессор, свое производство, и тд может быть вопросом безопастности, обсуждать нет сысла. Именно вопрос об использовании оригинальной архтектуры.
Использование CISC изжило свое, архитектура x86 уперлась в тупик и превратилась в RISC прикидывающийся CISC ради обратной совместимости с уже существующими гига и терра-тоннами двоичного кода.
Архитектуры VLIW / EPIC являются естественным продолжением в эволюционном развитии персональных компьютеров с процессорами общего назначения. Имея в теории и демонстрируя на практике ряд преимуществ, включая большую энерго-эффективность и меньшие требования к производственному техпроцессу. При массовом переходе широких слоев населения на подобное железо можно получить более разумное расходывание энергоресурсов как при эксплуатации, так производстве этих самых ЦПУ.
Компилятор уже есть, gcc-совместимый оптимизирующий, собирающий аж три дистрибутива линукса. Два из которых это Debian derivative'ы, а другой RPM based самопал с долгой историей на основе французского Mandrake. Т.е. пакетные дистрибы предоставляющие репозитории с двоичными пакетами прикладного софта — собирается не только ядро и «мир», но и прикладной софт в этих репозиториях.
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
Ну, зачем нужен Мерседес, если есть ВАЗ?
Или Рено — если есть опель?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что
У них линейка на SPARC-совместимом тоже есть.
CAF>Вроде сверхзадач перед Эльбрусами не ставится, а вот затраты — огромные.
Не огромные.
CAF>Это вообще экономичски обоснованный проект? Есть идеи?
Экономически обоснованных проектов вблизи оборонки нет. Это не исключает того, что их можно сравнивать по экономическим показателям.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Ты как-то не понял мою мысль. Можно было сделать что-то RISC — ARM подобное, что бы не надо было поддерживать свою архитектуру. И запускать ARM скомпилированный код. Сейчас же есть режим поддержки x86. Зачем для всего этого новую, причем совершенно другую аркхитектуру городить?
Потому, что взяли готовые наработки. А когда в свое время их нарабатывали, выбор своей архитектуры был вполне уместен, ARM'а тогда не было, x86 никому еще в кошмарном сне не мог присниться.
Re[7]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, playnext, Вы писали:
P>Ну а так почти в тему. Процессор военный ведь?
- На танке установлена рация...
— Товарищ майор, а рация на лампах или на транзисторах?
— Для тупых повторяю: рация на танке!
Можно подумать то, что "военность" проца — это какая-то индульгенция для того, чтобы тридцать лет кормить всех "завтраками", насилуя теоретические разработки советского времени. Смысл разработки процессора — в том, чтобы выпускать его серийно, в промышленных масштабах. Если производства нет, то какая нахрен разница, что там за "не имеющие аналогов" технологии используются и насколько они опережали время в эпоху 80386.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус?
Моё непреклонное ИМХО — попил бабла. Посмотрите на эти рожи от правительства (привет, Сердюков!) — вы правда верите, что наикрупнейшим расхитителям гос.собственности есть какое-то дело до... обороны? ИТ?
Не исключаю, что этим проектом занимались действительно одарённые люди, но конечно же не ради "православный считатель из скреп и родного навоза в каждый дом". Он даже мне, насквозь "айтишнику", не нужен вообще даже на поиграться. Даже запросто так. Потому что я уже начал ценить своё время. Так что да, "Эльбрус не нужен". Вместе со скрипачом.
Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
Если я правильно понимаю, то надо поддерживать линейку компиляторов и всего инструментария для них. При чем разница в архитектуре с RISC/CISC значительная. Закрытый код вообще не портировать.
Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что
Вроде сверхзадач перед Эльбрусами не ставится, а вот затраты — огромные. Это вообще экономичски обоснованный проект? Есть идеи?
Доредактировал:
Если есть не экономически обоснованный смысл — то озвучьте. Именно использования столь нестандартной архитектуры без поддержки существующего ПО. Про трансляцию с х86 известно.
По цифрам — вроде вложили 600млн, и стоит 1 комп 500К денег. Да еще кучу бабла потратили с 70-х годов, но его уже потратили, нет смысла сейчас обсуждать.
Попрошу воздержаться от совсем уж говносрача, особенно, с политичекским уклоном. (Ну да я наивен, но все же.)
Добавлю еще для новеньких:
Я про архитектуру именно. Свое, полностью контролирумое железо я понимаю. Произведенное в РФ, а не заказанное в Тайване, Китае или еще где. Тут я поддерживаю 100% импортозамещение для всех критических целей, сколько бы оно не стоило. Это вплолне объективно обоснованная цель.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, pagid, Вы писали:
P>>Это по затратам на уровне поддержания не самого сложного программного продукта. И апдейт чего? GCC? там же наверно компилятор это кодогенератор для него.
LS>насколько я знаю, нет. LS>там какой-то другой компилятор переделан. LS>но на нём собирается весь альт линукс, включая ядро, так что компилятор достаточно зрел.
Да, весьма зрелый.
На VLIW-платформах компилятор является частью ЦПУ, потому развивать его должен-вынужден вендор данного процессора. На этапе компиляции у VLIW выполняется все то, чем вынуждены в рантайме заниматься декодировщик с планировщиком в x86-архитектуре. Реализованные при этом в x86 ни разу не аппаратно, а как интерпретаторы firmware-кода.
Отсюда у VLIW получается сразу несколько преимуществ.
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>Не так, зачем нужен ваз, если есть другие нормальные марки?
Чтобы не получилось так, что далекий Трамп в своейн далекой Америке подписал на досуге бумажку, и к твоей машине тормозные колодки вдруг стало не купить.
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>Не знаю как тебе, но мне очень не хочется иметь в стране бессильную в реальной войне армию.
Вы лично как армии помогаете? Срочную службу хотя бы прошли?
Здравствуйте, playnext, Вы писали:
P>>>Срочную службу хотя бы прошли? S>>К сожалению, нет S>>Моя служба должна была быть в 90е. Родители не пустили. P>Ну вот, а меня пустили. Вообще то это священная обязаность гражданина служить. Родители тут не причем.
Дада, давай, начинай грязь на меня лить, да повонючее. Объяви что я голоса не имею и прочие санкции введи.
Главное же с топика чъехать на обсуждение меня, да?
Здравствуйте, LaptevVV, Вы писали:
LVV>Извини, но интел реально гуано после pdp-11.
Это было очень заметно до тех пор пока в системе на на х86 было 64К памяти, когда стало больше пусть даже 128К, а тем более 640, мнение уже должно было поменяться. А когда интел очень гладенько перешел на 32-модель, pdp-11 пришлось заменить другой, сходной только идейно системой, и в добавок степень "коровистости" стала уже близкой. Но Интел (AMD конечно, но без разницы) очень гладко переехал на 64бита. Можно сколько угодно извергать кирпичи, но у Интела работающая годная десктопно-серверная система
CAF>>Кстати, а вот зачем нужен этот самый Эльбрус? K>Моё непреклонное ИМХО — попил бабла.
Обычно под попил бабла новое не придумывают. Ведь на это надо бабло. В целом я скорее за чем против новой архитектуры. В глобальном, а не экономическом смысле. Должна быть альтернатива. Если эта альтернатива г — время ее убьет, благо вроде много ресурсов на него не тратилось. А если в ней есть чтото хорошее — время это раскроет, и тогда появится и экономическая выгода.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Gt_, Вы писали:
N>>Я таким URL не доверяю и никому не советую, и слово "брехня" относится скорее к ним. N>>Пусть дадут реальную установку полдесятку действительно независимых экспертов, причём за пределами РФ. Тогда и посмотрим.
Gt_>ну да, типично украинское. сначала набросить "по отзывам тех, кто это реально применял", а как макнули сразу слиться в недоверие
Конечно, отзывы должны быть реальные, а не из заведомо агитационного источника, и чтобы тестеров было несколько и они имели опыт поиска спрятанных граблей. По вашей ссылке же информации около нуля и повторить её нереально (и не только из-за закрытости железа).
Ваше "макнули" и "украинское" как раз показывает отсутствие аргументов у вас.
Gt_>>> тем более, что meldown превращает нароботки последних лет интел в тыкву N>>AMD не превратила, и он сейчас впереди. И не x86 единым живо IT. Gt_>у амд точно та же корявая архитектура без какой-либо защиты доступа к кешу. адаптация вариаций мелтдаун к амд вопрос времени.
Частично оно Spectre подвержено, но это уже не Meltdown (который был самой тяжёлой формой).
Здравствуйте, netch80, Вы писали:
N>Не поможет, пока в качестве памяти используется DRAM. N>Или для DRAM надо операцию смены открытой строки ускорить раз в 30 минимум (фантастика на втором этаже (c)), или выбросить каку и переходить на SRAM (ценник умножить на 10, а в первые 5 лет на 20, плотность упаковки разделить на столько же). N>Пока есть проблема с DRAM — все эти супер-EPIC (VLIW) будут отставать от Atomʼа. Время открытия строки не имеет никакого отношения к полосе пропускания. Проблема латентности памяти замечательно решается кэшированием. Кстати кэш — это и есть SRAM, вон АМД пихает по 60МБайт на кристалл — и вроде как их чипы не стоят запредельных денег.
Опять же непонятно, какое отношение это всё имеет к VLIW.
N>Разумеется, рекламные бенчмарки будут на синтетических тестах, когда SIMD перерабатывает потоки данных с тщательно рассчитанными тактировкой и предвыборкой — именно такие тесты вам и рисуют (и кролики ведутся), а потом по отзывам тех, кто это реально применял, Эльбрус на обычных действиях с трудом догоняет пень-три.
N>А Intel и AMD тем временем просто спускаются с горы и овладевают всем стадом, догоняя длину конвейера микроопераций до 200 и выше. Они уже на этом вашем VLIW обожглись и повторять не хотят.
Gt_>>пытаться с двумя деревянными рублями догнать интел просто глупо, посоревноваться с интелом и арм сможет лишь то, что будет в разы больше инструкций за такт прожевывать. например vliw.
N>Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~ Ты путаешь тёплое с мягким, то есть процессор общего назначения со специализированной архитектурой. Перепроектировать ничего не нужно, ибо суперскалярные архитектуры фундаментально не отличаются от VLIW.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
Ответ прост — легаси. СССР сделали на нем С-300, тогда других вариантов не было. РФ продолжает делать эти зенитные комплексы, но переносить платформу на другую ISA страшно и затратно. Вот и идет валкое развитие и поддержка.
N>Не-а. Потому что нет реального теста. Есть странная писулька от агит-сайта, которая даже на уровне теста содержит <1/10 от того, что должно быть.
чувак, сосредоточься. тебя обвинили в украинстве потому, что ты верил в отзывы когда набрасывал "по отзывам", а как тебя макнули в реальный отзыв тут же перестал тем самым отзывам верить.
и после ответа на твой же голословный наброс еще и меня, показавшего реальный отзыв с реальным тестом, умудрился обвинить в отсутствии аргументов.
N>Теги в стиле Эльбруса как раз ничего не стоят по сравнению с общими затратами на выборку и интерпретацию. N>А насколько Эльбрус подвержен всему Meltdown-like семейству, опять же, тебе не скажут.
тэги стоят нескольких байт в каждом регистре и соответственно исключают доступ к чужим данным в принципе.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
N>>"Обнаружив", "может"... да, забить все предшествующие команды этими fapb... кстати, какой там предел их количества на одну ШК?
V>https://www.slideshare.net/profyclub_ru/ss-41396492
Очевидно, ты в полемическом задоре даже не прочитал ссылку, на которую ссылаешься.
Ничего про предел fapb на ШК нет. В примере ассемблерного кода ни одной fapb.
По ссылке приводится пример математического расчёта. Почему-то все мерятели бенчмарками Эльбруса показывают только математику. Найди пример распаковки 7z-архива (один из типовых тестов, на которых сравнивают x86), перепаковки видео по ffmpeg. Какую-нибудь древнюю бегалку-стрелялку типа Doom (чтобы не требовался SSE и было достаточно типового оборудования лаптопа). Я подозреваю, что нет: им слабо́, потому что будут показаны результаты, с которыми стыдно идти даже к папуасам.
Здравствуйте, Sinclair, Вы писали:
S>Про compile()/eval() я себе не очень представляю, как получить хотя бы как-то работающую реализацию. Откуда будут браться тексты, которые туда будут скормлены?
В языке Go существенная часть компилятора является частью стандартной библиотеки. А именно, полноценный настоящий парсер и алгебра типов. Благодаря этому всякие полезные програмки для работы с Go понимают синтаксис языка, а не пытаются его угадать с помощью регуляных выражений и творческой смекалки автора, что весьма удобно.
Если бы так же сделали с Си, в этом был бы смысл. А целый компилятор с кодогенераровом в библиотеку засовысать, я не знаю, зачем это нужно.
Здравствуйте, ononim, Вы писали:
O>Кствти, совпадение или нет, но последний кукурузо увидел свет аккурат через год после появления первого x86-64 камня. Вся эта внутренняя гибкость так и не позволила осилить декодирование новых опкодов.
Исполнение, скорее. Если у тебя есть декодер команд 386, то доделать его, чтобы он x86 понимал, несложно. Но что с этими декодированными командами делать, если у тебя нету 64-битных регистров и ALU?
Здравствуйте, a7d3, Вы писали:
A>>>>Такое впечатление, что ты знаешь систему команд Эльбруса. A>>>>Поделись информацией!
A>>>Есть книжка раздаваемая официально http://www.mcst.ru/doc/book_121130.pdf
A>>Ну так система команд-то где? A>>Информационного шума (маркетингового булшита) дохрена, но где конкретная информация?
A>А книжку почитать? Приложение 3, 4 посмотреть.
Ты сам-то книжку читал? Приложение смотрел? Где там система команд?
Ты вообще, знаешь, что такое система команд?
Вообще, это не книжка, а кусок говна, которая
сформирована по принципу некоей китайской энциклопедии,
согласно которой животные делятся на:
а) принадлежащих Императору,
б) набальзамированных,
в) прирученных,
г) молочных поросят,
д) сирен,
е) сказочных,
ж) бродячих собак,
з) включённых в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.
Здравствуйте, Privalov, Вы писали:
P>Как человек, никогда не видевший PDP-11, могу ли я поинтересоваться?
LVV>>Дело не в объеме памяти, а архитектуре системы команд. P>Ее в самом деле сильно хвалили, но в чем там фишка, не рассказывали.
Для некоторого основного набора команд (MOV, ADD, SUB, BIS, CMP...) источник и приёмник могли быть абсолютно любого типа из поддерживаемых, и независимо друг от друга. Память, регистры — не важно.
Плюс к тому:
1) Работа со стеком без отдельных приёмов — работал автоинкремент и автодекремент.
2) Эти самые автоинкремент и автодекремент работали для любого регистра, сокращая операции на последовательную работу с областью памяти.
3) Сюда же универсально легли методы задать любой команде константу-литерал или абсолютный адрес в памяти через использование регистра PC для адресации; тут же была адресация относительно PC (которую в x86 сделали только в 64 битах, раньше не было) — для позиционно-независимого кода.
LVV>>аргументы могли располагаться где угодно. P>Это как? Разве не через стек шла передача аргументов?
Можно было и через регистры, и через стек.
Но на PDP-11 был ещё один интересный фокус: аргументы подпрограммы посреди вызывающего кода, сразу за командой JSR — вызова подпрограммы. Использовался для этого регистр связи, отличающийся от PC.
P> Это на ЕС не было стека, приходилось выделять память, оставлять адрес выделенной области в одном из регистров, потом на входе все очищать. Поэтому на ЕС рекомендовали не злоупотреблять вызовами подпрограмм.
Сейчас там точно так же нет стека, но GCC компилирует в ABI, в котором стек сделан на R13. И используют — почти как на x86: декрементировал на входе в подпрограмму, попользовался в локальных смещениях (доступны и отрицательные, но команда на 2 байта длиннее), инкрементировал обратно на выходе.
LVV>>Методы адресации — единообразные. P>И этого не понял. Во все времена адресация была прямая, непосредственная, несколько типов косвенной. Я что-то пропустил?
См. выше. Например, непосредственная константа в команде — через (PC)+, абсолютная адресация — через @(PC)+.
Например, команда "записать 41 по адресу 25" (считаем, оба восьмеричные):
MOV #41, @#25
на самом деле она превращалась в последовательность:
MOV (PC)+, @(PC)+
.WORD 41
.WORD 25
В x86 и аналогах для непосредственной константы надо делать отдельный тип команды.
Что интересно, можно было делать и следующую хохму:
MOV R0, (PC)+
X: .WORD 0
записал себе в ячейку прямо в коде и пошёл дальше потом из этой X прочитать (в относительной адресации).
LVV>>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>>Командой пересылки осуществляется ввод-вывод! P>Такое было на Motorola 68040. Часть памяти отображалась на ввод/вывод. Не нужна была отдельная команда чтения/записи в порт. Но какие преимущества это давало при программировании, я не очень понимаю.
Так на x86 тоже такого сейчас до чёрта, и даже рекомендуют укладывать большие области регистров на память.
Из стандартных устройств только на память отображаются все APIC, HPET...
И на MIPS, ARM, многих других нет отдельного I/O, только через пространство памяти.
X86 старый в этом смысле — уникум.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>>>Командой пересылки осуществляется ввод-вывод! K>>А где сейчас это не так? LVV>В Интеле — отдельная адресация портов.
Далеко не во всём и не везде, и есть заметная тяга в сторону адресации в памяти (коллега koandrew объявил это требование абсолютным, но это не так). Преимущества адресации по памяти:
1. Прямой доступ как к куску памяти, чтобы там складывать структуры данных. Особенно ценно для видеопамяти (для которой даже на первых PC был доступ именно как к памяти), но также для сетевых адаптеров, USB, AHCI и многих прочих, где высокоскоростной I/O требует работы в стиле "сформировали связанный список дескрипторов запрошенных операций и пнули адаптер выполнять их".
Для I/O это неудобно — потребовалась бы поддержка компилятора (как в Borland Pascal — IO изображалось массивом), а ещё на x86 дико неудобная и потому медленная адресация I/O (один регистр DX, без индексного регистра и без смещения в команде — то есть на любой чих надо этот DX перезаписывать).
2. Возможность постраничного управления доступом к ресурсу. Например, Linux мапит области таймеров (APIC и HPET) как readonly в юзерские процессы, чтобы операции даже высокоточного чтения таймера не требовали переключения в ядро. IOMMU для виртуалок также позволяет легко пробросить устройство в гостевую систему, если оно выделено в блок 4K-страниц и не соседствует с другими, которых не надо пробрасывать.
Адресация через I/O остаётся, как минимум, для специальных применений:
1. Собственно управление конфигурационным пространством PCI (порты 0CF8, 0CFC). PCI Express повторил этот механизм (как рекомендованный, но на x86 так делают, считаем, все).
2. Совместимость с ISA-стилем, где требуется (поставьте SATA контроллер в IDE режим и увидите, как он всякие 1F0 начнёт аллоцировать).
Но при этом всё равно есть много тех, кто использует хотя бы частично старое. Вот видяха (GT710):
Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
Memory at e8000000 (64-bit, prefetchable) [size=128M]
Memory at f0000000 (64-bit, prefetchable) [size=32M]
I/O ports at e000 [size=128]
Видеопамять одним куском... но и порты рядом. А вот AHCI контроллер — 5 отдельных кусков (!)
I/O ports at f090 [size=8]
I/O ports at f080 [size=4]
I/O ports at f070 [size=8]
I/O ports at f060 [size=4]
I/O ports at f020 [size=32]
Memory at f3126000 (32-bit, non-prefetchable) [size=2K]
Странные люди эти Intel.
И вдогонку: часть I/O проводится сейчас вообще через конфигурационное пространство PCI! Это относится к подавляющей части настроек чипсета. Можно посмотреть в интеловской доке по мостам (северный — в процессоре последние 10 лет), все базовые настройки — только через PCI конфигурацию. I/O порты после этого остаются в основном для внутренней логики устройств, которые в зависимости от поставки могут быть встроенными или дискретными. Но при этом доступ в конфигурационное пространство PCI всё равно идёт через I/O порты, которые тут же перехватывает корневой хаб северного моста
То есть на типичном x86 сейчас не два, а три таких пространства, каждое чуть для своей роли
Здравствуйте, jamesq, Вы писали:
N>>А вообще, разные разрядности — тоже разные системы команд, и это давно делается (любой x86 их сейчас поддерживает аж три).
J>Ну нет, это не так конечно. Эти разрядности — просто различные варианты одной системы команд. Оно же в корне ничего не меняется:
У них разные, несовместимые парсеры.
В отличие, например, от IBM zSeries, у которой добавлены 64-битные команды, не ломая старые, а разрядность адреса (24/31/64) свободно управляется непривилегированной командой.
При совершенно разных системах команд сделать совместимость по общей части пула регистров — банально, это делали и PDP-11+VAX, и ARM/32+ARM/64, и x86-32+IA64, и x86 со всеми тремя режимами. Но это не создаёт всем одинаковую систему команд.
J> как были вот эти переходы в зависимости от регистра флагов, так и остаются. Те же команды FPU,
Которое фактически deprecated и Intel регулярно грозится исключить его совсем, или перевести на микрокод, с замедлением на порядок.
J> более крупные регистры включают в себя более мелкие. J>Там же не появляются вот эти вот shadow регистры, как в Z80
Эээ... не знаю, почему для вас shadow регистры это признак другой системы команд, а не системного расширения текущей, но на всякий случай напомню, что в x86 пул FP регистров = пулу MM, но не пулу XMM/YMM/ZMM, последний — совсем другие регистры.
N>Конечно, отзывы должны быть реальные, а не из заведомо агитационного источника, и чтобы тестеров было несколько и они имели опыт поиска спрятанных граблей. По вашей ссылке же информации около нуля и повторить её нереально (и не только из-за закрытости железа). N>Ваше "макнули" и "украинское" как раз показывает отсутствие аргументов у вас.
но согласись, мой аргумент с реальным тестом заметно весомей твоего наброса "по отзывам тех, кто это реально применял" (тм)
N>Частично оно Spectre подвержено, но это уже не Meltdown (который был самой тяжёлой формой).
этих форм миллион, еще один вид — foreshadow. при этом у ibm power та же фигня. когда им сбоку присобачат защиту памяти на подобии тагов эльбруса разрыв еще сократиться.
Здравствуйте, ononim, Вы писали:
CAF>>>>Эльбрус существует в промышленных масштабах? W>>>Интел с аналогичной архитектурой. CAF>>IA-64 ? так ее и закрыли, проект скорее всего не окупился. Зачем еще раз так делать? O>IA-64 навернулся потому что ему была подложена свинья в виде AMD64 O>То есть технологию делали из расчета грядущего перехода с x86, на это рассчитывали и технари и что наверно важнее — бизнесменеджмент. И они как изначально таргетировали IA64 как неизбежность для своего уже имеющегося рынка, и исходя из этого планировали свои бизнес процессы, и проявили стандартную для большой корпорации неповоротливость когда внезапно выскочил конкурент в виде AMD64.
Не совсем. Во время Merced, на конец 90-х интел-совместимые x86-процессоры делали и Cyrix, и AMD, весьма успешно. И хотелось интеловцам такой процессор, чтобы и 64-битный и конкуренты не смогли повторить. А рынок посмотрел на стоимость интелевского решения и сказал, что уж лучше инициатива x86_64, оно же Amd64. Отторжение рынком Merced произошло еще на этапе идей и начала производства этого железа в кристаллах, из-за попыток монополизировать сектор.
Здравствуйте, Sinclair, Вы писали:
Pzz>>Ты высказался про имплементацию, он высказался про спецификацию языка. S>Не-а. Спецификация всегда пишется в терминах некоторой абстрактной "целевой машины". Например, весь C# специфицирован в терминах CLR, а Java — в терминах JVM.
Это потому, что и C# и Java — это языки, изначально нацеленные на одну вполне конкретную целевую машину, пусть и виртуальную.
Интересно, терминах какой целевой машины описан C/C++
N>> Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
N>> Memory at e8000000 (64-bit, prefetchable) [size=128M]
N>> Memory at f0000000 (64-bit, prefetchable) [size=32M]
N>> I/O ports at e000 [size=128]
S>Там же 3 куска, но я догадываюсь, что енто непрерывный адрес,
В каком смысле?
S> только к чему такая разбивка (128+32, а не 160)?
PCI позволяет выделять адресное пространство только степенями двойки.
Почему 3 куска в сумме 176, а не один на 256 — надо спрашивать дизайнера карты. Я не в курсе. Возможно, заточка на работу в 32-битных ОС требует такой оптимизации.
LVV>>Зачем нужен этот гуано Интел, если есть нормальные марки: Эльбрус, pdp-11 ... CAF>Не надо скатываться.
Извини, но интел реально гуано после pdp-11.
Я работал — это была блестящая архитектура!
Интел, кстати, содрал систему прерываний с нее... CAF>PDP-11, X86 были (и есть) вполне коммерческими успехами, ближайший сородич Эльбруса вроде уже почил давно.
А кто ближайший сородич Эльбруса? CAF>Есть что по теме сказать. Ты же все-таки представитель науки. Может знаешь что? CAF>Нам в Универе об Эльбрусе немного рассказывали, там совсем другая система команд. И просто щелчком кодогенератор с РИСК/ЦИСК не поменяшь.
В начале 2 половины 80-х в журнале Программирование печатали статью Бабаяна про архитектуру Эльбруса.
Потом была книжка Пентковского Автокод Эльбрус Эль-76. Книжку можно найти в сети.
Основное — машинный язык Эльбруса — это аппаратно реализованный язык высокого уровня процедурного типа с аппаратными проверками типов на основе тегов.
Потом Пенковский слинял в США.
Так что посты в сети об участии Пентковского в разработках Пентиумов вполне могут быть правдой.
Я видел Эльбрус на конференции по свободному ПО в Переславле — Залесском в конце января этого года.
Там есть институт программных систем — они АльтЛинукс развивают.
И на эту конференцию для участников поставили небольшую выставку машин российского производства.
В том числе и Эльбрус.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Эту ветку сразу можно отделять и в политику.
CAF>>Попрошу воздержаться от совсем уж говносрача, особенно, с политичекским уклоном. (Ну да я наивен, но все же.) S>Этим самым ты отметаешь единственную причину: госбезопасность. Хотите вы этого или нет, но в продукции западных контор часто находят "закладки". Прямо в железе. S>Не знаю как тебе, но мне очень не хочется иметь в стране бессильную в реальной войне армию.
Наши пацаны, которые служили в околокомпьютерных сферах, говорили, что там у нас ВСЕ свое.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
компилятора. понятно что отдел за десятком сотрудников такой проект не потянет. нужны посерьезней вложения.
CAF>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
Да не окупятся они. Вложить деньги налогоплательщиков, да "посерьёзней", пока дают, вот и вся история. Заодно почесать гондурас сверхдлинного слова с явным параллелизмом. Опять же, за счёт налогоплательщиков, почему бы и не почесать?
Здравствуйте, LaptevVV, Вы писали:
LVV>Извини, но интел реально гуано после pdp-11. LVV>Я работал — это была блестящая архитектура!
А с другой стороны, кого это сейчас волнует, кроме разработчиков компиляторов?...
LVV>А кто ближайший сородич Эльбруса?
Почитай в википедии статью про VLIW, там их перечисленно сколько-то.
Идея VLIW звучит, теоретически, разумно: переложить все сложности планирования вычислений с процессора на компилятор. Типа, компилятор, он умный, он справится лучше. Только компиляторщики, к сожалению, не осилили сделать достаточно умный компилятор. А процессорщики тем временем на месте тоже не сидели, и современные процессоры стали очень умными.
LVV>Основное — машинный язык Эльбруса — это аппаратно реализованный язык высокого уровня процедурного типа с аппаратными проверками типов на основе тегов.
Извини, но булшит это все.
Ну какой там может быть язык высокого уровня, если этот процессор в вопросе распараллеливания вычислений полагается на компилятор (или на ручное кодирование, что озвереешь делать в промышленных массштабах)? Конечно, к нему можно и "однопоточную" программу написать, но только при этом из него и половины заявленной производительности не выжмешь.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, pagid, Вы писали:
P>>Это по затратам на уровне поддержания не самого сложного программного продукта. И апдейт чего? GCC? там же наверно компилятор это кодогенератор для него.
LS>насколько я знаю, нет. LS>там какой-то другой компилятор переделан. LS>но на нём собирается весь альт линукс, включая ядро, так что компилятор достаточно зрел.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Ты как-то не понял мою мысль. Можно было сделать что-то RISC — ARM подобное, что бы не надо было поддерживать свою архитектуру. И запускать ARM скомпилированный код. Сейчас же есть режим поддержки x86. Зачем для всего этого новую, причем совершенно другую аркхитектуру городить?
Ты точно программист?
Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
Здравствуйте, alpha21264, Вы писали:
A>Ты точно программист? A>Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
То-то не только Опера слилась, но и даже IE/Edge, а уж про прочие Яндекс.Браузер даже и вспоминать не хочется
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[4]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, playnext, Вы писали:
S>>>Не знаю как тебе, но мне очень не хочется иметь в стране бессильную в реальной войне армию. P>>Вы лично как армии помогаете? S>Узнавал про контрактную службу. Сказали что старый уже....
P>>Срочную службу хотя бы прошли? S>К сожалению, нет S>Моя служба должна была быть в 90е. Родители не пустили.
Ну вот, а меня пустили. Вообще то это священная обязаность гражданина служить. Родители тут не причем.
Здравствуйте, jamesq, Вы писали:
J>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Если есть не экономически обоснованный смысл — то озвучьте. Именно использования столь нестандартной архитектуры без поддержки существующего ПО. Про трансляцию с х86 известно.
J>Вот интересно — а кто нибудь сделает процессоры с несколькими системами команд на борту?
Ты не поверишь!
Ну и есть я дамаю другие похожие бинарные трансляторы приложений на лету.
LVV>>Извини, но интел реально гуано после pdp-11. P>Это было очень заметно до тех пор пока в системе на на х86 было 64К памяти, когда стало больше пусть даже 128К, а тем более 640, мнение уже должно было поменяться. А когда интел очень гладенько перешел на 32-модель, pdp-11 пришлось заменить другой, сходной только идейно системой, и в добавок степень "коровистости" стала уже близкой. Но Интел (AMD конечно, но без разницы) очень гладко переехал на 64бита. Можно сколько угодно извергать кирпичи, но у Интела работающая годная десктопно-серверная система
РНе...
Дело не в объеме памяти, а архитектуре системы команд.
В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные.
Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была.
Регистры внешних устройств адресовались адресами памяти — это блеск!
Командой пересылки осуществляется ввод-вывод!
Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие.
Одной командой можно было очистить ВСЮ память.
Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, ononim, Вы писали:
O>Потому мое ИМХО таково, что VLIW оптимален для эмбеддеда/мобильников и всяких JIT сред исполнения, а для десктопа/нативного кода — ну так себе. Хотя для opensource тоже норм, если не лень пересобирать мир под каждый новый проц.
Точка зрения понятно, но есть нюанс.
Открываем https://www.archlinux32.org/packages/ смотрим на Arch.
Даже такие маргиналы как мейнтейнеры 32-х битного ArchLinux держат в репозиториях бинарники собранные под разные варианты 32-разрядного x86.
Здравствуйте, pagid, Вы писали:
LVV>>Дело не в объеме памяти, а архитектуре системы команд. LVV>>В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные. P>Это очень красиво, я тоже был и до сих пор в восторге, но оно не помогло использовать более 64К памяти.
Это не имеет никакого отношения к архитектуре системы команд.
VAX и M68k имели по сути такую же архитектуру — вершина CISC, любой аргумент почти любого типа. Но у них уже было 32-битное пространство без сложностей по рассматриванию огромного мира в крошечное окошко.
P> Там страницы переключаюся с отображением на 64К, а в в x86 сегментная организация, что оказалось куда как гибче и работоспособнее и без напрягов переехало на 32-разрядеую архитектуру.
Не переезжало оно без напрягов: в 32 битах его тупо не используют — безумных нет, а в 64 и нельзя использовать напрямую.
Вот если бы они сделали в стиле IBM, что в 32 и 64 битах сегментные регистры выбирают корневой страничный каталог — их бы использовали и по делу.
LVV>>Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие. LVV>>Одной командой можно было очистить ВСЮ память. LVV>>Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение. P>Угу. Только интеловская плавно расширилась на 32 разряда и на 64, а для той такой возможности не было.
Ничего такого "плавного" в x86 не было. Парсинг команд в 32 и 64 заметно другой и разный между ними самими. Дополнительные регистры добавлены костылями, как и 64-битные данные большинства команд. Методы адресации заметно перестроились.
Видимость сходства, да, но внутри совсем другое.
Лучше бы, сохраняя общую архитектуру, полностью перекроили построение системы команд с нуля.
Но AMD были нищие и не могли это себе позволить.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
Вот именно такой подход ("А когда мы отобъем своё бабло и с каким наваром?") в сфере национальной безопасности приводит
к ситуации, которая сейчас наблюдается, например в США в области производства обогащенного урана.
Американская обогатительная корпорация была в своё время приватизирована (неужели наши приватизаторы надоумили? ) именно с целью
максимизации прибыли от отрасли. В итоге оказалось, что выгоднее перепродавать российский уран, чем добывать и обогащать свой.
В итоге имеются признаки развала урановой отрасти (капитилистического народного хозяйства ).
Я полагаю, не надо повторять, что свои микропроцессоры — это тоже сфера национальной безопасности.
LVV>>Дело не в объеме памяти, а архитектуре системы команд. LVV>>В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные. P>Это очень красиво, я тоже был и до сих пор в восторге, но оно не помогло использовать более 64К памяти. Там страницы переключаюся с отображением на 64К, а в в x86 сегментная организация, что оказалось куда как гибче и работоспособнее и без напрягов переехало на 32-разрядеую архитектуру.
1. Там без проблем работало 256 кил памяти.
А потом они создали VAX...
2. Я бы не сказал, что интел переехал без напрягов. Там столько аппаратуры допилили — фактичски новый комп создали.
LVV>>Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была. LVV>>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>>Командой пересылки осуществляется ввод-вывод! P>Это не так уж и важно.
Для программиста и компиляторов — важно. LVV>>Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие. LVV>>Одной командой можно было очистить ВСЮ память. LVV>>Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение. P>Угу. Только интеловская плавно расширилась на 32 разряда и на 64, а для той такой возможности не было.
DEC Alpha: https://wiki2.org/ru/DEC_Alpha
В 2007 году прекратили выпуск — когда у Интел только появились 64-битные системы...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
VV>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>Командой пересылки осуществляется ввод-вывод!
Оно и у интела сейчас, фактически, так. Очень редко можно встретить PCI устройство, которое садилось бы на I/O space. Большая часть их садится на Memory space. И доступ к ним идет через команды, работающие с памятью.
Здравствуйте, pagid, Вы писали:
P>Это очень красиво, я тоже был и до сих пор в восторге, но оно не помогло использовать более 64К памяти. Там страницы переключаюся с отображением на 64К, а в в x86 сегментная организация, что оказалось куда как гибче и работоспособнее и без напрягов переехало на 32-разрядеую архитектуру.
Сегментная адресация в интеле, фактически, умерла. В 32-битном режиме она не используется, в 64-битном еще и железом не поддерживается. Используется страничная адресация, как и везде.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах?
зачем нужен ПЗРК Пэтриот, когда С-400 лучше и дешевле?
Можно же производство пэтроита свернуть и пусть все покупают С-400. Зачем городить производство и продолжать думать над новыми разработками ПЗРК, когда с-400 хорош и его догонять очень дорого и долго?
Здравствуйте, MadHuman, Вы писали:
MH>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? MH>зачем нужен ПЗРК Пэтриот, когда С-400 лучше и дешевле? MH>Можно же производство пэтроита свернуть и пусть все покупают С-400. Зачем городить производство и продолжать думать над новыми разработками ПЗРК, когда с-400 хорош и его догонять очень дорого и долго?
Ты бы внимательней весть тредик прочитал прежде чем писать. Вопрос именно о своей и очень нетипичной архитектуре.
США не могут вместо пэтриот купить с400. Затраты вполне оправданы. МЦСЧ могли бы сделать РИСК архитектуру, есть даже СПАРК у них.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Надо, зачем нужнен именно VLIW для обесаечения нац безопастности? Почему не сделали РИСК АРМ-подобную например, что бы все бинари запускать из коробки?
ARM требует лицензирования. Эльбрус был разработан до того, как ARM стал суперпопулярным.
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Надо, зачем нужнен именно VLIW для обесаечения нац безопастности? Почему не сделали РИСК АРМ-подобную например, что бы все бинари запускать из коробки? P>ARM требует лицензирования. Эльбрус был разработан до того, как ARM стал суперпопулярным.
Я написал АРМ-подобную, не АРМ в точности. Вот есть же сейчас х86 эмуляция например. Для этого нужна лицензия? Вот и зачем нужно поддерживать все свое ПО? Почему не сделать процессор для которого легко сделать бин совместимость с существующими архитектурами. Все свое, без закладок. Взял все ПО и запустил.
Здравствуйте, a7d3, Вы писали:
A>Бинарный транслятор нужен-то «на один раз» — чтобы не пересобирать бинарники из исходников.
Хм... Дык для второго, третьего и последующих разов уже нужен высокоинтеллектуальный компилятор, который будет собирать из старого кода непосредственно под VLIW. Он уже есть у эльбрусовцев? Или как это всю жизнь у Бабаяна было — "мы создали проц, который в разы обгоняет нынешние иностранные разработки — подождите еще лет десять и мы это вам продемонстрируем"?
Здравствуйте, pagid, Вы писали:
Pzz>>Сегментная адресация в интеле, фактически, умерла. P>Ну и слава богу. Разговор о том, что в 16-разрядном режиме она была куда как удобнее и обеспечивала большие возможности, чем pdp-шное переключение 4-х килобайтовых страниц.
8-килобайтных, ради точности. 8 штук по 8KB (но по 4Кслов — может, поэтому так запомнилось).
N>Я таким URL не доверяю и никому не советую, и слово "брехня" относится скорее к ним. N>Пусть дадут реальную установку полдесятку действительно независимых экспертов, причём за пределами РФ. Тогда и посмотрим.
ну да, типично украинское. сначала набросить "по отзывам тех, кто это реально применял", а как макнули сразу слиться в недоверие
Gt_>> тем более, что meldown превращает нароботки последних лет интел в тыкву
N>AMD не превратила, и он сейчас впереди. И не x86 единым живо IT.
у амд точно та же корявая архитектура без какой-либо защиты доступа к кешу. адаптация вариаций мелтдаун к амд вопрос времени.
Здравствуйте, Cyberax, Вы писали:
C>Тут вопрос в чём, 20 лет назад своя архитектура имела смысл. Но сейчас есть RISC-V со свободно лицензированными патентами, есть полностью открытые архитектуры MIPS и SPARC с истёкшими патентами и даже x86 уже свободен по большей части (до SSE3). C>Можно было бы уже раз пять переделать процессор на один из этих вариантов.
1. Это другие ниши.
2. Один из процов (МЦСТ R1000) и так реализует последнюю спецификацию SPARC.
Ну и, кивание на другие архитектуры бессмысленно.
Как показала практика, в конечном итоге всё упирается в цену.
Взять тот же AVR — взялся из ниоткуда, контора-производитель Atmel на середину 90-х тоже никто и ничто — классическая тёмная лошадка.
Затем появились тонны референсных бордов на нём (где самые известные — линейка Ардуино), и проц стал сверхпопулярен.
N>Самое прямое. Только не к VLIW в целом, а к EPIC, который в Эльбрусе. N>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая. N>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
булшит. во первых э2к не просто выполняет команды спекулятивно, он выполнят несколько спекулятивных веток одновременно. кроме этого компилятор положит в префеч патерн необходимых данных сильно раньше, чем дойдет до исполнения ШК. компилятор заранее знает все, что может понадобится.
Здравствуйте, ononim, Вы писали:
O>IA-64 навернулся потому что ему была подложена свинья в виде AMD64
Причем свинья очень годная и по совокупности пользовательских характеристик превосходящая IA-64
V>Взять тот же AVR — взялся из ниоткуда, контора-производитель Atmel на середину 90-х тоже никто и ничто — классическая тёмная лошадка. V>Затем появились тонны референсных бордов на нём (где самые известные — линейка Ардуино), и проц стал сверхпопулярен.
Ага ага (c)
Мир микроконтроллеров вообще полон сюрпризов для среднестатистического программиста, судящего об их популярности по статьям на хабре.
Вот еще маркетинговая картинка: https://static2.seekingalpha.com/uploads/sa_presentations/780/780/slides/6.jpg?1470147054
Думаете Infineon это ARM или MIPS? Но нет, свой велосипед родом из 1999.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Marty, Вы писали: M>https://alexanius-blog.blogspot.com/2017/01/2017.html — чувак размышляет, как из C сделать C++
Да там вообще сплошной фейспалм. От чувака, который занимается _компиляторами_, ожидается чуть больше понимания в этих вопросах.
Из простейшего — "убрать слова register / auto / inline". Он, как автор компилятора, запросто может их игнорировать безо всякого вмешательства комитета по стандартизации.
Из более сложного — рассуждения про eval и рекомпиляцию. Ну, как бы в 2017 году быть не в курсе того, как устроен JIT в CLR/JVM — очень, очень странно.
В общем, складывается впечатление, что автор вообще никаких языков, кроме С, вблизи не видел. Слышал что-то про С++, но дальше — fog of war.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
G>>А каким образом компилятор будет знать за сколько тактов придут данные и насколько заранее надо запускать предвыборку?
Pzz>Ну в принципе, скорость DRAM примерно одинаковая...
У меня пяти-портовый DDR контроллер. Когда система idle, латенси практически стабильная с всплесками думается из-за рефреша. А вот когда идет большой трафик пакетов, то все — различается в несколько раз от чтения до чтения. Несколько мастеров лезут в эту память, пишут-читают, контроллер еще шедулит запросы по-разному. Бороться с этим можно конечно, но побороть до конца нельзя. И цена растет.
И там же три небольших процессора идут к одному арбитру, а потом уже одинь путь в DDR controller. И тут уже латенси прыгает вообще сильно когда они все лезут в память.
G>>Если все в кеше уже, то наверное проще, и то я не уверен что латенси не будет плавать (например из-за обеспечения когерентности).
Pzz>Я сильно сомневаюсь, что Эльбрус аппаратно сильно парится насчет обеспечения когерентности. Вообще, из известных мне процессоров аппаратная когерентность встречается только у интела/амд. У всяких прочих армов и мипсов это делается програмно.
Здравствуйте, Sinclair, Вы писали:
S>Из простейшего — "убрать слова register / auto / inline". Он, как автор компилятора, запросто может их игнорировать безо всякого вмешательства комитета по стандартизации.
Он пишет философский текст о том, каким должен был бы быть язык С, если его проектировать сейчас, с учетом накопленного опыта. Понятно, что это текст философский, никто так делать не будет, потому что груз совместимости и всякое такое.
Слова register/auto/inline в современном С действительно, лишние.
S>Из более сложного — рассуждения про eval и рекомпиляцию. Ну, как бы в 2017 году быть не в курсе того, как устроен JIT в CLR/JVM — очень, очень странно.
Ты высказался про имплементацию, он высказался про спецификацию языка.
Здравствуйте, ononim, Вы писали:
O>То есть такая "низкоуровневость" нативного кода сильно урезает возможности новых версий процессоров более оптимально исполнять старый код.
Учитывая количество языков с JIT или прекомпиляцией в нативный код на клиентской системе, это может быть не такая уж и проблема.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, LaptevVV, Вы писали:
LVV>В Интеле — отдельная адресация портов.
Она на практике почти не используется уже лет сто.
PCI Express например прямо запрещает их использовать:
Помимо этого, для доступа ко всему конфигурационному пространству PCIe тоже необходимо использовать memory mapped IO.
Так что можешь смело забыть про то, что они существуют.
Кстати, в ARMах и в RISC-V тоже используется только отображение в память.
Здравствуйте, koandrew, Вы писали:
LVV>>В Интеле — отдельная адресация портов. K>Она на практике почти не используется уже лет сто. K>PCI Express например прямо запрещает их использовать:
Неправда.
Там сказано не "all BARs shall be memory" или аналог, а, дословно, "endpoint must not depend on operation system allocation of I/O resources". Ключевое — "operating system allocation" и "depend".
То есть OS не должна заниматься перераспределением I/O портов после начальной настройки (средствами BIOS). Для ресурсов на памяти такого ограничения не ставится.
Практически же на машинах с PCI Express продолжает активно использоваться I/O пространство. Вот с моего настольника:
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 0
5)
Subsystem: ASRock Incorporation Ethernet Connection I217-V
Flags: bus master, fast devsel, latency 0, IRQ 25
Memory at f3100000 (32-bit, non-prefetchable) [size=128K]
Memory at f3129000 (32-bit, non-prefetchable) [size=4K]
I/O ports at f040 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] PCI Advanced Features
Kernel driver in use: e1000e
Kernel modules: e1000e
Это встроенная, то есть тут нельзя сослаться на проблемы совместимости — если бы был запрет на I/O порты, её бы давно подточили, и у неё не было бы такого диапазона.
K>Помимо этого, для доступа ко всему конфигурационному пространству PCIe тоже необходимо использовать memory mapped IO.
Нет, не необходимо.
В отличие от первых 256 байт, стиль доступа к остальным не специфицирован собственно стандартом PCI.
Маппинг на память это стиль Intel. У AMD вместо этого расширен регистр по I/O адресу 0x0CF8.
K>Так что можешь смело забыть про то, что они существуют.
Не может.
K>Кстати, в ARMах и в RISC-V тоже используется только отображение в память.
Да, кроме x86 я и не помню, кто бы использовал отдельное I/O пространство. (Ну не вспоминаем чисто канальные архитектуры и прочие редкости.)
Здравствуйте, netch80, Вы писали:
N>Очевидно, ты в полемическом задоре даже не прочитал ссылку, на которую ссылаешься. N>Ничего про предел fapb на ШК нет.
Боюсь, очевидно малость другое — ты пытаешься произносить вслух громкие вещи, смысла которых не понимаешь. ))
Для команд навроде fapb не требуется большего "предела", чем максимальная сбрасываемая длина конвейера вычислений, учитывая, что работает одновременно 4 конвейера, т.е. один основной и 3 альтернативных. Т.е., там, где у обычного проца происходит срыв конвейера при ошибке предсказания ветвления, у Эльбруса происходит переключение на один из конвейеров, работающий по альтернативной ветке, что резко уменьшает "сбрасываемую длину" конвейера, которая, собсно, и определяет необходимый размер внутренних буферов fapb.
Соответственно, у каждой модели Эльбруса кол-во этих регистров будет определяться характеристиками конвейера.
Перевожу на русский — вопрос был тупой донельзя.
N>В примере ассемблерного кода ни одной fapb.
Да я уже понял, что ты ни черта не понял.
N>По ссылке приводится пример математического расчёта. Почему-то все мерятели бенчмарками Эльбруса показывают только математику. Найди пример распаковки 7z-архива (один из типовых тестов, на которых сравнивают x86), перепаковки видео по ffmpeg. Какую-нибудь древнюю бегалку-стрелялку типа Doom (чтобы не требовался SSE и было достаточно типового оборудования лаптопа). Я подозреваю, что нет: им слабо́, потому что будут показаны результаты, с которыми стыдно идти даже к папуасам.
Свистишь как последний выскочка о всякой, прости хосподи, фигне.
В современном мире железо разрабатывается под софт, а софт под железо.
Ты же тут упорно делаешь вид, что подход должен быть сугубо односторонним.
С таким подходом пройдите, плиз, в детсад на смену подгузников.
Тут взрослые дядьки, всё-таки, общаются.
Здравствуйте, netch80, Вы писали:
N>Компилятор же тоже под него заточен? Так покажи реальную производительность не на специально подобранной расчётной задаче
Быстродействие тех же GPU измеряют на специально-подобранных расчётных задачах.
Про аппаратные кодеки аудио-видео аналогично.
Потому что классические CPU оказались неприспособлены под основные выч. задачи:
В современном мире железо разрабатывается под софт, а софт под железо.
Целевой рынок Эльбруса — это военка, космос, внутренние защищённые сети, критически-важное управление (те самые ядерные реакторы в т.ч., хотя это и "мем", но явно не в этом случае).
Соотв, измерять быстродействие нужно на тех задачах:
— обработка сигналов;
— шифрование/дешифрование данных;
— мат-моделирование сложных систем;
— ИИ.
— и т.д.
N>Что, нет данных?
Согласно последним данным, у процов Интел 9-го поколения быстродействие каждого ядра в пересчёте на мегагерц упало примерно на 20%, а быстродействие ядер Эльбруса пока только растёт. Т.е. классические архитектуры явно вошли в насыщение, т.е. приблизиться к ним вполне реально.
Прямо сейчас закончилась уже разработка модификации Эльбрус-8СВ, которая показывает увеличение быстродействия в нагруженных вычислениях более чем вдвое от модицикации 8с.
Одновременно подходит к концу разработка Эльбрус-16с (до 6-8 раз раз улучшение от модификации 8с), активно разрабатывается Эльбрус-32с.
Эльбрус — это не DSP, не GPU и не cell, это для тех самых "общих задач", но с приличной долей вычислений, именно на таких тестах он показывает себя весьма достойно (см. ссылку еще раз).
Т.е., к 2021/2022-му году ожидается достижение примерно таких же показателей на упомянутых задачах, как у топовых процов Интел сегодня.
Итого, сократили принципиальное отставание до, примерно, 5-ти лет, что уже не критично, ИМХО.
В нишах, где доля вычислений относительно невысока, туда разработана линейка МЦСТ R1000: http://www.mcst.ru/r_1000
Ожидается апдейт и этой линейки.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, a7d3, Вы писали:
A>>Архитектуры VLIW / EPIC являются естественным продолжением в эволюционном развитии персональных компьютеров с процессорами общего назначения. Имея в теории и демонстрируя на практике ряд преимуществ, включая большую энерго-эффективность и меньшие требования к производственному техпроцессу.
НС>Объясни тогда, почему и nVidia и AMD перешли в своих графических картах от VLIW к RISC?
Очень хочется тензорные ядра/процессоры причислить к RISC'ам или же речь про RT-ядра?
Да и почему разговор о видеокартах всплывает там, где речь шла о процессорах общего назначения.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, a7d3, Вы писали:
A>>>>>Такое впечатление, что ты знаешь систему команд Эльбруса. A>>>>>Поделись информацией!
A>>>>Есть книжка раздаваемая официально http://www.mcst.ru/doc/book_121130.pdf
A>>>Ну так система команд-то где? A>>>Информационного шума (маркетингового булшита) дохрена, но где конкретная информация?
A>>А книжку почитать? Приложение 3, 4 посмотреть.
A>Ты сам-то книжку читал? Приложение смотрел? Где там система команд? A>Ты вообще, знаешь, что такое система команд?
В курсе, знаю — сиди читай книжку до просветления, авось дойдет.
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что P>У них линейка на SPARC-совместимом тоже есть.
По крайней мере была точно.
CAF>>Вроде сверхзадач перед Эльбрусами не ставится, а вот затраты — огромные. P>Не огромные.
Нуу поддержка архитектуры дорого стои по-моему. И за это еще платить и платить.
CAF>>Это вообще экономичски обоснованный проект? Есть идеи? P>Экономически обоснованных проектов вблизи оборонки нет. Это не исключает того, что их можно сравнивать по экономическим показателям.
Вроде он доступен всем. Какие показатели есть?
Я согласен, что он нужен если позволяет улучшить обороноспособность. Я просто не понимаю как. Приобрести их и разобраться враги смогут?
Здравствуйте, wl., Вы писали:
wl.>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что
wl.>например, поэтому
Ты как-то не понял мою мысль. Можно было сделать что-то RISC — ARM подобное, что бы не надо было поддерживать свою архитектуру. И запускать ARM скомпилированный код. Сейчас же есть режим поддержки x86. Зачем для всего этого новую, причем совершенно другую аркхитектуру городить?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Ты как-то не понял мою мысль. Можно было сделать что-то RISC — ARM подобное, что бы не надо было поддерживать свою архитектуру. И запускать ARM скомпилированный код. Сейчас же есть режим поддержки x86. Зачем для всего этого новую, причем совершенно другую аркхитектуру городить?
Она нагорожена уже довольно давно, разработаны принципы кодогенерации, насколько оптимизированные , но тем не менее хлеба не просят и особых текущих затрат тоже.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Ну, зачем нужен Мерседес, если есть ВАЗ? LVV>>>Или Рено — если есть опель? САД>>Не так, зачем нужен ваз, если есть другие нормальные марки? LVV>Именно! LVV>Зачем нужен этот гуано Интел, если есть нормальные марки: Эльбрус, pdp-11 ...
Не надо скатываться.
PDP-11, X86 были (и есть) вполне коммерческими успехами, ближайший сороди Эльбруса вроде уже почил давно.
Яне разбираюсь в марках машин, там наверное был смысл.
Есть что по теме сказать. Ты же все-таки представитель науки. Может знаешь что?
Нам в Универе об Эльбрусе немного рассказывали, там совсем другая система команд. И просто щелчком кодогенератор с РИСК/ЦИСК не поменяшь.
(Извини за излишнюю фамильярность, но я думаю, что на форуме ты другого не ждут.)
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Ты как-то не понял мою мысль. Можно было сделать что-то RISC — ARM подобное, что бы не надо было поддерживать свою архитектуру. И запускать ARM скомпилированный код. Сейчас же есть режим поддержки x86. Зачем для всего этого новую, причем совершенно другую аркхитектуру городить? P>Она нагорожена уже довольно давно, разработаны принципы кодогенерации, насколько оптимизированные , но тем не менее хлеба не просят и особых текущих затрат тоже.
В теории может и разарботаны. Так тебе же все ПО надо будет постоянно поддерживать. Всю его жизнь. Каждый апдейт перекомпилировать, проверять и т.д. И это все деньги, как это окупится?
P>ARM же вроде как лицензировать нужно?
Минобороны могло бы и возразить
Я уже написал, что хотя бы РИСК, что-то более похожее. Что бы можно было существущее ПО просто использовать.
Я не спорю, что смысл может есть (должен быть) Но какой? Завоевать рынок — не похоже. Оградить себя от врагов — не понимаю как поможет?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>В теории может и разарботаны. Так тебе же все ПО надо будет постоянно поддерживать. Всю его жизнь. Каждый апдейт перекомпилировать, проверять и т.д. И это все деньги, как это окупится?
Это по затратам на уровне поддержания не самого сложного программного продукта. И апдейт чего? GCC? там же наверно компилятор это кодогенератор для него.
CAF>Я уже написал, что хотя бы РИСК, что-то более похожее. Что бы можно было существущее ПО просто использовать.
Без разницы. Может RISK чем-то и лучше, может и нет, но это чисто теоретический спор когда изделие находится в уже работающем состоянии.
CAF>Я не спорю, что смысл может есть (должен быть) Но какой? Завоевать рынок — не похоже. Оградить себя от врагов — не понимаю как поможет?
Не использовать в критических местах чужое железо.
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>В теории может и разарботаны. Так тебе же все ПО надо будет постоянно поддерживать. Всю его жизнь. Каждый апдейт перекомпилировать, проверять и т.д. И это все деньги, как это окупится? P>Это по затратам на уровне поддержания не самого сложного программного продукта. И апдейт чего? GCC? там же наверно компилятор это кодогенератор для него.
Всех продуктов. Каждую новую персию надо перекомпилировать и возможно тестировать. И не все собирается ГЦЦ. Что с другими языками, платформами? Все это надо подделживать, и питон, и руби, и джаву, и джавоскрипт и т.д.
CAF>>Я уже написал, что хотя бы РИСК, что-то более похожее. Что бы можно было существущее ПО просто использовать. P>Без разницы. Может RISK чем-то и лучше, может и нет, но это чисто теоретический спор когда изделие находится в уже работающем состоянии.
Риск — в риск проще сделать бинарный транслатор, или просто поддержать бинарную совместимость.
CAF>>Я не спорю, что смысл может есть (должен быть) Но какой? Завоевать рынок — не похоже. Оградить себя от врагов — не понимаю как поможет? P>Не использовать в критических местах чужое железо.
Стоп, стоп. Я про архитектуру именно. Свое, полностью контролирумое железо я понимаю. Произведенное в РФ, а не заказанное в Тайване, Китае или еще где. Тут я поддерживаю 100% импортозамещение для всех критических целей, сколько бы оно не стоило. Это вплолне объективно обоснованная цель.
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>Не знаю как тебе, но мне очень не хочется иметь в стране бессильную в реальной войне армию.
Почитай, плз, еще раз. И весь топик, с последними моими комментами. Вопрос именно в столь нестандартной архитектуре.
Re[3]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Почитай, плз, еще раз. И весь топик, с последними моими комментами. Вопрос именно в столь нестандартной архитектуре.
Замечательно. Софтверные вредоносы не заработают by arch.
Matrix has you...
Re[4]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Почитай, плз, еще раз. И весь топик, с последними моими комментами. Вопрос именно в столь нестандартной архитектуре. S>Замечательно. Софтверные вредоносы не заработают by arch.
Как это связанно? Расскажи. Я не понимаю, серьезно.
Все равно же весь линукс запускается, все ПО. Просто после компиляции. Точно также все не наше ПО надо сертифицировать.
А с питоном, джавой и т.д. как ?
LVV>>Ну, зачем нужен Мерседес, если есть ВАЗ? LVV>>Или Рено — если есть опель? CC>Вот только эльбрус это ВАЗ.
Нифига подобного.
Эльбрус и Эльбрус-2 работали в СССР.
И опережали свое время.
Это Эльбрус-3 в связи с развалом Союза почил в бозе.
Сейчас (на мой взгляд, правильно) пытаются возродить.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Зачем нужен этот гуано Интел, если есть нормальные марки: Эльбрус, pdp-11 ... CAF>>Не надо скатываться. LVV>Извини, но интел реально гуано после pdp-11. LVV>Я работал — это была блестящая архитектура! LVV>Интел, кстати, содрал систему прерываний с нее... CAF>>PDP-11, X86 были (и есть) вполне коммерческими успехами, ближайший сородич Эльбруса вроде уже почил давно. LVV>А кто ближайший сородич Эльбруса?
IA-64 (Itanium)
Кстати может новые уже появились?
CAF>>Есть что по теме сказать. Ты же все-таки представитель науки. Может знаешь что? CAF>>Нам в Универе об Эльбрусе немного рассказывали, там совсем другая система команд. И просто щелчком кодогенератор с РИСК/ЦИСК не поменяшь. LVV>В начале 2 половины 80-х в журнале Программирование печатали статью Бабаяна про архитектуру Эльбруса. LVV>Потом была книжка Пентковского Автокод Эльбрус Эль-76. Книжку можно найти в сети. LVV>Основное — машинный язык Эльбруса — это аппаратно реализованный язык высокого уровня процедурного типа с аппаратными проверками типов на основе тегов.
LVV>Потом Пенковский слинял в США. LVV>Так что посты в сети об участии Пентковского в разработках Пентиумов вполне могут быть правдой.
LVV>Я видел Эльбрус на конференции по свободному ПО в Переславле — Залесском в конце января этого года. LVV>Там есть институт программных систем — они АльтЛинукс развивают. LVV>И на эту конференцию для участников поставили небольшую выставку машин российского производства. LVV>В том числе и Эльбрус.
Ну это конечно хорошо. Но зачем? Что делать с этим автокодом сейчас то? Как деньги будут зарабатывать?
LVV>>А кто ближайший сородич Эльбруса? CAF>IA-64 (Itanium) CAF>Кстати может новые уже появились?
Это ни разу не сородич — даже близко не лежит. LVV>>Основное — машинный язык Эльбруса — это аппаратно реализованный язык высокого уровня процедурного типа с аппаратными проверками типов на основе тегов. CAF>Ну это конечно хорошо. Но зачем? Что делать с этим автокодом сейчас то? Как деньги будут зарабатывать?
Это — в оборонку пока больше.
Институт программных систем деньги зарабатывает совсем не на эльбрусе — как-то они там с сетями работают...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>А кто ближайший сородич Эльбруса? CAF>>IA-64 (Itanium) CAF>>Кстати может новые уже появились? LVV>Это ни разу не сородич — даже близко не лежит.
А кто ближе? LVV>>>Основное — машинный язык Эльбруса — это аппаратно реализованный язык высокого уровня процедурного типа с аппаратными проверками типов на основе тегов. CAF>>Ну это конечно хорошо. Но зачем? Что делать с этим автокодом сейчас то? Как деньги будут зарабатывать? LVV>Это — в оборонку пока больше.
А что потом то? И зачем оборонке своя архитектуры. Ну вот сделали Байкал — понимаю, свой завод — понмаю. Все железо — да. Но Эльбрус то зачем? LVV>Институт программных систем деньги зарабатывает совсем не на эльбрусе — как-то они там с сетями работают...
Это оффтопик.
Здравствуйте, Gt_, Вы писали:
Gt_>потому то x86 на серьезные задачи не проектировался. у интел уже лет 8 скорость ядра уперлась в потолок, при этом архитектра дубова и не в состоянии защитить данные в облачной инфраструктуре (meltdown всяукие не вылечить в принипе). Gt_>а вот архитектра эльбруса и память защищает и много больше задач за такт выполняет. только вот сыро там все, начиная с компилятора. понятно что отдел за десятком сотрудников такой проект не потянет. нужны посерьезней вложения.
А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
Re[4]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Почитай, плз, еще раз. И весь топик, с последними моими комментами. Вопрос именно в столь нестандартной архитектуре. S>Замечательно. Софтверные вредоносы не заработают by arch.
На эту тему уже был однажды пост покойного мыщъха в том духе, что подобный подход — это типичное "security through obscurity", при том, что архитектура Эльбруса на самом деле давно в общем-то известна, всем кто хотел. Она собственно даже не скрывается официально, компы с ним в принципе как бы продаются и в гражданском секторе. Но вот в отличие от x86 методов анализа на безопасность не наработано.
Не знаю насколько это важно, просто вспомнил. Найти сам пост не нашел по быстрому.
Здравствуйте, LaptevVV, Вы писали:
CC>>Вот только эльбрус это ВАЗ. LVV>Нифига подобного. LVV>Эльбрус и Эльбрус-2 работали в СССР.
ВАЗ тоже работал в СССР.
LVV>И опережали свое время.
...которое было сорок лет назад.
LVV>Это Эльбрус-3 в связи с развалом Союза почил в бозе. LVV>Сейчас (на мой взгляд, правильно) пытаются возродить.
Вот об этом и речь — нафига? Это же примерно, как если бы в Штатах пытались возродить Cray-2 — с точки зрения "чем бы прикольным заняться" оно интересно, конечно, но вот практически...
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, 0xCAFEDEAD, Вы писали:
S>компилятора. понятно что отдел за десятком сотрудников такой проект не потянет. нужны посерьезней вложения.
CAF>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
S>Да не окупятся они. Вложить деньги налогоплательщиков, да "посерьёзней", пока дают, вот и вся история. Заодно почесать гондурас сверхдлинного слова с явным параллелизмом. Опять же, за счёт налогоплательщиков, почему бы и не почесать?
в моей канторе в бесплатные печеньки и фрукты больше вкладывают. вложения в эльбрус смешные. если бы гос-во хоть немного вложило, тогда можно было бы чего-то ждать. хуавей в тупую упаковку армов на порядок больше тратит, чем эльбрусу выдали.
Gt_>>потому то x86 на серьезные задачи не проектировался. у интел уже лет 8 скорость ядра уперлась в потолок, при этом архитектра дубова и не в состоянии защитить данные в облачной инфраструктуре (meltdown всяукие не вылечить в принипе). Gt_>>а вот архитектра эльбруса и память защищает и много больше задач за такт выполняет. только вот сыро там все, начиная с компилятора. понятно что отдел за десятком сотрудников такой проект не потянет. нужны посерьезней вложения.
CAF>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
вложений не было. пацанам пиво поставили, они за пиво прототип свояли. сначала нужны вложения, и не в деревянных. на 2.5ghz ядро эльбруса вполне потягается с современным ядром xeon gold. перевести всякие ораклы на бесплатные хадупы на контролиремой архитектуре и китайцы хотят и индусы. но нужен продукт, а не прототип за пивко.
Здравствуйте, pagid, Вы писали:
P>Это по затратам на уровне поддержания не самого сложного программного продукта. И апдейт чего? GCC? там же наверно компилятор это кодогенератор для него.
насколько я знаю, нет.
там какой-то другой компилятор переделан.
но на нём собирается весь альт линукс, включая ядро, так что компилятор достаточно зрел.
Здравствуйте, 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х.
Gt_>>>потому то x86 на серьезные задачи не проектировался. у интел уже лет 8 скорость ядра уперлась в потолок, при этом архитектра дубова и не в состоянии защитить данные в облачной инфраструктуре (meltdown всяукие не вылечить в принипе). Gt_>>>а вот архитектра эльбруса и память защищает и много больше задач за такт выполняет. только вот сыро там все, начиная с компилятора. понятно что отдел за десятком сотрудников такой проект не потянет. нужны посерьезней вложения.
CAF>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
Gt_>вложений не было. пацанам пиво поставили, они за пиво прототип свояли. сначала нужны вложения, и не в деревянных. на 2.5ghz ядро эльбруса вполне потягается с современным ядром xeon gold. перевести всякие ораклы на бесплатные хадупы на контролиремой архитектуре и китайцы хотят и индусы. но нужен продукт, а не прототип за пивко.
Пацаны, пивко, ты о чем?
И причем здесь ораклы и хадупы? Переведут где угодно. (Правда на Эльбрусе нет джавы) И почем китайцы и индусы захотят эльбрус? Что им можно предложить. Для наших хоть независимость от других стран в теории.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
A>Вот ниже видео, таймкод 20:15, довольно много деталей по тому что может этот ЦПУ. A>Фактически там есть режим работы с аппаратным valgrind'ом (таймкод 33:50). Т.е. хороша и современна не только VLIW-архитектура, но и ряд других вещей в этой железке. Такой вариант построения процессоров это технологический прогресс, а не какой-то самостийный колхоз A>https://www.youtube.com/watch?v=rVrUtqhsxvE&t=1215
Это все конечно хорошо. Но непонятно насколько реально полезно. Большинство ПО сейчас пишут в для язков в которых уже нет прямых указателей. Там всxе тоже защищено.
И как на этом планируют деньги заработать? Вот в чем вопрос. Дешевле свой гипервизор сделать, который эмулирует x86 на x86 со всеми проверками доступа памяти.
Кстати, а вот зачем нужен этот самый Intel? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
Если я правильно понимаю, то надо поддерживать линейку компиляторов и всего инструментария для них. При чем разница в архитектуре VLIW/IA-64/EPIC с RISC/CISC значительная. Закрытый код вообще не портировать.
Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что
Вроде сверхзадач перед Интелями не ставится, а вот затраты — огромные. Это вообще экономичски обоснованный проект? Есть идеи?
...
Ну ты понял, да?
Re[7]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, 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>Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
Не понял. Ты думаешь, что поддерживать свою архитектуру проще чем реализовать чужую?
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, 0xCAFEDEAD, Вы писали:
W>Кстати, а вот зачем нужен этот самый Intel? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
W>Ну ты понял, да?
Нет. Если ты про x86 и семью, то они уже окупились. Да и созданы до мипсов спарков и т.д.
Или ты о чем?
Re[3]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, playnext, Вы писали:
S>>Не знаю как тебе, но мне очень не хочется иметь в стране бессильную в реальной войне армию. P>Вы лично как армии помогаете?
Узнавал про контрактную службу. Сказали что старый уже....
P>Срочную службу хотя бы прошли?
К сожалению, нет
Моя служба должна была быть в 90е. Родители не пустили.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Это все конечно хорошо. Но непонятно насколько реально полезно. Большинство ПО сейчас пишут в для язков в которых уже нет прямых указателей. Там всxе тоже защищено. CAF>И как на этом планируют деньги заработать? Вот в чем вопрос. Дешевле свой гипервизор сделать, который эмулирует x86 на x86 со всеми проверками доступа памяти.
Поэтапный переход к процессорам с такими защищенными режимами, как контекстная защита в Эльбрусах — это просто следствие технического прогресса в сфере вычислительной техники. Пригодится везде, где люди сейчас вынуждены пользоваться различными санитайзерами и valgrind'ом.
Про монетизацию в том интервью хорошо рассказано на примере эмбедид систем повышенной надежности, за счет исполнения программного кода в защищенном режиме. Сперва портируются рантаймы вроде uClibc | musl, а после этого уже остальная начинка, у тех же АСУ ТП она небольшая.
Здравствуйте, 0xCAFEDEAD, Вы писали:
W>>Зачем городить еще одну архитектуру в промышленных масштабах?
CAF>Или ты о чем?
Она не "еще одна", а "одна из уже" существующих в промышленных масштабах. Потому есть ощущение, что твоя критика из стартового сообщения несколько мимо кассы.
Re[9]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Нет. Все не так. JIT компилятор кстати тоже написан почти весь на с++ и даже на джава. Но генерят они код для целевой плтформы оба. Интерпретатор тоже генерит код. Хоть и попроще.
Ну, я примерно это и сказал. Ты читать-то умеешь, или только писать?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Нет. Все не так. JIT компилятор кстати тоже написан почти весь на с++ и даже на джава. Но генерят они код для целевой плтформы оба. Интерпретатор тоже генерит код. Хоть и попроще.
Pzz>Ну, я примерно это и сказал. Ты читать-то умеешь, или только писать?
Интерпретатор генерит код для целевой платформы. Его тоже надо портировать. Что не понятного?
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, 0xCAFEDEAD, Вы писали:
W>>>Зачем городить еще одну архитектуру в промышленных масштабах?
CAF>>Или ты о чем?
W>Она не "еще одна", а "одна из уже" существующих в промышленных масштабах. Потому есть ощущение, что твоя критика из стартового сообщения несколько мимо кассы.
Эльбрус существует в промышленных масштабах??? Не смеши меня.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Это все конечно хорошо. Но непонятно насколько реально полезно. Большинство ПО сейчас пишут в для язков в которых уже нет прямых указателей. Там всxе тоже защищено. CAF>>И как на этом планируют деньги заработать? Вот в чем вопрос. Дешевле свой гипервизор сделать, который эмулирует x86 на x86 со всеми проверками доступа памяти.
A>Поэтапный переход к процессорам с такими защищенными режимами, как контекстная защита в Эльбрусах — это просто следствие технического прогресса в сфере вычислительной техники. Пригодится везде, где люди сейчас вынуждены пользоваться различными санитайзерами и valgrind'ом.
A>Про монетизацию в том интервью хорошо рассказано на примере эмбедид систем повышенной надежности, за счет исполнения программного кода в защищенном режиме. Сперва портируются рантаймы вроде uClibc | musl, а после этого уже остальная начинка, у тех же АСУ ТП она небольшая.
Ок, вот есть первое (в данном тредике) действительно обоснованное потенциальное конкурентное преимущество. И это именно преимущество "архитектуры" Эльбрус, то что и имелось ввиду.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Интерпретатор генерит код для целевой платформы. Его тоже надо портировать. Что не понятного?
Pzz>Интерпретатор вообще ничего не генерит. Он интерпретирует. Поэтому его называют "интерпретатор".
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах?
ZEN>Выбрали VLIW — https://www.ixbt.com/cpu/vliw.shtml
То хоть тред читал? Ты думаешь я слова VLIW не слышал?
Re[6]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, playnext, Вы писали:
P>>>>Срочную службу хотя бы прошли? S>>>К сожалению, нет S>>>Моя служба должна была быть в 90е. Родители не пустили. P>>Ну вот, а меня пустили. Вообще то это священная обязаность гражданина служить. Родители тут не причем. S>Дада, давай, начинай грязь на меня лить, да повонючее. Объяви что я голоса не имею и прочие санкции введи. S>Главное же с топика чъехать на обсуждение меня, да?
Ну извини. Я ни в коем случае никого не хотел обижать. Но современное поколение в РФ в основном в армию старается не ходить. Это нормально.
Ну а так почти в тему. Процессор военный ведь?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
CAF>Если я правильно понимаю, то надо поддерживать линейку компиляторов и всего инструментария для них. При чем разница в архитектуре с RISC/CISC значительная. Закрытый код вообще не портировать.
CAF>Сделали бы свой свой процессор на уже поддерживаемой архитектуре. SPARC, MIPS вроде уже у нас есть. ARM — идеальный кандидат, ну или ARM совместимый клон, и забить на лицензию. X86? Там лицензия вроде нужна, да наследие былых времен тяготит, так что
CAF>Вроде сверхзадач перед Эльбрусами не ставится, а вот затраты — огромные. Это вообще экономичски обоснованный проект? Есть идеи?
CAF>Доредактировал: CAF>Если есть не экономически обоснованный смысл — то озвучьте. Именно использования столь нестандартной архитектуры без поддержки существующего ПО. Про трансляцию с х86 известно. CAF>По цифрам — вроде вложили 600млн, и стоит 1 комп 500К денег. Да еще кучу бабла потратили с 70-х годов, но его уже потратили, нет смысла сейчас обсуждать. CAF>Попрошу воздержаться от совсем уж говносрача, особенно, с политичекским уклоном. (Ну да я наивен, но все же.) CAF>Добавлю еще для новеньких: CAF>Я про архитектуру именно. Свое, полностью контролирумое железо я понимаю. Произведенное в РФ, а не заказанное в Тайване, Китае или еще где. Тут я поддерживаю 100% импортозамещение для всех критических целей, сколько бы оно не стоило. Это вплолне объективно обоснованная цель.
Вот интересно — а кто нибудь сделает процессоры с несколькими системами команд на борту?
Если появится задача мигрировать наконец-то с этого набившего оскомину x86 на что нибудь получше. Можно сделать x86 ядро + свеженькие. И вот выпускать их лет 20-30, чтобы софт обновился. А далее — x86 можно эмулировать будет. Как нынче DosBox написали.
Говорили же, что появление amd64 закрепляет старомодную архитектуру, и дурное это дело.
Здравствуйте, jamesq, Вы писали:
J>Вот интересно — а кто нибудь сделает процессоры с несколькими системами команд на борту?
Если отвечать на подразумеваемый вопрос — Intel делал — IA64 (Merced, Itanium...)
Сдохло — на него не стали переходить (главным образом, конечно, из-за принципиальной стратегической ошибки
, но и слабость компиляторов помогла.
Кстати, в рамках этого треда реквестирую рассказ, как с той же проблемой у Эльбруса. Если так же — то, пока с доступом к памяти не разобрались, только хоронить.
Исторически, было ещё несколько аналогичных прецедентов (например, VAX + PDP-11).
А вообще, разные разрядности — тоже разные системы команд, и это давно делается (любой x86 их сейчас поддерживает аж три).
J>Если появится задача мигрировать наконец-то с этого набившего оскомину x86 на что нибудь получше. Можно сделать x86 ядро + свеженькие. И вот выпускать их лет 20-30, чтобы софт обновился. А далее — x86 можно эмулировать будет. Как нынче DosBox написали.
В Эльбрусе как раз эмуляция x86, как один из важных режимов.
J>Говорили же, что появление amd64 закрепляет старомодную архитектуру, и дурное это дело.
Да. Но она ведь почему-то выжила? И в производительности на один камень ей мало равных (ну, в части случаев PPC её обходит).
N>А вообще, разные разрядности — тоже разные системы команд, и это давно делается (любой x86 их сейчас поддерживает аж три).
Ну нет, это не так конечно. Эти разрядности — просто различные варианты одной системы команд. Оно же в корне ничего не меняется: как были вот эти переходы в зависимости от регистра флагов, так и остаются. Те же команды FPU, более крупные регистры включают в себя более мелкие.
Там же не появляются вот эти вот shadow регистры, как в Z80
Re[7]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, playnext, Вы писали:
P>Но современное поколение в РФ в основном в армию старается не ходить. Это нормально.
Только почему то взятки теперь дают за то чтобы пойти в армию
Здравствуйте, LaptevVV, Вы писали:
LVV>Дело не в объеме памяти, а архитектуре системы команд. LVV>В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные.
Это очень красиво, я тоже был и до сих пор в восторге, но оно не помогло использовать более 64К памяти. Там страницы переключаюся с отображением на 64К, а в в x86 сегментная организация, что оказалось куда как гибче и работоспособнее и без напрягов переехало на 32-разрядеую архитектуру.
LVV>Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была. LVV>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>Командой пересылки осуществляется ввод-вывод!
Это не так уж и важно.
LVV>Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие. LVV>Одной командой можно было очистить ВСЮ память. LVV>Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение.
Угу. Только интеловская плавно расширилась на 32 разряда и на 64, а для той такой возможности не было.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Зачем нужна своя VLIW архитектура?
Она уже есть и по большому счету ничем не хуже любой другой собственной архитектуры.
С колокольни околосистемного программиста, никогда процессоры не разрабатывавшего у VLIW есть свои плюсы, которые однако же и одновременно минусы. CISC/RISC позволяют более гибкую оптимизацию на уровне процессора, VLIW же с ее параллелизацией на уровне компилятора подразумевает что однажды скомпиленный код на будущих процессорах будет параллелиться точно так же как и на старых. То есть такая "низкоуровневость" нативного кода сильно урезает возможности новых версий процессоров более оптимально исполнять старый код. С другой стороны умные декодеры, те самые, которые в х86 позволяют параллелить код, они тоже кушать хотят, потому offload их работы на компилятор теоретически снижает энергопотребление.
Потому мое ИМХО таково, что VLIW оптимален для эмбеддеда/мобильников и всяких JIT сред исполнения, а для десктопа/нативного кода — ну так себе. Хотя для opensource тоже норм, если не лень пересобирать мир под каждый новый проц.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 0xCAFEDEAD, Вы писали:
W>>Она не "еще одна", а "одна из уже" существующих в промышленных масштабах. CAF>Эльбрус существует в промышленных масштабах?
Интел с аналогичной архитектурой.
PS Как-то не предполагал, что придется разжевать, и в рот положить
O>>Потому мое ИМХО таково, что VLIW оптимален для эмбеддеда/мобильников и всяких JIT сред исполнения, а для десктопа/нативного кода — ну так себе. Хотя для opensource тоже норм, если не лень пересобирать мир под каждый новый проц. A>Точка зрения понятно, но есть нюанс. A>Открываем https://www.archlinux32.org/packages/ смотрим на Arch.-+ A>Даже такие маргиналы как мейнтейнеры 32-х битного ArchLinux держат в репозиториях бинарники собранные под разные варианты 32-разрядного x86.
Ну я ж писал что в опенсурсе тоже норм. В целом более тесная связка компонентов системы подразумевает большие возможности для оптимизации и меньшие — для унификации. В данном случае компоненты — проц и компилятор.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>Потому мое ИМХО таково, что VLIW оптимален для эмбеддеда/мобильников и всяких JIT сред исполнения, а для десктопа/нативного кода — ну так себе. Хотя для opensource тоже норм, если не лень пересобирать мир под каждый новый проц. A>>Точка зрения понятно, но есть нюанс. A>>Открываем https://www.archlinux32.org/packages/ смотрим на Arch.-+ A>>Даже такие маргиналы как мейнтейнеры 32-х битного ArchLinux держат в репозиториях бинарники собранные под разные варианты 32-разрядного x86. O>Ну я ж писал что в опенсурсе тоже норм. В целом более тесная связка компонентов системы подразумевает большие возможности для оптимизации и меньшие — для унификации. В данном случае компоненты — проц и компилятор.
А много ли народу в современных линуксах что-то там пересобирают на своих компах?
Поголовно качают уже готовые бинарники с репозиториев. Даже когда пользователями являются профессиональные специалисты из мира разработки софта. Сколько реально осталось source based дистрибутивов линукса и какое количество пользователей у них?
Будет в репозиториях лежать несколько вариантов бинарников — под разные варианты поколения VLIW, так же как делали последние года с вариациями 32-разрядного x86.
В тоже время, у Эльбрусов давно есть встроенный бинарный транслятор x86-инструкций в VLIW-машкод. А это гораздо сложнее, чем сконвертировать VLIW-инструкции одного поколения под более новое. Так что вопрос унификации под разные VLIW может решаться и бинарной трансляцией — как динамической, так и с кэшированием. Например, как в случае приложений под современные Android'ы, то самое «выполняется оптимизация приложений».
Как человек, никогда не видевший PDP-11, могу ли я поинтересоваться?
LVV>Дело не в объеме памяти, а архитектуре системы команд.
Ее в самом деле сильно хвалили, но в чем там фишка, не рассказывали.
LVV>В pdp все было единообразно,
В чем заключалось единообразие, можешь просветить?
LVV>аргументы могли располагаться где угодно.
Это как? Разве не через стек шла передача аргументов? Это на ЕС не было стека, приходилось выделять память, оставлять адрес выделенной области в одном из регистров, потом на входе все очищать. Поэтому на ЕС рекомендовали не злоупотреблять вызовами подпрограмм.
LVV>Методы адресации — единообразные.
И этого не понял. Во все времена адресация была прямая, непосредственная, несколько типов косвенной. Я что-то пропустил?
LVV>Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была.
То есть, выполнялся одной командой?
LVV>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>Командой пересылки осуществляется ввод-вывод!
Такое было на Motorola 68040. Часть памяти отображалась на ввод/вывод. Не нужна была отдельная команда чтения/записи в порт. Но какие преимущества это давало при программировании, я не очень понимаю.
Пока все, пожалуй. Может, еще что потом вспомню.
P.S. на третьем курсе один из наших преподов любил повторять: глупых вопросов не бывает.
Здравствуйте, LaptevVV, Вы писали:
LVV>РНе... LVV>Дело не в объеме памяти, а архитектуре системы команд. LVV>В pdp все было единообразно, аргументы могли располагаться где угодно. Методы адресации — единообразные.
Неправда. На единообразие им тупо не хватило места в 16 битах.
ADDB, SUBB байтные — не введены.
XOR, MUL, DIV, ASH, ASHC имеют одним аргументом только регистр.
Для обычной группы сдвигов (ASL, ASR, ROL, ROR) не хватило места на аргумент — величину сдвига.
Про плавучку вообще молчу — группа FIS брала аргументы со стека и возвращала результат на стек, потому что иначе не нашли места для аргументов.
LVV>Инкремент и декремент — единообразен. Это вообще ПЕСНЯ была.
Причём косвенные их варианты использовались чуть чаще, чем никогда (режим 3 по PC не в счёт).
LVV>Регистры внешних устройств адресовались адресами памяти — это блеск!
Да, это впервые появилось именно в PDP-11. Позднее из неё распространилось на всех. Так же как схема флагов NZVC.
LVV>Командой пересылки осуществляется ввод-вывод!
А вот то, что MOV ставила флаги, признано ошибкой и с 80-х никем не повторяется.
LVV>Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие. LVV>Одной командой можно было очистить ВСЮ память.
Если бы она после этого останавливалась, был бы смысл. А так — нелепое хакерство на померяться дурью удалецкой.
LVV>Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение.
Зато идейный последователь подхода PDP-11 в лице M68k — умер в начале 90-х, потому что не смог перейти со своей универсальностью в мир, где out-of-order исполнение, переименование регистров и иерархия кэшей.
CAF>>>А что потом то? И зачем оборонке своя архитектуры. Ну вот сделали Байкал — понимаю, свой завод — понмаю. Все железо — да. Но Эльбрус то зачем?
Gt_>>что бы не грустить потом как хуавей, с его байкалом. упаковать арм ядра может и хуавей, но нужен то всем полноценный проц, а не еще один байкал.
CAF>Зачем нужна своя VLIW архитектура?
что бы не упереться в производительность одного потока как интел с x86. vliw позволяет больше инструкций за такт + перенести блок предсказаний в компилятор.
пытаться с двумя деревянными рублями догнать интел просто глупо, посоревноваться с интелом и арм сможет лишь то, что будет в разы больше инструкций за такт прожевывать. например vliw.
Re[8]: Эту ветку сразу можно отделять и в политику.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, playnext, Вы писали:
P>>Но современное поколение в РФ в основном в армию старается не ходить. Это нормально. S>Только почему то взятки теперь дают за то чтобы пойти в армию
Да наверно, может сечас. В основном из бедных регионов, поскольку в армии как минимум кормят. В Дагестане такое распространено.
A>В тоже время, у Эльбрусов давно есть встроенный бинарный транслятор x86-инструкций в VLIW-машкод. А это гораздо сложнее, чем сконвертировать VLIW-инструкции одного поколения под более новое.
Насколько я понимаю, он скорее софтверный чем хардварный, и потомку медленный.
Ну и обрастание слоями VLIW2VLIW трансляции выглядит еще более костыльно чем то, что есть в х86 сейчас.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
A>>В тоже время, у Эльбрусов давно есть встроенный бинарный транслятор x86-инструкций в VLIW-машкод. А это гораздо сложнее, чем сконвертировать VLIW-инструкции одного поколения под более новое. O>Насколько я понимаю, он скорее софтверный чем хардварный, и потомку медленный. O>Ну и обрастание слоями VLIW2VLIW трансляции выглядит еще более костыльно чем то, что есть в х86 сейчас.
Бинарный транслятор нужен-то «на один раз» — чтобы не пересобирать бинарники из исходников.
Про слои и костыльность — это же обратная совместимость бинарного кода. Будет странно, если бинарник собранный под современный Эльбрус через пять лет откажется работать на более новой модели из того же семейства ЦПУ.
Здравствуйте, Pzz, Вы писали:
Pzz>Сегментная адресация в интеле, фактически, умерла.
Ну и слава богу. Разговор о том, что в 16-разрядном режиме она была куда как удобнее и обеспечивала большие возможности, чем pdp-шное переключение 4-х килобайтовых страниц.
Здравствуйте, LaptevVV, Вы писали:
LVV>1. Там без проблем работало 256 кил памяти.
Там использование было менее удобным, чем в х86. Оно было ориентировано скорее на многозадачную ОС в которой каждому процессу выделено (64К — <для служебных целей>) В x86 выход за 64К для 16-разрфдных приложений более удобен. Именно по этой причине в момент создания первых ПК х86 выглядела куда как привлекательней.
LVV>А потом они создали VAX...
Но это уже не PDP-11, и красота и элегантность ушли, несмотря на попытку перенести принципы. Хотя архитектура тоже очень достойная получилась.
LVV>2. Я бы не сказал, что интел переехал без напрягов. Там столько аппаратуры допилили — фактичски новый комп создали.
А программную совместимость сохранили, и чужеродными не были ни 16-разрядные программы в 32-разрядной среде, 32-разрядные в современной 64-разрядной ОС настолько же родные, насколько и 64-разрядные.
LVV>DEC Alpha: https://wiki2.org/ru/DEC_Alpha
Это совсем не PDP и не VAX, а совершенно другая архитектура и машина.
LVV>В 2007 году прекратили выпуск — когда у Интел только появились 64-битные системы...
Потому как на фоне х64 стали совсем не нужны.
Здравствуйте, LaptevVV, Вы писали:
P>>Это очень красиво, я тоже был и до сих пор в восторге, но оно не помогло использовать более 64К памяти. Там страницы переключаюся с отображением на 64К, а в в x86 сегментная организация, что оказалось куда как гибче и работоспособнее и без напрягов переехало на 32-разрядеую архитектуру. LVV>1. Там без проблем работало 256 кил памяти.
4MB. Потому что система виртуальной памяти расширяла адрес до 22 бит.
Но называть "без проблем" метод выглядывания в огромный мир через крошечное окошко — некорректно.
Именно после PDP-11, БЭСМ-6 и ещё ряда похожих машин с такой же проблемой — поняли, насколько это неудобно и неэффективно, и стали делать, что виртуальное пространство заведомо больше физического, причём в разы (чтобы можно было ядру, например, дважды уложить весь RAM на виртуальную память, и ещё оставалось место под устройства).
LVV>А потом они создали VAX...
Да. В VAX народ настолько был перепуган проблемами, которые увидел на PDP-11, что стал перегинать палку в противоположном направлении (как 512-байтные страницы).
LVV>>>Система команд небольшая, но за счет развитости и единообразия видов адресации возможности очень большие. LVV>>>Одной командой можно было очистить ВСЮ память. LVV>>>Я долго после pdp плевался на систему команд интела, где на каждый чих — отдельное специальное решение. P>>Угу. Только интеловская плавно расширилась на 32 разряда и на 64, а для той такой возможности не было. LVV>DEC Alpha: https://wiki2.org/ru/DEC_Alpha
Там не было никакого плавного расширения или аккуратного перехода. Просто абсолютно другая архитектура.
Эмуляцию VAX сделали на Alpha, но медленную.
LVV>В 2007 году прекратили выпуск — когда у Интел только появились 64-битные системы...
1. IA64 — это 2001 год. Да, это другая архитектура, но всё-таки у Intel.
2. Были AMD, были Sun SPARC, были 64-битные MIPS. Чуть позже догнала IBM с PPC и S/390.
Здравствуйте, a7d3, Вы писали:
A>>>В тоже время, у Эльбрусов давно есть встроенный бинарный транслятор x86-инструкций в VLIW-машкод. А это гораздо сложнее, чем сконвертировать VLIW-инструкции одного поколения под более новое. O>>Насколько я понимаю, он скорее софтверный чем хардварный, и потомку медленный. O>>Ну и обрастание слоями VLIW2VLIW трансляции выглядит еще более костыльно чем то, что есть в х86 сейчас.
A>Бинарный транслятор нужен-то «на один раз» — чтобы не пересобирать бинарники из исходников.
A>Про слои и костыльность — это же обратная совместимость бинарного кода. Будет странно, если бинарник собранный под современный Эльбрус через пять лет откажется работать на более новой модели из того же семейства ЦПУ.
На EPIC — запросто. Например, решат, что не нужно 5 АЛУ, достаточно 4. (Цифры для примера.)
И всё — старые программы надо будет компилировать заново.
С традиционной архитектурой таких проблем нет.
Здравствуйте, Gt_, Вы писали:
Gt_>что бы не упереться в производительность одного потока как интел с x86. vliw позволяет больше инструкций за такт + перенести блок предсказаний в компилятор.
Не поможет, пока в качестве памяти используется DRAM.
Или для DRAM надо операцию смены открытой строки ускорить раз в 30 минимум (фантастика на втором этаже (c)), или выбросить каку и переходить на SRAM (ценник умножить на 10, а в первые 5 лет на 20, плотность упаковки разделить на столько же).
Пока есть проблема с DRAM — все эти супер-EPIC (VLIW) будут отставать от Atomʼа.
Разумеется, рекламные бенчмарки будут на синтетических тестах, когда SIMD перерабатывает потоки данных с тщательно рассчитанными тактировкой и предвыборкой — именно такие тесты вам и рисуют (и кролики ведутся), а потом по отзывам тех, кто это реально применял, Эльбрус на обычных действиях с трудом догоняет пень-три.
А Intel и AMD тем временем просто спускаются с горы и овладевают всем стадом, догоняя длину конвейера микроопераций до 200 и выше. Они уже на этом вашем VLIW обожглись и повторять не хотят.
Gt_>пытаться с двумя деревянными рублями догнать интел просто глупо, посоревноваться с интелом и арм сможет лишь то, что будет в разы больше инструкций за такт прожевывать. например vliw.
Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, 0xCAFEDEAD, Вы писали:
W>>>Она не "еще одна", а "одна из уже" существующих в промышленных масштабах. CAF>>Эльбрус существует в промышленных масштабах? W>Интел с аналогичной архитектурой.
IA-64 ? так ее и закрыли, проект скорее всего не окупился. Зачем еще раз так делать?
W>PS Как-то не предполагал, что придется разжевать, и в рот положить
Здравствуйте, barrett, Вы писали:
B>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
B>Вот именно такой подход ("А когда мы отобъем своё бабло и с каким наваром?") в сфере национальной безопасности приводит B>к ситуации, которая сейчас наблюдается, например в США в области производства обогащенного урана. B>Американская обогатительная корпорация была в своё время приватизирована (неужели наши приватизаторы надоумили? ) именно с целью B>максимизации прибыли от отрасли. В итоге оказалось, что выгоднее перепродавать российский уран, чем добывать и обогащать свой. B>В итоге имеются признаки развала урановой отрасти (капитилистического народного хозяйства ). B>Я полагаю, не надо повторять, что свои микропроцессоры — это тоже сфера национальной безопасности.
Надо, зачем нужнен именно VLIW для обесаечения нац безопастности? Почему не сделали РИСК АРМ-подобную например, что бы все бинари запускать из коробки?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Я написал АРМ-подобную, не АРМ в точности.
Как это не в точности, если "что бы все бинари запускать из коробки"? Расширенную что ли, но лицензия все равно нужна, а поддерживать работу с расширенной архитектурой нужно точно так же, если на расширение не забить изначально.
CAF>Вот есть же сейчас х86 эмуляция например. Для этого нужна лицензия?
Представления не имею, но если единственная функция платформы эмулировать х86, то Интел точно посчитает, что лицензия нужна.
CAF>Вот и зачем нужно поддерживать все свое ПО? Почему не сделать процессор для которого легко сделать бин совместимость с существующими архитектурами. Все свое, без закладок. Взял все ПО и запустил.
Так своё или не своё?
Pzz>Идея VLIW звучит, теоретически, разумно: переложить все сложности планирования вычислений с процессора на компилятор. Типа, компилятор, он умный, он справится лучше. Только компиляторщики, к сожалению, не осилили сделать достаточно умный компилятор. А процессорщики тем временем на месте тоже не сидели, и современные процессоры стали очень умными.
Парням из TI это расскажи. Компилятор для TI C64x достаточно умный. Единственный смысл аппаратных штук Интел — выполнять старый код без перекомпиляции. На TI C64x этого не надо, так что компилятор отлично справляется.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, a7d3, Вы писали:
A>>Отсюда у VLIW получается сразу несколько преимуществ.
Pzz>С другой стороны, у планировщика в процессоре есть реальная свеженькая статистика исполнения того кода, который в данный момент исполняется, а у компилятора ее нет.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, a7d3, Вы писали:
A>>Бинарный транслятор нужен-то «на один раз» — чтобы не пересобирать бинарники из исходников.
П>Хм... Дык для второго, третьего и последующих разов уже нужен высокоинтеллектуальный компилятор, который будет собирать из старого кода непосредственно под VLIW. Он уже есть у эльбрусовцев? Или как это всю жизнь у Бабаяна было — "мы создали проц, который в разы обгоняет нынешние иностранные разработки — подождите еще лет десять и мы это вам продемонстрируем"?
Уже несколько лет как у них есть компилятор, собирающий под этот VLIW два линуха и совместимый с GCC, в том числе, по intrinsic'ам.
Здравствуйте, a7d3, Вы писали:
A>Уже несколько лет как у них есть компилятор, собирающий под этот VLIW два линуха и совместимый с GCC, в том числе, по intrinsic'ам.
Зачем им нужен транслятор тогда? Проц есть, средства сборки под него есть — так вперед, к промышленному выпуску! Или не, надо опять "еще лет десять подождать, и тогда..."?
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, a7d3, Вы писали:
A>>Уже несколько лет как у них есть компилятор, собирающий под этот VLIW два линуха и совместимый с GCC, в том числе, по intrinsic'ам.
П>Зачем им нужен транслятор тогда? Проц есть, средства сборки под него есть — так вперед, к промышленному выпуску! Или не, надо опять "еще лет десять подождать, и тогда..."?
«Тред не читай — сразу отвечай».
Тут видос в треде мелькал, посмотри. Заодно почитай уже сказанное по технической части.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Произведенное в РФ, а не заказанное в Тайване, Китае или еще где. Тут я поддерживаю 100% импортозамещение для всех критических целей, сколько бы оно не стоило. Это вплолне объективно обоснованная цель.
Эльбрус в Тайване и производят. В РФ нет завода производящего микропроцессоры.
Здравствуйте, netch80, Вы писали:
N>Или для DRAM надо операцию смены открытой строки ускорить раз в 30 минимум (фантастика на втором этаже (c)), или выбросить каку и переходить на SRAM (ценник умножить на 10, а в первые 5 лет на 20, плотность упаковки разделить на столько же).
Эльбрус в том числе позиционируется как сигнальный процессор, но те часто работают поверх SRAM, особенно в военке.
N>Разумеется, рекламные бенчмарки будут на синтетических тестах, когда SIMD перерабатывает потоки данных с тщательно рассчитанными тактировкой и предвыборкой — именно такие тесты вам и рисуют (и кролики ведутся), а потом по отзывам тех, кто это реально применял, Эльбрус на обычных действиях с трудом догоняет пень-три.
Ты что-то путаешь.
Он работает на уровня Пня-3 в режиме эмуляции x86.
N>А Intel и AMD тем временем просто спускаются с горы и овладевают всем стадом, догоняя длину конвейера микроопераций до 200 и выше. Они уже на этом вашем VLIW обожглись и повторять не хотят.
Это имеет смысл только на многопоточных ядрах.
Современные 2 потока на ядро в Интелах — тоже ни о чём, пока мест.
Да, для задач общего (произвольного) плана такая "динамическая многопоточность" рулит.
Но для неких конкретных вычислительных алгоритмов — далеко не факт.
Напомню, что 4-е пни во многих мультимедиа-тестах долго сливали более старым 3-м пням.
N>Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~
Как сам думаешь, ~800млн РУБЛЕЙ — это большие расходы на разработку подобного проца и всей обвязки вокруг него?
ИМХО, это сущие копейки.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Здравствуйте, MadHuman, Вы писали:
MH>>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? MH>>зачем нужен ПЗРК Пэтриот, когда С-400 лучше и дешевле? MH>>Можно же производство пэтроита свернуть и пусть все покупают С-400. Зачем городить производство и продолжать думать над новыми разработками ПЗРК, когда с-400 хорош и его догонять очень дорого и долго?
CAF>Ты бы внимательней весть тредик прочитал прежде чем писать. Вопрос именно о своей и очень нетипичной архитектуре.
CAF>США не могут вместо пэтриот купить с400. Затраты вполне оправданы. МЦСЧ могли бы сделать РИСК архитектуру, есть даже СПАРК у них.
Уверен? Я думаю наши бы с радостью перевооружили всю армию НАТО на С-400. Так что не надо тут сказки рассказывать.
N>Не поможет, пока в качестве памяти используется DRAM. N>Или для DRAM надо операцию смены открытой строки ускорить раз в 30 минимум (фантастика на втором этаже (c)), или выбросить каку и переходить на SRAM (ценник умножить на 10, а в первые 5 лет на 20, плотность упаковки разделить на столько же). N>Пока есть проблема с DRAM — все эти супер-EPIC (VLIW) будут отставать от Atomʼа. N>Разумеется, рекламные бенчмарки будут на синтетических тестах, когда SIMD перерабатывает потоки данных с тщательно рассчитанными тактировкой и предвыборкой — именно такие тесты вам и рисуют (и кролики ведутся), а потом по отзывам тех, кто это реально применял, Эльбрус на обычных действиях с трудом догоняет пень-три.
брехня. по факту в реальных задачах отставание 1.5-2 раза, при частоте 1.3Ghz.
что характерно DRAM не мешает, даже учитывая разницу на порядок по кешу.
N>А Intel и AMD тем временем просто спускаются с горы и овладевают всем стадом, догоняя длину конвейера микроопераций до 200 и выше. Они уже на этом вашем VLIW обожглись и повторять не хотят.
они не хотят vliw, я не хочу менять свой старый 3700k, т.к. длина конвеера выросла лишь во влажных мечтах, но не моих задачах. в ближайшие годы патчи meldown возню с конвейером обнулят полностью.
N>Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~
раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву
Здравствуйте, Gt_, Вы писали:
Gt_>брехня. по факту в реальных задачах отставание 1.5-2 раза, при частоте 1.3Ghz.
Я таким URL не доверяю и никому не советую, и слово "брехня" относится скорее к ним.
Пусть дадут реальную установку полдесятку действительно независимых экспертов, причём за пределами РФ. Тогда и посмотрим.
N>>А Intel и AMD тем временем просто спускаются с горы и овладевают всем стадом, догоняя длину конвейера микроопераций до 200 и выше. Они уже на этом вашем VLIW обожглись и повторять не хотят. Gt_>они не хотят vliw, я не хочу менять свой старый 3700k, т.к. длина конвеера выросла лишь во влажных мечтах, но не моих задачах а не реальных задачах. в ближайшие годы патчи meldown возню с конвейером обнулят полностью.
N>>Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~ Gt_>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл.
"И вы говорите" (c)
Gt_> тем более, что meldown превращает нароботки последних лет интел в тыкву
AMD не превратила, и он сейчас впереди. И не x86 единым живо IT.
Здравствуйте, a7d3, Вы писали:
A>Например, Transmeta пыталась делать VLIW-процессоры, но опередила время и рухнула из-за недостатка ресурсов и не совсем корректно позиционировала их. Сейчас VLIW хорошо себя показали на видеокартах и появилась прослойка людей привыкших к вычислениям и работе с такими архитектурами.
VLIW-карт уже почти не осталось. В NVidia и AMD внутри что-то типа RISC'а. Из десктопных GPU последний VLIW был в AMD TeraScale где-то 6 лет назад.
Кто-то ещё с VLIW есть в мобильных GPU, но лень вспоминать.
Здравствуйте, Pzz, Вы писали:
Pzz>Потому, что взяли готовые наработки. А когда в свое время их нарабатывали, выбор своей архитектуры был вполне уместен, ARM'а тогда не было, x86 никому еще в кошмарном сне не мог присниться.
Тут вопрос в чём, 20 лет назад своя архитектура имела смысл. Но сейчас есть RISC-V со свободно лицензированными патентами, есть полностью открытые архитектуры MIPS и SPARC с истёкшими патентами и даже x86 уже свободен по большей части (до SSE3).
Можно было бы уже раз пять переделать процессор на один из этих вариантов.
Здравствуйте, a7d3, Вы писали:
A>В железе как раз таки делать и не научились. Все это у x86 является не аппаратным решением, это программное внутри микрокода (firmware), загружаемом при инициализации ЦПУ — зашифрованный и подписанный блоб, содержимое которого известно лишь вендору.
Неа. Я работал с представителями Intel'а для обхода аппаратной баги (в транзакционной памяти).
Так вот, собственно программируемого процессорного firmware там всего несколько килобайт и много туда не запихать. Всё декодирование инструкций осуществляется полностью аппаратно, с очень ограниченными возможностями влияния.
Исключения — это несколько сложных или устаревших инструкций. Но даже реальный режим до сих пор делается аппаратно, хотя казалось бы.
Блобы, которые загружаются в CPU — это реализации управления питанием SSM, настройки всяких турбо-режимов и т.п. Процессор прекрасно работает и без них.
A>Анализ динамического исполнения, для предсказывания переходов, в реальности представляет собой агрессивные спекулятивные исполнения различных веток глубиной в несколько операторов условного перехода. Реализация подобных вещей есть в VLIW, получается она гораздо проще и дешевле.
Не получается.
Здравствуйте, vdimas, Вы писали:
N>>Или для DRAM надо операцию смены открытой строки ускорить раз в 30 минимум (фантастика на втором этаже (c)), или выбросить каку и переходить на SRAM (ценник умножить на 10, а в первые 5 лет на 20, плотность упаковки разделить на столько же). V>Эльбрус в том числе позиционируется как сигнальный процессор, но те часто работают поверх SRAM, особенно в военке.
Позиционироваться-то можно, а он реально работает поверх SRAM? И есть такие установки в доступе (пусть даже ДСП по предзаказу)?
N>>Разумеется, рекламные бенчмарки будут на синтетических тестах, когда SIMD перерабатывает потоки данных с тщательно рассчитанными тактировкой и предвыборкой — именно такие тесты вам и рисуют (и кролики ведутся), а потом по отзывам тех, кто это реально применял, Эльбрус на обычных действиях с трудом догоняет пень-три. V>Ты что-то путаешь. V>Он работает на уровня Пня-3 в режиме эмуляции x86.
На конвертированном коде? И во сколько раз конвертер слабее ожидаемого на нативном? А с учётом задач класса "типовой линукс", а не тщательно подобранной мультимудии?
N>>А Intel и AMD тем временем просто спускаются с горы и овладевают всем стадом, догоняя длину конвейера микроопераций до 200 и выше. Они уже на этом вашем VLIW обожглись и повторять не хотят. V>Это имеет смысл только на многопоточных ядрах. V>Современные 2 потока на ядро в Интелах — тоже ни о чём, пока мест.
V>Да, для задач общего (произвольного) плана такая "динамическая многопоточность" рулит. V>Но для неких конкретных вычислительных алгоритмов — далеко не факт. V>Напомню, что 4-е пни во многих мультимедиа-тестах долго сливали более старым 3-м пням.
P4 вообще были дефектного дизайна, их сравнивать сложно. Он и не пошёл дальше, Core сделали из P3.
N>>Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~ V>Как сам думаешь, ~800млн РУБЛЕЙ — это большие расходы на разработку подобного проца и всей обвязки вокруг него? V>ИМХО, это сущие копейки.
Слишком много неизвестных, чтобы реально сравнивать.
LVV>>1. Там без проблем работало 256 кил памяти. N>4MB. Потому что система виртуальной памяти расширяла адрес до 22 бит.
Я работал еще на 18 бит... N>Но называть "без проблем" метод выглядывания в огромный мир через крошечное окошко — некорректно. N>Именно после PDP-11, БЭСМ-6 и ещё ряда похожих машин с такой же проблемой — поняли, насколько это неудобно и неэффективно, и стали делать, что виртуальное пространство заведомо больше физического, причём в разы (чтобы можно было ядру, например, дважды уложить весь RAM на виртуальную память, и ещё оставалось место под устройства).
Ну, виртуальная память современного вида была сделана еще в начале 60 годов, насколько помню. Это как раз в pdp было сделано наоборот.
LVV>>В 2007 году прекратили выпуск — когда у Интел только появились 64-битные системы... N>1. IA64 — это 2001 год. Да, это другая архитектура, но всё-таки у Intel. N>2. Были AMD, были Sun SPARC, были 64-битные MIPS. Чуть позже догнала IBM с PPC и S/390.
Я имел ввиду, что оси только появились — когда dec уже все закончила.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Я работал еще на 18 бит...
Так тут наверно не еще, а у разных моделей семейства по разному.
LVV>Ну, виртуальная память современного вида была сделана еще в начале 60 годов, насколько помню. Это как раз в pdp было сделано наоборот.
Там маленькое адресное пространство по причине 16-битности, потому и наоборот.
Здравствуйте, netch80, Вы писали:
N>Я таким URL не доверяю и никому не советую, и слово "брехня" относится скорее к ним. N>Пусть дадут реальную установку полдесятку действительно независимых экспертов, причём за пределами РФ. Тогда и посмотрим. А кому это надо?
Здравствуйте, Cyberax, Вы писали:
C>Блобы, которые загружаются в CPU — это реализации управления питанием SSM, настройки всяких турбо-режимов и т.п. Процессор прекрасно работает и без них.
A>>Анализ динамического исполнения, для предсказывания переходов, в реальности представляет собой агрессивные спекулятивные исполнения различных веток глубиной в несколько операторов условного перехода. Реализация подобных вещей есть в VLIW, получается она гораздо проще и дешевле. C>Не получается.
Не SSM, а скорее SMM.
А спекулятивных вычислений в Эльбрусах чуть ли не в разы больше, чем в x86 — предпочитают так, чем условные переходы. Используется совместно с переименованием регистров.
Здравствуйте, netch80, Вы писали:
V>>Как сам думаешь, ~800млн РУБЛЕЙ — это большие расходы на разработку подобного проца и всей обвязки вокруг него? V>>ИМХО, это сущие копейки. N>Слишком много неизвестных, чтобы реально сравнивать.
CAF>>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
N>Безопасность, "крутая" технология, распил — отметаем.
N>Ответ прост — легаси. СССР сделали на нем С-300, тогда других вариантов не было. РФ продолжает делать эти зенитные комплексы, но переносить платформу на другую ISA страшно и затратно. Вот и идет валкое развитие и поддержка.
э2к это середина двухтысячных, т.е. лет на 20 после с-300.
Здравствуйте, a7d3, Вы писали:
A>>>Анализ динамического исполнения, для предсказывания переходов, в реальности представляет собой агрессивные спекулятивные исполнения различных веток глубиной в несколько операторов условного перехода. Реализация подобных вещей есть в VLIW, получается она гораздо проще и дешевле. C>>Не получается. A>Не SSM, а скорее SMM.
Да, перепутал ночью.
A>А спекулятивных вычислений в Эльбрусах чуть ли не в разы больше, чем в x86 — предпочитают так, чем условные переходы. Используется совместно с переименованием регистров.
То есть? VLIW со спекуляцией? Это как?
Здравствуйте, koandrew, Вы писали:
N>>Не поможет, пока в качестве памяти используется DRAM. N>>Или для DRAM надо операцию смены открытой строки ускорить раз в 30 минимум (фантастика на втором этаже (c)), или выбросить каку и переходить на SRAM (ценник умножить на 10, а в первые 5 лет на 20, плотность упаковки разделить на столько же). N>>Пока есть проблема с DRAM — все эти супер-EPIC (VLIW) будут отставать от Atomʼа. K> Время открытия строки не имеет никакого отношения к полосе пропускания.
А откуда взялось про полосу пропускания? Сам придумал?
K>Опять же непонятно, какое отношение это всё имеет к VLIW.
Самое прямое. Только не к VLIW в целом, а к EPIC, который в Эльбрусе.
У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая.
А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
А если бы процессор сам просто считал связи команд, он мог бы давно выполнить те, что идут следом и никак не завязаны на те, что застряли.
Не зря в последних процессорах конвейер команд дорос до каких-то страшных цифр типа "97 исходных команд, 224 микрооперации".
K> Кстати кэш — это и есть SRAM,
В "глубине души" он, конечно, SRAM. Только у кэша схемы поиска по ассоциативности занимают место, время (заметное) и греются.
K> вон АМД пихает по 60МБайт на кристалл — и вроде как их чипы не стоят запредельных денег.
Да. Только доступ к кэшу такого размера стоит... обычно что-то типа 20-30 тактов. Цифры от Intel, у остальных может быть ещё хуже.
Ну вот и считай — только дошёл до L3, уже считай 20 тактов потерял. А на оперативку — ещё больше.
K> Проблема латентности памяти замечательно решается кэшированием.
В твоих, и авторов Эльбруса, мечтах.
Остальные, кто с реальным миром возится, очень ценят каждую возможность что-то сохранить в кэше.
N>>Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~ K> Ты путаешь тёплое с мягким, то есть процессор общего назначения со специализированной архитектурой.
Я не путаю, это тебе так хочется читать.
K> Перепроектировать ничего не нужно, ибо суперскалярные архитектуры фундаментально не отличаются от VLIW.
Какие-то "суперскалярные архитектуры" от теоретического VLIW где-то на Марсе — может, и не отличаются. Но я о них тут не говорю.
А вот out-of-order суперскалярность и EPIC несовместимы на уровне принципов.
Здравствуйте, Gt_, Вы писали:
N>>Конечно, отзывы должны быть реальные, а не из заведомо агитационного источника, и чтобы тестеров было несколько и они имели опыт поиска спрятанных граблей. По вашей ссылке же информации около нуля и повторить её нереально (и не только из-за закрытости железа). N>>Ваше "макнули" и "украинское" как раз показывает отсутствие аргументов у вас.
Gt_>но согласись, мой аргумент с реальным тестом заметно весомей твоего наброса "по отзывам тех, кто это реально применял" (тм)
Не-а. Потому что нет реального теста. Есть странная писулька от агит-сайта, которая даже на уровне теста содержит <1/10 от того, что должно быть.
Представь себе, что ты даёшь железку на Эльбрусе на тест, например, команде тестов с какого-нибудь overclockers.ru, phoronix.com, 3dnews.ru, IXBT.
Да они его со всех сторон оближут и протестируют всё, что можно. Там не будет одной несчастной программы (ладно, двух, обе очень специальные и из одной области), которая ещё непонятно почему выбрана и как собрана. Только в явных задачах на производительность будет минимум десяток разных тестов, а лучше два. Linpack, ffmpeg, zip/unzip, 7z параллельный... Будут тесты чего-то нелёгкого поверх scipy, pandas и аналогов. Будет подсчитана какая-нибудь несложная нейросетка на полсуток расчёта, и сравнено, тот же результат расчёта, или отличается (что покажет на тонкие различия в реализации плавучки).
И, разумеется, будет проверка скорости на уровне "сколько грузится ОС", "сколько выполняется какой-нибудь find /usr/lib | wc" и т.п.
Для каждой софтины будет проверено несколько вариантов компиляции (как минимум, с базовой оптимизацией, с максимизацией скорости и минимизацией объёма).
Будет взят компилятор, измерена его работа (а это очень серьёзно — специфика GCC, Clang такова, что там огромное количество нечислового манипулирования мелкими порциями данных, развесистый доступ по ссылкам...), в разных режимах оптимизации. Будут указаны размеры исполняемых файлов, библиотек, проанализировано, на что потрачены основные ресурсы, какое соотношение объёмов служебных частей (типа прологов/эпилогов функций) и основных, не видно ли каких-то тупых ляпов в коде, насколько эффективны распределения регистров и т.п.
Я намеренно всё это писал только по памяти, профессиональный сравниватель с ходу может этот список как минимум в 2 раза толще написать посреди ночи с закрытыми глазами.
И где это по ссылке? Ах да, два пакета газовой динамики (причём почему газовой динамики и почему выбраны именно эти два?), причём даже не указано, как сравнивались результаты расчётов (может, там в выходных данных вообще ничего похожего на правду). Агитка — она и есть агитка, и пригодна только для сельского туалета.
N>>Частично оно Spectre подвержено, но это уже не Meltdown (который был самой тяжёлой формой). Gt_>этих форм миллион, еще один вид — foreshadow. при этом у ibm power та же фигня. когда им сбоку присобачат защиту памяти на подобии тагов эльбруса разрыв еще сократиться.
Теги в стиле Эльбруса как раз ничего не стоят по сравнению с общими затратами на выборку и интерпретацию.
А насколько Эльбрус подвержен всему Meltdown-like семейству, опять же, тебе не скажут.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, a7d3, Вы писали:
A>>А спекулятивных вычислений в Эльбрусах чуть ли не в разы больше, чем в x86 — предпочитают так, чем условные переходы. Используется совместно с переименованием регистров. C>То есть? VLIW со спекуляцией? Это как?
Технически никакой сложности — считать две-три ветки в рамках одной длинной инструкции разными микрокомандами.
Да и официальные лица утверждают, что в Эльбрусе много спекулятивных вычислений, в том числе см.видео Эльбрус
Здравствуйте, netch80, Вы писали:
N>А вот out-of-order суперскалярность и EPIC несовместимы на уровне принципов.
Можно подумать нет реордеринга на этапе компиляции широких инструкций VLIW/EPIC.
Т.е. весь тот out-of-order, что делается у x86 в режиме исполнения, в случае VLIW выполняется компилятором. И в x86 и в VLIW это все дает множество микроинструкций на выходе, но вот у компилятора времени ощутимо больше на более глубокий анализ кода, соответственно, окно анализа шире.
Если же совсем утрировано, то load'ы поднимаются наверх, а store сдигаются вниз. Если промахнулись по взаимозависимостям, то в Эльбрусах включается «компенсирующий код».
N>>Самое прямое. Только не к VLIW в целом, а к EPIC, который в Эльбрусе. N>>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая. N>>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
Gt_>булшит. во первых э2к не просто выполняет команды спекулятивно, он выполнят несколько спекулятивных веток одновременно. кроме этого компилятор положит в префеч патерн необходимых данных сильно раньше, чем дойдет до исполнения ШК. компилятор заранее знает все, что может понадобится.
Здравствуйте, a7d3, Вы писали:
C>>То есть? VLIW со спекуляцией? Это как? A>Технически никакой сложности — считать две-три ветки в рамках одной длинной инструкции разными микрокомандами.
VLIW на то и VLIW, что имеет очень длинные инструкции. Для спекуляции их надо будет разбирать на микроинструкции, планировать их и т.д.
Нет, можно конечно. Но зачем??
A>Да и официальные лица утверждают, что в Эльбрусе много спекулятивных вычислений, в том числе см.видео Эльбрус
Мало ли что они могут утверждать.
CAF>>>Эльбрус существует в промышленных масштабах? W>>Интел с аналогичной архитектурой. CAF>IA-64 ? так ее и закрыли, проект скорее всего не окупился. Зачем еще раз так делать?
IA-64 навернулся потому что ему была подложена свинья в виде AMD64
То есть технологию делали из расчета грядущего перехода с x86, на это рассчитывали и технари и что наверно важнее — бизнесменеджмент. И они как изначально таргетировали IA64 как неизбежность для своего уже имеющегося рынка, и исходя из этого планировали свои бизнес процессы, и проявили стандартную для большой корпорации неповоротливость когда внезапно выскочил конкурент в виде AMD64.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, a7d3, Вы писали:
C>>>То есть? VLIW со спекуляцией? Это как? A>>Технически никакой сложности — считать две-три ветки в рамках одной длинной инструкции разными микрокомандами. C>VLIW на то и VLIW, что имеет очень длинные инструкции. Для спекуляции их надо будет разбирать на микроинструкции, планировать их и т.д.
C>Нет, можно конечно. Но зачем??
Спекулятивные вычисления у Эльбруса на уровне исходного кода языков программирования. Это компилятор реализует набивая микрокомандами широкие инструкции. В итоге, на АЛУ подается машинный код из микроинструкций примерно так же, как поток микроинструкций на RISC-ядра внутри современных x86, появляющиеся после декодировщика CISC-инструкций (являющихся машинным кодом x86-процессора).
Т.е. по исполнению внутри процессоров получается одинаково, различается лишь обвязка в лице декодировщиков с планировщиками. В случае Эльбруса обвязкой выступает компилятор, а у x86 обвязка псевдоаппаратная внутри процессора (firmware-управляемая).
A>Не совсем. Во время Merced, на конец 90-х интел-совместимые x86-процессоры делали и Cyrix, и AMD, весьма успешно. И хотелось интеловцам такой процессор, чтобы и 64-битный и конкуренты не смогли повторить. А рынок посмотрел на стоимость интелевского решения и сказал, что уж лучше инициатива x86_64, оно же Amd64. Отторжение рынком Merced произошло еще на этапе идей и начала производства этого железа в кристаллах, из-за попыток монополизировать сектор.
Еслиб цены были на IA64 на уровне (чуть выше) x86-64 то где был бы этот x86-64 сейчас? Бонусный вопрос: где был бы сейчас AMD? Супербонус: а хотел ли интел чтобы AMD был там?
Причина убившая IA64 проста как грабли: во всяких непонятных ситуациях клиент выбирает подешевле.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Еслиб цены были на IA64 на уровне (чуть выше) x86-64 то где был бы этот x86-64 сейчас?
Да там же, где и сейчас.
O>Причина убившая IA64 проста как грабли: во всяких непонятных ситуациях клиент выбирает подешевле.
Особенно, если и другие параметры не хуже, а в обсуждаемом случае многие и лучше.
Здравствуйте, ononim, Вы писали:
A>>Не совсем. Во время Merced, на конец 90-х интел-совместимые x86-процессоры делали и Cyrix, и AMD, весьма успешно. И хотелось интеловцам такой процессор, чтобы и 64-битный и конкуренты не смогли повторить. А рынок посмотрел на стоимость интелевского решения и сказал, что уж лучше инициатива x86_64, оно же Amd64. Отторжение рынком Merced произошло еще на этапе идей и начала производства этого железа в кристаллах, из-за попыток монополизировать сектор. O>Еслиб цены были на IA64 на уровне (чуть выше) x86-64 то где был бы этот x86-64 сейчас? O>Причина убивная IA64 проста как грабли: во всяких непонятных ситуациях клиент выбирает подешевле.
В таком пространстве доводов дискутировать сложновато — очень уж оно напоминает обмен субъективными оценочными суждениями.
На тот момент в серверном сегменте очень хорошо себя чувствовали UltraSPARC и со стороны Intel была попытка подвинуть их своим IA64 (Merced/Itanium). Однако случился dot-com bubble и денег на «клевые сервера» у клиентов не стало — емкость этого сегмента сдулась настолько, что в разы упали продажи прогрессивных и проверенных временем UltraSPARC'ов.
O>>Еслиб цены были на IA64 на уровне (чуть выше) x86-64 то где был бы этот x86-64 сейчас? O>>Причина убивная IA64 проста как грабли: во всяких непонятных ситуациях клиент выбирает подешевле. A>В таком пространстве доводов дискутировать сложновато — очень уж оно напоминает обмен субъективными оценочными суждениями.
Ну так мы же в форуме КСВ. И даже еще не скатились на личности, так что все ок В целом да — мое субьективное ИМХО состоит в том что если выходишь с новым продуктом на рынок в котором уже есть конкуренты то надо быть или сильно лучше конкурентов или дешевле. А интел сделал все наоборот. Было бы все иначе если бы интел сделал дешевле — вопрос конечно спорный, но опять же ИМХО вероятность получения совершенно иной картины мира была сильно отличной от нуля.
Как много веселых ребят, и все делают велосипед...
CAF>>>Надо, зачем нужнен именно VLIW для обесаечения нац безопастности? Почему не сделали РИСК АРМ-подобную например, что бы все бинари запускать из коробки? P>>ARM требует лицензирования. Эльбрус был разработан до того, как ARM стал суперпопулярным. CAF>Я написал АРМ-подобную, не АРМ в точности. Вот есть же сейчас х86 эмуляция например. Для этого нужна лицензия? Вот и зачем нужно поддерживать все свое ПО? Почему не сделать процессор для которого легко сделать бин совместимость с существующими архитектурами. Все свое, без закладок. Взял все ПО и запустил.
потому что рынку еще одная вялая копия арма или x86 не нужна, а вкладывать на ровне с лидерами сотни млрд долларов в разработки не реально.
в эльбрус вкладывают бюджет сравнимый с годовой зп одного менеджера второго эшелона из интел. с таким бюджетом идти на рынок арм или x86 бессмысленно.
N>>>Самое прямое. Только не к VLIW в целом, а к EPIC, который в Эльбрусе. N>>>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая. N>>>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
Gt_>>булшит. во первых э2к не просто выполняет команды спекулятивно, он выполнят несколько спекулятивных веток одновременно. кроме этого компилятор положит в префеч патерн необходимых данных сильно раньше, чем дойдет до исполнения ШК. компилятор заранее знает все, что может понадобится.
CAF>А ты не работал там случаем?
utm_source=eetimes&utm_medium=relatedcontent O>>>>Нет, это именно то что выше по ссылке. O>>>>https://www.infineon.com/cms/en/product/microcontroller/ O>>>>У них там есть в списке армы, но их в их продуктах на самом деле мало. Gt_>>>да, в списке армы и mips, а то что по ссылке AUDO в разделе легаси ... O>>AUDO это 16битное легаси да, на рынке рулит AURIX. Gt_>нет. по ссылке свой велосипед родом из 1999 (тм) 32 бита audo max. раздел легаси.
Это ссылка на откуда родом. Вот ссылка на современные девайсы которые пришли на замену AUDO
Вот ссылка на производителя. И да, они все 32 бита. Тут так принято.
Gt_>тот велосипед заменили банальным мипс.
У них нету MIPS микроконтроллеров. ХЗ зачем они их лицензировали в 2000м году. Нету и все.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
CAF>Я про архитектуру именно. Свое, полностью контролирумое железо я понимаю. Произведенное в РФ, а не заказанное в Тайване, Китае или еще где. Тут я поддерживаю 100% импортозамещение для всех критических целей, сколько бы оно не стоило. Это вплолне объективно обоснованная цель.
Мне как раз пофиг где что производится, я далек от всех этих секретностей, импортозамещений и военщины.
А вот как раз сама архитектура интересная. У Intel был Itanium как перспективная замена x86, но увы — они решили дальше не делать.
А здесь другая ситуация — госсектор, нерыночные условия, может так что получится.
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
Здравствуйте, ononim, Вы писали:
V>>Взять тот же AVR — взялся из ниоткуда, контора-производитель Atmel на середину 90-х тоже никто и ничто — классическая тёмная лошадка. V>>Затем появились тонны референсных бордов на нём (где самые известные — линейка Ардуино), и проц стал сверхпопулярен. O>Ага ага
На твоём графике надо читать так, что Microchip Technology противопоставляется Atmel и AVR?
Рилли?
Угадай с одного раза, какие 8-битные микроконтроллеры производит Microchip Technology?
O>Мир микроконтроллеров вообще полон сюрпризов для среднестатистического программиста, судящего об их популярности по статьям на хабре.
Не могу не согласиться.
Ты как раз нормально зашёл. ))
В общем, я плотно программировал на AVR в первый же год их выпуска, в 96-м.
По одной простой причине — мы закупали у Atmel их реализации i8051-архитектуры, и это была лучшая реализация на тот момент.
В одну из закупок подкинули нам даташит и горсть процов даром на "попробовать".
Зачем ты даёшь ссылки на графики и инфу, которую не понимаешь?
По первой и последней ссылке встречаются производители, которые вообще не играют на рынке 8-битных контроллеров.
Это ж двойное пробитие двойного дна.
Кароч, кыш отседа, школота.
V>На твоём графике надо читать так, что Microchip Technology противопоставляется Atmel и AVR?
Нет, это просто анализ рынка _всех_ MCU. Как видно AVR'а там пару процентов — ровно та самая аудитория хабра, половина которой паяют эти ФМКrb d китайских блоках питания В серъезных девайсах доля AVR тождественно равна нулю.
V>По первой и последней ссылке встречаются производители, которые вообще не играют на рынке 8-битных контроллеров.
А с чего ты решил что речь именно 8битные MCU?
V>Это ж двойное пробитие двойного дна. V>Кароч, кыш отседа, школота.
Кыш-кыш хипстерье.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>Еслиб цены были на IA64 на уровне (чуть выше) x86-64 то где был бы этот x86-64 сейчас? O>>>Причина убивная IA64 проста как грабли: во всяких непонятных ситуациях клиент выбирает подешевле. A>>В таком пространстве доводов дискутировать сложновато — очень уж оно напоминает обмен субъективными оценочными суждениями. O>Ну так мы же в форуме КСВ. И даже еще не скатились на личности, так что все ок В целом да — мое субьективное ИМХО состоит в том что если выходишь с новым продуктом на рынок в котором уже есть конкуренты то надо быть или сильно лучше конкурентов или дешевле. А интел сделал все наоборот. Было бы все иначе если бы интел сделал дешевле — вопрос конечно спорный, но опять же ИМХО вероятность получения совершенно иной картины мира была сильно отличной от нуля.
Почему тогда не вспомнить как Transmeta пыталась укрепиться на рынке со своими VLIW-процессорами?
Кстати, первое и единственное место работы небезизвестного Linus Torvalds'а.
Не сбылась мечта о росте промышленной автоматизации из-за начавшейся китаезации производств?
Здравствуйте, ononim, Вы писали:
V>>На твоём графике надо читать так, что Microchip Technology противопоставляется Atmel и AVR? O>Нет, это просто анализ рынка _всех_ MCU.
Здравствуйте, ononim, Вы писали:
V>>На твоём графике надо читать так, что Microchip Technology противопоставляется Atmel и AVR? O>В серъезных девайсах доля AVR тождественно равна нулю.
Еще и ссылка нерелевантная.
V>>Это ж двойное пробитие двойного дна. V>>Кароч, кыш отседа, школота. O>Кыш-кыш хипстерье.
Да школота, без вариантов. ))
Последние лет 7+ Atmel более переехал на ARM-ядра.
Но у AVR была ж целая эпоха, про которую школота ни слухом, ни духом.
В исходном посте была ретроспектива, но ты и этого умудрился не уловить.
A>Почему тогда не вспомнить как Transmeta пыталась укрепиться на рынке со своими VLIW-процессорами?
Crusoe юыли обычные 32хбитные процы. Они ничем не были качественно лучше имеющихся процов для конечных потребителей. Переход на дешевые и шустрые 64 бита, при посредственном 32хбитном режиме совместимости — это возможно рынок бы съел, но он не съел просто дешевые 32битные crusoe посредственной производительности — таких камней и так было в избытке.
И не съел дорогие IA64 с посредственным (а изначально никаким) 32хбитным режимом совместимости от интела, так как уже были дешевые AMD64. А топ менежмент вместо того чтобы брать рынок демпингом — начал тупо играть монопольными связями.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Gt_, Вы писали:
Gt_>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву
Meldown не всегда важен. Скажем, если я на своем личном компьютере вычислительные рассчеты вычисляю, что мне до вашего meldown'а?
Здравствуйте, netch80, Вы писали:
N>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
У Эльбруса есть же, вроде, команда предвыборки. Так что она ШК запускает предвыборку, потом идет еще несколько команд, которые чем-то другим занимаются, потом очередная ШК обрабатывает ранее заказанные данные.
Другой вопрос, что это требует очень умного компилятора. А успехи компиляторных наук, насколько я в курсе, не оправдали надежд, которые на них возлагались в 70-е. Возможно, если бы в моде были более другие языки программирования, более предназначенные для статического анализа, ситуация была бы несколько другая, но пока имеем, что имеем...
Здравствуйте, ononim, Вы писали:
A>>Почему тогда не вспомнить как Transmeta пыталась укрепиться на рынке со своими VLIW-процессорами? O>Crusoe юыли обычные 32хбитные процы. Они ничем не были качественно лучше имеющихся процов для конечных потребителей. Переход на дешевые и шустрые 64 бита, при посредственном 32хбитном режиме совместимости — это возможно рынок бы съел, но он не съел просто дешевые 32битные crusoe посредственной производительности — таких камней и так было в избытке. O>И не съел дорогие IA64 с посредственным (а изначально никаким) 32хбитным режимом совместимости от интела, так как уже были дешевые AMD64. А топ менежмент вместо того чтобы брать рынок демпингом — начал тупо играть монопольными связями.
Transmeta со своими VLIW-процессорами никогда не толкалась в тех же нишах, на которые целился VLIW от Intel (EPIC/IA64).
Получись у Transmeta в середине 2000-х и внутри современных планшетов/мобильников/нетбуков были бы не ARM'ы, а множество VLIW.
Для бытовой же техники, вроде домашних роутеров, сотовых и VoIP-телефонов, более чем достаточно MIPS'ов.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Gt_, Вы писали:
Gt_>>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву
Pzz>Meldown не всегда важен. Скажем, если я на своем личном компьютере вычислительные рассчеты вычисляю, что мне до вашего meldown'а?
а типа мелтдаун будет спрашивать чего ты там хочешь делать на личном компютере. может ему биткоины майнить важнее.
Gt_>>а типа мелтдаун будет спрашивать чего ты там хочешь делать на личном компютере. может ему биткоины майнить важнее.
Pzz>Мелтдаун позволяет читать память, а не запускать произвольный код.
Здравствуйте, Gt_, Вы писали:
Gt_>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву
Meltdown — обычный аппаратный баг и он уже исправлен в последних процессорах Intel, без потери производительности.
Gt_>>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву C>Meltdown — обычный аппаратный баг и он уже исправлен в последних процессорах Intel, без потери производительности.
интел то чем вам насалолил ? баг архитектурный, не только в интеле. он и ibm power и в арме. без защищенного режима в стиле эльбруса это и не вылечить. причем мелтдаун лишь одна из самых очевидных вариаций. там еще парочку вариаций уже наковряли.
Pzz>У Эльбруса есть же, вроде, команда предвыборки. Так что она ШК запускает предвыборку, потом идет еще несколько команд, которые чем-то другим занимаются, потом очередная ШК обрабатывает ранее заказанные данные.
Pzz>Другой вопрос, что это требует очень умного компилятора. А успехи компиляторных наук, насколько я в курсе, не оправдали надежд, которые на них возлагались в 70-е. Возможно, если бы в моде были более другие языки программирования, более предназначенные для статического анализа, ситуация была бы несколько другая, но пока имеем, что имеем...
А каким образом компилятор будет знать за сколько тактов придут данные и насколько заранее надо запускать предвыборку?
Если все в кеше уже, то наверное проще, и то я не уверен что латенси не будет плавать (например из-за обеспечения когерентности).
А в случае внешней памяти все вообще становится очень плохо.
Потом команда предвыборки это все-таки команда, ее еще надо из памяти прочитать, да в кеше место занимает.
Да и она у всех наверное есть, использовать ее тяжело.
Здравствуйте, Gt_, Вы писали:
Gt_>>>раз даже одна рота смогла уделать с производительностью на такт, значит есть смысл. тем более, что meldown превращает нароботки последних лет интел в тыкву C>>Meltdown — обычный аппаратный баг и он уже исправлен в последних процессорах Intel, без потери производительности. Gt_>интел то чем вам насалолил ?
Intel — основная жертва. Meltdown работает из-за того, что биты защиты проверяются после спекуляции. В AMD сразу всё работало правильно, потому Meltdown'у он не подвержен.
Gt_>баг архитектурный, не только в интеле. он и ibm power и в арме. без защищенного режима в стиле эльбруса это и не вылечить. причем мелтдаун лишь одна из самых очевидных вариаций. там еще парочку вариаций уже наковряли.
Это семейство Spectre, которое, действительно, архитектурное.
Здравствуйте, gardener, Вы писали:
G>А каким образом компилятор будет знать за сколько тактов придут данные и насколько заранее надо запускать предвыборку?
Ну в принципе, скорость DRAM примерно одинаковая...
G>Если все в кеше уже, то наверное проще, и то я не уверен что латенси не будет плавать (например из-за обеспечения когерентности).
Я сильно сомневаюсь, что Эльбрус аппаратно сильно парится насчет обеспечения когерентности. Вообще, из известных мне процессоров аппаратная когерентность встречается только у интела/амд. У всяких прочих армов и мипсов это делается програмно.
Здравствуйте, a7d3, Вы писали:
A>Касаемо полезности динамического анализа для реордеринга операций — в эльбрусах это решили компенсирующим кодом. Для того чтобы спокойно обыгрывать коллизии с зависимостях между отдельными load/store операциями, относительно которых компилятор не был уверен. Такой подход получился опять же проще и дешевле чем в x86.
A>И т.д. и т.п.
Такое впечатление, что ты знаешь систему команд Эльбруса.
Поделись информацией!
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, a7d3, Вы писали:
A>>Касаемо полезности динамического анализа для реордеринга операций — в эльбрусах это решили компенсирующим кодом. Для того чтобы спокойно обыгрывать коллизии с зависимостях между отдельными load/store операциями, относительно которых компилятор не был уверен. Такой подход получился опять же проще и дешевле чем в x86.
A>>И т.д. и т.п.
A>Такое впечатление, что ты знаешь систему команд Эльбруса. A>Поделись информацией!
Ну и потом, все системы разные. Как DDR latency может быть разные, так и архитектуры (интерконнект и прочее), не перекомпилировать же каждый раз.
И потом, данные или код могут быть в кеше уже, а могут и нет. Могут быть в L1 или L2. Не угадаешь latency.
Здравствуйте, netch80, Вы писали:
N>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая.
А на деле, даже вшивые RISC-микроконтроллеры имеют до 4-х стадий исполнения команды.
N>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
Команды fapb загружаются в специальный буфер инструкций предподкачки (Prefetch Instruction Buffer -PIB) и, циклически повторяясь, работают асинхронно по отношению к основной программе. Подкачанные ими данные помещаются в специальный буфер предварительно подкачанных массивов (Array Prefetch Buffer — APB), откуда непосредственно перед использованием пересылаются синхронными командами пересылки элементов массивов (mova) в регистровый файл. Таким образом, компилятор, обнаружив в программе регулярный доступ к данным, может реализовать предварительное асинхронное их считывание, забросив операции считывания на достаточное для подкачки расстояние от команд, использующих данные. Далее можно в коде программы заменить все инструкции загрузки из памяти (load) на инструкции пересылки данных (mova) из буфера APB.
Здравствуйте, Gt_, Вы писали:
N>>Не-а. Потому что нет реального теста. Есть странная писулька от агит-сайта, которая даже на уровне теста содержит <1/10 от того, что должно быть.
Gt_>чувак, сосредоточься. тебя обвинили в украинстве потому, что ты верил в отзывы когда набрасывал "по отзывам", а как тебя макнули в реальный отзыв тут же перестал тем самым отзывам верить.
Это не отзыв, и почему — я уже объяснил.
Если "украинство" это применение головного мозга по назначению и хотя бы элементарный анализ, то спасибо за комплимент.
Gt_>и после ответа на твой же голословный наброс еще и меня, показавшего реальный отзыв с реальным тестом, умудрился обвинить в отсутствии аргументов.
Да, потому что их нет, как и реального отзыва.
N>>Теги в стиле Эльбруса как раз ничего не стоят по сравнению с общими затратами на выборку и интерпретацию. N>>А насколько Эльбрус подвержен всему Meltdown-like семейству, опять же, тебе не скажут.
Gt_>тэги стоят нескольких байт в каждом регистре и соответственно исключают доступ к чужим данным в принципе.
Подробности — в студию. Конкретные механизмы и правила их применения.
Здравствуйте, ononim, Вы писали:
CAF>>>>Эльбрус существует в промышленных масштабах? W>>>Интел с аналогичной архитектурой. CAF>>IA-64 ? так ее и закрыли, проект скорее всего не окупился. Зачем еще раз так делать? O>IA-64 навернулся потому что ему была подложена свинья в виде AMD64
Ну тогда можно называть любой чей-то крах "конкуренты подложили свинью — сделали лучше и дешевле".
O>То есть технологию делали из расчета грядущего перехода с x86, на это рассчитывали и технари и что наверно важнее — бизнесменеджмент. И они как изначально таргетировали IA64 как неизбежность для своего уже имеющегося рынка, и исходя из этого планировали свои бизнес процессы, и проявили стандартную для большой корпорации неповоротливость когда внезапно выскочил конкурент в виде AMD64.
N>>Самое прямое. Только не к VLIW в целом, а к EPIC, который в Эльбрусе. N>>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая. N>>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
Gt_>булшит. во первых э2к не просто выполняет команды спекулятивно, он выполнят несколько спекулятивных веток одновременно.
Ссылки в студию. Хотя бы родную документацию.
Gt_> кроме этого компилятор положит в префеч патерн необходимых данных сильно раньше, чем дойдет до исполнения ШК. компилятор заранее знает все, что может понадобится.
Компилятор точно предсказывает кэшированность данных? И на основании чего же?
И почему у других такого нет?
Выдачу prefetch в предыдущей ШК не предлагать, это слишком слабая мера.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
N>>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая.
V>А на деле, даже вшивые RISC-микроконтроллеры имеют до 4-х стадий исполнения команды.
А в Киеве дядька. Некоторые и до шести, но у "вшивых" RISC любая зависимость по данным или по доступу к шине тормозит последующие команды.
N>>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.
V>
V>Команды fapb загружаются в специальный буфер инструкций предподкачки (Prefetch Instruction Buffer -PIB) и, циклически повторяясь, работают асинхронно по отношению к основной программе. Подкачанные ими данные помещаются в специальный буфер предварительно подкачанных массивов (Array Prefetch Buffer — APB), откуда непосредственно перед использованием пересылаются синхронными командами пересылки элементов массивов (mova) в регистровый файл. Таким образом, компилятор, обнаружив в программе регулярный доступ к данным, может реализовать предварительное асинхронное их считывание, забросив операции считывания на достаточное для подкачки расстояние от команд, использующих данные. Далее можно в коде программы заменить все инструкции загрузки из памяти (load) на инструкции пересылки данных (mova) из буфера APB.
"Обнаружив", "может"... да, забить все предшествующие команды этими fapb... кстати, какой там предел их количества на одну ШК?
Здравствуйте, netch80, Вы писали:
N>"Обнаружив", "может"... да, забить все предшествующие команды этими fapb... кстати, какой там предел их количества на одну ШК?
Здравствуйте, netch80, Вы писали:
Gt_>>булшит. во первых э2к не просто выполняет команды спекулятивно, он выполнят несколько спекулятивных веток одновременно. N>Ссылки в студию. Хотя бы родную документацию.
Да полно ж инфы.
Там, помимо основного конвейера, еще три альтернативных.
Если основной "промахивается", то он становится альтернативным, а "попавший куда надо" становится основным.
Здравствуйте, LaptevVV, Вы писали:
LVV>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>Командой пересылки осуществляется ввод-вывод!
Здравствуйте, Cyberax, Вы писали:
C>VLIW на то и VLIW, что имеет очень длинные инструкции. Для спекуляции их надо будет разбирать на микроинструкции, планировать их и т.д.
А в чём проблема-то? Транзисторы нынче дешёвые и их много, потому дублирование отдельных субблоков в железе не вызывает проблем.
LVV>>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>>Командой пересылки осуществляется ввод-вывод! K>А где сейчас это не так?
В Интеле — отдельная адресация портов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, netch80, Вы писали:
N>Неправда.
Правда. Поддержка IO портов там только для совместимости — в частности потому, что они есть только на x86.
N>Там сказано не "all BARs shall be memory" или аналог, а, дословно, "endpoint must not depend on operation system allocation of I/O resources". Ключевое — "operating system allocation" и "depend". N>То есть OS не должна заниматься перераспределением I/O портов после начальной настройки (средствами BIOS). Для ресурсов на памяти такого ограничения не ставится.
Нет — тут имеется в виду как раз то, чтобы девайсы не рассчитывали, что запрошенные через BAR IO ресурсы им по факту предоставят. Как раз потому, что они доступны не на всех платформах, а PCIe девайсы по идее должны работать на любых архитектурах (и, собственно, многие девайсы таки работают — в частности, я лично видел сетевуху, работающую подключённой к ARM SoC с PCIe Root Complex).
N>Практически же на машинах с PCI Express продолжает активно использоваться I/O пространство. Вот с моего настольника: N>Это встроенная, то есть тут нельзя сослаться на проблемы совместимости — если бы был запрет на I/O порты, её бы давно подточили, и у неё не было бы такого диапазона.
И тем не менее это таки для совместимости Если не веришь — попробуй поменять IO BAR и убедиться, что всё по прежнему пашет
N>Нет, не необходимо. N>В отличие от первых 256 байт, стиль доступа к остальным не специфицирован собственно стандартом PCI.
Ну здрассте!
7.2.2. PCI Express Enhanced Configuration Access Mechanism (ECAM)
<...>
The ECAM utilizes a flat memory-mapped address space to access device configuration registers. In this case, the memory address determines the configuration register accessed and the memory data updates (for a write) or returns the contents of (for a read) the addressed register. The mapping from memory address space to PCI Express Configuration Space address is defined in Table 7-1.
Здравствуйте, koandrew, Вы писали:
K>Нет — тут имеется в виду как раз то, чтобы девайсы не рассчитывали, что запрошенные через BAR IO ресурсы им по факту предоставят. Как раз потому, что они доступны не на всех платформах, а PCIe девайсы по идее должны работать на любых архитектурах (и, собственно, многие девайсы таки работают — в частности, я лично видел сетевуху, работающую подключённой к ARM SoC с PCIe Root Complex).
Хм, такое прочтение тоже возможно, приму сейчас на веру. Жаль, что там настолько туманные формулировки.
N>>Практически же на машинах с PCI Express продолжает активно использоваться I/O пространство. Вот с моего настольника: N>>Это встроенная, то есть тут нельзя сослаться на проблемы совместимости — если бы был запрет на I/O порты, её бы давно подточили, и у неё не было бы такого диапазона. K>И тем не менее это таки для совместимости Если не веришь — попробуй поменять IO BAR и убедиться, что всё по прежнему пашет
Отложу до плановой перезагрузки. Но я уверен, что на дофига карт это не пройдёт — если их рассчитывали только на x86. Тем более это не относится к встроенным ресурсам материнки, для которых не надо рассчитывать на возможность работы под другими типами процессоров.
N>>Нет, не необходимо. N>>В отличие от первых 256 байт, стиль доступа к остальным не специфицирован собственно стандартом PCI. K>Ну здрассте! K>
K>7.2.2. PCI Express Enhanced Configuration Access Mechanism (ECAM)
K><...>
K>The ECAM utilizes a flat memory-mapped address space to access device configuration registers. In this case, the memory address determines the configuration register accessed and the memory data updates (for a write) or returns the contents of (for a read) the addressed register. The mapping from memory address space to PCI Express Configuration Space address is defined in Table 7-1.
OK, про букву стандарта был неправ. Но AMD это не поддерживали в ранних версиях и сейчас продолжают предоставлять альтернативный механизм через классические порты. Это вообще-то имеет смысл и потому, что до определённого момента может быть невозможно определить место для размещения MMIO области конфигурации.
В BIOS у них я видел предпочтение именно IO-варианта даже для расширенного пространства — видимо, для универсальности.
Вполне возможно и ожидать, что где-то MMIO и не будет назначено.
Здравствуйте, ononim, Вы писали:
A>>Почему тогда не вспомнить как Transmeta пыталась укрепиться на рынке со своими VLIW-процессорами? O>Crusoe юыли обычные 32хбитные процы.
Нет. Это VLIW процессор с программной виртуальной машиной для эмуляции х86 и ее архитектуры.
Здравствуйте, netch80, Вы писали:
N>Отложу до плановой перезагрузки. Но я уверен, что на дофига карт это не пройдёт — если их рассчитывали только на x86. Тем более это не относится к встроенным ресурсам материнки, для которых не надо рассчитывать на возможность работы под другими типами процессоров.
Железячники — ужасные ретрограды, которые ненавидят изменения. Достаточно посмотреть на спеки HDMI или DisplayPort, чтобы обнаружить там "уши" допотопных CRT-мониторов, хотя, казалось бы, оба эти стандарта до мозга костей цифровые
N>OK, про букву стандарта был неправ. Но AMD это не поддерживали в ранних версиях и сейчас продолжают предоставлять альтернативный механизм через классические порты. Это вообще-то имеет смысл и потому, что до определённого момента может быть невозможно определить место для размещения MMIO области конфигурации.
В современных процах есть виртуальная шина PCI, на которой находятся системные виртуальные "девайсы", среди которых есть Host Bridge, в конфигурационном пространстве которого как раз и находятся базовые регистры разных областей памяти для MMIO, среди которых есть и PCIEXBAR. Вот его как раз системная прошивка должна запрограммировать для того, чтобы использовать ECAM.
N>В BIOS у них я видел предпочтение именно IO-варианта даже для расширенного пространства — видимо, для универсальности. N>Вполне возможно и ожидать, что где-то MMIO и не будет назначено.
PCI Express настоятельно рекомендует не использовать non-prefetchable пространства, то есть управляющие регистры, чтение/запись в которые имеют сайд-эффекты, более того, 64-битные BAR вообще по определению только prefetchable, потому почти все PCIe девайсы мапят управляющие регистры как раз в расширенное конфигурационное пространство PCIe. Самой собой, чтобы это работало, нужно чтобы ECAM работал.
A>>>Почему тогда не вспомнить как Transmeta пыталась укрепиться на рынке со своими VLIW-процессорами? O>>Crusoe юыли обычные 32хбитные процы. НС>Нет. Это VLIW процессор с программной виртуальной машиной для эмуляции х86 и ее архитектуры.
Я про точку зрения юзера/кастомера. Что там внутри всем пох, хоть лампы, хоть терминал в Связующую Бездну. С точки зрения юзеров это был yet another 32битный-i386-compatible CPU.
А вот переход на 64бита вполне мог являтся обоснованным фактором (с точки зрения юзера!) для отрубания хвостов совместимости. Но интел по сути собственноручно отказалась от рынка десктопов с IA-64.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
НС>>Нет. Это VLIW процессор с программной виртуальной машиной для эмуляции х86 и ее архитектуры. O>Я про точку зрения юзера/кастомера. Что там внутри всем пох, хоть лампы, хоть терминал в Связующую Бездну.
Кастомер процессоров это, в основном, производитель оборудования. И ему совсем не пох что там внутри.
НС>>>Нет. Это VLIW процессор с программной виртуальной машиной для эмуляции х86 и ее архитектуры. O>>Я про точку зрения юзера/кастомера. Что там внутри всем пох, хоть лампы, хоть терминал в Связующую Бездну. НС>Кастомер процессоров это, в основном, производитель оборудования. И ему совсем не пох что там внутри.
1 Это были лихие 90е (нуок, начало 2000х), кастомеры-энд-юзеры вполне были влиятельной частью рынка
2 Производителю еще более пох что внутри, его интересуют характеристики. А они таковые — x86-32 посредственной производительности.
Вощем внутренняя VLIWвость кукурузо была настолько же интересна всем породам кастомеров, насколько интересна внутренняя RISCовость современных Core.
Кствти, совпадение или нет, но последний кукурузо увидел свет аккурат через год после появления первого x86-64 камня. Вся эта внутренняя гибкость так и не позволила осилить декодирование новых опкодов.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Вощем внутренняя VLIWвость кукурузо была настолько же интересна всем породам кастомеров, насколько интересна внутренняя RISCовость современных Core.
Да не внутренняя она была, а внешняя. Эмуляция х86 была софтовой. Трансмета даже демонстрировала джава-машину, генерящую нативный vliw код.
НС>Да не внутренняя она была, а внешняя. Эмуляция х86 была софтовой.
В интеле почти такая же хрень крутицца, только кому это интересно, если проц исполняет х86 код.
Был ли нативный набор инструкций в кукурузо документирован (сходу таковая документация не нагугливается)? Если да — позволял ли кукурузо исполнять нативный код просто так? Если да — был ли хоть один дистриб Линуха под нативный код кукурузы? Они хотябы пошевелились хоть както продвинуть на рынке _свою_ платформу (запуск под ней симулятора чужой платформы — ни разу не является таким шагом) ? Вот что важно для кастомеров, а не — "мы тут транзисторы напаяли, нате, кушайте".
[UPD] НС>Трансмета даже демонстрировала джава-машину, генерящую нативный vliw код.
Почему демонстрировала, а не сделала полезный _продукт_ — плагин в браузер мегаускоряющий апплеты?
[UPD2]
Вот что педивикия гласит:
The native crusoe code – even if it was documented and available – is not very conducive to general-purpose OS stuff. It has no notion of memory protection, and there's no MMU for code accesses, so things like kernel modules simply wouldn't work.
Вобщем, нативный набор команд крузо был бесполезен для чего либо иного, кроме написания эмуляторов других систем. Так что глупо его сравнивать и с Титаником, и с L-брусом.
В принципе на нем было бы _очень_ эффективным нативное исполнение управляемых сред, а-ля Сингулярити. Но к сожалению современное ОСестроение слишком погрязло в CP/M-like operating systems
Андроид тоже был бы в кассу, в начале своего развития, когда там еще была классическая Джава. Но когда был Крузо, Андроила еще не было. А когда Андроид появился, Крузо уже не было. Не пересеклись вощем судьбинушки.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, vdimas, Вы писали:
N>>Очевидно, ты в полемическом задоре даже не прочитал ссылку, на которую ссылаешься. N>>Ничего про предел fapb на ШК нет. V>Боюсь, очевидно малость другое — ты пытаешься произносить вслух громкие вещи, смысла которых не понимаешь. )) V>Для команд навроде fapb не требуется большего "предела", чем максимальная сбрасываемая длина конвейера вычислений, учитывая, что работает одновременно 4 конвейера, т.е. один основной и 3 альтернативных. Т.е., там, где у обычного проца происходит срыв конвейера при ошибке предсказания ветвления, у Эльбруса происходит переключение на один из конвейеров, работающий по альтернативной ветке, что резко уменьшает "сбрасываемую длину" конвейера, которая, собсно, и определяет необходимый размер внутренних буферов fapb.
Ну так где хоть один такой буфер? И где хоть одна команда?
От тебя пока только абстракции со сказками про 4 конвейера.
V>Соответственно, у каждой модели Эльбруса кол-во этих регистров будет определяться характеристиками конвейера.
Где регистры? Где эти "характеристики конвейера"? Как их померять? Где данные от независимых измерителей? У какой модели этих альтернативных конвейеров 3, у какой — меньше, у какой — больше?
V>Перевожу на русский — вопрос был тупой донельзя.
Да-да, конечно.
— Этот прибор может работать при температуре до -350 градусов по Цельсию.
— Физика не допускает температур ниже -273!
— Прибор секретный, физики могут и не знать.
N>>В примере ассемблерного кода ни одной fapb. V>Да я уже понял, что ты ни черта не понял.
Я задал конкретный вопрос. Ты юлишь и отвечаешь на совсем другое. Уже всё ясно, что у тебя данных просто нет. Ты говорил про "инсайд"? Самое время задать ему конкретные вопросы, а не хвастать псевдознанием.
V>Свистишь как последний выскочка о всякой, прости хосподи, фигне. V>В современном мире железо разрабатывается под софт, а софт под железо. V>Ты же тут упорно делаешь вид, что подход должен быть сугубо односторонним.
Компилятор же тоже под него заточен? Так покажи реальную производительность не на специально подобранной расчётной задаче, покажи ассемблерный выхлоп, документацию с подробностями реализации, и тогда обсудим, где кто кому конвейер, предсказатель и тому подобное, где была польза от процессора, а где от компилятора, и так далее.
Что, нет данных? Секретный инсайд тоже молчит? Ну, тогда свистун тут ты.
V>С таким подходом пройдите, плиз, в детсад на смену подгузников. V>Тут взрослые дядьки, всё-таки, общаются.
Именно. Твой подгузник с электронной пищалкой за два доллара про "Прибор секретный" скоро перестанет работать, потому что переполнился продуктом вторичным.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, netch80, Вы писали:
N>>Я таким URL не доверяю и никому не советую, и слово "брехня" относится скорее к ним. N>>Пусть дадут реальную установку полдесятку действительно независимых экспертов, причём за пределами РФ. Тогда и посмотрим. K> А кому это надо?
Хех, один из самых правильных вопросов в этом треде
Раз монстры Запада (tm) не побежали дружной толпой в сторону EPIC стиля Эльбруса, значит, там нет такого, на чём можно было бы хорошо выехать.
Мне лично — честно интересно посмотреть на альтернативные реализации — хотя бы чтобы оценить для себя самого перспективы развития, и куда самому двигаться — но нет времени и вдохновения на глубокий анализ.
Авторам и распространителям Эльбруса интересно только военное применение (или нет, но я российскую внутреннюю политику не понимаю и не хочу стараться понимать).
Остались действительно те самые независимые эксперты, типа phoronix, которым анализ такого чуда — большой плюс в репутацию. Но раз у них нету данных, то им просто ничего не дают, сколь ни просят (я уверен, что просили десятки раз).
Можно долго продолжать меряться, у кого длиннее, на основании тех крох информации, что подкидывают с барского стола, но у меня на это настроение просыпается не чаще раза в неделю. Так что спим дальше...
Здравствуйте, Pzz, Вы писали: S>>Из более сложного — рассуждения про eval и рекомпиляцию. Ну, как бы в 2017 году быть не в курсе того, как устроен JIT в CLR/JVM — очень, очень странно. Pzz>Ты высказался про имплементацию, он высказался про спецификацию языка.
Не-а. Спецификация всегда пишется в терминах некоторой абстрактной "целевой машины". Например, весь C# специфицирован в терминах CLR, а Java — в терминах JVM.
Поэтому в данном случае бессмысленно рассуждать о спецификации в отрыве от реализации. Как минимум на уровне что — возможно, а что — нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, ononim, Вы писали:
O>Андроид тоже был бы в кассу, в начале своего развития, когда там еще была классическая Джава. Но когда был Крузо, Андроила еще не было. А когда Андроид появился, Крузо уже не было. Не пересеклись вощем судьбинушки.
Классическая Java категорически не подходит для исполнения на реальных высокоскоростных CPU. Все аппаратные реализации (в том числе от ARM!) провалились с треском.
Для скорости нужно транслировать Java во что-то более приемлимое. Ну а если уж транслировать, то можно и сразу в x86.
Самое близкое что было — это процессоры от Azul, которые реально на вход принимали JVM-байткод и транслировали его в RISC-подобный микрокод на лету.
O>>Андроид тоже был бы в кассу, в начале своего развития, когда там еще была классическая Джава. Но когда был Крузо, Андроила еще не было. А когда Андроид появился, Крузо уже не было. Не пересеклись вощем судьбинушки. C>Классическая Java категорически не подходит для исполнения на реальных высокоскоростных CPU. Все аппаратные реализации (в том числе от ARM!) провалились с треском.
Но на том этапе ее можно было итеративно оптимизировать под крузо, с далвиком это _возможно_ сделать сложнее будет. А может и нет. Но это вторичная проблема, первичная — крузо уже нет
Крузо был бы хорош тем что у него нету MMU и прочих хардварных фич, который нужны классическим ОС, но не классической джаве, и связанных с ними потерь соотношения performance/wattage. То есть по нагугленному — это был проц, заточенный именно для трансляции других систем команд. Можно сказать он несколько опередил свое время, так бывает.
C>Самое близкое что было — это процессоры от Azul, которые реально на вход принимали JVM-байткод и транслировали его в RISC-подобный микрокод на лету.
Еще в ARM есть (или уже был?) никому не нужный Jazelle.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, vdimas, Вы писали:
V>Боюсь, очевидно малость другое — ты пытаешься произносить вслух громкие вещи, смысла которых не понимаешь. )) V>Для команд навроде fapb не требуется большего "предела", чем максимальная сбрасываемая длина конвейера вычислений, учитывая, что работает одновременно 4 конвейера, т.е. один основной и 3 альтернативных. Т.е., там, где у обычного проца происходит срыв конвейера при ошибке предсказания ветвления, у Эльбруса происходит переключение на один из конвейеров, работающий по альтернативной ветке, что резко уменьшает "сбрасываемую длину" конвейера, которая, собсно, и определяет необходимый размер внутренних буферов fapb.
Здравствуйте, Pzz, Вы писали: Pzz>Это потому, что и C# и Java — это языки, изначально нацеленные на одну вполне конкретную целевую машину, пусть и виртуальную. Pzz>Интересно, терминах какой целевой машины описан C/C++
Да, вы, пожалуй, правы.
С избегает упоминания каких-либо свойств целевой архитектуры.
И даже, наверное, можно попробовать определить eval() или compile() в тех же терминах — хотя для этого придётся очень сильно перепахать сам язык.
В управляемой среде можно себе позволить возвращать object, сохраняя строгую динамическую типизацию.
Я не вполне себе представляю сигнатуру eval() в строго статически типизированном языке. (void*)? Но там же офигенный риск ошибки типизации, которая в неуправляемом языке имеет катастрофические последствия.
Как это предотвратить? Передать обязанность валидации типов в eval() — но тогда нужно уметь передавать в аргументах функции информацию о том, какие типы там ожидаются.
В С++ ещё можно было бы попытаться обойтись templates и compiler magic, типа
auto x = eval<int>("return 42;"); // Okauto y = eval<int>("return \"42\";"); // run-time error: invalid conversion from ‘const char*’ to ‘int’
А в чистом С? То есть придётся придумывать механизм описания метаданных на уровне языка.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>Интересно, терминах какой целевой машины описан C/C++
Ну для начала очевидное, но которое не проговаривается, потому что все привыкли и мало кто знает альтернативы:
1. Двоичная (всё состоит из битов, которые 0 или 1). Троичные машины "пролетают", так же как и более экзотические. Можно сэмулировать их работу с частичной потерей реального диапазона, потому что, например, unsigned типы обязаны быть из N бит и хранить значения от 0 до 2^N-1, но не выше.
2. Память состоит из ячеек равного размера, называемых байтами. Адресация ведётся байтами. Байт это не менее 8 бит, может быть и больше (как в Cray — 32 бита), но универсально на все виды памяти.
Неравного размера ячеек не может быть. Отсюда некоторые смешные последствия — например, если кто-то захочет пространство machine-specific registers в x86 представить в виде массива, у него не получится: они бывают и по 32, и по 64 бита, и нет правила, что чтение/запись по адресу 21 видит то же, что по адресу 20, но сдвинутым на 8 бит — нет, это просто разные сущности.
3. Начиная с C++20 — машина должна иметь представление целых чисел со знаком в дополнительном коде (twoʼs complement).
Чуть менее железячные:
4. Определённые ограничения на типы: например, signed int не может быть шире unsigned int, как и в любой подобной паре.
5. Вход языка и ввод-вывод данных должен поддерживать определённый набор символов, независимо от кодировки. (Точнее, может быть два разных — source и execution character sets.) Коды цифр должны быть последовательными. Символ с кодом 0 должен быть особым, не используемым в целях представления чего-то реального. (Формулировка другая, просто код 0 выделен для завершения строки, я написал уже следствие.)
Все коды из базового набора для исходников — должны влезать в байт.
6. В рантайме должны быть три последовательных потока ввода-вывода (stdin/stdout/stderr, их C++ аналоги). Это если hosted окружение. Тут же добавляются требования вроде запуска main() с командной строкой и т.п.
7. В плавучке, числа должны быть представлены в виде sign*mantissa*(base**exponent). Из такой формальности вытекает, например, что не может быть ситуации, как для целых — -128 представимо в int8_t, а +128 — нет, максимум +127. Формат части за знаком не может быть зависим от знака.
Ну и так далее... (надоело, на работу бежать надо). В общем, ограничений до чёрта, я даже из навскидку понятных не написал более половины.
Касательно Эльбруса — считается законным для C, например, записать кусок памяти как набор байт (символов), а затем прочитать его как число или указатель. Strict aliasing это явно допускает, поэтому теговая защита тут идёт нафиг, или теги должны как-то специально восстанавливаться.
(Хм, вообще на нём надо было бы запускать не Linux, а что-то вроде OS/400...)
Здравствуйте, Sinclair, Вы писали:
S>Я не вполне себе представляю сигнатуру eval() в строго статически типизированном языке. (void*)? Но там же офигенный риск ошибки типизации, которая в неуправляемом языке имеет катастрофические последствия.
Там и так по любому рискуешь этой ошибкой. Так что принципиального ухудшения не будет.
Здравствуйте, netch80, Вы писали: N>Там и так по любому рискуешь этой ошибкой. Так что принципиального ухудшения не будет.
Конечно же будет. Для "обычной" программы у нас есть возможность статически проверить типы и убедиться, что она делает более-менее то, что нам нужно.
Даже те места, где у нас идёт небезопасный каст, обычно применяются к заранее известному типу данных. То есть при приведении void* data к MY_STRUCT* у нас есть причины полагать, что в data — именно MY_STRUCT.
В динамике там может быть всё, что угодно. У нас должны быть какие-то способы ограничить тексты, которые будет успешно прожёвывать eval() или compile().
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
>Я не вполне себе представляю сигнатуру eval() в строго статически типизированном языке. (void*)? Но там же офигенный риск ошибки типизации, которая в неуправляемом языке имеет катастрофические последствия.
А как определятся интерфейс загрузки функции из DLL? Вот так примерно и определяется, возвращает (void*), а остальное — проблема пользователя.
Не надо воспринимать строгую статическую типизацию, как некую религиозную догму. Статическая типизация — удобная и полезная штука, но в некоторых случаях приходится делать unsafe.
Но я, впрочем, не сторонник внесения в стандарт Си функций типа eval/compile. В общем виде их нормально не реализуешь на большинстве популярных платформ.
Здравствуйте, Pzz, Вы писали:
Pzz>А как определятся интерфейс загрузки функции из DLL? Вот так примерно и определяется, возвращает (void*), а остальное — проблема пользователя.
Ну, в случае DLL у нас помимо ISO стандарта на язык есть определённые договорённости о calling convention плюс спецификация библиотеки, которые позволяют нам более-менее полагаться на стабильность результатов приведения void* к нужному нам типу. Ну, то есть теоретически мы знаем, что можно подложить левую DLL, и там вообще всё-всё взорвётся. Но на практике у нас есть более-менее работающие практики по согласованию вызовов.
Про compile()/eval() я себе не очень представляю, как получить хотя бы как-то работающую реализацию. Откуда будут браться тексты, которые туда будут скормлены?
Если это какой-то набор фиксированных источников, то наверное проще их все скомпилировать заранее и хранить сразу в пригодном для вызова виде.
Если это какая-то полная динамика, не входящая в наш цикл разработки, то она полностью бесполезна без методик контроля валидности.
Ну, то есть если мы хотим иметь какую-то интерактивную программу, в которую, как в ексель, вводится формулка, и мы интегрируем вызов этой формулки в нашу программу, то вот такой вот "небезопасный eval" — это худший возможный вариант. Чуть не то набрал — хлоп, page fault, приехали (это в лучшем случае).
Pzz>Но я, впрочем, не сторонник внесения в стандарт Си функций типа eval/compile. В общем виде их нормально не реализуешь на большинстве популярных платформ.
Ну вот то-то и оно. В общем, непонятна мотивация и сценарии использования этого eval().
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>Если бы так же сделали с Си, в этом был бы смысл. А целый компилятор с кодогенераровом в библиотеку засовысать, я не знаю, зачем это нужно.
А зачем вообще парсить код, если его не исполнять?
Здравствуйте, netch80, Вы писали:
N>А зачем вообще парсить код, если его не исполнять?
В случае с Go это полезно для написания всяких генераторов и анализаторов. Я не видел еще не одного проекта, который бы в рантайм что-то парсил, но вот нагенерировать всякого барахла и потом его использовать — это удобно.
Здравствуйте, Mystic Artifact, Вы писали:
MA>Цена действительно качественного JIT — около 50Mb исполнимого кода. Что там наркоманы в Го творят — это никому не интересно.
Здравствуйте, netch80, Вы писали:
Pzz>>Если бы так же сделали с Си, в этом был бы смысл. А целый компилятор с кодогенераровом в библиотеку засовысать, я не знаю, зачем это нужно.
N>А зачем вообще парсить код, если его не исполнять?
Чтобы всякие тузлы можно было написать, которые с кодом работают. Например "переименовать поле в классе CCC из XXX в YYY", или "построить список мест, откуда вызывается функция FFF" — куда как аккуратнее решается, если тулза способна по-настоящему распарсить текст, чем если она пытается угадать с помощью регулярных выражений, как это нередко делается.
Здравствуйте, Sinclair, Вы писали:
S>В динамике там может быть всё, что угодно. У нас должны быть какие-то способы ограничить тексты, которые будет успешно прожёвывать eval() или compile().
Ну, например, компилятор мог бы передавать eval'у, какой тип ожидается на выходе, а eval бы в рантайме проверял, получилось у него, или нет.
Здравствуйте, 0xCAFEDEAD, Вы писали:
A>>Ты точно программист? A>>Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
CAF>Не понял. Ты думаешь, что поддерживать свою архитектуру проще чем реализовать чужую?
Да, да, да, да, да и ещё триста раз да!
Более того, ты не сможешь привести ни одного современного примера поддержки чужой архитектуры.
Купить (с грехом пополам как AMD) ещё можно, самостоятельно воспроизвести — никогда.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, a7d3, Вы писали:
A>>>Такое впечатление, что ты знаешь систему команд Эльбруса. A>>>Поделись информацией!
A>>Есть книжка раздаваемая официально http://www.mcst.ru/doc/book_121130.pdf
A>Ну так система команд-то где? A>Информационного шума (маркетингового булшита) дохрена, но где конкретная информация?
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
A>>>Ты точно программист? A>>>Ты не знаешь, насколько труднее поддерживать чужую программу, чем писать свою?
CAF>>Не понял. Ты думаешь, что поддерживать свою архитектуру проще чем реализовать чужую?
A>Да, да, да, да, да и ещё триста раз да! A>Более того, ты не сможешь привести ни одного современного примера поддержки чужой архитектуры. A>Купить (с грехом пополам как AMD) ещё можно, самостоятельно воспроизвести — никогда.
Так вроде те же МЦСТ вполне спокойно и СПАРК выпускают. Архитектура открытая, прцессор свой.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>Здравствуйте, alpha21264, Вы писали:
A>>>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>>>>А как все эти вложения окупятся вот в чем вопрос? Я пока не вижу ответа.
A>>>Чем не устраивает ответ "как обычно"?
CAF>>А обычно это как?
A>Как всегда. A>Сейчас ты идёшь в магазин и покупаешь компьютер. A>И хотя ты в магазине платишь рубли, A>с каждого купленного компьютера Россия теряет, A>а США приобретают примерно тысячу долларов.
Ну это уж ты подзагнул.
A>В случае российского компьютера эту штуку баксов A>будут получать русские инженеры и рабочие. A>Даже если русский компьютер будет в десять раз дороже, A>Россия в целом станет на эту штуку баксов богаче.
Вообще-то мы это уже проходили в СССР. Я помню эти советские компьютеры. Кстати, были XT/AT совместимые
Но в общем это путь в никуда. Это хорошо поддержать своих, но в разумных пределах. И вопрос не в том, зачем Рос компьютер, а зачем своя архитектура. Ведь там даже gcc нет. Нужно свой компилятор поддерживать, и все им собирать. Об остальных языках я вообще молчу.
A>Вот потому так истерят наши США-нские (хотел сказать коллеги) оппоненты.
Вообще-то я в США живу ныне. А мы не в политике, и разговор именно как о перспективах техники. Я же сразу написал, и не раз повторял. Свой процессор, свое производство, и тд может быть вопросом безопастности, обсуждать нет сысла. Именно вопрос об использовании оригинальной архтектуры.
Здравствуйте, a7d3, Вы писали:
A>Архитектуры VLIW / EPIC являются естественным продолжением в эволюционном развитии персональных компьютеров с процессорами общего назначения. Имея в теории и демонстрируя на практике ряд преимуществ, включая большую энерго-эффективность и меньшие требования к производственному техпроцессу.
Объясни тогда, почему и nVidia и AMD перешли в своих графических картах от VLIW к RISC?
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Так вроде те же МЦСТ вполне спокойно и СПАРК выпускают. Архитектура открытая, прцессор свой.
Они проц для архитектуры спарка непозволительно долго разрабатывали, кста.
Забавно, что на порядки более мощный Эльбрус, однако, был разработан совсем на смешные деньги/ресурсы.
Тут рядом кое-кто из коллег стучит по столу кулаком и требует самого подробного сравнения с нынешними топами от Интел... еще бы помнить, что бюджеты разработок отличаются на несколько порядков, а быстродействие в единицы раз — в зависимости от задач в 2-8 раза.
Т.е., таки да, свою архитектуру пилить проще, то бишь дешевле.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.
Выражаю всем участникам благодарность за более менее содержательные ответы. Не все детали я понял
Но я очень рад, что не все не скатилось в полный хлам. К сожалению большинство обсуждает технические детали, а не экономические.
Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF> Зачем городить еще одну архитектуру в промышленных масштабах?
просто сраз спрошу, афтор в курсе что такой явный параллелизм и об истории IA64?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>> Зачем городить еще одну архитектуру в промышленных масштабах?
B>просто сраз спрошу, афтор в курсе что такой явный параллелизм и об истории IA64?
В общих чертах. Но какое отношение мои познания в архитектурах имеет отношение к вопросу? Тут уже много людей высказалось, даже ссылок привели. Есть что добавить?
Время открытия строки не имеет никакого отношения к полосе пропускания. Проблема латентности памяти замечательно решается кэшированием. Кстати кэш — это и есть SRAM, вон АМД пихает по 60МБайт на кристалл — и вроде как их чипы не стоят запредельных денег.
