Depish Dev

В ответ на пост А вообще конечно все эти бенчмарки ни о чем не говорят. Производительность нужно изменять в реальных прикладных задачах.

Наткнулся случайно на бенч) https://github.com/yellow-footed-honeyguide/benchmark-c-vs-all Ну по классике конечно, чел пишет на си, и написал бенчи на остальные языки, и накосячил сильно, видимо изучал си и раст, ибо на этих языках норм написал но я думаю есть куда расти. А вот в плюсах накосячил жестко) а в го совсем смертоносно)) Такой результат у меня был с его кодом: Benchmark Results: +--------+-------------------------------+------------------+ | Rank | Language (Compiler Version) | Execution Time | +========+===============================+==================+ | 1 | C (Clang) 18.1.8 | 0.1200s | +--------+-------------------------------+------------------+ | 2 | Rust (1.82.0) | 0.1220s | +--------+-------------------------------+------------------+ | 3 | C++ (Clang++) 18.1.8 | 0.1660s | +--------+-------------------------------+------------------+ | 4 | C (GCC) 13.2.1 | 0.1690s | +--------+-------------------------------+------------------+ | 5 | C++ (G++) 13.2.1 | 0.1770s | +--------+-------------------------------+------------------+ | 6 | Go (1.23.3) | 0.9350s | +--------+-------------------------------+------------------+ Я переписал на плюсах так, чтобы это было в логике похоже как это в сях у него (в сях у него обьект на стеке а в плюсах он в кучу поместил так еще и в юиники завернул, двойные разыменования, накладные..., и не знает что std::array и так зануляет, двойное зануление с помощью std::fill сделал) С моими правками получилась такая картина: Benchmark Results: +--------+-------------------------------+------------------+ | Rank | Language (Compiler Version) | Execution Time | +========+===============================+==================+ | 1 | C++ (Clang++) 18.1.8 | 0.0000s | +--------+-------------------------------+------------------+ | 2 | C++ (G++) 13.2.1 | 0.0600s | +--------+-------------------------------+------------------+ | 3 | Rust (1.82.0) | 0.1220s | +--------+-------------------------------+------------------+ | 4 | C (Clang) 18.1.8 | 0.1280s | +--------+-------------------------------+------------------+ | 5 | C (GCC) 13.2.1 | 0.1700s | +--------+-------------------------------+------------------+ | 6 | Go (1.23.3) | 0.8960s | +--------+-------------------------------+------------------+ Даже си проиграл, но тут я думаю что просто бенч на сях плохо написан. Моя правка: https://gist.github.com/eSkry/b30ae1fa4d5ae7e05145d1f4747f03ca

Сделал чат канала публичным @depish_dev_chat

Вот смотрю на моддинг внутрянки страйкбольных приводов и не понимаю к чему вся эта дикость, усиленная пружина, усиленные шестерни, замена пластиковых зубьев поршня на металлические, более сильный двигатель и т.д... Буд-то специально решили с завода сделать говно, создать проблем и потом героически их решать за оверпрайс! Можно ведь конструкционно другой механизм сделать, который будет испытывать меньшие динамические нагрузки. А если и материал сразу сделать нормальный то нужда в модификации отпадет... К примеру зачем усложнение в виде кучи пластиковых шестерней и прочих подвижных механизмов из пластика подверженных динамическим нагрузкам (из-за постоянной смены напряженности пружины), расположения двигателя в ручке. Можно ведь сделать соосную схему с планетарным редуктором, который будет надежнее а главное что замена пружины на более сильную не повлечет за собой замену всех остальных деталей как это есть на текущих AEG приводах..

Жаль что записало видео квадратом, нужно будет придумать как записать широкоформатное видео. А так уже перестало подташнивать при игре, скоро можно будет и не в тренировочных полетать! А пока вот вылеты на Ка-50 и Ми-28Н В этом посте есть большое видео, которое не загрузилось в Дзен. Откройте оригинал поста в телеграме, чтобы его посмотреть

И так, опробовал я этот VR шлем и осталось двоякое впечатление: Игры для которых я НЕ покупал его (хотя конечно играть буду) - играются в превосходном качестве, пикселей нет, есть небольшая нечеткость но это из-за моего зрения, если надеть очки то размытость пропадает. А вот в игре War Thunder для которой я и покупал шлем все достаточно печально. Здесь на каждый глаз идет разрешение 2160x2160, т.е. нужно рендерить 2160x2160x2 пикселей, что дает фризы при игре в авиасимы. Пришлось в SteamVR изменить разрешение для рендера чтобы было играбельно. НО!!! Что при полном рендере в 100% что в уменьшенном - качество картинки а именно детализация окружающего мира в игре оставляет желать лучшего - зерно да мыло =( После применения манипуляций я сел как и рассчитывал в вертолет и чуть не лишился ужина который я не так давно съел! Видимо нужно будет постепенно привыкать к тому, как качается и двигается авиация. Не все так гладко с PICO. Чтобы поиграть в SteamVR необходимо поставить Streaming Assistant на ПК и подключиться, но что в китайской прошивке, что в глобальной на которую я сразу перепрошил шлем. Версия Streaming Assistant ниже той что на ПК а обновиться она не хотела из маркета =/ Пришлось вручную закидывать APK нужной версии а так же устанавливать ту же версию на ПК.

Не удержался и докупил трассер + планки пикатини. Жаль не было крепления для фонарика, сам фонарь есть - крепления нет :( Всетаки это какая-то наркоманская штука, начинаешь покупать эти привода, обвес и не можешь остановиться ...

Потихоньку пополняю комплект устройств для авиасимов ✈️🚁. Пока так. Остались только вертолётные педали которые неизвестно где взять. Те что в магазинах выходят по стоимости как новая игровая консоль. Pico 4 Pro 🥽 уже в пути. Не дешевое это удовольствие - играть в авиасимы...

Steam 2023 Итоги года. Ну не много то и играл 😁

А вот и обновочка

Перенос обновлений оригинального репозитория в собственный Для чего это нужно ? Например если у вас существует репозиторий созданный на основе другого но не с помощью форка и необходимо получать все обновления с этого репозитория. Вводные данные: https://github.com/another_company/application - Оригинальный репозиторий https://github.com/my_company/application - Свой репозиторий Этап 1 Данный этап необходимо выполнить 1 раз. Он является подготовительным к дальнейшим обновлениями. Подготовка репозиториев к слиянию, и его слияние: Для начала нужно стянуть репозиторий в который будем заливать изменения из другого репозитория: git clone https://github.com/my_company/application Теперь необходимо добавить remote оригинального репозитория git remote add sync_remote https://github.com/another_company/application. Здесь sync_remote это имя remote которое мы задали. По этому имени в дальнейшем можно обращаться к веткам оригинального репозитоиря. Локальный remote по умолчанию называется origin. Чтобы посмотреть список добавленых remote нужно выполнить git remote -v: sync_remote https://github.com/another_company/application (fetch) sync_remote https://github.com/another_company/application (push) origin https://github.com/my_company/application (fetch) origin https://github.com/my_company/application (push) Для примера будем сливать ветки develop. Чтобы получить новые комиты в sync_remote нужно выполнить: git fetch sync_remote. После чего загрузится оригинальный репозиторий локально. Слияние веток из разных remote Для того чтобы перенести всю историю комитов из sync_remote в origin необходимо выполнить: git checkout -b <new-branch-name> <your-custom-remote-name>/<branch>. В текущем примере получается git checkout -b tempdevelop sync_remote/develop. Главное это чтобы создалась новая ветка в origin основаная на ветки из remote. В существующую ветку так смержить не получится на данном этапе. Далее переходим в нашу ветку origin/develop: git checkout develop. И выполняем слияние веток git merge tempdevelop --allow-unrelated-histories. Ключ --allow-unrelated-histories необходим для того, чтобы git смог слить 2 различных истории коммитов. Останется только разрешить конфликты и в ветке develop будут все изменения с sync_remote/develop. При первом слиянии, конфликтов может быть очень много Краткая сводка комманд: git clone https://github.com/my_company/application git remote add sync_remote https://github.com/another_company/application git fetch sync_remote git checkout -b tempdevelop sync_remote/develop git checkout develop git merge tempdevelop --allow-unrelated-histories Далее необходимо слить с нашей веткой develop остальные ветки, чтобы была единая история. Этап 2 На втором этапе мы можем обновлять собвтенные ветки на основе удаленного репозитория: # Обновляем оригинальную ветку git fetch sync_remote git checkout sync_remote/release/v1.0.0 git pull # Обновляем свою ветку git checkout release/v1.0.0 git pull # Мержим git merge sync_remote/release/v1.0.0 В примере выше мы стянули обновления с оригинального репозитория, переключились на собственную релизную ветку обновили ее и слили в нее изменения из оригинальной ветки. #git #github

В последнее время стал писать очень много отдельных модулей под рабочий проект. Каждый раз приходилось описывать сборочные скрипты под эти модули. Когда количество модулей перевалило за 10шт решил наконец создать шаблонный репозиторий. В шаблон входит: - Генерация проектных файлов с помощью CMake - Подключен менеджер пакетов Conan - Python скрипт для сборки (если не хочется руками прописывать Conan и CMake команды) - Описал несколько Python модулей для выполнения команд в shell из Python и работы с git. Собственно сам шаблон: https://github.com/eSkry/CMakeConanProjectTemplate