Здравствуйте, 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.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, netch80, Вы писали:
N>Очевидно, ты в полемическом задоре даже не прочитал ссылку, на которую ссылаешься. N>Ничего про предел fapb на ШК нет.
Боюсь, очевидно малость другое — ты пытаешься произносить вслух громкие вещи, смысла которых не понимаешь. ))
Для команд навроде fapb не требуется большего "предела", чем максимальная сбрасываемая длина конвейера вычислений, учитывая, что работает одновременно 4 конвейера, т.е. один основной и 3 альтернативных. Т.е., там, где у обычного проца происходит срыв конвейера при ошибке предсказания ветвления, у Эльбруса происходит переключение на один из конвейеров, работающий по альтернативной ветке, что резко уменьшает "сбрасываемую длину" конвейера, которая, собсно, и определяет необходимый размер внутренних буферов fapb.
Соответственно, у каждой модели Эльбруса кол-во этих регистров будет определяться характеристиками конвейера.
Перевожу на русский — вопрос был тупой донельзя.
N>В примере ассемблерного кода ни одной fapb.
Да я уже понял, что ты ни черта не понял.
N>По ссылке приводится пример математического расчёта. Почему-то все мерятели бенчмарками Эльбруса показывают только математику. Найди пример распаковки 7z-архива (один из типовых тестов, на которых сравнивают x86), перепаковки видео по ffmpeg. Какую-нибудь древнюю бегалку-стрелялку типа Doom (чтобы не требовался SSE и было достаточно типового оборудования лаптопа). Я подозреваю, что нет: им слабо́, потому что будут показаны результаты, с которыми стыдно идти даже к папуасам.
Свистишь как последний выскочка о всякой, прости хосподи, фигне.
В современном мире железо разрабатывается под софт, а софт под железо.
Ты же тут упорно делаешь вид, что подход должен быть сугубо односторонним.
С таким подходом пройдите, плиз, в детсад на смену подгузников.
Тут взрослые дядьки, всё-таки, общаются.
Здравствуйте, 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.
Здравствуйте, 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
Ожидается апдейт и этой линейки.
Здравствуйте, Sinclair, Вы писали:
Pzz>>Ты высказался про имплементацию, он высказался про спецификацию языка. S>Не-а. Спецификация всегда пишется в терминах некоторой абстрактной "целевой машины". Например, весь C# специфицирован в терминах CLR, а Java — в терминах JVM.
Это потому, что и C# и Java — это языки, изначально нацеленные на одну вполне конкретную целевую машину, пусть и виртуальную.
Интересно, терминах какой целевой машины описан C/C++
Здравствуйте, 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...)
А кому это надо?
