на счет RISCa все вы правильно описали но все это следствие фиксированой длины команды которая ограничела набор команд и заставила выбрать только простые и элементарные которые в свою очередь требуют меньше транзисторов фиксированый размер дал возможность уменьшитьшину адрессов для команд ... не намного, а 1,2 (сегодня на 3) разряда но это относительно длиные пути в чипе а максимальная частота чипа ограничиваеться самым длинным соеденением задействованым в процессе. по той же причине удлиняют конвеер, разбивают на простые этапы что бы уменьшить схему и сократить пути. первые армы были с 3мя этапами, потом долгое время с 5ю теперь 13 ... кстти у этого подхода есть недостатки :-) вспомним чем 21 (кажеться)этапный обернулся для П4 ... и более современные проблемы с предзагрузкой команд.
Интел давно уже внутри работает как RISC и запускает микрокод. а его попытка с Itanium ... долго низенько летела , но взлетела ...
я так же имел дело с Xeon Phy , первой версии на отдельной карте отличный был процессор было много энтузиазма вокруг нео с некоторыми упрощениями можно сказать это был массив Atom ядер каждое из которых поддерживало Hyperthreading если я не ошибаюсь у меня была версия с 64 или 128 ядрами каждый был самостоятелным, на каждом бежал х86 код ... но ... они не завезли туда (в целях экономии) ни ММХ ни SSE и все , мир не принял :-) (как и фирма где я работал) недают Интелу слезть с их наборов инструкций его берут только для совместимости как с существуюшим софтом так и знаниями програмистов :-) вот смениться поколениЯ :-) и все интелу крышка
есть разница между инструкцией с расширеным функционалом и акселератором расположеном на одной подложке. может быть разница не очень заметна но она есть.
да раньше работа с акселерарором выгляделала как запись особого значения в специальный адресс , как будто запись в память сегодня добавления intrinsics в комиляторы стало обыденным делом и то что выглядит как ассемблерная инструкция не обязательно являеться таковой.
как реализовано у Apple я не знаю, они предоставляют высокоурвневые API из которых точно не возможно понять детали без дизассемблирования кода. так же Neural Engine наверное выполняет больше функций чем просто AMX я предпопагаю что там так же армовские ядра типа Cortex Mx с различными акселераторами и да именно тесная интеграция и использование одних кешей позволяет им добиться лучшей производительности но это точно также верно и для AMX.
ну и ... основная разница между RISC и CISC это размер машинной инструкции у риска она посноянная у сиска переменная все остальны различия и особенности вытикают только из этой особенности в этом плане Интелы попрежнему CISC а все Армы RISC.
но интелы отстают по производительности не поэтому они тащят за собой огромный хвост легаси поддержек. где была информация что до 40% площади чипа нужны только для этой подержки. как только кто то у них решиться обрубить этот хвост - они "побегут" :-) но мне не вериться что они способны на это ...
"2. The next section in the code is to to invoke a Linux system call to request access to Intel® AMX features. This is performed using the arch_prctl(2) based mechanism for applications to request usage of the Intel® AMX features. Specific information is described in the Linux kernel documentation. "
добавление акселераторов делает ли из RISC CISC ? xм .... не уверен :-) MMX, SSE , NEON , SVE - все это акселераторы :-) да таже nvidia с тенсорами. а вот перегонка данных между процессорами очень затратное действие особенно в сегодняшней PC aрхитектуре. не зря Apple сделала свой чип
смею предположить что матричные регистры вообще не сохраняються при переключении, а содаеться очередь команд от разных контекстов. и если существует несколько пытающихся использовать AMX они ждут друг друга, один поток выполнил часть , результат сохранился в L1/L2 и другой получит время , и все это на железном уровне. хм (мысли в слух) получаеться как с hyperthreading. вот только особого практического смыла в этом мне не видиться
я так понимаю эти все расширения с родни нвидиовским tensor core ? есть ли информация сколько АМХ у интелов ? у каждого ядра или нет ? как они работают с hyperthreading ? что на счем AMD CPU ?
я вижу еще один способ личного использования например в местах где запрещают использование LLM и физически закрывают к ним доступ ;-) но можно принести свой лэптоп :-) и на нем гонять персонального асистента :-) даже если он будет без доступа в интернет :-)
то есть можно прикупить RTX 4070 16G и использовать его для реальной работы с финансовой точки зрения это не выгодно но за приватность и автономность не сильно завышаная плата :-)
я не физик :-) но смею предположить например как в кинескопах отклоняют пучек электронов
так и тут возможно можно отклонять магнитное поле или луч лазера с помощью электроной линзы
или например магнитная головка которая под воздействием электрического заряда меняет форму (как линза) и изза этого может измерять магнитное поле в другой точке
я предполагаю что головка читает строго под собой как бы фокусируясь но кто мешает электрическим способом сделать фокус на нанометр в сторону
ну и да в крайнем случае напечать 128 трилионов головок раз возможно спозиционировать одну головку с точностью до нанометра и считывать на скорости пролетающие под ней биты ... то почему их просто не напечатать в таком количестве
а ненадо регулировать высоту полета , полета ведь не будет :-) управлять лучем/потоком (ой незнаю чем еше там) с помошью электричества что бы одна головка могла считать все на площади под ней без механического перемещения лет наверное 20 назад у IBM был прототип носителя основаный на физическом прокалывании какой то пленки с последущим востановлением отверстий, есть отверстие 1 нет 0 :-) и делали они это сразу большой матрицей так сказать "иголок" мне кажеться к этому прийдет блин для хранение блин для считывания сэнгвичем назовут :-)
а что мешает в HDD избавиться от механической составляющей (кроме цены) вместо перемещения одной головки сделать матрицу головок для всех положений навярняка можно сделать оптическое управление , и использовать один и тот же лазер для смежных ячеек да еще чтение и запись можно разпаралелить , возрастет скорость
пробежал бегло по тексту глаз зацепился за 2 утверждения
""При использовании pthread из набора стандартной библиотеки С glibc в Linux доступен богатый выбор примитивов синхронизации: мьютексы, условные переменные, спинлоки и барьеры, которые обычно редко где используются в коде на С ""
что значит редко ... по надобности использутся, если аппликация multithreaded то без них нельзя и да, как говориться в С так носят, конечно сегодня выбор С для написания чего либо не всегда очевиден, но когда кроме него ничего не было , по другому и нельзя. Все эти примитивы широко используются везде и всегда
"Используя даже самые простые механизмы в виде базовых примитивов синхронизации, предоставляемых операционной системой и стандартной библиотекой языка С, можно проектировать и создавать достаточно гибкие в плане функциональности многопоточные приложения. "
все языки в итоге компилирутся/интерпретируються и работают на конкретной опреционой системе и ничем кроме того что операционная система предостволяет пользоваться не могут .. примитивы С максимально приближены к ОС все остальное реализовано через них и поверх них так что Go тоже пользуеться ими же
смотря как понимать "использует" как фирма для своей работы - нет не использует как фирма поддерживающая опен соурс сообшества , ну да как бы не усложняет жизнь :-) ведь вроде "весь мир" пользуеться гитом ;-) и можно даже сказать , что хорошо , что не стали навязывать всем меркуриал a могли и на sourceforge там кажеться раньше SVN был :-)
скажем так ... я точно знаю что такие проэкты как folly и buck живут "2ой жизнью" в 2х репозиториях и да надо подтягивать PR если они интересны так же как и обратно релизать из меркуриала в гит но так как в Мете живут на монорепо, вред ли им хочеться не контролируемый "шум" из сообщества :-)
конечно не умерла но сильно видоизменилась
раньше за проценты боролись
сегодня в разу подавай иначе время вложенное в оптимизацию не выгодно :-)
на счет RISCa все вы правильно описали
но все это следствие фиксированой длины команды
которая ограничела набор команд
и заставила выбрать только простые и элементарные
которые в свою очередь требуют меньше транзисторов
фиксированый размер дал возможность уменьшитьшину адрессов для команд ... не намного, а 1,2 (сегодня на 3) разряда
но это относительно длиные пути в чипе
а максимальная частота чипа ограничиваеться самым длинным соеденением задействованым в процессе.
по той же причине
удлиняют конвеер, разбивают на простые этапы что бы уменьшить схему и сократить пути.
первые армы были с 3мя этапами, потом долгое время с 5ю
теперь 13 ...
кстти у этого подхода есть недостатки :-) вспомним чем 21 (кажеться)этапный обернулся для П4 ...
и более современные проблемы с предзагрузкой команд.
Интел давно уже внутри работает как RISC и запускает микрокод.
а его попытка с Itanium ... долго низенько летела , но взлетела ...
я так же имел дело с Xeon Phy , первой версии на отдельной карте
отличный был процессор
было много энтузиазма вокруг нео
с некоторыми упрощениями
можно сказать это был массив Atom ядер каждое из которых поддерживало Hyperthreading
если я не ошибаюсь у меня была версия с 64 или 128 ядрами
каждый был самостоятелным, на каждом бежал х86 код ...
но ... они не завезли туда (в целях экономии) ни ММХ ни SSE
и все , мир не принял :-)
(как и фирма где я работал)
недают Интелу слезть с их наборов инструкций
его берут только для совместимости
как с существуюшим софтом так и знаниями програмистов :-)
вот смениться поколениЯ :-) и все интелу крышка
может тогда не RGB a NV12. это в 1.5 раза меньше данных :-)
вроде не должно быть переноса RGB туда сюда
так как указан для декодера -hwaccel_output_format_cuda
используеться scale_cuda а потом опять h264_nvenc
есть разница между инструкцией с расширеным функционалом и акселератором расположеном на одной подложке.
может быть разница не очень заметна но она есть.
да раньше работа с акселерарором выгляделала как запись особого значения в специальный адресс , как будто запись в память
сегодня добавления intrinsics в комиляторы стало обыденным делом
и то что выглядит как ассемблерная инструкция не обязательно являеться таковой.
как реализовано у Apple я не знаю, они предоставляют высокоурвневые API из которых точно не возможно понять детали без дизассемблирования кода.
так же Neural Engine наверное выполняет больше функций чем просто AMX
я предпопагаю что там так же армовские ядра типа Cortex Mx с различными акселераторами
и да именно тесная интеграция и использование одних кешей позволяет им добиться лучшей производительности
но это точно также верно и для AMX.
вот другой примет NEON у ARM
только у RISC части есть instruction fetch и decode
кооторый используеться для всех инструкций в том числе NEONoвских
но разных частей процессора dаже разные длины конвееров
у RISC - 13
у NEON - 10
и на самом деле NEON это DSP aксселератор тестно интегрированый в процессор
https://en.wikipedia.org/wiki/ARM_Cortex-A8
на 3тей странице картинка
https://web.archive.org/web/20150101062932/http://www.arm.com/files/pdf/A8_Paper.pdf
ну и ... основная разница между RISC и CISC это
размер машинной инструкции
у риска она посноянная у сиска переменная
все остальны различия и особенности вытикают только из этой особенности
в этом плане Интелы попрежнему CISC
а все Армы RISC.
но интелы отстают по производительности не поэтому
они тащят за собой огромный хвост легаси поддержек.
где была информация что до 40% площади чипа нужны только для этой подержки.
как только кто то у них решиться обрубить этот хвост - они "побегут" :-)
но мне не вериться что они способны на это ...
не совсем
выполнение любой ассемблерной команды может зависить от предыдущих и pipeline может так сказать замереть.
но в случае с Intel AMX судя по всему произходит как вы предположили : через syscal
https://www.intel.com/content/www/us/en/developer/articles/code-sample/advanced-matrix-extensions-intrinsics-functions.html
"2. The next section in the code is to to invoke a Linux system call to request access to Intel® AMX features. This is performed using the arch_prctl(2) based mechanism for applications to request usage of the Intel® AMX features. Specific information is described in the Linux kernel documentation. "
добавление акселераторов делает ли из RISC CISC ? xм .... не уверен :-)
MMX, SSE , NEON , SVE - все это акселераторы :-)
да таже nvidia с тенсорами.
а вот перегонка данных между процессорами очень затратное действие
особенно в сегодняшней PC aрхитектуре.
не зря Apple сделала свой чип
смею предположить что матричные регистры вообще не сохраняються при переключении, а содаеться очередь команд от разных контекстов. и если существует несколько пытающихся использовать AMX они ждут друг друга, один поток выполнил часть , результат сохранился в L1/L2 и другой получит время , и все это на железном уровне. хм (мысли в слух) получаеться как с hyperthreading. вот только особого практического смыла в этом мне не видиться
я так понимаю эти все расширения с родни нвидиовским tensor core ?
есть ли информация сколько АМХ у интелов ? у каждого ядра или нет ?
как они работают с hyperthreading ?
что на счем AMD CPU ?
домашние пользпватели все одинаковые
во всех старнах и на всех континентах
и не важна технология подключения к интернету
АDSL или оптоволокно
я вижу еще один способ личного использования
например в местах где запрещают использование LLM и физически закрывают к ним доступ ;-)
но можно принести свой лэптоп :-)
и на нем гонять персонального асистента :-)
даже если он будет без доступа в интернет :-)
то есть можно прикупить RTX 4070 16G и использовать его для реальной работы
с финансовой точки зрения это не выгодно
но за приватность и автономность не сильно завышаная плата :-)
если ли где то сравнение скорости работы на локальном железе ?
я не физик :-)
но смею предположить например как в кинескопах отклоняют пучек электронов
так и тут возможно можно отклонять магнитное поле
или луч лазера с помощью электроной линзы
или например магнитная головка которая под воздействием электрического заряда меняет форму (как линза)
и изза этого может измерять магнитное поле в другой точке
я предполагаю что головка читает строго под собой как бы фокусируясь
но кто мешает электрическим способом сделать фокус на нанометр в сторону
ну и да в крайнем случае напечать 128 трилионов головок
раз возможно спозиционировать одну головку с точностью до нанометра
и считывать на скорости пролетающие под ней биты ...
то почему их просто не напечатать в таком количестве
а ненадо регулировать высоту полета , полета ведь не будет :-)
управлять лучем/потоком (ой незнаю чем еше там) с помошью электричества
что бы одна головка могла считать все на площади под ней без механического перемещения
лет наверное 20 назад у IBM был прототип носителя основаный на физическом прокалывании какой то пленки с последущим востановлением отверстий, есть отверстие 1 нет 0 :-)
и делали они это сразу большой матрицей так сказать "иголок"
мне кажеться к этому прийдет
блин для хранение блин для считывания
сэнгвичем назовут :-)
а что мешает в HDD избавиться от механической составляющей (кроме цены)
вместо перемещения одной головки
сделать матрицу головок для всех положений
навярняка можно сделать оптическое управление , и использовать один и тот же лазер для смежных ячеек
да еще чтение и запись можно разпаралелить , возрастет скорость
я имел ввиду что примитивы С и примитивы ОС это одно и тоже
С не добаляет не убовляет ничего
пробежал бегло по тексту глаз зацепился за 2 утверждения
""При использовании
pthreadиз набора стандартной библиотеки С glibc в Linux доступен богатый выбор примитивов синхронизации: мьютексы, условные переменные, спинлоки и барьеры, которые обычно редко где используются в коде на С ""что значит редко ... по надобности использутся, если аппликация multithreaded то без них нельзя
и да, как говориться в С так носят, конечно сегодня выбор С для написания чего либо не всегда очевиден, но когда кроме него ничего не было , по другому и нельзя.
Все эти примитивы широко используются везде и всегда
"Используя даже самые простые механизмы в виде базовых примитивов синхронизации, предоставляемых операционной системой и стандартной библиотекой языка С, можно проектировать и создавать достаточно гибкие в плане функциональности многопоточные приложения. "
все языки в итоге компилирутся/интерпретируються и работают на конкретной опреционой системе
и ничем кроме того что операционная система предостволяет пользоваться не могут ..
примитивы С максимально приближены к ОС
все остальное реализовано через них и поверх них
так что Go тоже пользуеться ими же
смотря как понимать "использует"
как фирма для своей работы - нет не использует
как фирма поддерживающая опен соурс сообшества , ну да как бы не усложняет жизнь :-)
ведь вроде "весь мир" пользуеться гитом ;-)
и можно даже сказать , что хорошо , что не стали навязывать всем меркуриал
a могли и на sourceforge там кажеться раньше SVN был :-)
скажем так ... я точно знаю что такие проэкты как folly и buck живут "2ой жизнью" в 2х репозиториях
и да надо подтягивать PR если они интересны
так же как и обратно релизать из меркуриала в гит
но так как в Мете живут на монорепо, вред ли им хочеться не контролируемый "шум" из сообщества :-)