Значит, вокруг вас не сформировано окружение, где было бы комфортно откровенно разговаривать. И это ведет нас снова к тому, что отсутствуют навыки формирования такого окружения.
Человеки не очень умеют просить, зато умеют требовать. Не умеют благодарить, зато умеют обесценивать
Как по мне, это говорит только об одном - отсутствии навыков искать нужных людей и заводить хорошие знакомства. Отсюда выливается все остальное. Когда нет навыков по социализации с людьми, с которыми комфортно, тогда действительно нужен суррогат.
В том же и идея, что код работает как надо. Если код пропускает часть вычислений, то он не работает как нужно, а значит, код не выполняет свою задачу. Если же код выполняет свою задачу, никому не интересно, работает ли он быстрее ожидаемого.
"Что бы вы сделали, если бы обнаружили, что ваш код работает быстрее, чем ожидалось?"
Цель: Проверить понимание оптимизации и потенциальных проблем, связанных с чрезмерной оптимизацией.
Каким образом этот вопрос связан с пониманием оптимизации и чрезмерной оптимизацией вообще? Тут варианта всего два - либо код корректно выполняет возложенную на него задачу, либо не выполняет. Если он корректно выполняет задачу, то о какой оптимизации вообще может идти речь? Или это какой-то очень странный способ вытащить кандидата на разговор о поддержке оптимизированного кода?
Официальная документация говорит, что любой проект на Android обязан AndroidManifest.xml содержать в корневом каталоге. И это не по чьему-то субъективному мнению, а по вполне объективным требованиям проектов для Android
Опрос мне показался несколько ограничивающим. Я считаю, что все эти пункты важны и вносят свой вклад в общую атмосферу. Невозможно создать атмосферу без синергии музыки, визуала, наличия некоторых философских элементов, нарратива, визуала и геймплея.
Конкретно в случае Firefly III радует то, что к нему есть некоторый API, который позволяет даже в случае прекращения поддержки реализовать свои пайплайны обработки данных даже на том же питоне. Плюс он self-hosted, что не может не радовать. Кажется, что Ваша идея финансовой аналитики с помощью своих скриптов хорошо ложится на возможности этого инструмента. Звучит как тема для следующей статьи. В любом случае, спасибо за статью!
Существует Firefly III. На мой взгляд, достаточно удобный инструмент для ведения личной бухгалтерии и некоторого рода аналитики (в основном, связанной с выходом за бюджет). Пробовали им пользоваться? Если да, какие для себя обнаружили минусы?
Для этого можно использовать базовую аналитику банка, приложения для учета финансов, но у них есть минусы.
Тема минусов и плюсов не раскрыта. Понятно, что у готовых систем может не быть той гибкости, которая будет у пачки скриптов на питоне, но все-таки интересно было бы провести сравнение и более подробно остановиться на преимуществах и недостатках решений.
Оптимизация - это более широкое понятие, чем улучшение кода по времени/памяти, поэтому это вполне себе оптимизация (инфраструктуры)
Изначально некорректно понял Ваш посыл. В такой постановке согласен.
это будет стоит очень дорого, а по сути превращаться в клауд-гейминг
Все верно. В целом, интересна судьба облачного гейминга - судя по тому, на что мы уже можем посмотреть, спрос на это пусть и есть, но не такой масштабный, если смотреть на игровой рынок в целом.
Почему ничего не делают? Все симуляции, перемещения и любые другие операции выносят на сторону сервера. Помимо этого существуют разные механизмы дополнительной верификации, включая, но не ограничиваясь античитами. Почему Вы считаете, что с этим ничего не делают?
Технически, помогает, просто не со 100% эффективностью. Часть читеров отсеивается банально на уровне сканирования памяти приложения, часть читеров будет отсеяна серверными проверками, часть поймает античит и статический анализ. Читеры и разработчики игр похожи на то, что происходит в информационной безопасности - обороняющаяся сторона всегда в догонябщем положении. Поэтому я сомневаюсь, что когда-либо в принципе настанет время совсем без читеров.
Дополню так же, что сервер и так обложен всеми проверками. Есть отдельные типы читов, создатели которых пытаются отреверсить логику работы сервера и находят разного рода уязвимости. Где-то это связано с ошибками обработки параметров от клиента, где-то находятся специфичные параметры, позволяющие проверки обойти и т.п. Не все так просто. Будь это так легко - античитов бы не было. Большая часть мультиплеерных игр и так не дает выполнять никаких операций на клиенте и все симуляции, включая перемещение, делаются на сервере.
Это никак не связано с оптимизацией. Это называется listen server и этот подход используется для того, чтобы не было необходимости хостить выделенный сервер, он же dedicated server. Довод про то, что в этом случае античиты не помогут - это спорное заявление. Сильно зависит от типа античита, на каком уровне он работает (на уровне приложения или в kernel mode) и прочих параметрах. В целом, отследить использование читов в listen сервере возможно. Эффективно ли - вопрос. upd: не указал еще про самый очевидный способ защиты - в клиентах игр очень часто используют так называемые "защищенные" значения, которые шифруются в памяти по определенным правилам, чаще всего используются обычные xor и сдвиги. Это позволяет в разы усложнить поиск значений в памяти приложения и, как следствие, ограничить использование программ навроде Cheat Engine. Но, опять же, это зависит от того, насколько хотят взломать - такие приемы уже давно научились распознавать и обходить по-своему.
Со сборкой мусора возникает резонный вопрос - зачем и по каким причинам ему отдается предпочтение, а не более, на первый взгляд, маловесной системе из умных указателей. Я не видел статей, которые бы сравнивали эти два варианта менеджмента памяти на каких-то реальных или около реальных кейсах. Насчет нуля абстракций и простоты логики - это все зависит сильно от проекта, на самом деле. Где-то да, это даст максимальную простоту, а где-то это в итоге приведет к ненужным усложнениям во имя "оптимизации". К тому же важно помнить, что игровые студии предпочитают экономить не ресурсы компьютера, а время сотрудников. Так что вопрос такой, не самый простой и от случая к случаю можно получить очень разные мнения и результаты. Я работал с чем-то отдаленно похожим на ECS. В плане производительности нареканий не было совершенно, но иногда уходило прилично времени на то, чтобы найти нужный компонент и нужную систему для того, чтобы внести в них правки. Но т.к. проект требовал множества сущностей одномоментно, это был разумный компромисс. В целом, так уж получается, что подходы подстраивают под нужды и цели бизнеса, а не наоборот. Отсюда, в общем-то, появляются всякие абстракции, библиотеки (и движки тоже) и все движется к тому, чтобы можно было взять любого программиста на стеке Х и безшовно заменить его на другого из этого же стека. Мое личное мнение, что именно на этом все завязано. Именно отсюда идут корни всяких книг навроде "Чистый код" Роберта Мартина, именно поэтому мы начинаем жертвовать ресурсы машины во имя бизнес-процессов.
Если коротко суммировать то, что я написал - все зависит от конкретного проекта, его специфики, масштабов, конкретной студии, которая его разрабатывает и итоговых целей этого проекта. Где-то можно пожертвовать половину бюджета кадра ради того, чтобы студии было проще жить, где-то предпочтение нужно отдать производительности проекта. Отсюда выбирается уже методология и подходы работы.
Такой подход используется в том числе и в казуальных играх, правда, в чуть меньших масштабах. Основная проблема - сложнее поддерживать и изменять такой код. В геймдеве в течение недели могут приходить правки по игровой механике, которые сравнимы с тем, чтобы переписать все заново. Поэтому в геймдеве часто встречается низкокачественный код, что ведет к очевидным ошибкам даже на банальном манипулировании объектами в куче. То, что Вы описали, чаще всего, применяется в каких-то частных случаях. Например, при оптимизации какой-либо подсистемы, которая уже точно будет существовать в каком-то плюс-минус определенном виде. edit: к слову, насчет умных указателей и иже с ними: в Unreal Engine они активно используются, а это игровой движок, который по праву можно назвать флагманом среди аналогичных разработок.
Ваш довод имеет право на жизнь и я с ним, скорее, согласен, чем нет. Но нельзя исключать человеческий фактор, который накладывается на сверхсжатые сроки реализации геймплея. Внизу фрагмент кода, который я наблюдал не на одном игровом проекте.
Entity* gameObject = Engine::createGameEntity(/* some args */);
// some gameplay logic here
..............................
// some code inside multiple if statemets
{
delete gameObject;
}
..............................
// and here we go again
if(gameObject)
gameObject->SomeFunc();
Проблема ли это движка? Нет. Но если бы движок форсировал использование умных указателей для таких сущностей, то большинства ошибок от банальной невнимательности можно было бы избежать. Это не оправдание, конечно, суровых реалий геймдева, но иногда приходится искать баланс между "правильно" и надо еще вчера.
Значит, вокруг вас не сформировано окружение, где было бы комфортно откровенно разговаривать. И это ведет нас снова к тому, что отсутствуют навыки формирования такого окружения.
Как по мне, это говорит только об одном - отсутствии навыков искать нужных людей и заводить хорошие знакомства. Отсюда выливается все остальное.
Когда нет навыков по социализации с людьми, с которыми комфортно, тогда действительно нужен суррогат.
Нет времени вдумчиво читать статью, нужно работать.
В том же и идея, что код работает как надо. Если код пропускает часть вычислений, то он не работает как нужно, а значит, код не выполняет свою задачу.
Если же код выполняет свою задачу, никому не интересно, работает ли он быстрее ожидаемого.
Не знаком с OpenCV, но, кажется, со стороны C# можно было вызывать методы из DLL?
Каким образом этот вопрос связан с пониманием оптимизации и чрезмерной оптимизацией вообще? Тут варианта всего два - либо код корректно выполняет возложенную на него задачу, либо не выполняет. Если он корректно выполняет задачу, то о какой оптимизации вообще может идти речь?
Или это какой-то очень странный способ вытащить кандидата на разговор о поддержке оптимизированного кода?
>На чистом ассемблере
А вот это я бы с удовольствием почитал
Официальная документация говорит, что любой проект на Android обязан AndroidManifest.xml содержать в корневом каталоге. И это не по чьему-то субъективному мнению, а по вполне объективным требованиям проектов для Android
Опрос мне показался несколько ограничивающим.
Я считаю, что все эти пункты важны и вносят свой вклад в общую атмосферу. Невозможно создать атмосферу без синергии музыки, визуала, наличия некоторых философских элементов, нарратива, визуала и геймплея.
Конкретно в случае Firefly III радует то, что к нему есть некоторый API, который позволяет даже в случае прекращения поддержки реализовать свои пайплайны обработки данных даже на том же питоне. Плюс он self-hosted, что не может не радовать.
Кажется, что Ваша идея финансовой аналитики с помощью своих скриптов хорошо ложится на возможности этого инструмента. Звучит как тема для следующей статьи.
В любом случае, спасибо за статью!
Существует Firefly III. На мой взгляд, достаточно удобный инструмент для ведения личной бухгалтерии и некоторого рода аналитики (в основном, связанной с выходом за бюджет).
Пробовали им пользоваться? Если да, какие для себя обнаружили минусы?
Тема минусов и плюсов не раскрыта.
Понятно, что у готовых систем может не быть той гибкости, которая будет у пачки скриптов на питоне, но все-таки интересно было бы провести сравнение и более подробно остановиться на преимуществах и недостатках решений.
Изначально некорректно понял Ваш посыл. В такой постановке согласен.
Все верно. В целом, интересна судьба облачного гейминга - судя по тому, на что мы уже можем посмотреть, спрос на это пусть и есть, но не такой масштабный, если смотреть на игровой рынок в целом.
Почему ничего не делают?
Все симуляции, перемещения и любые другие операции выносят на сторону сервера. Помимо этого существуют разные механизмы дополнительной верификации, включая, но не ограничиваясь античитами. Почему Вы считаете, что с этим ничего не делают?
Технически, помогает, просто не со 100% эффективностью.
Часть читеров отсеивается банально на уровне сканирования памяти приложения, часть читеров будет отсеяна серверными проверками, часть поймает античит и статический анализ. Читеры и разработчики игр похожи на то, что происходит в информационной безопасности - обороняющаяся сторона всегда в догонябщем положении. Поэтому я сомневаюсь, что когда-либо в принципе настанет время совсем без читеров.
Дополню так же, что сервер и так обложен всеми проверками. Есть отдельные типы читов, создатели которых пытаются отреверсить логику работы сервера и находят разного рода уязвимости. Где-то это связано с ошибками обработки параметров от клиента, где-то находятся специфичные параметры, позволяющие проверки обойти и т.п. Не все так просто. Будь это так легко - античитов бы не было. Большая часть мультиплеерных игр и так не дает выполнять никаких операций на клиенте и все симуляции, включая перемещение, делаются на сервере.
Это никак не связано с оптимизацией. Это называется listen server и этот подход используется для того, чтобы не было необходимости хостить выделенный сервер, он же dedicated server.
Довод про то, что в этом случае античиты не помогут - это спорное заявление. Сильно зависит от типа античита, на каком уровне он работает (на уровне приложения или в kernel mode) и прочих параметрах. В целом, отследить использование читов в listen сервере возможно. Эффективно ли - вопрос.
upd: не указал еще про самый очевидный способ защиты - в клиентах игр очень часто используют так называемые "защищенные" значения, которые шифруются в памяти по определенным правилам, чаще всего используются обычные xor и сдвиги. Это позволяет в разы усложнить поиск значений в памяти приложения и, как следствие, ограничить использование программ навроде Cheat Engine. Но, опять же, это зависит от того, насколько хотят взломать - такие приемы уже давно научились распознавать и обходить по-своему.
Со сборкой мусора возникает резонный вопрос - зачем и по каким причинам ему отдается предпочтение, а не более, на первый взгляд, маловесной системе из умных указателей. Я не видел статей, которые бы сравнивали эти два варианта менеджмента памяти на каких-то реальных или около реальных кейсах.
Насчет нуля абстракций и простоты логики - это все зависит сильно от проекта, на самом деле. Где-то да, это даст максимальную простоту, а где-то это в итоге приведет к ненужным усложнениям во имя "оптимизации". К тому же важно помнить, что игровые студии предпочитают экономить не ресурсы компьютера, а время сотрудников. Так что вопрос такой, не самый простой и от случая к случаю можно получить очень разные мнения и результаты.
Я работал с чем-то отдаленно похожим на ECS. В плане производительности нареканий не было совершенно, но иногда уходило прилично времени на то, чтобы найти нужный компонент и нужную систему для того, чтобы внести в них правки. Но т.к. проект требовал множества сущностей одномоментно, это был разумный компромисс.
В целом, так уж получается, что подходы подстраивают под нужды и цели бизнеса, а не наоборот. Отсюда, в общем-то, появляются всякие абстракции, библиотеки (и движки тоже) и все движется к тому, чтобы можно было взять любого программиста на стеке Х и безшовно заменить его на другого из этого же стека. Мое личное мнение, что именно на этом все завязано. Именно отсюда идут корни всяких книг навроде "Чистый код" Роберта Мартина, именно поэтому мы начинаем жертвовать ресурсы машины во имя бизнес-процессов.
Если коротко суммировать то, что я написал - все зависит от конкретного проекта, его специфики, масштабов, конкретной студии, которая его разрабатывает и итоговых целей этого проекта. Где-то можно пожертвовать половину бюджета кадра ради того, чтобы студии было проще жить, где-то предпочтение нужно отдать производительности проекта. Отсюда выбирается уже методология и подходы работы.
Такой подход используется в том числе и в казуальных играх, правда, в чуть меньших масштабах.
Основная проблема - сложнее поддерживать и изменять такой код. В геймдеве в течение недели могут приходить правки по игровой механике, которые сравнимы с тем, чтобы переписать все заново. Поэтому в геймдеве часто встречается низкокачественный код, что ведет к очевидным ошибкам даже на банальном манипулировании объектами в куче.
То, что Вы описали, чаще всего, применяется в каких-то частных случаях. Например, при оптимизации какой-либо подсистемы, которая уже точно будет существовать в каком-то плюс-минус определенном виде.
edit: к слову, насчет умных указателей и иже с ними: в Unreal Engine они активно используются, а это игровой движок, который по праву можно назвать флагманом среди аналогичных разработок.
Ваш довод имеет право на жизнь и я с ним, скорее, согласен, чем нет. Но нельзя исключать человеческий фактор, который накладывается на сверхсжатые сроки реализации геймплея. Внизу фрагмент кода, который я наблюдал не на одном игровом проекте.
Проблема ли это движка? Нет. Но если бы движок форсировал использование умных указателей для таких сущностей, то большинства ошибок от банальной невнимательности можно было бы избежать.
Это не оправдание, конечно, суровых реалий геймдева, но иногда приходится искать баланс между "правильно" и надо еще вчера.