Вот как возможный пример — мы в позапрошлом месяце имели удовольствие посетить гамбургскую оперу, там давали оперу Модеста Мусоргского «Борис Годунов». Декорации выглядели вот так:
Действо кстати, офигенное было. Визуальный ряд был, пожалуй, попроще чем в «Леди Макбет мценского уезда», куда мы ходили весной (там то в Unreal Engine нарендерили), но всё равно круто неимоверно — зал рукоплескал.
Эх, самые "классные" щелчки были у клавиатуры Электроника МС 7004, что шла вместе с ДВК-4. Я на ней года три отработал (убив две штуки). Клавиши время от времени отказывали, но щёлкали классно.
Есть ещё, кстати, "полумеханики". То есть там мембрана, но клавиши ходят по специальным направляющим - слайдерам. На работе у меня Dell QuietKey (точную модель не помню, ей больше двадцати лет), а вот домой пару лет назад я на барахолке как-то купил Sun Type 7 (по факту это Fujitsu) и очень доволен. Свичи называются "Rubber dome with slider". Клавиши не щёлкают, но они не болтаются, как в совсем дешёвых, совсем другое ощущение при наборе.
Помилосердствуйте, "Ассемблеру" Юрова - двадцать лет книжке, там всё заканчивается на MMX (да и то без примеров), часть уже не актуальна, а 64 бит вообще не рассматривается.
Если уж брать книжку по ассемблеру на русском, то хотя бы вот эту:
Помимо уже упоминавшихся выше OBS и стандартного Snipping Tool из Windows 11 ещё три инструмента до кучи:
Старенький Nimbus Capture (я одно время пользовался заметочником Nimbus и там этот рекордер шёл "в комплекте"). Только надо искать старую версию 4.6.0 по архивам. Прост как пять копеек, пользуюсь скорее "по инерции".
Коллега рядом пользуется ShareX. Чуть более навороченный и перегруженный настройками, но в общем работу выполняет (одно время ffmpeg там надо было доставлять отдельно, сейчас вроде идёт в одном флаконе).
А, и ZoomIt от SysInternals, он буквально на прошлой неделе обновился до 7.2, это, пожалуй самый простой и легковесный инструмент из всех.
Они все не только рекордеры, но и скриншотеры, само собой.
Я с GT 9600 игрался лет этак пятнадцать назад с nvpp, и помню что до теоретически достижимой пропускной способности было ох как далеко. Но у меня сейчас есть Radeon Pro WX 9100, она получше, и действительно на гитхабе вижу эксперименты с пирамидами на OpenCL, так что, пожалуй, сделаю ещё один подход к снаряду. Спасибо за наводку, будет чем заняться долгими зимними вечерами.
Пайплайн, конечно есть, но я реализовал двухбуферную "классику" с Front/Back буферами. Там сценарий использования такой, что оператор дёргает за джойстики и видит на экране как перемещается деталь в рентгене. И дискомфортный лаг начинает быть заметен уже где-то с пары сотен миллисекунд (тем более что также есть определённые лаги в ПЛК и манипуляторе - всё ж таки надо елозить туда-сюда несколько сот кило). Мне проще показать - вот эта железяка:
Где-то на 0:50 и 1:30 и 1:50 ненадолго видны Live картинки на левом мониторе, и мне таки пришлось приложить определённые усилия, чтобы достаточно "гладко" показывать 20 FPS поток на каждом третьем кадре 60 Hz монитора без пропуска кадров, потому что даже просто пропуск одного кадра уже заметен оператору в виде "подёргивания".
GPU - это отдельная тема, но в моём конкретном случае "бутылочное горлышко" - это передача фрейм буфера в GPU и обратно. Я работаю с рентгеновским плоскопанельным детектором. У него картинка - 2000х2000, 16 бит, то есть 8 мегабайт. Такая картинка прилетает 20 раз в секунду. Технически фреймграббер - это самодельная PCI-E 4х плата c DMA, детектор висит на оптоволокне, вот по нему он и гонит 160 мегабайт в секунду. На каждый фрейм драйвером вызывается callback, где я получаю указатель на область памяти, в которой лежит картинка. И вот у меня есть 50 миллисекунд на то, чтобы забрать эту картинку, выполнить Flat Field Correction (это грубо говоря вычитание Offset и умножение на Gain коэффициенты попиксельно), затем поднять контраст - тут работает лапласиан пирамида, и по уровням этой пирамиды прогоняется LUT "S" - формы, плюс свёртка для High Pass фильтра повышения резкости, переброс в 8 бит и показ на экране, синхронно с vsync монитора. Основная проблема, которая возникает - время передачи в GPU и обратно, ну и пирамида не очень хорошо параллелится, так что всё это крутится на CPU. А, кстати, сколько нынче занимает времени передать 8 мегабайт в GPU и обратно?
В общем да, согласен. Это и от поколения зависит и более современные вроде не так чувствительны. Есть ещё такая фишка как Prefetch, но тут сколько я ни игрался, никакого выигрыша не увидел, либо напротив, результат только хуже. Похоже на то, что современные процессоры с этим сами успешно справляются, и вмешательство им только мешает.
Что касается целей вообще — намедни в одном из телеграм каналов программистстких мемчиков узрел прекрасное как раз про цели. Видео постить не буду, ибо оно содержит так сказать обсценную лексику и в общем не в формате хабра, но бородатый харизматичный чувак (имени не знаю) топил за то, что если человек занимается любимым делом, отдаваясь ему полностью, без остатка, то все вопросы экзистенциальности, смысла, и целесообразности вообще отпадают сами собой. И фраза "у самурая нет цели, есть только путь" наполнилась новыми красками. А если серьёзно, что по части классификации сотрудников относительно целей компании с точки зрения руководства очень неплохо Джек Уэлч написал в книге "Мои годы в GE".
А у меня во какой улов с барахолки (но, правда с немецкой):
Это древний арифмометр Diehl, хорошо сохранившийся, где-то конец пятидесятых, с мотором (мотор живой), Там изюминка в том, что это первая железяка с памятью и округлением (вроде бы). Умножение полуавтоматическое, а деление — полный автомат. Каретка жива, но +/- заклинены, если смогу починить, то "Старое железо", вероятно, пополнится постом. Ну и с позапрошлой барахолки Brunsviga ждёт своего часа, там всё ОК, просто почистить и смазать надо:
Хобби у меня такое появилось — собираю старые арифмометры.
А я вот прочитал с большим интересом, особенно последний пример (я закончил физтех, у нас был семестр статистики, но весьма рудиментарный). Я работаю в области неразрушающего контроля и есть сценарии, кода детали проверяются лишь частично, исходя из статистической вероятости появления дефектов литья, пример в статье во многом с этим перекликается. В чём-то предыдущий оратор прав — статья довольно быстро уйдёт с главной хабра и её таки ждёт определённое "забвение", но совсем она не исчезнет, и найдутся люди, которые её найдут, и которым она будет полезна, как мне. Ссылки также весьма ценные, я с удовольствием полистал вчера вечером Кендалла и Стюарта, так что "автор, пиши ещё".
Нет, конечно, равно как и со знаками, разрешёнными для файловой системы:
Было б в общем крайне странно, если бы на немецкой ОС нельзя было использовать умляуты для имён. Нет, ей именно кириллические символы (точнее вообще все, что дальше чем ÿ U+00FF) не нравятся.
То есть раньше пункт меню создания Zip архива находился на первом уровне, а теперь все засунули на второй Compress to...>Zip/7z/Tar. Ну такое.
Вот, кстати, буквально вчера на немецкой Win 11 хотел создать архив из папки с русскими буковками (так уж получилось), и на тебе:
Там написано, мол "не смогла я, потому что кой-какие буковки, (как например, Провыание) мне не нравятся и для zip-архива ну никак не годятся, так что переименуйте вначале". Ни у Far ни у 7-zip таких проблем нет.
Шел 2023 год, Юникод отпразновал тридцатилетний юбилей...
Перед обслуживанием робот должен быть обесточен, при проверке должен быть человек рядом с кнопкой аварийного стопа. На производстве всегда так.
Да не, не всегда, это от того, что именно обслуживается зависит. При замене банальных сенсоров или датчиков никто робот не отключает (но он блокируется разомкнутыми дверными контактами, которые в целях безопасности продублированы). Тем более при пусконаладке, особенно при программировании его позиций или связанной с ним системы машинного зрения оператор находится рядом с ним и он вполне себе двигается, и никто в общем постоянно не стоит у кнопки экстренного останова, хотя по ТБ мы в паре работаем. Это поначалу немного стрёмно, когда рядом в полуметре под пять тонн ездят туда-сюда, но потом привыкаешь. Там другие средства безопасность обеспечивают (я чуть ниже коммент оставил). Ну и прежде чем что-то делать, надо семь раз подумать, конечно. А так - нарушение ТБ (или неправильный дизайн системы безопасности) налицо, конечно.
Сам виноват, к сожалению. При нахождении рядом с перемещающимся роботом-манипулятором в зоне опасности он обязан был держать в руках пульт управления со специальной кнопкой. По-немецки Tot-Man-Taster, по-русски я не знаю, "Кнопка-Мёртвого-Человека", наверное. У этой кнопки три положения, и робот будет перемещаться только если эта кнопка нажата до половины. Если её отпустить (чел потерял сознание), либо прожать до конца (мышцы сжались от шока), то робот мгновенно и жёстко остановится.
Она обычно расположена на обратной стороне пульта, под левую руку, вот так это выглядит:
Ну и робот должен быть обнесён решёткой, а в режиме полной автоматики без удержания этой кнопки должен иметь возможность перемещаться только при закрытых и залоченных дверях.
С точки зрения чистоты архитектуры не очень понятно, почему ядро вообще знает о кнопках на каком-то там стилусе и что-то там инвертирует. Оно должно брать сырые данные от HID устройства и отправлять их драйверу, а тот уже должен разбираться с назначением кнопок.
Я вчера в обеденный перерыв проверил навскидку (взяв за основу https://github.com/andralex/MedianOfNinthers). Скажем так - там всё сильно зависит от исходных данных. На случайном наборе гистограммный метод вроде равно чуть быстрее, но далеко не вдвое, однако если входные данные, скажем уже отсортированы, то в общем почти без шансов, разве что на одинарной точности, где всего два прохода надо.
Это хороший вопрос. Да, не совсем, если во входном массиве все элементы будут NaN, то сработает, а вот если перемешаны с "нормальными" — то нет (точнее не всегда). Я проверил как реагирует на NaN "референсная" NI реализация - там если хотя бы одно число NaN, то и результат всегда NaN, что в общем логично. Это просто элементарная проверка на первом прогоне, и она не должна сильно просадить производительность. Я добавлю, пожалуй, как только время появится. А с плюс минус бесконечностями вроде дружит.
Я этим летом упражнялся с AVX2/AVX512 на ассемблере, и в рамках компиляции несложной DLL библиотеки под Windows сделал это упражнение практически на всех ассемблерах, до которых смог дотянуться. Но остановился, как ни странно на EuroAssembler. Довольно любопытная, очень легковесная и в чём-то необычная штука, в учебных целях - самое оно, как по мне.
Вот как возможный пример — мы в позапрошлом месяце имели удовольствие посетить гамбургскую оперу, там давали оперу Модеста Мусоргского «Борис Годунов». Декорации выглядели вот так:
Действо кстати, офигенное было. Визуальный ряд был, пожалуй, попроще чем в «Леди Макбет мценского уезда», куда мы ходили весной (там то в Unreal Engine нарендерили), но всё равно круто неимоверно — зал рукоплескал.
Эх, самые "классные" щелчки были у клавиатуры Электроника МС 7004, что шла вместе с ДВК-4. Я на ней года три отработал (убив две штуки). Клавиши время от времени отказывали, но щёлкали классно.
Есть ещё, кстати, "полумеханики". То есть там мембрана, но клавиши ходят по специальным направляющим - слайдерам. На работе у меня Dell QuietKey (точную модель не помню, ей больше двадцати лет), а вот домой пару лет назад я на барахолке как-то купил Sun Type 7 (по факту это Fujitsu) и очень доволен. Свичи называются "Rubber dome with slider". Клавиши не щёлкают, но они не болтаются, как в совсем дешёвых, совсем другое ощущение при наборе.
Вот так это выглядит, если колпачок скинуть:
Помилосердствуйте, "Ассемблеру" Юрова - двадцать лет книжке, там всё заканчивается на MMX (да и то без примеров), часть уже не актуальна, а 64 бит вообще не рассматривается.
Если уж брать книжку по ассемблеру на русском, то хотя бы вот эту:
Помимо уже упоминавшихся выше OBS и стандартного Snipping Tool из Windows 11 ещё три инструмента до кучи:
Старенький Nimbus Capture (я одно время пользовался заметочником Nimbus и там этот рекордер шёл "в комплекте"). Только надо искать старую версию 4.6.0 по архивам. Прост как пять копеек, пользуюсь скорее "по инерции".
Коллега рядом пользуется ShareX. Чуть более навороченный и перегруженный настройками, но в общем работу выполняет (одно время ffmpeg там надо было доставлять отдельно, сейчас вроде идёт в одном флаконе).
А, и ZoomIt от SysInternals, он буквально на прошлой неделе обновился до 7.2, это, пожалуй самый простой и легковесный инструмент из всех.
Они все не только рекордеры, но и скриншотеры, само собой.
Я с GT 9600 игрался лет этак пятнадцать назад с nvpp, и помню что до теоретически достижимой пропускной способности было ох как далеко. Но у меня сейчас есть Radeon Pro WX 9100, она получше, и действительно на гитхабе вижу эксперименты с пирамидами на OpenCL, так что, пожалуй, сделаю ещё один подход к снаряду. Спасибо за наводку, будет чем заняться долгими зимними вечерами.
Пайплайн, конечно есть, но я реализовал двухбуферную "классику" с Front/Back буферами. Там сценарий использования такой, что оператор дёргает за джойстики и видит на экране как перемещается деталь в рентгене. И дискомфортный лаг начинает быть заметен уже где-то с пары сотен миллисекунд (тем более что также есть определённые лаги в ПЛК и манипуляторе - всё ж таки надо елозить туда-сюда несколько сот кило). Мне проще показать - вот эта железяка:
Где-то на 0:50 и 1:30 и 1:50 ненадолго видны Live картинки на левом мониторе, и мне таки пришлось приложить определённые усилия, чтобы достаточно "гладко" показывать 20 FPS поток на каждом третьем кадре 60 Hz монитора без пропуска кадров, потому что даже просто пропуск одного кадра уже заметен оператору в виде "подёргивания".
GPU - это отдельная тема, но в моём конкретном случае "бутылочное горлышко" - это передача фрейм буфера в GPU и обратно. Я работаю с рентгеновским плоскопанельным детектором. У него картинка - 2000х2000, 16 бит, то есть 8 мегабайт. Такая картинка прилетает 20 раз в секунду. Технически фреймграббер - это самодельная PCI-E 4х плата c DMA, детектор висит на оптоволокне, вот по нему он и гонит 160 мегабайт в секунду. На каждый фрейм драйвером вызывается callback, где я получаю указатель на область памяти, в которой лежит картинка. И вот у меня есть 50 миллисекунд на то, чтобы забрать эту картинку, выполнить Flat Field Correction (это грубо говоря вычитание Offset и умножение на Gain коэффициенты попиксельно), затем поднять контраст - тут работает лапласиан пирамида, и по уровням этой пирамиды прогоняется LUT "S" - формы, плюс свёртка для High Pass фильтра повышения резкости, переброс в 8 бит и показ на экране, синхронно с vsync монитора. Основная проблема, которая возникает - время передачи в GPU и обратно, ну и пирамида не очень хорошо параллелится, так что всё это крутится на CPU. А, кстати, сколько нынче занимает времени передать 8 мегабайт в GPU и обратно?
В общем да, согласен. Это и от поколения зависит и более современные вроде не так чувствительны. Есть ещё такая фишка как Prefetch, но тут сколько я ни игрался, никакого выигрыша не увидел, либо напротив, результат только хуже. Похоже на то, что современные процессоры с этим сами успешно справляются, и вмешательство им только мешает.
Что касается целей вообще — намедни в одном из телеграм каналов программистстких мемчиков узрел прекрасное как раз про цели. Видео постить не буду, ибо оно содержит так сказать обсценную лексику и в общем не в формате хабра, но бородатый харизматичный чувак (имени не знаю) топил за то, что если человек занимается любимым делом, отдаваясь ему полностью, без остатка, то все вопросы экзистенциальности, смысла, и целесообразности вообще отпадают сами собой. И фраза "у самурая нет цели, есть только путь" наполнилась новыми красками. А если серьёзно, что по части классификации сотрудников относительно целей компании с точки зрения руководства очень неплохо Джек Уэлч написал в книге "Мои годы в GE".
А у меня во какой улов с барахолки (но, правда с немецкой):
Это древний арифмометр Diehl, хорошо сохранившийся, где-то конец пятидесятых, с мотором (мотор живой), Там изюминка в том, что это первая железяка с памятью и округлением (вроде бы). Умножение полуавтоматическое, а деление — полный автомат. Каретка жива, но +/- заклинены, если смогу починить, то "Старое железо", вероятно, пополнится постом. Ну и с позапрошлой барахолки Brunsviga ждёт своего часа, там всё ОК, просто почистить и смазать надо:
Хобби у меня такое появилось — собираю старые арифмометры.
А я вот прочитал с большим интересом, особенно последний пример (я закончил физтех, у нас был семестр статистики, но весьма рудиментарный). Я работаю в области неразрушающего контроля и есть сценарии, кода детали проверяются лишь частично, исходя из статистической вероятости появления дефектов литья, пример в статье во многом с этим перекликается. В чём-то предыдущий оратор прав — статья довольно быстро уйдёт с главной хабра и её таки ждёт определённое "забвение", но совсем она не исчезнет, и найдутся люди, которые её найдут, и которым она будет полезна, как мне. Ссылки также весьма ценные, я с удовольствием полистал вчера вечером Кендалла и Стюарта, так что "автор, пиши ещё".
Нет, конечно, равно как и со знаками, разрешёнными для файловой системы:
Было б в общем крайне странно, если бы на немецкой ОС нельзя было использовать умляуты для имён. Нет, ей именно кириллические символы (точнее вообще все, что дальше чем ÿ U+00FF) не нравятся.
То есть раньше пункт меню создания Zip архива находился на первом уровне, а теперь все засунули на второй Compress to...>Zip/7z/Tar. Ну такое.
Вот, кстати, буквально вчера на немецкой Win 11 хотел создать архив из папки с русскими буковками (так уж получилось), и на тебе:
Там написано, мол "не смогла я, потому что кой-какие буковки, (как например, Провыание) мне не нравятся и для zip-архива ну никак не годятся, так что переименуйте вначале". Ни у Far ни у 7-zip таких проблем нет.
Шел 2023 год, Юникод отпразновал тридцатилетний юбилей...
Да не, не всегда, это от того, что именно обслуживается зависит. При замене банальных сенсоров или датчиков никто робот не отключает (но он блокируется разомкнутыми дверными контактами, которые в целях безопасности продублированы). Тем более при пусконаладке, особенно при программировании его позиций или связанной с ним системы машинного зрения оператор находится рядом с ним и он вполне себе двигается, и никто в общем постоянно не стоит у кнопки экстренного останова, хотя по ТБ мы в паре работаем. Это поначалу немного стрёмно, когда рядом в полуметре под пять тонн ездят туда-сюда, но потом привыкаешь. Там другие средства безопасность обеспечивают (я чуть ниже коммент оставил). Ну и прежде чем что-то делать, надо семь раз подумать, конечно. А так - нарушение ТБ (или неправильный дизайн системы безопасности) налицо, конечно.
Сам виноват, к сожалению. При нахождении рядом с перемещающимся роботом-манипулятором в зоне опасности он обязан был держать в руках пульт управления со специальной кнопкой. По-немецки Tot-Man-Taster, по-русски я не знаю, "Кнопка-Мёртвого-Человека", наверное. У этой кнопки три положения, и робот будет перемещаться только если эта кнопка нажата до половины. Если её отпустить (чел потерял сознание), либо прожать до конца (мышцы сжались от шока), то робот мгновенно и жёстко остановится.
Она обычно расположена на обратной стороне пульта, под левую руку, вот так это выглядит:
Ну и робот должен быть обнесён решёткой, а в режиме полной автоматики без удержания этой кнопки должен иметь возможность перемещаться только при закрытых и залоченных дверях.
С точки зрения чистоты архитектуры не очень понятно, почему ядро вообще знает о кнопках на каком-то там стилусе и что-то там инвертирует. Оно должно брать сырые данные от HID устройства и отправлять их драйверу, а тот уже должен разбираться с назначением кнопок.
Это называется "когда мысли сходятся". Мне по работе для пары тестов понадобилось, "слепил на коленке" из ардуинки:
Там правда не только частотомер, но и пара простеньких триггеров.
Я вчера в обеденный перерыв проверил навскидку (взяв за основу https://github.com/andralex/MedianOfNinthers). Скажем так - там всё сильно зависит от исходных данных. На случайном наборе гистограммный метод вроде равно чуть быстрее, но далеко не вдвое, однако если входные данные, скажем уже отсортированы, то в общем почти без шансов, разве что на одинарной точности, где всего два прохода надо.
Это хороший вопрос. Да, не совсем, если во входном массиве все элементы будут NaN, то сработает, а вот если перемешаны с "нормальными" — то нет (точнее не всегда). Я проверил как реагирует на NaN "референсная" NI реализация - там если хотя бы одно число NaN, то и результат всегда NaN, что в общем логично. Это просто элементарная проверка на первом прогоне, и она не должна сильно просадить производительность. Я добавлю, пожалуй, как только время появится. А с плюс минус бесконечностями вроде дружит.
Я этим летом упражнялся с AVX2/AVX512 на ассемблере, и в рамках компиляции несложной DLL библиотеки под Windows сделал это упражнение практически на всех ассемблерах, до которых смог дотянуться. Но остановился, как ни странно на EuroAssembler. Довольно любопытная, очень легковесная и в чём-то необычная штука, в учебных целях - самое оно, как по мне.