Резистор можно сделать из графитового (простого) карандаша. Если требуется высокое сопротивление, то можно плотно изрисовать лист бумаги карандашом и подключить клеммы методом прижатия с двух сторон шайбами и болтом. Собсно на производстве резисторы так и изготавливают - на пленку наносят тонкий слой графита и сворачивают её в несколько слоёв.
Прошу учесть, что RVA профиль не для микроконтроллеров, а для +/- полноценных процессоров, и в мире процессоров многие ваши умолчания могут быть просто не верны: ...
Спасибо за напоминание.
Объясните как вы видите, что наличие дополнительных инструкций влияет на прикладной код (напоминаю RVA - про процессоры, а не микроконтроллеры).Что интерфейс numpy (или BLAS или pytorch) должен измениться из-за изменения ISA?
Я правильно понимаю, что у Вас процессор общего назначения это вычислитель, который в основном занять инфёренсом нейросеток ? Так вот, поспешу разочаровать, 99.9% приложений в мире - это базы данных и сетевые стеки. Для этих пользователей совершенно класть на специальные возмоности процессора ускоряющие BLAS и pytorch!
И да, реализация BLAS потребует адаптации к новым взможностям процессора.
Или даже (глупый, но функционально не запрещённый возможный пример) - работа с векторами в обработчике сигналов?
Вы правильно прочувствовали суть проблемы, но я немного формализую Ваш ответ.
Основная проблема, с точки зрения ПО, с векторным расширением состоит в том, что оно сильно раздувает контекст, который постоянно требуется сохранять таск-свитчеру при переключении задач и обработки прерываний. В RVV есть некоторый хак позволяющий немного соптимизировать - не сохранять если не было измений состояния, но насколько он эффективен я не знаю. Именно по этой причине я считаю, что векторные вычисления должны быть вынесены в отдельный аппаратный блок, а не интегрированны в основное ядро. Т.е. с точки зрения ОС это должен быть аппартный ресурс, доступ к которому регламентируется специализированным API, по аналогии с GPU, но "потеснее". Подобным образом сделано у Apple M1,2,3.
Да банально, например, GF(2) операции, которыми ускоряют кучу вещей - от обработки изображений и до криптографии.
Во-первых, для криптографии и обработки изображений существуют специализированные процессоры, если Вы вдруг забыли. Основная задача процессора общего назначения - быстро перекладывать массивы данных с места на место и котроллировать права доступа (виртуализация памяти и ресурсов). Во вторых, все битовые операции прекрасно выражаются через две базовых - NAND и NOR, вот их и следует занести в систему команд. Ядра с ортогональной системой команд имеют кратчайшие критические пути, что позволяет разгонять их до умопомрачительных частот. На мой взгляд в этом направлении и следует развиваться, а не в наращивании системы команд и создании "неповоротливых", прожорливых вычислетелей, 90% аппаратуры которых просто простаивает без дела.
Странные инструкции для насилия над битами в процессоры ставят не для красоты, а потому что они полезны для выполнения реальных алгоритмов.
В современном мире полезность и бесполезность определяются прежде всего статистикой. Как часто эти опреции используются ? Какой процент их в смешаном коде ? Как добавление новых операций повлияет на Fmax ? На эти вопросы ответы были даны исследованиями проведенными Паттерсоном и Хеннесси в 1980-х, и повторно в 2010-х. Ответ однозначный: избыточные операции - зло! А если есть свободное место на кристалле, то гораздо эффективнее отдать его под кэш и регистры, а не под навороченные команды. Я даже не уверен, что векторные вычисления должны быть в системе команд. С моей точки зрения их целесообразней выполнить отдельным блоком (отельным вычислителем), пусть даже на том же кристалле. Дело в том, что векторных вычислителей требуется в разы меньше чем обычных многофункциональных ядер, по этому имело бы смысл делать процессоры в виде комбинации из N многофункциональных минималистичных ядер + M векторных, где M << N. big.LITTLE это как раз шаг в данном направлении.
Про площадь - ну допустим (хотя видится, что при реализации по-уму вся эта не критичная по площади комбинаторика будет о-малое занимать).
У разработчика цифровой микросхемы каждый вентиль на счету. Не понятно зачем в RVA22 втащили дополнительные битовые манипуляции и еще одну разновидность FP ? Вот это все надо ликвидировать:
• Zfhmin Half-Precision Floating-point transfer and convert.
Еще там куча всякой дряни для управления сложными кэшами. x86 как-то обходится без этого.
Если прикинуть, вся эта излишняя пурга занимает не мало места.
Ну с векторным расширением, насколько я краем уха слышал в RISC-V проблемы.
Какие, если не секрет ?
Э.... а вот это вообще не понял.Middlewaare (в виде компиляторов, ОС, платформ и библиотек - которое пишется один раз) для того и существует, чтобы писатель конечного софта этим не заморачивался.
И конечный софт и библиотеки придется адаптировать к новым инструкциям. Или Вы полагаете, что достаточно добавить поддержку в компилятор и на этом успокоиться ?
Так профиль (с набором обязательных расширений) - это же наоборот огромный шаг вперёд к унификации.
Вопрос в количестве этих расширений. Подавляющая их часть требуется для очень узконишевых приложений, но обязятельность вынуждает производителей раздувать площадь кристалла, а всех остальных - наращивать кодовую базу (ведь все эти расширения должны поддерживаться в софте). Теряется сам смысл идеи "Reduced Instruction Set Computer" за которую еще совсем недавно боролись сподвижники Паттерсона и Асановича.
Профиль RV64GC был компактный и самодостаточный. Нужно добавить в него RVV и сосредоточить усилия на микроархитекткрных решениях, а не на постоянном наращивании системы команд.
Так и есть, это саботаж. Не даром китайцы послали лесом весь этот сброд и начали пилить свою RISC-X как вариант RISC-V с некоторыми изменениями. Несколько лет назад я еще думал зачем они это делают, ведь это лишает их совместимости с огромной базой софта и компиляторов. Теперь всё стало понятно.
О боже, что они сделали с некогда стройной, выверенной, минималистичной архитектурой.
Зачем вам этот кадавр ? Зачем вам миллиард бесполезных расширений, да еще и обязательных к имплементации ? Почему нельзя остановиться на RV64CG + RVV 1.0, спроектировать и изготовить высокопроизводительный микропроцессор который бы уделал все существующие процы на x86 и ARM ? Кто-то должен остановить этот конгломерат бюрократов!
сейчас буквально любая usb-сетевуха работает с буквально любым телефоном
Сейчас это когда ? На какой версии Android ? Автор показал почему оно НЕ работает на его устройстве (Samsung Galaxy S20, Android 13). Возможно, в более новых версия Android либо исправили regexp определяющий имя сетевого интерфейса (добавили что-то типа \|usb\\d), либо ядро Linux сконфигурировали так, чтобы всем сетевым интерфейсам присваивалось имя вида eth?. На ядре linux 6.x сетевому интерфейсу устройства CDC Ethernet Gadget всё еще присваивается имя usb? поумолчанию. Подозреваю, что это можно настроить в Device-Tree без перекомпиляции ядра.
В приведенной Вами таблице указаны результаты тестов на системе, а не "голого" процессора. Известно, что у Apple II видеоподсистема (как и у C64, или у Atari 800) останавливает центральный процессор при обновлении кадра, что занимает почти половину времени. Еще один момент состоит в том, что в Apple II использовалась динамическая память, которая требует циклов регенерации в процессе выполнения которых она недоступна и процессор простаивает в ожидании. Вы же проводите замеры чистого процессора без внешних раздражителей на статической памяти.
Известно, что i8080 в среднем выполняет 0.125 млн операций в секунду на частоте 1 МГц. Для MOS 6502 этот показатель равен 0.45 млн, т.е. в три с половиной раза больше. Однако у i8080 больше регистров, но у 6502 первая страница памяти (256 байт) может использоваться как таблица указателей, что существенно ускоряет вычисления. В итоге выиграет тот бенчмарк, который более тщательно адаптирован под специфику процессора и конкретной вычислительной системы. :-)
И все экспериментаторы остались с целыми руками-глазами, надеюсь?
Вот это один из парадоксов жизни. В моём детстве абсолютно всё было небезопасным, даже игры. И я не припомню, чтобы кто-то из нас сильно повредился или попал в больницу с отравлением или травмами. Да, были небольшие ожоги (свинец неудачно выплавил на ногу), вывихи стопы (после плыжка из окна 2-го этажа на стройке), стопу гвоздем проколо когда лазил по помойкам в поисках радиодеталей... но в целом все живы и здоровы по сей день. Сейчас же всё окружено заборами и суровыми законами, а толку никакого. Дети не умеют перелезть забор или залезть на дерево чтобы яблоко достать. :-)
Все мы с детства знаем, что нитроглицерин крайне вырывоопасен. Но почему в аптеке продают таблетки "нитроглицерин" без ограничений и почему они не вызрываются ? Этот вопрос беспокоил любого советсткого школьника с младших классов, для меня он и по сей день остается без ответа. ;)
Резистор можно сделать из графитового (простого) карандаша. Если требуется высокое сопротивление, то можно плотно изрисовать лист бумаги карандашом и подключить клеммы методом прижатия с двух сторон шайбами и болтом. Собсно на производстве резисторы так и изготавливают - на пленку наносят тонкий слой графита и сворачивают её в несколько слоёв.
Еще один способ - смачить бумагу солёной водой.
Рисованный резистор из бумаги
Спасибо за напоминание.
Я правильно понимаю, что у Вас процессор общего назначения это вычислитель, который в основном занять инфёренсом нейросеток ? Так вот, поспешу разочаровать, 99.9% приложений в мире - это базы данных и сетевые стеки. Для этих пользователей совершенно класть на специальные возмоности процессора ускоряющие BLAS и pytorch!
И да, реализация BLAS потребует адаптации к новым взможностям процессора.
Вы правильно прочувствовали суть проблемы, но я немного формализую Ваш ответ.
Основная проблема, с точки зрения ПО, с векторным расширением состоит в том, что оно сильно раздувает контекст, который постоянно требуется сохранять таск-свитчеру при переключении задач и обработки прерываний. В RVV есть некоторый хак позволяющий немного соптимизировать - не сохранять если не было измений состояния, но насколько он эффективен я не знаю. Именно по этой причине я считаю, что векторные вычисления должны быть вынесены в отдельный аппаратный блок, а не интегрированны в основное ядро. Т.е. с точки зрения ОС это должен быть аппартный ресурс, доступ к которому регламентируется специализированным API, по аналогии с GPU, но "потеснее". Подобным образом сделано у Apple M1,2,3.
Во-первых, для криптографии и обработки изображений существуют специализированные процессоры, если Вы вдруг забыли. Основная задача процессора общего назначения - быстро перекладывать массивы данных с места на место и котроллировать права доступа (виртуализация памяти и ресурсов). Во вторых, все битовые операции прекрасно выражаются через две базовых - NAND и NOR, вот их и следует занести в систему команд. Ядра с ортогональной системой команд имеют кратчайшие критические пути, что позволяет разгонять их до умопомрачительных частот. На мой взгляд в этом направлении и следует развиваться, а не в наращивании системы команд и создании "неповоротливых", прожорливых вычислетелей, 90% аппаратуры которых просто простаивает без дела.
В современном мире полезность и бесполезность определяются прежде всего статистикой. Как часто эти опреции используются ? Какой процент их в смешаном коде ? Как добавление новых операций повлияет на Fmax ? На эти вопросы ответы были даны исследованиями проведенными Паттерсоном и Хеннесси в 1980-х, и повторно в 2010-х. Ответ однозначный: избыточные операции - зло! А если есть свободное место на кристалле, то гораздо эффективнее отдать его под кэш и регистры, а не под навороченные команды. Я даже не уверен, что векторные вычисления должны быть в системе команд. С моей точки зрения их целесообразней выполнить отдельным блоком (отельным вычислителем), пусть даже на том же кристалле. Дело в том, что векторных вычислителей требуется в разы меньше чем обычных многофункциональных ядер, по этому имело бы смысл делать процессоры в виде комбинации из N многофункциональных минималистичных ядер + M векторных, где M << N. big.LITTLE это как раз шаг в данном направлении.
Который в конечном счете выдаст 42 ?
Можно подробностей каких именно операций не хватает ?
У разработчика цифровой микросхемы каждый вентиль на счету. Не понятно зачем в RVA22 втащили дополнительные битовые манипуляции и еще одну разновидность FP ? Вот это все надо ликвидировать:
• Zba Address computation.
• Zbb Basic bit manipulation.
• Zbs Single-bit instructions.
• Zfhmin Half-Precision Floating-point transfer and convert.
Еще там куча всякой дряни для управления сложными кэшами. x86 как-то обходится без этого.
Если прикинуть, вся эта излишняя пурга занимает не мало места.
Какие, если не секрет ?
И конечный софт и библиотеки придется адаптировать к новым инструкциям. Или Вы полагаете, что достаточно добавить поддержку в компилятор и на этом успокоиться ?
Кто нибудь может сосчитать общее число команд входящих в RVA23 ?
Вопрос в количестве этих расширений. Подавляющая их часть требуется для очень узконишевых приложений, но обязятельность вынуждает производителей раздувать площадь кристалла, а всех остальных - наращивать кодовую базу (ведь все эти расширения должны поддерживаться в софте). Теряется сам смысл идеи "Reduced Instruction Set Computer" за которую еще совсем недавно боролись сподвижники Паттерсона и Асановича.
Профиль RV64GC был компактный и самодостаточный. Нужно добавить в него RVV и сосредоточить усилия на микроархитекткрных решениях, а не на постоянном наращивании системы команд.
Так и есть, это саботаж. Не даром китайцы послали лесом весь этот сброд и начали пилить свою RISC-X как вариант RISC-V с некоторыми изменениями. Несколько лет назад я еще думал зачем они это делают, ведь это лишает их совместимости с огромной базой софта и компиляторов. Теперь всё стало понятно.
О боже, что они сделали с некогда стройной, выверенной, минималистичной архитектурой.
Зачем вам этот кадавр ? Зачем вам миллиард бесполезных расширений, да еще и обязательных к имплементации ? Почему нельзя остановиться на RV64CG + RVV 1.0, спроектировать и изготовить высокопроизводительный микропроцессор который бы уделал все существующие процы на x86 и ARM ? Кто-то должен остановить этот конгломерат бюрократов!
Сейчас это когда ? На какой версии Android ? Автор показал почему оно НЕ работает на его устройстве (Samsung Galaxy S20, Android 13). Возможно, в более новых версия Android либо исправили regexp определяющий имя сетевого интерфейса (добавили что-то типа \|usb\\d), либо ядро Linux сконфигурировали так, чтобы всем сетевым интерфейсам присваивалось имя вида eth?. На ядре linux 6.x сетевому интерфейсу устройства CDC Ethernet Gadget всё еще присваивается имя usb? поумолчанию. Подозреваю, что это можно настроить в Device-Tree без перекомпиляции ядра.
Вот! Надо добавить в список. ;)
Не верно ты, дядь Фёдор, бутерброд ешь! :)
В приведенной Вами таблице указаны результаты тестов на системе, а не "голого" процессора. Известно, что у Apple II видеоподсистема (как и у C64, или у Atari 800) останавливает центральный процессор при обновлении кадра, что занимает почти половину времени. Еще один момент состоит в том, что в Apple II использовалась динамическая память, которая требует циклов регенерации в процессе выполнения которых она недоступна и процессор простаивает в ожидании. Вы же проводите замеры чистого процессора без внешних раздражителей на статической памяти.
Известно, что i8080 в среднем выполняет 0.125 млн операций в секунду на частоте 1 МГц. Для MOS 6502 этот показатель равен 0.45 млн, т.е. в три с половиной раза больше. Однако у i8080 больше регистров, но у 6502 первая страница памяти (256 байт) может использоваться как таблица указателей, что существенно ускоряет вычисления. В итоге выиграет тот бенчмарк, который более тщательно адаптирован под специфику процессора и конкретной вычислительной системы. :-)
Вот это один из парадоксов жизни. В моём детстве абсолютно всё было небезопасным, даже игры. И я не припомню, чтобы кто-то из нас сильно повредился или попал в больницу с отравлением или травмами. Да, были небольшие ожоги (свинец неудачно выплавил на ногу), вывихи стопы (после плыжка из окна 2-го этажа на стройке), стопу гвоздем проколо когда лазил по помойкам в поисках радиодеталей... но в целом все живы и здоровы по сей день. Сейчас же всё окружено заборами и суровыми законами, а толку никакого. Дети не умеют перелезть забор или залезть на дерево чтобы яблоко достать. :-)
Все мы с детства знаем, что нитроглицерин крайне вырывоопасен. Но почему в аптеке продают таблетки "нитроглицерин" без ограничений и почему они не вызрываются ? Этот вопрос беспокоил любого советсткого школьника с младших классов, для меня он и по сей день остается без ответа. ;)
Хорошая подборка, не знал про неё, спасибо. Про ж/д, заводы, пароходы... всё так! :)
Да, неваляшки в магазинах не залёживались. ;)
Но вы не представляете сколько я извел газет на силитровые ракетке. Дома, простите, ж#пу подтирать нечем было. ;)
Этот ваш порох - баловство для мажоров. Настоящее счастье советского пионера выглядело так:
Два болта + гайка + коробок спичек.
Cилитра + газета "Правда".
Шарик для игры в настольный теннис.
Кукла "невяляшка" (вариант на п. 3).
Пустая банка от дихлофоса + карбид.
Не совсем пустая банка от дихлофоса.
Не совсем пустая банка от лака для волос.
Пустой тюбик от зубной пасты.
Краска "серебрянка" (порошок).
Магниевые колёсные диски + напильник.
Перманганат калия AKA "марганцовка".
Медная трубка + гвоздь + резинка о трусов + коробок спичек.
Асфальт + гвоздь + кирпич + коробок спичек.
Спица от велосипеда + коробок спичек.
Старый автомобильный (свинцовый) аккумулятор.
Банка керосина.
Цельный электропровод сечением 2.5мм2 + резинка от трусов.
Медицинский жгут + брусок дерева + два болта.
Ветка орехового дерева + капроновая веревка + сварочный электрод.
Конденсатор на 600В + два коротких проводника.
Лампочка накаливания 6В + напильник + коробок спичек + батарейка на 4.5В.
"Стартер" от ламп дневного освещения.
Много "стартеров".
Старый огнетушитель.
Использованный балончик от сифона.
Неиспользованный болончик от сифона.
труба + дихлофос + картошка.
Это только часть того, что вспомнилось и было опробовано. :-) А современные дети кроме питарды ничего не видели. Скукотища!
Кто мешает в yeild() сделать сохранение errno на ряду с другими параметрами контекста ? В общем-то это уже давно сделано за вас.
Откуда Вы это взяли ? errno is thread safe очень давно. Никаких проблем с нитями у errno нет.