Я невкурсе геймдев технологий. Но у меня приятель вкурсе. Техлид. Вобщем у них щас в моде Unreal Engine.
И это у них там прямо такой тренд.. Кодят они на плюсах. Но на собеседовании знания UE имеют приоритет над
плюсами. Вот такой рыночный парадокс.
Поддерживается ли шарпы я не знаю. Но поддерживаются плюсы и какой-то Engine Script.
Вообще в данном вопросе я скажу что язык на самом деле не особо важен. Современные движки
настолько умные что для них нагрузка падает на 99% на engine. А разработчик становится
просто девопсом который конфигурит свойства игровых объектов и на этом все.
Такая-же ситуация в машинном обучении. Язык неважен потому что переходники и адаптеры
всегда написаныы на Python, Ruby e.t.c.
Смотри. На самом деле вся эта болтовня только про то чтобы ты во время дампа не дампил вообще всю вселенную а только селективно указал то что тебе надо. Я думаю что я дал тебе достаточно пищи для размышления. Попробуй дампить по одной табличке. По одной схеме. По одной базе. Лишняя табличка? Прибей ее к чорту. Или перенеси ее в такую схему чтоб ее и духу не было рядом. Короче действуй-злодейтсвуй.
Обычно торрент клиенты - примерно одиаковы. Разница может быть в номерах портов. Например у меня
были открыты порты для Transmission. А потом я запустил Vuze но забыл открыть порты на router. И долго
пытался сообразить почему линка долго стоит в состоянии сбора метаданных.
Я-бы начал с сетевого теста на Raspberry Pi. Доступны ли порты.
И второе - у торрентов не существует гарантированной полосы. Они зависят от меняющихся условий.
Например от времени суток. В своем регионе IP адресов лучше наверное качать начиная с 8 вечера
когда все сидеры зайдут в сеть.
Еще влияет наличие дополнительных протоколов обнаружения. Например больше всего их
у Vuze. Поэтому Vuze теоретически будет качать их большего числа источников.
Imaginer, потом атомики. Просто померяй какую долю времеи сьедает Update по отношению к общему.
Это то что доложно определять твою стратегию оптимизации concurrency. Измерения - великая вешь. И очень часто
разработчики имеют очень смутное представление что им надо оптимизировать в первую очередь.
Anaflion, тут даже вопрос не о блокировании экрана. А просто о смыслах. Ты посмотри о каких частотах там речь идет. Человек хочет 1000 раз в секунду выводить float аргумент. Зачем он тебе нужен? Какой толк в буферизации или небуферизации если глазами эту информацию все равно не взглядом не охватить и не осмыслить. Я в таких случаях просто завожу отдельный поток
который обновляет atomic переменные и тихонько публикует их в мониторингах. И видеть их уже можно через
ICMP, JMX, или просто через какой-то статус страничку в вебе. Вот это более инженерный подход.
Если нужно отладочное логгирование - то там спецом библиотеки есть. Но такое логгирование обычно имеет
глобальный выключатель чтоб в релизе не мешало.
WSGlebKavash, вообще я не одобряю питание звуковой техники от компьютерных ИБП. Тем более что синуса нет. Это грязное напряжение. Может оно и не повлияет на входные электрические цепи звукотехнки но оно может где-то всплыть как наводки в других частях звуковых трактов.
В прицнипе аккумуляторы одинаковой емкости и напряжения можно соединять в параллель. Бери молоток. Разбивай 2 УБП. Доставай аккумуляторы. В третьем сверли дырку. Выводи провода. Соединяй в параллель все 3 аккумулятора. Вот такая гирлянда по идее должна работать дольше. Но как теперь это повлияет на процесс заряда - я не знаю. Зарядное будет напрягатся больше. Ведь теперь ему надо дать больший ток или как оно там работает я ХЗ.
Imaginer, слушай мне вот эта процедура Update(float) совсем не нравится. Во первых убери из нее cout. Вывод в консоль - блокирующий и вредит производительности.
Во вторых она делает слишком много всего всякого. Коллизии. Гравитация. Это разные ее части
и я-бы разбил процедуру на под-процедуры как раз для регулировки перформанса. Это во вторых.
В третьих нужно понять временную диаграмму. Сколько % общего времени игры занимает эта процедура.
Поскольку она - эксклюзивная то ее время должно быть меньше чем суммарное. Посчитай с точностью
до милисекунд и микросекунд. Например игра работала 1 минуту и из этого времени Update(float) кумулятивно
занимал допустим 55 секунд. И тогда мы будем понимать есть ли вообще шанс у читателей успеть заскочить
в блокировку и что-то прочитать. И еще посчитай сколько раз вызывался update за 1 минуту. Блокировка
это такая сволочь что даже не делая полезной работы она может забирать полезные циклы CPU.
Исходя из полученных результатов можно будет придумать стоит ли тебе делать 1000 Герц на физику и 60
на визуализацию. Мне кажется что с физикой ты где-то ошибся. Не видно прямо таких убедительных
причин чтоб так часто обновлять вселенную.
Если писатель редкий а читатели - частые - то существует вариант оптимистичного лока который разрешает
читателям не брать mutex а просто читать некий atomic счетчик. Я не знаю как этот шаблон может называться
в С++ его можно реализовать поверх std:atomic. Но в Java он выделен в StampedLock. Типа блокировка основанная
на таймстампе времени.
Я хотел оперировать только символами. А символы из диапазона Unicode https://en.wikipedia.org/wiki/Private_Use_Areas которые в приватном использовании. Я себе это так понимаю что берешь его под свою задачу и как хочешь так и интерпретируешь.
И пара байт это как раз и будет символ из этого резервного диапазона.
Почему я интересовался именно символами и строками? Я опирался на то что строка - это основной транспортный формат. Мне ведь в JSON складывать блоб без base64 кодирование не получится. А это кодирование портит статистику сжатия.
Но вобщем это забавный творческий эксперимент. И это конечно никакой не архиватор. Конечно
snappy, LZW был бы лучше в этом случае полюбому. Но алгоритмы сжатия всегда на выходе продуцируют
сырые байты.
Kano, авторитет эти типа как в хату заходит? Или сколько соборов на плечах наколото?
Понимаешь тут проблема какая. Когда что-то не формализовано - начинается софистика
и схоластика. Сколько архангелов на кончике иголки помещаются? Или отец сын и дух святой
сие есть что? Единый бог или в трех инстанциях? Вот такие пироги.
И это у них там прямо такой тренд.. Кодят они на плюсах. Но на собеседовании знания UE имеют приоритет над
плюсами. Вот такой рыночный парадокс.
Поддерживается ли шарпы я не знаю. Но поддерживаются плюсы и какой-то Engine Script.
Вообще в данном вопросе я скажу что язык на самом деле не особо важен. Современные движки
настолько умные что для них нагрузка падает на 99% на engine. А разработчик становится
просто девопсом который конфигурит свойства игровых объектов и на этом все.
Такая-же ситуация в машинном обучении. Язык неважен потому что переходники и адаптеры
всегда написаныы на Python, Ruby e.t.c.