Это да, но на днях видел вакансию middle C++ developer на "от 90К" с нехилыми требованиями. Откликов уже было больше тысячи! Куды крестьянину податься?? (с)
Упадёт. Но зато получишь лояльную на многие годы клиентскую базу. И как будто есть другие варианты повысить рентабельность. Если всегда слизывать только верхнюю пенку, долго на рынке не продержишься.
Смотрите мой ответ ниже (не там написал). Ну и async никаких прерываний не делает. И почти все случаи использования async/wait в ASP.NET, При написании контролёров и моделей, это вырождённый случай, когда async-функция вызывается сразу вместе с конструкцией wait.
Связана так, что чтобы что-то, любой user-level код, выполнить асинхронно, нужен другой поток. Низкоуровневые операции ввода-вывода не считаем, так как это не user-level код.
Но, вполне возможно, что async/await не рассчитаны на задачи (не заточены под), специфические для unity.
При таком подходе метод (Dispose) для высвобождения данных контейнера будет вызван автоматически при выходе из конструкции.
Не в этом дело. Если написать явный вызов Dispose, то он тоже вызовется "автоматически", то есть просто потому, что он там стоит. А дело в том, что тут Dispose вызовется даже если внутри блока код выкинет исключение.
Прочитал пока только начало, но уже несколько комментариев.
1) Для обработки множества задач на ограниченном количестве потоков в C# придуман async/await. Может, unity.jobs был придуман до этого?
2)
Используя структуры для работы с Unity Job System, мы обходим стороной проблему гонки состояний
Не катит, от слова совсем. Если объектом хоть как-то пользуются несколько потоков и хотя бы один поток его изменяет, то вместо race condition для классов мы имеем N копий объекта для структур, что вообще не имеет смысла - все потоки, кроме изменяющего, вообще никогда не видят никаких изменений объекта. А если им и не надо их видеть, то это значит, что объект используется локально в одном потоке и проблемы многопоточности тут вообще ни при чем. Тогда остаётся единственное преимущество структур - они не требуют работы с кучей (heap).
3)
Для многопоточной среды это неприемлемо, поскольку джобы должны обращаться к памяти по фиксированным адресам.
Ничего джобы не должны и прекрасно могли бы обращаться к managed объектам, которые двигаются в памяти сборщиком мусора. Причина тут какая-то другая. Автор, вы как-то плаваете в базе дот-нета.
Есть простая вещь, ROI - сколько денежки мы получим, если потратим одну денежку на конретную фичу (например, на возможность поменять позицию кпонки или на разные цветовые гаммы интерфейса). И всё. Если выгодно захватить крылья распределения пользователей, то захватыаем, тратясь на доп. функциональность. По идее. По уму. Но вот где тот ум, это уже другая история.
Комментарии были не про жизнь, а про конкретный пример - колесо на видео, а видео имеет частоту, кадры в секунду. Вот из-за этой частоты и возникает стробоскопический эффект. Все очень конкретно и понятно.
Это да, но на днях видел вакансию middle C++ developer на "от 90К" с нехилыми требованиями. Откликов уже было больше тысячи! Куды крестьянину податься?? (с)
Это асе верно, но... про автоматизацию тестирования вы слышали?
Покажите слово "забыть" у меня. Или слова "нельзя встраивать".
Упадёт. Но зато получишь лояльную на многие годы клиентскую базу. И как будто есть другие варианты повысить рентабельность. Если всегда слизывать только верхнюю пенку, долго на рынке не продержишься.
Оптимизация способности входить и выходить в/из холодильника.
Это абсолютно логично, если на каждый вложенный 1 руб ты получаешь хотя бы 5 копеек чистой прибыли (в квартал, например).
В пивом уже решено - по 1 и 1.5 л продают почти во всех магазинах. Осталась малость, потребовать всё остальное.
Нелогично, если допольтельные 20% усилий удовлетворят ещё 5% пользователей, но это будет экономически выгодно.
Потребовать лишнее пиво?)
Смотрите мой ответ ниже (не там написал). Ну и async никаких прерываний не делает. И почти все случаи использования async/wait в ASP.NET, При написании контролёров и моделей, это вырождённый случай, когда async-функция вызывается сразу вместе с конструкцией wait.
Ладно, убедили)
Связана так, что чтобы что-то, любой user-level код, выполнить асинхронно, нужен другой поток. Низкоуровневые операции ввода-вывода не считаем, так как это не user-level код.
Но, вполне возможно, что async/await не рассчитаны на задачи (не заточены под), специфические для unity.
4)
Не в этом дело. Если написать явный вызов Dispose, то он тоже вызовется "автоматически", то есть просто потому, что он там стоит. А дело в том, что тут Dispose вызовется даже если внутри блока код выкинет исключение.
Прочитал пока только начало, но уже несколько комментариев.
1) Для обработки множества задач на ограниченном количестве потоков в C# придуман async/await. Может, unity.jobs был придуман до этого?
2)
Не катит, от слова совсем. Если объектом хоть как-то пользуются несколько потоков и хотя бы один поток его изменяет, то вместо race condition для классов мы имеем N копий объекта для структур, что вообще не имеет смысла - все потоки, кроме изменяющего, вообще никогда не видят никаких изменений объекта. А если им и не надо их видеть, то это значит, что объект используется локально в одном потоке и проблемы многопоточности тут вообще ни при чем. Тогда остаётся единственное преимущество структур - они не требуют работы с кучей (heap).
3)
Ничего джобы не должны и прекрасно могли бы обращаться к managed объектам, которые двигаются в памяти сборщиком мусора. Причина тут какая-то другая. Автор, вы как-то плаваете в базе дот-нета.
Есть простая вещь, ROI - сколько денежки мы получим, если потратим одну денежку на конретную фичу (например, на возможность поменять позицию кпонки или на разные цветовые гаммы интерфейса). И всё. Если выгодно захватить крылья распределения пользователей, то захватыаем, тратясь на доп. функциональность. По идее. По уму. Но вот где тот ум, это уже другая история.
Что-что? Ссылочку про недоразвитость можно?
Покажите исследования, где катаракта и прочие развиваются от монитора или телефона. А пока будем считать это модным хайпом.
Комментарии были не про жизнь, а про конкретный пример - колесо на видео, а видео имеет частоту, кадры в секунду. Вот из-за этой частоты и возникает стробоскопический эффект. Все очень конкретно и понятно.
Это как аборигены строили американские самолёты из говна и палок? (карго культ)
А вроде как DeepSeek гораздо меньше ест ресурсов, нет?