Сезонные (и другие естественные) колебания, и средняя температура — это разные вещи, и на климат второе влияет гораздо больше, чем первое.
В Сахаре ночью температура может опускаться до 0 градусов цельсия, но от этого она не перестает быть пустыней.
Во время последнего леднякового периода, когда большинство серверных регионов были покрыты ледяной шапкой в несколько километров толщиной, средняя температура на земле была всего на ~4 градуса целсия ниже текущей.
И поэтому foreach не нужно использовать никогда, игнорируя здравый смысл?
Даже с учетом того, что
1. В 99% случаев никакого прироста производительности это не даст
2. В оставшихся 1% случаев требуется, как вы сами сказали, «адаптированное решение», которое не всегда упирается в foreach и garbage collection
3. В Unity 5.5 обновили версию компилятора, и в будущих версиях будут обновлять версию runtime, и вы останетесь с исправленными багами но отвратительным кодом, с оптимизацией на спичках
У меня один вопрос — что вы делаете в мире C#? Пишите игры на С++, а лучше сразу на ассемблере. Там никакого garbage collect, только unmanaged код, только хардкор. Зато без лагов и без фризов.
Вы меня извините, но я не знаю что такое «ынтерпрайз», «коротинах» и «подхачивание».
Расшифровывать ваш «пацанский слэнг» мне, честно говоря, надоело.
Как компиляция кода во внешнюю сборку связана с геймдевом?
В серьезных проектах объем кода может быть такой, что компиляция редактором при малейших изменениях может занимать несколько минут. И спасает только внешняя компиляция.
Безусловно, если пытаться компилировать более высокой версией компилятора, то могут возникнуть проблемы. Это никак не означает, что геймдев разработка как-то отличается от любой другой в этом плане.
Ну так и есть, лаги-фризы, как и говорил, ничего нового.
Закончились аргументы — начались голословные утверждения с переходом на личности. Ничего нового.
Если вы не понимаете, что свойства используются для инкапсуляции и если вы захотите изменить поле на свойство то вы сломаете обратную совместимость с уже скомпилированным кодом, который использует этот класс, то мне вас жаль.
Ах, да, я забыл, у вас же свой геймдев, без компиляции кода в dll, без повторного использования кода.
В таком случае прячьтесь под кровать — мы в компании выпустили около 15 мобильных игр и приложений, все из них — 3D, все из них отлично работают на low-end устройствах, выдавая стабильный FPS даже на самых дерьмовых девайсах. Да — с использованием строк, foreach и свойств.
Мне вот страшно, если вы и ваш друг прийдете в программирование со своими советами бездумно никогда не использовать строки и foreach. Проблема Unity (как и у php в свое время) в том, что из-за низкого порога вхождения начинают появляться вот такие вот кадры со своими советами и своими псевдо знаниями о том, как работает mono или gc, которые на самом деле были вычитаны из статей от таких же кадров.
Давайте разберем по-порядку.
«cg memory allocation в foreach»
Во-первых, это верно лишь в некоторых случаях. При работе с массивами компилятор развернет foreach в обычный for loop.
Во-вторых, It's not the size that matters, it's how you use it. Вопрос в том, когда это становится проблемой. На моей практике это становится проблемой, когда вы начинаете бездумно фигачить foreach с сотнями итераций в Update цикл. Опять же — проблема не в foreach а в вас.
В-третьих, допустим, есть действительно случаи, когда нужно сделать тяжелый foreach в каждом Update цикле, и его имеет смысл заменить на for. Такие случаи редкие, но встречаются, и иногда так имеет смысл делать. Но говорить, что «Просто не использовать foreach — это самое простое и правильное что можно сделать» — это же полный бред.
Тоже самое со свойствами и строками. Есть случаи, когда от них стоит отказаться. Но такие случаи крайне редки, и говорить что «имеет смысл ВООБЩЕ отказаться от строк и свойств» — это ахинея и за такие советы надо просто бить по рукам.
Понимаете, есть разница между тем, что говорите вы: «Кешируйте результат GetComponent() если он нужен в каждом Update цикле», и тем, что говорит автор: «Кешируйте все, что вы получаете через GetComponent<>».
А еще это не надо делать в Update loop, а можно делать фиксированное количество раз в секунду. Оптимизировать конкретную задачу можно разными способами. Наилучший способ оптимизировать 50 тысяч вызовов свойств в Update, это не делать 50 тысяч вызовов свойств в update а не отказываться от свойств. Хотя я в вашем примере так и не увидел необходимости делать 50к вызовов свойств в каждом update цикле.
Почти все советы оптимизации по CPU — это реально «вредные советы», и в целом, ахинея. Лучше удалите этот бред, а то сейчас новички начитаются и пойдут лепить код без свойств, строк и foreach.
Вы, конечно, тут кидаетесь результатами синтетик тестов, мол, вот доступ к свойствам в 10 раз быстрее, чем доступ к полю. Только вы не учитываете, какой процент нагрузки на CPU реально занимает игровая логика, а какой — логика движка. Нет никакого смысла заранее писать код без свойств, если в 99.9999% случаев этот код будет вызываться одноразово, а не в Update. Это называется оптимизация на спичках.
Возьмем следующее утверждение:
Инстанциирование объектов является очень тяжелой операций, поэтому стоит для частых созданий использовать пул объектов и затем их переиспользовать.
С одной стороны, вы, конечно, правы. Инстанциирование объектов — это тяжелая операция. Но на моей практике использовать пул объектов мне пришлось лишь 1 раз — когда надо было удалять и инстанциировать около сотни объектов в Update. В остальных 99% случаев об этом даже не надо думать. А это утверждение, наверное, единственное адекватное из списка по CPU.
Мне, честно говоря, страшно представить, что вы делали в своей игре, если вам пришлось оптимизировать отказом от использования foreach, свойств и строк. Если у вас в игре сотни тысяч объектов, каждый из которых использует свойство в Update, то это не свойства медленные, это вы что-то делаете не так.
Да, я действительно считаю, что антивирусная индустрия строится на «корявой системе пользователей». Другие системы не идеальны, но безусловно лучше. В прочем, в последних версиях Windows почти исправилась.
Я считаю что будущее за операционными системами, в которых приложения и программы проходят премодерацию, и при этом по умолчанию запускаются в своей песочнице, и для доступа к файлам и другим ресурсам должны получить явное разрешение от пользователя.
Мне самому, как разработчику и человеку привыкшему к экосистеме Windows это не нравится, но то что к этому все идет — факт. Как только современные ОС примут эту систему и сделают ее по умолчанию, антивирусная индустрия в массе своей умрет. Останутся корпоративные антивирусы, разве что.
Как иронично. Люди, полностью построившие свой бизнес исключительно за счет наличия в windows корявой системы пользователей и за счет пофигизма при разработке ранних версий, теперь подают в суд на Microsoft.
Значит этот асус — говно, и его надо выкинуть. У всех есть устройств есть проблемы, но одно дело когда эта проблема несущественна и в целом понятна, а другое дело — когда проблема не дает использовать продукт по назначению.
Early 2010?
Отлично. А теперь предлагаю вам провести небольшой эксперимент. Покупаете самую дешевую беспроводную мышку от Logitech с Nano Receiver'ом.
Устанавливаете на Macbook какую-нибудь игру типа Starcraft II или Diablo 3.
Запускаете игру. Вставляете Nano Receiver в порт. Наблюдаете как FPS который выдает видеокарта падает с 60 до 5-10.
Если я не ошибаюсь, эта аппаратная проблема присутствует во всей линейке макбуков 2010 года.
Я по ссылке вижу адаптеры.
Ладно, я думаю, вы прекрасно поняли, о чем я говорю. Если вы со мной не согласны можете аргументировать свою позицию, а не кидать мне ссылки на гугл где показаны адаптеры между двумя портами и говорить что они обратно совместимы.
USB Type-c имеет обратную совместимость с USB 3.X.
А я-то думал, что обратная совместимость — это когда можно воткнуть старый usb кабель в новый порт (и наоборот), как это можно сделать с USB 3.0 Type A и USB 2.0 Type A. Без переходников, адаптеров, итд.
Видимо, какие-то у вас свои представления об обратной совместимости.
Год назад про USB Type-c никто ничего не слышал, стоило Apple ввести USB Type-c, так теперь он «Ближайшее время USB Type-c станет стандартом везде».
Спешу вас разочаровать — не станет. То есть может, конечно, и станет, но точно не в ближайшее время. Производители устройств, которые в отличии от Apple дорожат своими покупателями, никогда не будут полностью убирать поддержку стандартного usb. А это значит, что все перифирийные устройства вроде мышек, клавиатур, будут выпускать с USB. И максимум что они будут делать — это класть переходник в коробку.
А это значит, что производители ноутбуков и материнских плат точно так же не будут отказывтаься от стандартного USB.
Вы меня поймите правильно — я всеми руками за то, что бы избавиться от громоздких USB.
Только вот рынок так не работает. Эволюция (вроде USB 3.0 с его обратной совместимостью) как правило происходит гораздо быстрее и стабильнее чем революция.
Отличный пример — HDMI, который вышел 15 лет назад. Люди до сих пор пользуются уродливыми VGA и DVI.
А что уж к такому будущему? Можно сразу отказаться от любых разъемов, и сделать любые подключения к ноутбуку (в том числе мониторы) беспроводным. Ведь в этом будущем проводов вообще не будет, или вы в этом сомневаетесь?
Есть грань между поддатлкиванием к будущему и потерей реальности. Я, например, ни сколько не был удивлен, когда убрали dvd привод; в моем десктопном ПК я выпилил его за ненадобностью много лет до того как Apple перестала его ставить в макбуки. Отсутствие Ethernet порта — это боль, т.к. во многих гостиницах до сих пор можно встретить ethernet розетки вместо нормального вайфая. Но это можно пережить.
То, о чем говорите вы — это потеря реальности. Вы мне покажите монитор, который подключается по USB-C, да еще и который можно подключить один к другому. Таких сегодня не существует.
А что, если я не хочу ставить глючный и не нужный мне iTunes и не хочу делать никакую синхронизацию? Я хочу просто получить доступ к своему устройству, и без джейлбрейков не могу этого сделать.
Вы поймите, я не пытаюсь тут кого-то троллить. Я ведь пытался привыкнуть к экосистемe apple. Пытался пользоваться iTunes. Но он неудобный, глючит, а альтернативы Apple не дает. Отсутствие конкуренции и third party software в экосистеме Apple делает ненужным развитие и улучшение продуктов.
В Сахаре ночью температура может опускаться до 0 градусов цельсия, но от этого она не перестает быть пустыней.
Во время последнего леднякового периода, когда большинство серверных регионов были покрыты ледяной шапкой в несколько километров толщиной, средняя температура на земле была всего на ~4 градуса целсия ниже текущей.
По-моему, вы пишите:
Даже с учетом того, что
1. В 99% случаев никакого прироста производительности это не даст
2. В оставшихся 1% случаев требуется, как вы сами сказали, «адаптированное решение», которое не всегда упирается в foreach и garbage collection
3. В Unity 5.5 обновили версию компилятора, и в будущих версиях будут обновлять версию runtime, и вы останетесь с исправленными багами но отвратительным кодом, с оптимизацией на спичках
У меня один вопрос — что вы делаете в мире C#? Пишите игры на С++, а лучше сразу на ассемблере. Там никакого garbage collect, только unmanaged код, только хардкор. Зато без лагов и без фризов.
Через пару десятков комментариев, вы наконец поняли, о чем я говорю.
Расшифровывать ваш «пацанский слэнг» мне, честно говоря, надоело.
В серьезных проектах объем кода может быть такой, что компиляция редактором при малейших изменениях может занимать несколько минут. И спасает только внешняя компиляция.
Безусловно, если пытаться компилировать более высокой версией компилятора, то могут возникнуть проблемы. Это никак не означает, что геймдев разработка как-то отличается от любой другой в этом плане.
Закончились аргументы — начались голословные утверждения с переходом на личности. Ничего нового.
Если вы не понимаете, что свойства используются для инкапсуляции и если вы захотите изменить поле на свойство то вы сломаете обратную совместимость с уже скомпилированным кодом, который использует этот класс, то мне вас жаль.
Ах, да, я забыл, у вас же свой геймдев, без компиляции кода в dll, без повторного использования кода.
В таком случае прячьтесь под кровать — мы в компании выпустили около 15 мобильных игр и приложений, все из них — 3D, все из них отлично работают на low-end устройствах, выдавая стабильный FPS даже на самых дерьмовых девайсах. Да — с использованием строк, foreach и свойств.
Мне вот страшно, если вы и ваш друг прийдете в программирование со своими советами бездумно никогда не использовать строки и foreach. Проблема Unity (как и у php в свое время) в том, что из-за низкого порога вхождения начинают появляться вот такие вот кадры со своими советами и своими псевдо знаниями о том, как работает mono или gc, которые на самом деле были вычитаны из статей от таких же кадров.
Давайте разберем по-порядку.
«cg memory allocation в foreach»
Во-первых, это верно лишь в некоторых случаях. При работе с массивами компилятор развернет foreach в обычный for loop.
Во-вторых, It's not the size that matters, it's how you use it. Вопрос в том, когда это становится проблемой. На моей практике это становится проблемой, когда вы начинаете бездумно фигачить foreach с сотнями итераций в Update цикл. Опять же — проблема не в foreach а в вас.
В-третьих, допустим, есть действительно случаи, когда нужно сделать тяжелый foreach в каждом Update цикле, и его имеет смысл заменить на for. Такие случаи редкие, но встречаются, и иногда так имеет смысл делать. Но говорить, что «Просто не использовать foreach — это самое простое и правильное что можно сделать» — это же полный бред.
Тоже самое со свойствами и строками. Есть случаи, когда от них стоит отказаться. Но такие случаи крайне редки, и говорить что «имеет смысл ВООБЩЕ отказаться от строк и свойств» — это ахинея и за такие советы надо просто бить по рукам.
Вы, конечно, тут кидаетесь результатами синтетик тестов, мол, вот доступ к свойствам в 10 раз быстрее, чем доступ к полю. Только вы не учитываете, какой процент нагрузки на CPU реально занимает игровая логика, а какой — логика движка. Нет никакого смысла заранее писать код без свойств, если в 99.9999% случаев этот код будет вызываться одноразово, а не в Update. Это называется оптимизация на спичках.
Возьмем следующее утверждение:
С одной стороны, вы, конечно, правы. Инстанциирование объектов — это тяжелая операция. Но на моей практике использовать пул объектов мне пришлось лишь 1 раз — когда надо было удалять и инстанциировать около сотни объектов в Update. В остальных 99% случаев об этом даже не надо думать. А это утверждение, наверное, единственное адекватное из списка по CPU.
Мне, честно говоря, страшно представить, что вы делали в своей игре, если вам пришлось оптимизировать отказом от использования foreach, свойств и строк. Если у вас в игре сотни тысяч объектов, каждый из которых использует свойство в Update, то это не свойства медленные, это вы что-то делаете не так.
Я считаю что будущее за операционными системами, в которых приложения и программы проходят премодерацию, и при этом по умолчанию запускаются в своей песочнице, и для доступа к файлам и другим ресурсам должны получить явное разрешение от пользователя.
Мне самому, как разработчику и человеку привыкшему к экосистеме Windows это не нравится, но то что к этому все идет — факт. Как только современные ОС примут эту систему и сделают ее по умолчанию, антивирусная индустрия в массе своей умрет. Останутся корпоративные антивирусы, разве что.
Отлично. А теперь предлагаю вам провести небольшой эксперимент. Покупаете самую дешевую беспроводную мышку от Logitech с Nano Receiver'ом.
Устанавливаете на Macbook какую-нибудь игру типа Starcraft II или Diablo 3.
Запускаете игру. Вставляете Nano Receiver в порт. Наблюдаете как FPS который выдает видеокарта падает с 60 до 5-10.
Если я не ошибаюсь, эта аппаратная проблема присутствует во всей линейке макбуков 2010 года.
Сегодня 2016й год, а проблемы все те же, на некоторых новых макбуках wifi не может одновременно работать с некоторыми usb 3.0 устройствами
Но основной кайф не в том что есть проблема, а в том что Apple эти проблемы никогда не признаёт и не пытается их исправить.
Ладно, я думаю, вы прекрасно поняли, о чем я говорю. Если вы со мной не согласны можете аргументировать свою позицию, а не кидать мне ссылки на гугл где показаны адаптеры между двумя портами и говорить что они обратно совместимы.
А я-то думал, что обратная совместимость — это когда можно воткнуть старый usb кабель в новый порт (и наоборот), как это можно сделать с USB 3.0 Type A и USB 2.0 Type A. Без переходников, адаптеров, итд.
Видимо, какие-то у вас свои представления об обратной совместимости.
Спешу вас разочаровать — не станет. То есть может, конечно, и станет, но точно не в ближайшее время. Производители устройств, которые в отличии от Apple дорожат своими покупателями, никогда не будут полностью убирать поддержку стандартного usb. А это значит, что все перифирийные устройства вроде мышек, клавиатур, будут выпускать с USB. И максимум что они будут делать — это класть переходник в коробку.
А это значит, что производители ноутбуков и материнских плат точно так же не будут отказывтаься от стандартного USB.
Вы меня поймите правильно — я всеми руками за то, что бы избавиться от громоздких USB.
Только вот рынок так не работает. Эволюция (вроде USB 3.0 с его обратной совместимостью) как правило происходит гораздо быстрее и стабильнее чем революция.
Отличный пример — HDMI, который вышел 15 лет назад. Люди до сих пор пользуются уродливыми VGA и DVI.
Есть грань между поддатлкиванием к будущему и потерей реальности. Я, например, ни сколько не был удивлен, когда убрали dvd привод; в моем десктопном ПК я выпилил его за ненадобностью много лет до того как Apple перестала его ставить в макбуки. Отсутствие Ethernet порта — это боль, т.к. во многих гостиницах до сих пор можно встретить ethernet розетки вместо нормального вайфая. Но это можно пережить.
То, о чем говорите вы — это потеря реальности. Вы мне покажите монитор, который подключается по USB-C, да еще и который можно подключить один к другому. Таких сегодня не существует.
Вы поймите, я не пытаюсь тут кого-то троллить. Я ведь пытался привыкнуть к экосистемe apple. Пытался пользоваться iTunes. Но он неудобный, глючит, а альтернативы Apple не дает. Отсутствие конкуренции и third party software в экосистеме Apple делает ненужным развитие и улучшение продуктов.