Оптимизации, очевидно, не могут гарантировать встраивания всех функций. Ваш пример сломается если функция, например, слишком велика для встраивания (или по каким-то иным эвристикам компилятор решит, что делать этого не следует), или если она находится в иной единице трансляции при отключенном LTO.
С описанием согласен, но акцент на предсказателе ветвлений тут лишний. Реорганизация ветвей может иметь большое влияние на производительность и в архитектурах вообще без предсказателя (например, в микроконтроллерах), где инструкции перехода сбрасывают конвейер и приостанавливают исполнение. Вашим интринсиком вы можете сказать компилятору, какая ветвь наименее вероятна, и она будет исполнятся после исполнения инструкции перехода (с возможным сбросом конвейера), в то время как более вероятная ветвь перехода вообще не потребует.
задаёт наиболее вероятное значение целочисленного выражения expression, что может помочь процессору путём подсказок во время предсказания ветвлений (branch prediction)
Интринсики для указания вероятности ветвления к аппаратному предсказателю ветвлений никакого отношения не имеют. Как и написано в документации, на которую вы ссылаетесь, это влияет лишь на генерацию кода. В общем случае, компилятор ничего не знает об аппаратном предсказателе ветвлений, и манипулировать его состояниями не может (оставим в стороне вещи вроде сброса конвейера, это про другое).
Одним из аргументов против использования std::array может служить довод о том, что-де когда он передаётся в функции по ссылке, то при обращении к его элементам происходит дополнительная косвенность.
Косвенность у вас в бенчмарке исчезла из-за того, что вызываемая функция была встроена в место вызова (inlined). Думаю, будет легко показать, что при отсутствии встраивания косвенность не исчезает, значит примеры не эквивалентны.
Это, несомненно, так, но по ссылке не электромагнит. Устройство по ссылке сохраняет намагниченность без источника энергии; энергия требуется лишь для переключения состояния. Движущихся частей в конструкции нет, что делает её исключительно надежной.
Система захвата же. Один магнит держит минимум 20 кгс (в оптимальных условиях до 25 кгс) при собственной массе около 70 г. Магниты можно включать по нескольку штук параллельно: 4 штуки = 80 кгс при массе 280 г. Ваш захват сколько держит?
Ну я не видел ваши коммиты, но вы уверены, что их отвергают по национальному признаку, а не по иным причинам? Да и откуда им знать о вашей национальности, если вы сами не рассказываете об этом?
Какая-то неожиданная мнительность на грани с паранойей, ну доколе.
Речь шла про кикад, я про него и спрашивал. Во-первых, отклонение патчей по национальному признаку является событием из ряда вон выходящим, но я не сомневаюсь, что где-то есть маргинальные проекты с поехавшими мейнтейнерами, которые это практикуют. Кикад и наверное весь популярный софт в их число не входит. Во-вторых, история с Эльбрусом, на которую вы ссылаетесь, не имеет отношения к отклонению по национальному признаку. Я не знаю, что успели раздуть из этого в новостях, но если вы почитаете оригинальную переписку в LKML то увидите, что патч отклонен из-за отказа в сотрудничестве с компанией. К национальности авторов это отношения не имеет.
Вы, очевидно, плохо представляете себе, как устроен контроль версий в ПО. Без сарказма советую обратить внимание, и вы увидите, как KiCAD с git из коробки попадает на 1-й или 2-й уровень по вашей классификации.
Kicad брать за основу неправильно, уже есть прецеденты, когда предлагаемые изменения к opensource ПО, исходящие из РФ блокируются и не рассматриваются к внедрению в проект.
МОП означает металл-оксид-полупроводник, одна из технологий производства полевых транзисторов; в некоторых областях сегодня вытесняется современными альтернативами. По-английски будет MOS. FET на русский переводится как полевой транзистор.
Направление векторов было выбрано так, чтобы зона пониженного давления создавалась у верхней поверхности цилиндра
Согласно вот этой схеме выше, область пониженного давления возникнет снизу, а не сверху, и F_L будет направлена вниз. У вас стрелка w_c, a_c явно не в ту сторону показывает, это же очевидно.
Информации о контроллерах первого прототипа, к сожалению, нет, но в текущем прототипе используются BLDC-контроллеры Hobbywing Skywalker 80A
Это не векторные контроллеры, так что непонятно, к чему относится математическая модель, и что ещё в ней не соответствует реально достигнутому результату.
На диаграмме сил у вас направление w_c и a_c, кажется, перепутано. Ещё не раскроете секрет, какого бренда контроллеры моторов привода цилиндров использовались в первом прототипе?
У вас в "математической модели" в нижнем плече диоды перевёрнуты, и в уравнениях состояния БДПТ используется угловое ускорение где должна быть угловая скорость.
Оптимизации, очевидно, не могут гарантировать встраивания всех функций. Ваш пример сломается если функция, например, слишком велика для встраивания (или по каким-то иным эвристикам компилятор решит, что делать этого не следует), или если она находится в иной единице трансляции при отключенном LTO.
С описанием согласен, но акцент на предсказателе ветвлений тут лишний. Реорганизация ветвей может иметь большое влияние на производительность и в архитектурах вообще без предсказателя (например, в микроконтроллерах), где инструкции перехода сбрасывают конвейер и приостанавливают исполнение. Вашим интринсиком вы можете сказать компилятору, какая ветвь наименее вероятна, и она будет исполнятся после исполнения инструкции перехода (с возможным сбросом конвейера), в то время как более вероятная ветвь перехода вообще не потребует.
Интринсики для указания вероятности ветвления к аппаратному предсказателю ветвлений никакого отношения не имеют. Как и написано в документации, на которую вы ссылаетесь, это влияет лишь на генерацию кода. В общем случае, компилятор ничего не знает об аппаратном предсказателе ветвлений, и манипулировать его состояниями не может (оставим в стороне вещи вроде сброса конвейера, это про другое).
Косвенность у вас в бенчмарке исчезла из-за того, что вызываемая функция была встроена в место вызова (inlined). Думаю, будет легко показать, что при отсутствии встраивания косвенность не исчезает, значит примеры не эквивалентны.
>данные компоненты можно приобрести в России?
Теперь уже нет. Раньше надо было думать!
Ну тогда вам и три магнита не нужно, достаточно одного или двух, что предпочтительнее вашего подхода.
А ваши штифты выдержат 60 кгс?
Налажено, но отгрузка пока только по предзаказам. Отгрузка новых заказов будет в октябре. Цена 130€.
Ну вот видите, устройство по ссылке вполне составляет конкуренцию вашей конструкции.
Это, несомненно, так, но по ссылке не электромагнит. Устройство по ссылке сохраняет намагниченность без источника энергии; энергия требуется лишь для переключения состояния. Движущихся частей в конструкции нет, что делает её исключительно надежной.
Система захвата же. Один магнит держит минимум 20 кгс (в оптимальных условиях до 25 кгс) при собственной массе около 70 г. Магниты можно включать по нескольку штук параллельно: 4 штуки = 80 кгс при массе 280 г. Ваш захват сколько держит?
kak tebe takoe, elon musk https://files.zubax.com/products/com.zubax.epm/Zubax_EPM_Datasheet.pdf
Коммутируют конечно. Разве что с отключением возникнут проблемы.
Ну я не видел ваши коммиты, но вы уверены, что их отвергают по национальному признаку, а не по иным причинам? Да и откуда им знать о вашей национальности, если вы сами не рассказываете об этом?
Какая-то неожиданная мнительность на грани с паранойей, ну доколе.
Речь шла про кикад, я про него и спрашивал. Во-первых, отклонение патчей по национальному признаку является событием из ряда вон выходящим, но я не сомневаюсь, что где-то есть маргинальные проекты с поехавшими мейнтейнерами, которые это практикуют. Кикад и наверное весь популярный софт в их число не входит. Во-вторых, история с Эльбрусом, на которую вы ссылаетесь, не имеет отношения к отклонению по национальному признаку. Я не знаю, что успели раздуть из этого в новостях, но если вы почитаете оригинальную переписку в LKML то увидите, что патч отклонен из-за отказа в сотрудничестве с компанией. К национальности авторов это отношения не имеет.
Вы, очевидно, плохо представляете себе, как устроен контроль версий в ПО. Без сарказма советую обратить внимание, и вы увидите, как KiCAD с git из коробки попадает на 1-й или 2-й уровень по вашей классификации.
Хотя бы один пример сможете привести?
МОП означает металл-оксид-полупроводник, одна из технологий производства полевых транзисторов; в некоторых областях сегодня вытесняется современными альтернативами. По-английски будет MOS. FET на русский переводится как полевой транзистор.
Согласно вот этой схеме выше, область пониженного давления возникнет снизу, а не сверху, и F_L будет направлена вниз. У вас стрелка w_c, a_c явно не в ту сторону показывает, это же очевидно.
Это не векторные контроллеры, так что непонятно, к чему относится математическая модель, и что ещё в ней не соответствует реально достигнутому результату.
На диаграмме сил у вас направление w_c и a_c, кажется, перепутано. Ещё не раскроете секрет, какого бренда контроллеры моторов привода цилиндров использовались в первом прототипе?
У вас в "математической модели" в нижнем плече диоды перевёрнуты, и в уравнениях состояния БДПТ используется угловое ускорение где должна быть угловая скорость.