Здравствуйте, 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>Ссылки в студию. Хотя бы родную документацию.
Да полно ж инфы.
Там, помимо основного конвейера, еще три альтернативных.
Если основной "промахивается", то он становится альтернативным, а "попавший куда надо" становится основным.
Здравствуйте, ononim, Вы писали:
O>То есть такая "низкоуровневость" нативного кода сильно урезает возможности новых версий процессоров более оптимально исполнять старый код.
Учитывая количество языков с JIT или прекомпиляцией в нативный код на клиентской системе, это может быть не такая уж и проблема.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, LaptevVV, Вы писали:
LVV>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>Командой пересылки осуществляется ввод-вывод!
Здравствуйте, Cyberax, Вы писали:
C>VLIW на то и VLIW, что имеет очень длинные инструкции. Для спекуляции их надо будет разбирать на микроинструкции, планировать их и т.д.
А в чём проблема-то? Транзисторы нынче дешёвые и их много, потому дублирование отдельных субблоков в железе не вызывает проблем.
LVV>>Регистры внешних устройств адресовались адресами памяти — это блеск! LVV>>Командой пересылки осуществляется ввод-вывод! K>А где сейчас это не так?
В Интеле — отдельная адресация портов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, 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 пространство. (Ну не вспоминаем чисто канальные архитектуры и прочие редкости.)
Здравствуйте, 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 сейчас не два, а три таких пространства, каждое чуть для своей роли
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
N>>"Обнаружив", "может"... да, забить все предшествующие команды этими fapb... кстати, какой там предел их количества на одну ШК?
V>https://www.slideshare.net/profyclub_ru/ss-41396492
Очевидно, ты в полемическом задоре даже не прочитал ссылку, на которую ссылаешься.
Ничего про предел fapb на ШК нет. В примере ассемблерного кода ни одной fapb.
По ссылке приводится пример математического расчёта. Почему-то все мерятели бенчмарками Эльбруса показывают только математику. Найди пример распаковки 7z-архива (один из типовых тестов, на которых сравнивают x86), перепаковки видео по ffmpeg. Какую-нибудь древнюю бегалку-стрелялку типа Doom (чтобы не требовался SSE и было достаточно типового оборудования лаптопа). Я подозреваю, что нет: им слабо́, потому что будут показаны результаты, с которыми стыдно идти даже к папуасам.
Здравствуйте, 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 и ее архитектуры.
А облака у всех?
