Чуть выше в треде привели пример решения — pragma simd, описываемая стандартом. Дело теперь за компиляторами — надо её поддержать для всех архитектур, тогда и векторный код будет генерироваться.
Последние векторные инструкции в процессорах Intel мне всё больше напоминают некоторые функции стандарта MPI (message passing interface). Тут тебе и gather/scatter, и stride-access. Интересно, скоро ли напишут вариант реализации MPI для систем с общей памятью прямо на интринсиках :-)
Я не предлагал писать что-то через интринсики. Интринсики — это тот же самый асм, только завёрнутый более аккуратно в синтаксис использующего его языка высокого уровня. Вместо ассемблер-специфичных clobber-list, двойных процентов у имён регистров и прочее код оформляется как вызов inline-функций. Сахар, не более.
> самый красивый и чистый способ
У каждого понятия «красоты» и «чистоты» свои. Понятия «простота разработки/поддержки» и «скорость работы» более объективны.
Сразу всплывающие проблемы для Вашего примера кода.
1. Он теперь только для ARM. Если бы этот пример был для IA-32 — та же проблема: код оказывается только для одной архитектуры. У меня были проблемы при попытке переноса огромной массы кода, написанной на асме (ядро двоичного транслятора) даже для случая IA-32 -> Intel 64. Вроде бы одно является развитием другого, а вот фиг асм переиспользуешь.
2. Поправьте меня, если мои знания устарели, но у ARM всего один вид SIMD — это 128-битный NEON. У Интеловской же архитектуры за всё время накопилось векторных расширений: 64-битный MMX, 128-битный SSE/SSE2/SSE3/SSE4.1/SSE4.2, 128-битный AVX, 256-битный AVX2. А на MIC'ах уже есть 512-битный AVX3.x. И для какой же ширины регистров и набора инструкций писать асм в таком случае, если у пользователя может оказаться совершенно разное железо (разве что MMX можно уже забыть как страшный сон)? Придётся писать 3-4 варианта всех процедур на асме. Я бы предпочёл, чтобы это за меня сделал компилятор.
Мне кажется, что надо упомянуть ещё одну нечасто вспоминаемую, но, как мне кажется, критически важную особенность параллельных программ, написанных на Cilk и на Cilk Plus. Это — возможность детерминистичного (повторяемого от запуска к запуску) исполнения. Для последовательных программ это свойство почти естественно, тогда как немногие парадигмы параллельного программирования гарантируют это. Я думаю, не нужно объяснять ценность повторяемости исполнения при отладке.
Более того, для программ на Cilk определена «сериальная элизия» (serial elision) — результат работы параллельной программы эквивалентен одному из исполнений её последовательного «близнеца», в котором такие директивы, как spawn, cilk_for заменены на вызов функции и обыкновенный for.
Вы скажете: «А как же программы, которые используют генератор (псевдо)случайных чисел?». Для этого случая для Cilk реализован быстрый параллельный детерминированный генератор псевдослучайных чисел (прочтите внимательно все определения, чтобы впечатлиться). Статья, описывающая, как это работает, за авторством Чарльза Лейзерсона (один из авторов «Introduction to Algorithms»): Deterministic Parallel Random-Number
Generation for Dynamic-Multithreading Platforms
Я могу попробовать ответить. Любая торговая марка после её регистрации принадлежит компании только при условии, что эта компания отстаивает своё право на эксклюзивное использование вот именно этой комбинации слов. Если же слово/фраза становится нарицательным, или им начинают обозначать нечто большее, чем было изначально задумано, и не ассоциируют с правообладателем, то в суде исключительное право на использование как торговой марки после этого уже не отстоять.
Такое случалось в истории. Такие слова, как «капрон», «героин» и т.д. Я был очень удивлён, узнав совсем недавно, что «термос» — это тоже торговая марка! Обратный пример: компания Google отказала Оксфордскому словарю во включении глагола «to google» в словарь по тем же самым причинам.
По этой причине сотрудников любой компании обязуют в публичных коммуникациях обозначать торговые марки во этими дурацкими символами. Потому что если уж даже члены компании не защищают торговую марку, и есть документальные подтверждения в виде постов на форумах, то в суде при случае отстоять ничего не получится.
>> Тема необходимости функциональных симуляторов не раскрыта.
Хороший вопрос. Одна из областей их использования — разработка ПО до доступности железа, а точнее, совместная разработка (software/hardware codevelopment). Например, запуск Андроида для ARM с помощью SDK от Google на обыкновенном ПК c процессором IA-32 — это использование симуляции. Другой пример — Intel SDE и Wind River Simics включают в себя поддержку будущих инструкций Intel, и на них можно тестировать своё ПО заранее. Третий пример — Apple Rosetta, слой совместимости для PowerPC, который был использован при переводе Макинтошей на архитектуру Intel для того, чтобы старые приложения работали без перекомпиляции.
Разработка Firmware, BIOS, UEFI-прошивок, драйверов, компиляторов для новых архитектур ведётся на симуляторах и позволяет к моменту доступности первых железок иметь уже что-то более-менее отлаженное со стороны софта. Всё вместе — укорачивает цикл разработки и приближает момент выхода продукта на рынок.
Даже некоторые осторожные оценочные предсказания производительности можно получить на функциональной модели. Конечно, они будут далеки от той точности, которую дают потактовые модели. Но скорость работы функциональной симуляции иногда важнее.
Я планирую в ближайшее время опубликовать ещё одну заметку про симуляцию, там будет дан пример того, когда точности функциональных моделей хватает, чтобы сэкономить на числе сожжённых чайников.
к примеру некратная частота эмулируемого процессора по отношению к хосту может вести к рассинхрону.
В таких случаях это означает, что исходные приложения были написаны с завязкой на определённые значения длительностей некоторых операций, т.н. «синхронизация на sleep'ах». В таком случае симулятор должен моделировать задержки ключевых операций достаточно точно, чтобы гостевое приложение «не заметило» обмана. Для создателя модели это часто превращается в жуткую мороку, т.к. подобные аспекты работы железа могут не быть отражены в спецификациях.
То, что модель — это интерпретатор или ДТ, в принципе не определяет того, будут лаги или нет. Симулируемое время и время реальное связаны с друг другом только одним фактом: они оба монотонно возрастают. При условии, что симулятор написан честно и сам не использует «синхронизацию на sleep'ах».
В целом есть такой принцип: «корректные программы легко симулировать» — если ПО написано только на основе спецификаций, не использует информацию о длительностях операций и т.п., то внутри симулятора оно будет работать правильно.
Спасибо за ссылку! Уже не знаю почему, но я на проект NJ MCT в своих изысканиях не натыкался.
К сожалению, он и язык, на котором он написан, последнее время не поддерживаются.
Как я понял, проект забросили где-то в 1998 году. По меркам работ про декодеры это не так уж давно. Вот то, что проект написан на ML — это препятствие (для меня) посерьёзнее. Но оно тоже преодолимое, приходилось иметь дело с разными «странными» языками, да простят меня адепты оных.
Работа эта действительно примечательная. Печалит только, что презентация в папке slides на Гитхабе этого проекта совершенно чудовищная. Почти эталон того, как не следует делать презентации. Первые её две трети не по теме, только потом начинается описание построения виртуальной машины на #PF/#DF
эта система не для людей (возможно, она для инженеров Intel)
Я Вам скажу по секрету, что даже и инженеров система именования (а точнее, просто количество имён CPU/Платформ/SoC) порой вводит в ступор. Представьте, что у каждого кодового имени ещё может быть трёхбуквенная аббревиатура, и надо в голове держать соответствие первого и второго!
При этом, по-моему, эта проблема не отдельной компании, а всей индустрии в целом.
Дело тут в сумасшедшем темпе разработки SoC, при котором что-то новое надо выкатывать каждые несколько месяцев.
Отмечу, что все эти имена (Silvermont, Merryfield, Bay Trail...) в конце концов, как раз для гиков и разработчиков ПО. На прилавок всё это выходит под фиксированной торговой маркой, коих используется гораздо меньше. Вот Intel® Atom™ — это торговая марка, и именно такая нашлёпка будет на коробке/устройстве.
В конце концов, конечному потребителю важно знать время работы от батареи, скорость приложений, диагональ дисплея, а не техпроцесс, особенности работы предсказателя переходов и стоимость кэш-миссов. Ну и бренды, связанные с продуктом, конечно тоже важны. Я вот, например, совершенно не знаю, какой чипсет/проц у меня в планшете — мне просто лень гуглить. Но надпись «Intel Atom» на задней крышке у него имеется. Как только я захочу писать для него приложения, я не поленюсь, зайду на ARK и выясню детали архитектуры.
Например, глядя на Y14T9nG7W11S4, можно будет сразу сказать
Я боюсь, что ни один маркетолог не пропустит что-то типа Y14T9nG7W11S4, т.к. это очень похоже на шифровку Юстас-Алекс. То есть это опять же для гиков.
В каком документе перечислены все имеющиеся архитектуры Intel? :-)
Немножко придерусь к словам. Если Вам интересны именно «архитектуры», т.е. видимые системному программисту абстракции и связанные с ними наборы команд, то их не очень много, и ещё меньше из них ныне здравствуют. Поддерживаются, наверное, только Itanium и IA-32, но я не выяснял точно. Остальные уже упомянуты в этом треде: 4004, 8008, iAPX 432 и т.д. Забыли, правда, про StrongARM/XScale.
Если же подразумевались «микроархитектуры», т.е. внутренние реализации архитектур, то обычно эту их имена не используют для целей рекламы. По крайней мере с именами микроархитектур не ассоциируют предлагаемые функциональные особенности/преимущества. Для этих нужд используют маркетинговое имя, вроде Intel® Core (tm). Просто для того, чтобы оставить за собой пространство для манёвра, типа «вот описание архитектуры, а как она сделана внутри — это может поменяться без предварительного уведомления». Список микроархитектур для IA-32 ну очень длинный, я вынужден снова отослать интересующихся в Википедию.
Кстати, официальная база данных для сравнения выпущенных продуктов Intel называется ARK. С датами выхода, поддерживаемыми наборами команд, размерами и рекомендуемой ценой для партии. Есть даже Андроид приложение :-)
«Intel Core i7» — это торговая марка, которая используется Intel уже для ряда продуктов, основанных на различных микроархитектурах и техпроцессах: Nehalem, Westmere, Sandy Bridge, Ivy Bridge, Haswell (вроде ничего не забыл).
Смешивать Core i7 разных поколений — это примерно то же самое, что считать, что Pentium и Pentium IV — это примерно одно и то же. Или считать что Intel Xeon (тоже торговая марка) времён Pentium II — это почти равно Intel Xeon выпуска 2012 года.
Разговоры про «жёсткость» модели памяти — это очень тонкий вопрос и, честно говоря, не связанный с OoO напрямую. Если под «жёсткостью» IA-32 подразумевается т.н. sequential consistency, то это не так. Официальная спецификация (Intel IA-32 SDM, том 3А, секция 8.2.2) описывает ситуации, когда чтения и записи могут быть переупорядочены. Вот, приведу полный список.
Для однопроцессорных систем:
• Reads are not reordered with other reads.
• Writes are not reordered with older reads.
• Writes to memory are not reordered with other writes, with the following exceptions:
— writes executed with the CLFLUSH instruction;
— streaming stores (writes) executed with the non-temporal move instructions (MOVNTI, MOVNTQ,
MOVNTDQ, MOVNTPS, and MOVNTPD); and
— string operations (see Section 8.2.4.1).
• Reads may be reordered with older writes to different locations but not with older writes to the same location.
• Reads or writes cannot be reordered with I/O instructions, locked instructions, orserializing instructions.
• Reads cannot pass earlier LFENCE and MFENCE instructions.
• Writes cannot pass earlier LFENCE, SFENCE, and MFENCE instructions.
• LFENCE instructions cannot pass earlier reads.
• SFENCE instructions cannot pass earlier writes.
• MFENCE instructions cannot pass earlier reads or writes.
Для многопроцессорных систем:
• Individual processors use the same ordering principles as in a single-processor system.
• Writes by a single processor are observed in the same order by all processors.
• Writes from an individual processor are NOT ordered with respect to the writes from other processors.
• Memory ordering obeys causality (memory ordering respects transitive visibility).
• Any two stores are seen in a consistent order by processors other than those performing the stores
• Locked instructions have a total order.
Для того, чтобы при необходимости запретить переупорядочивание доступов в память, были введены инструкции LFENCE, SFENCE и MFENCE.
Вот кстати давно хотел узнать: а почему нет единого документа, в котором было бы нарисовано когда вышла та или иная архитектура, какие новые фичи и наборы команд появились
Пожалуй, самая полная историческая справка о датах выхода и доступности разных фич в процессорах доступна в Википедии, как это ни удивительно. Про единый документ — чуть ниже.
как через CPUID эту архитектуру определить
Какой бит используется в CPUID для индикации наличия определённой инструкции или класса инструкций всегда можно понять из описания инструкции в мануале Intel SDM. Например, для ANDN из расширения BMI1:
Далее смотрим в том же мануале (может быть, в другом его томе), что ассоциируется с флагом BMI1 в CPUID.
В итоге о BMI2 я узнал совершенно случайно
Есть такой интересный документ: Intel® Architecture Instruction Set Extensions Programming Reference. В нём описываются инструкции, ещё не включенные в реальную продукцию, но планируемые быть доступными в не столь далёком будущем. Обновляется он достаточно часто (я один раз обнаружил, что имею у себя устаревшую локальную версию и из-за этого не в курсе, что вообще происходит). Его части со временем переезжают в Intel SDM, когда инструкции перестают быть «новыми». Очень полезный документ для писателей компиляторов, симуляторов и других программистов системного уровня.
Мне кажется, что в этой фразе выпущено «не». Должно читаться:
Или я неправильно понял параграф про TBB?
У каждого понятия «красоты» и «чистоты» свои. Понятия «простота разработки/поддержки» и «скорость работы» более объективны.
Сразу всплывающие проблемы для Вашего примера кода.
1. Он теперь только для ARM. Если бы этот пример был для IA-32 — та же проблема: код оказывается только для одной архитектуры. У меня были проблемы при попытке переноса огромной массы кода, написанной на асме (ядро двоичного транслятора) даже для случая IA-32 -> Intel 64. Вроде бы одно является развитием другого, а вот фиг асм переиспользуешь.
2. Поправьте меня, если мои знания устарели, но у ARM всего один вид SIMD — это 128-битный NEON. У Интеловской же архитектуры за всё время накопилось векторных расширений: 64-битный MMX, 128-битный SSE/SSE2/SSE3/SSE4.1/SSE4.2, 128-битный AVX, 256-битный AVX2. А на MIC'ах уже есть 512-битный AVX3.x. И для какой же ширины регистров и набора инструкций писать асм в таком случае, если у пользователя может оказаться совершенно разное железо (разве что MMX можно уже забыть как страшный сон)? Придётся писать 3-4 варианта всех процедур на асме. Я бы предпочёл, чтобы это за меня сделал компилятор.
Ссылка
Более того, для программ на Cilk определена «сериальная элизия» (serial elision) — результат работы параллельной программы эквивалентен одному из исполнений её последовательного «близнеца», в котором такие директивы, как spawn, cilk_for заменены на вызов функции и обыкновенный for.
Вы скажете: «А как же программы, которые используют генератор (псевдо)случайных чисел?». Для этого случая для Cilk реализован быстрый параллельный детерминированный генератор псевдослучайных чисел (прочтите внимательно все определения, чтобы впечатлиться). Статья, описывающая, как это работает, за авторством Чарльза Лейзерсона (один из авторов «Introduction to Algorithms»): Deterministic Parallel Random-Number
Generation for Dynamic-Multithreading Platforms
Такое случалось в истории. Такие слова, как «капрон», «героин» и т.д. Я был очень удивлён, узнав совсем недавно, что «термос» — это тоже торговая марка! Обратный пример: компания Google отказала Оксфордскому словарю во включении глагола «to google» в словарь по тем же самым причинам.
По этой причине сотрудников любой компании обязуют в публичных коммуникациях обозначать торговые марки во этими дурацкими символами. Потому что если уж даже члены компании не защищают торговую марку, и есть документальные подтверждения в виде постов на форумах, то в суде при случае отстоять ничего не получится.
Хороший вопрос. Одна из областей их использования — разработка ПО до доступности железа, а точнее, совместная разработка (software/hardware codevelopment). Например, запуск Андроида для ARM с помощью SDK от Google на обыкновенном ПК c процессором IA-32 — это использование симуляции. Другой пример — Intel SDE и Wind River Simics включают в себя поддержку будущих инструкций Intel, и на них можно тестировать своё ПО заранее. Третий пример — Apple Rosetta, слой совместимости для PowerPC, который был использован при переводе Макинтошей на архитектуру Intel для того, чтобы старые приложения работали без перекомпиляции.
Разработка Firmware, BIOS, UEFI-прошивок, драйверов, компиляторов для новых архитектур ведётся на симуляторах и позволяет к моменту доступности первых железок иметь уже что-то более-менее отлаженное со стороны софта. Всё вместе — укорачивает цикл разработки и приближает момент выхода продукта на рынок.
Даже некоторые осторожные оценочные предсказания производительности можно получить на функциональной модели. Конечно, они будут далеки от той точности, которую дают потактовые модели. Но скорость работы функциональной симуляции иногда важнее.
Я планирую в ближайшее время опубликовать ещё одну заметку про симуляцию, там будет дан пример того, когда точности функциональных моделей хватает, чтобы сэкономить на числе сожжённых чайников.
В таких случаях это означает, что исходные приложения были написаны с завязкой на определённые значения длительностей некоторых операций, т.н. «синхронизация на sleep'ах». В таком случае симулятор должен моделировать задержки ключевых операций достаточно точно, чтобы гостевое приложение «не заметило» обмана. Для создателя модели это часто превращается в жуткую мороку, т.к. подобные аспекты работы железа могут не быть отражены в спецификациях.
То, что модель — это интерпретатор или ДТ, в принципе не определяет того, будут лаги или нет. Симулируемое время и время реальное связаны с друг другом только одним фактом: они оба монотонно возрастают. При условии, что симулятор написан честно и сам не использует «синхронизацию на sleep'ах».
В целом есть такой принцип: «корректные программы легко симулировать» — если ПО написано только на основе спецификаций, не использует информацию о длительностях операций и т.п., то внутри симулятора оно будет работать правильно.
Как я понял, проект забросили где-то в 1998 году. По меркам работ про декодеры это не так уж давно. Вот то, что проект написан на ML — это препятствие (для меня) посерьёзнее. Но оно тоже преодолимое, приходилось иметь дело с разными «странными» языками, да простят меня адепты оных.
Я Вам скажу по секрету, что даже и инженеров система именования (а точнее, просто количество имён CPU/Платформ/SoC) порой вводит в ступор. Представьте, что у каждого кодового имени ещё может быть трёхбуквенная аббревиатура, и надо в голове держать соответствие первого и второго!
При этом, по-моему, эта проблема не отдельной компании, а всей индустрии в целом.
Дело тут в сумасшедшем темпе разработки SoC, при котором что-то новое надо выкатывать каждые несколько месяцев.
Отмечу, что все эти имена (Silvermont, Merryfield, Bay Trail...) в конце концов, как раз для гиков и разработчиков ПО. На прилавок всё это выходит под фиксированной торговой маркой, коих используется гораздо меньше. Вот Intel® Atom™ — это торговая марка, и именно такая нашлёпка будет на коробке/устройстве.
В конце концов, конечному потребителю важно знать время работы от батареи, скорость приложений, диагональ дисплея, а не техпроцесс, особенности работы предсказателя переходов и стоимость кэш-миссов. Ну и бренды, связанные с продуктом, конечно тоже важны. Я вот, например, совершенно не знаю, какой чипсет/проц у меня в планшете — мне просто лень гуглить. Но надпись «Intel Atom» на задней крышке у него имеется. Как только я захочу писать для него приложения, я не поленюсь, зайду на ARK и выясню детали архитектуры.
Я боюсь, что ни один маркетолог не пропустит что-то типа Y14T9nG7W11S4, т.к. это очень похоже на шифровку Юстас-Алекс. То есть это опять же для гиков.
Немножко придерусь к словам. Если Вам интересны именно «архитектуры», т.е. видимые системному программисту абстракции и связанные с ними наборы команд, то их не очень много, и ещё меньше из них ныне здравствуют. Поддерживаются, наверное, только Itanium и IA-32, но я не выяснял точно. Остальные уже упомянуты в этом треде: 4004, 8008, iAPX 432 и т.д. Забыли, правда, про StrongARM/XScale.
Если же подразумевались «микроархитектуры», т.е. внутренние реализации архитектур, то обычно эту их имена не используют для целей рекламы. По крайней мере с именами микроархитектур не ассоциируют предлагаемые функциональные особенности/преимущества. Для этих нужд используют маркетинговое имя, вроде Intel® Core (tm). Просто для того, чтобы оставить за собой пространство для манёвра, типа «вот описание архитектуры, а как она сделана внутри — это может поменяться без предварительного уведомления». Список микроархитектур для IA-32 ну очень длинный, я вынужден снова отослать интересующихся в Википедию.
Кстати, официальная база данных для сравнения выпущенных продуктов Intel называется ARK. С датами выхода, поддерживаемыми наборами команд, размерами и рекомендуемой ценой для партии. Есть даже Андроид приложение :-)
Смешивать Core i7 разных поколений — это примерно то же самое, что считать, что Pentium и Pentium IV — это примерно одно и то же. Или считать что Intel Xeon (тоже торговая марка) времён Pentium II — это почти равно Intel Xeon выпуска 2012 года.
Для однопроцессорных систем:
• Reads are not reordered with other reads.
• Writes are not reordered with older reads.
• Writes to memory are not reordered with other writes, with the following exceptions:
— writes executed with the CLFLUSH instruction;
— streaming stores (writes) executed with the non-temporal move instructions (MOVNTI, MOVNTQ,
MOVNTDQ, MOVNTPS, and MOVNTPD); and
— string operations (see Section 8.2.4.1).
• Reads may be reordered with older writes to different locations but not with older writes to the same location.
• Reads or writes cannot be reordered with I/O instructions, locked instructions, orserializing instructions.
• Reads cannot pass earlier LFENCE and MFENCE instructions.
• Writes cannot pass earlier LFENCE, SFENCE, and MFENCE instructions.
• LFENCE instructions cannot pass earlier reads.
• SFENCE instructions cannot pass earlier writes.
• MFENCE instructions cannot pass earlier reads or writes.
Для многопроцессорных систем:
• Individual processors use the same ordering principles as in a single-processor system.
• Writes by a single processor are observed in the same order by all processors.
• Writes from an individual processor are NOT ordered with respect to the writes from other processors.
• Memory ordering obeys causality (memory ordering respects transitive visibility).
• Any two stores are seen in a consistent order by processors other than those performing the stores
• Locked instructions have a total order.
Для того, чтобы при необходимости запретить переупорядочивание доступов в память, были введены инструкции LFENCE, SFENCE и MFENCE.
Пожалуй, самая полная историческая справка о датах выхода и доступности разных фич в процессорах доступна в Википедии, как это ни удивительно. Про единый документ — чуть ниже.
Какой бит используется в CPUID для индикации наличия определённой инструкции или класса инструкций всегда можно понять из описания инструкции в мануале Intel SDM. Например, для
ANDNиз расширения BMI1:Далее смотрим в том же мануале (может быть, в другом его томе), что ассоциируется с флагом BMI1 в CPUID.
Есть такой интересный документ: Intel® Architecture Instruction Set Extensions Programming Reference. В нём описываются инструкции, ещё не включенные в реальную продукцию, но планируемые быть доступными в не столь далёком будущем. Обновляется он достаточно часто (я один раз обнаружил, что имею у себя устаревшую локальную версию и из-за этого не в курсе, что вообще происходит). Его части со временем переезжают в Intel SDM, когда инструкции перестают быть «новыми». Очень полезный документ для писателей компиляторов, симуляторов и других программистов системного уровня.
Анонсы новых наборов случаются, кстати, и делаются на сайте Intel Developer Zone. Например, для Intel Haswell New Instructions, Intel RTM.