Потому что работал с этими вещами не один десяток лет. Даже если ввести в теги по биту на каждый байт в кеш линии - получается, что при вытеснении грязной линии в память или следующий уровень надо записывать только отдельные байты, что сильно усложнит аппаратуру - и так сейчас не делают. Самое близкое, что видел - отдельные dirty bits на каждые 16 байт в кеш линии на одной GPUшке; на CPU только общий dirty bit на кеш линию.
один процессор работает только с одними байтами, а другой -- с другими байтами, т.е. имеющими разные адреса
Именно так. Но в кешах гранулярность хранения - кеш линия (обычно 64 байта) и просто так менять отдельные части нельзя (иначе у разных процессоров будут разные версии, при этом кеш линейка не отслеживает, какие байты в ней изменены). Если, скажем, разные процессоры меняют разные целые числа в одной линейке, в каждый момент должна быть одна валидная версия, содержащая изменения от всех процессоров. Для синхронизации есть протоколы когерентности, причём их использование необходимо независимо от модели памяти.
Так вопрос не в сериализации, а в постоянных обращениях разных процессоров к разным частям кеш линейки (с обновлениями) без прерываний и системных вызовов.
необходимостью иметь, фактически, связь процессоров (их кэшей, причём всех уровней) "все со всеми".
Это в любом случае нужно для когерентности кешей в любой модели памяти (записи в разные части кеш линеек должны корректно мёрджиться).
Так что, думаю, обработкой срочных запросов занимаются машины других архитектур, а на мэйнфреймах лежит, так сказать, бэкенд -- гигантские базы данных и всё такое, где важней общая производительность, а не время ответа.
Да, возможно так - основная база на мэйнфрейме, а какие-нибудь кеши в памяти и т.п. на машинках попроще.
у мэйнфреймов любое прерывание вызывает т.н. сериализацию ("временную отмену совмещений", как её переводили в советской литературе), в результате чего, по сути, кэш очищается
А как при этом с производительностью в клиент серверных приложениях, когда каждая микросекунда отклика на счету (например HFT), при этом данные для следующего запроса могут быть в кеше процессора? Или там есть технологии типа DPDK с возможностью обработать запрос из сети без прерываний и переключения в контекст ядра?
На Siemens C55 первое, что делалось после покупки - разлочивалась заливка мелодий и джавы с компа, после этого всё записывалось по кабелю. Не помню, чтобы с WAP страниц что-то скачивал, хотя по сайтам лазил.
тем более изучение i286 ассемблера не имеет никакого практического смысла
Статья точно не про практический смысл. Тут так, показать немножко низкого уровня для тех кто никогда с этим не сталкивался, детали всё равно уловят только те, кто и так всё это знает )
Удобоваримые книжки стали появляться тогда, когда актуальность уже пропала.
У меня бумажная книжка (Джордейн) появилась заметно раньше всяких документов в электронном виде (Ralph Brown's interrupt list и иже с ними).
Вот я знаю пару десятов ЯП - в каких категориях прикажете мне мыслить?
Это нетипичный случай. Я про вариант, когда человек знает только Javascript и хорошо ещё, если может обобщить знания по Vue и React.
В статье сказано конкретно про GPRS ) И да, первый мобильник я купил, когда он уже был, но ещё тестировался. Через CSD, насколько понимаю, тарификация как за голосовой звонок.
Стоит тогда на Эльбрус посмотреть - там, например, разделены стеки возрата и данных. А если копнуть в историю - то ещё и на старый советский Эльбрус с аппаратным контролем типизации (подобное было и в iAPX 432).
когда как у x86 и ARM все ядра имеют поддержку спекулятивного выполнения
По крайней мере ARM ядра c in order микроархитектурой ещё живы; насчёт x86 не уверен, но они достаточно долго были таковыми (спекулятивное выполнение появилось только в Pentium Pro) и никто не мешает сделать новое x86 in order ядро - вопрос только в рыночной востребованности, сама по себе ISA не требует какой то конкретной микроархитектуры. При этом если RISC V таки дойдёт до HPC и энтерпрайза, спекулятивное выполнение в таких чипах скорее всего будет - например, у Syntacore в ядрах начиная с SCR6 спекулятивное выполнение есть.
микрокод высокой производительности ни разу не противоречит
Изначальный посыл RISC был в том, что реализованные в микрокоде инструкции со сложной семантикой удобны скорее человеку - компиляторы их не генерируют, а большая часть ПО пишется на языках высокого уровня - соответственно, все эти навороты с микрокодом только зря расходуют транзисторы, которые можно использовать более продуктивно.
подобные операции (шифрование, например) выполняются железными блоками, которые расположены отдельно от процессора
Да, для микроконтроллеров это логично, но в серверных чипах вполне можно выделить транзисторы на самом процессоре.
от изначальной идеи RISC (а она -- именно что небольшое количество простых команд)
Всё таки изначально Паттерсон в статье выступал в основном против микрокода. И да, в те времена - когда даже FPU на чипе встречалось нечасто - ISA, отображающая только то, что реализовано в железе, получалась весьма компактной. Но если в микроархитектуру добавляются векторные регистры, специализированные блоки в ALU и т.д. - странно не предоставлять к этому архитектурный доступ на уровне ISA.
ведь, полагаю, RISC-V шифрует данные в памяти? Регистров у него не так уж много
Инструкции работают со скалярными или векторными регистрами, если надо обработать большой массив, нужен цикл. И да, сейчас видимые отличие CISC/RISC скорее в наличии/отстутствии аргументов в памяти в арифметических инструкциях. Хотя сейчас в ARM есть, скажем, CISC-style атомики, инкрементирующие значение в памяти одной инструкцией, в спецификации (в железе пока не видел) есть и инструкции копирования памяти по типу REP MOVS в x86.
По крайней мере у нас в Нижнем в 2003-2005 GPRS (включая WAP) раздавался бесплатно в тестовом режиме - сначала так было у Билайна, позже тестировать начал НСС. Так что, скажем, читал книжки на Siemens C55 по дороге на работу в маршрутке на WAP сайтах - на самом телефоне всю память съедали мелодии и игрушки.
Сколько места займёт подпрограмма шифрования AES на ARM или RISC-V? Ну а на мэйнфреймах z/Architecture это делается одной командой.
Эти команды и на RISC процессорахесть. RISC на самом деле - не про простоту или небольшое количество инструкций (хотя название намекает), а про минимальную прослойку между ISA и железом процессора - изначально речь шла про борьбу с микрокодом, то есть о выкидывании инструкций, реализация которых требует по сути отдельных подпрограмм внутри процессора. Если в процессор добавляется специальный юнит для крипто операций, расширение ISA для работы с ним идее RISC не противречит.
Челлендж для тех, кто ассемблера боится. Это в начале 90х, помню, все знакомые (причём больше физики, чем программисты) гонялись за книжками по ассемблеру, прерываниям DOS/BIOS и т.п. - типа без этого ты вообще в компьютерах не разбираешься. Сейчас большинство программистов мыслят в терминах своих ЯП/фреймворков, что там снизу - тёмный лес...
Потому что работал с этими вещами не один десяток лет. Даже если ввести в теги по биту на каждый байт в кеш линии - получается, что при вытеснении грязной линии в память или следующий уровень надо записывать только отдельные байты, что сильно усложнит аппаратуру - и так сейчас не делают. Самое близкое, что видел - отдельные dirty bits на каждые 16 байт в кеш линии на одной GPUшке; на CPU только общий dirty bit на кеш линию.
Именно так. Но в кешах гранулярность хранения - кеш линия (обычно 64 байта) и просто так менять отдельные части нельзя (иначе у разных процессоров будут разные версии, при этом кеш линейка не отслеживает, какие байты в ней изменены). Если, скажем, разные процессоры меняют разные целые числа в одной линейке, в каждый момент должна быть одна валидная версия, содержащая изменения от всех процессоров. Для синхронизации есть протоколы когерентности, причём их использование необходимо независимо от модели памяти.
Так вопрос не в сериализации, а в постоянных обращениях разных процессоров к разным частям кеш линейки (с обновлениями) без прерываний и системных вызовов.
Это в любом случае нужно для когерентности кешей в любой модели памяти (записи в разные части кеш линеек должны корректно мёрджиться).
Да, возможно так - основная база на мэйнфрейме, а какие-нибудь кеши в памяти и т.п. на машинках попроще.
А как при этом с производительностью в клиент серверных приложениях, когда каждая микросекунда отклика на счету (например HFT), при этом данные для следующего запроса могут быть в кеше процессора? Или там есть технологии типа DPDK с возможностью обработать запрос из сети без прерываний и переключения в контекст ядра?
На Siemens C55 первое, что делалось после покупки - разлочивалась заливка мелодий и джавы с компа, после этого всё записывалось по кабелю. Не помню, чтобы с WAP страниц что-то скачивал, хотя по сайтам лазил.
Раз уж выводите все символы через ah=02h, смысл в отдельной обработке доллара вроде как пропадает.
Тем не менее выводите вы его той же самой второй функцией 21го прерывания )
Угу, но поучиться на ошибках предков стоит )
Статья точно не про практический смысл. Тут так, показать немножко низкого уровня для тех кто никогда с этим не сталкивался, детали всё равно уловят только те, кто и так всё это знает )
У меня бумажная книжка (Джордейн) появилась заметно раньше всяких документов в электронном виде (Ralph Brown's interrupt list и иже с ними).
Это нетипичный случай. Я про вариант, когда человек знает только Javascript и хорошо ещё, если может обобщить знания по Vue и React.
В статье сказано конкретно про GPRS ) И да, первый мобильник я купил, когда он уже был, но ещё тестировался. Через CSD, насколько понимаю, тарификация как за голосовой звонок.
Стоит тогда на Эльбрус посмотреть - там, например, разделены стеки возрата и данных. А если копнуть в историю - то ещё и на старый советский Эльбрус с аппаратным контролем типизации (подобное было и в iAPX 432).
По крайней мере ARM ядра c in order микроархитектурой ещё живы; насчёт x86 не уверен, но они достаточно долго были таковыми (спекулятивное выполнение появилось только в Pentium Pro) и никто не мешает сделать новое x86 in order ядро - вопрос только в рыночной востребованности, сама по себе ISA не требует какой то конкретной микроархитектуры. При этом если RISC V таки дойдёт до HPC и энтерпрайза, спекулятивное выполнение в таких чипах скорее всего будет - например, у Syntacore в ядрах начиная с SCR6 спекулятивное выполнение есть.
Изначальный посыл RISC был в том, что реализованные в микрокоде инструкции со сложной семантикой удобны скорее человеку - компиляторы их не генерируют, а большая часть ПО пишется на языках высокого уровня - соответственно, все эти навороты с микрокодом только зря расходуют транзисторы, которые можно использовать более продуктивно.
Да, для микроконтроллеров это логично, но в серверных чипах вполне можно выделить транзисторы на самом процессоре.
Всё таки изначально Паттерсон в статье выступал в основном против микрокода. И да, в те времена - когда даже FPU на чипе встречалось нечасто - ISA, отображающая только то, что реализовано в железе, получалась весьма компактной. Но если в микроархитектуру добавляются векторные регистры, специализированные блоки в ALU и т.д. - странно не предоставлять к этому архитектурный доступ на уровне ISA.
Инструкции работают со скалярными или векторными регистрами, если надо обработать большой массив, нужен цикл. И да, сейчас видимые отличие CISC/RISC скорее в наличии/отстутствии аргументов в памяти в арифметических инструкциях. Хотя сейчас в ARM есть, скажем, CISC-style атомики, инкрементирующие значение в памяти одной инструкцией, в спецификации (в железе пока не видел) есть и инструкции копирования памяти по типу REP MOVS в x86.
Там по ссылке
так что речь не только о музыке.
По крайней мере у нас в Нижнем в 2003-2005 GPRS (включая WAP) раздавался бесплатно в тестовом режиме - сначала так было у Билайна, позже тестировать начал НСС. Так что, скажем, читал книжки на Siemens C55 по дороге на работу в маршрутке на WAP сайтах - на самом телефоне всю память съедали мелодии и игрушки.
Эти команды и на RISC процессорах есть. RISC на самом деле - не про простоту или небольшое количество инструкций (хотя название намекает), а про минимальную прослойку между ISA и железом процессора - изначально речь шла про борьбу с микрокодом, то есть о выкидывании инструкций, реализация которых требует по сути отдельных подпрограмм внутри процессора. Если в процессор добавляется специальный юнит для крипто операций, расширение ISA для работы с ним идее RISC не противречит.
И что он предлагает взамен (и как тут вообще влияет ISA)? Вроде пока ничего лучше для ускорения обычного однопоточного кода не придумано.
Челлендж для тех, кто ассемблера боится. Это в начале 90х, помню, все знакомые (причём больше физики, чем программисты) гонялись за книжками по ассемблеру, прерываниям DOS/BIOS и т.п. - типа без этого ты вообще в компьютерах не разбираешься. Сейчас большинство программистов мыслят в терминах своих ЯП/фреймворков, что там снизу - тёмный лес...