На фотке вижу аккум BL-5C(B?). Прямо не верится, ведь в миллионе новых девайсов — миллион новых батарей, а тут единый стандарт! Аж слезы навернулись. Обязательно куплю!
полностью неверно. на хорошем железе за счет большего числа конвейеров или более быстрой памяти, могут работать вещи, которые на «обычных» видеокартах убьют производительность в ноль. Вспомните, как во времена Oblivion проседала производительность с HDR и как это стало на новых картах через год-два. Девелоперов надо изредка сажать на минимально возможное железо, тогда они сделают проект играбельным и на нем.
Куда деваются кадры, которые не попадают в Refresh Rate монитора? Ведь он 60Гц, а при 300фпс 4 из 5 кадров — просто бесполезно потраченное время и выделенное процессором тепло. Оптимизировать ради циферки, конечно, приятно, но уж лучше бы подобрали железо и тест, где из неиграбльных 20 fps получаются отлично играбельные 60.
Кстати, в копилку знаний, если компилятор, определяет, что в данном foreach обрабатываются только массивы (даже если мы его пропустили через ICollection), то IL код получается с перебором массива, без итератора и заметно более быстрый, чем если этот foreach иногда подхватывает и коллекции. Причем, нередко такой foreach еще и оптимальнее for для массивов. Для проверки сделайте метод, который берет ICollection на вход и несколько замеров с массивом, списком, списком + массивом по очереди.
На самом деле, можно сказать, что да.
Библиотеки NDK x86 сделаны в ходе сотрудничества Intel и Google и специально оптимизированы под Atom, да и некоторые энтузиасты уже пытаются собирать части своих NDK библиотек под icc
Слухи, слухи… А если не слухи, то человек слил важную приватную информацию, что тоже либо пиар, либо подстава.
В любом случае, никто не утверждает, что кодить игру будет именно Bethesda. С тем же успехом это может оказаться и GSC, и аутсорс в 4a games (они ближе к этому проекту, чем кто-либо еще), и какая-нибудь студия, поглощенная беседкой для таких вот разработок.
Например файловый I/O может быть синхронным, тогда для уменьшения негативных эффектов из-за временно заблокированных на дисковых операциях процессов/потоков имеет смысл держать большой пул.
Пример не ахти, производительность его будет не то, чтобы «не на высоте», а просто «ниже плинтуса». Зато, все I/O операции рано или поздно будут выполнены, хотя скорее «поздно». Асинхронное I/O тут гораздо уместнее.
Чуть более удачный пример это вызов тысяч БД запросов в куче потоков — при большом количестве insert/update/delete блокировки заставят большую часть потоков ждать и разблокироваться при необходимости. Правда, практика показывает, что все-равно это довольно медленно и если отсортировать команды на 3-4 потока, то можно получить гораздо лучшую производительность.
Ну а тестирование серверного софта на ноутбуке вообще вызывает сомнения. Судя по тексту статьи, автор как раз писал о юзерском ноутбуке.
Выглядит уродски — рассеивает внимание, показывает обрезанный контент, еще и в другом стиле и цветовой гамме.
Это как в раме картины оставлять справа немного места для списка других картин, биографии автора и покупки пиццы.
Во-первых, речь идет о не серверном п.о., судя по тестированию на клиентском ноутбуке Я специально это подчеркнул в своем посте. Для серверов еще как-то можно оправдать большим количеством задач/запросов.
Во-вторых, одновременное выполнение потоков, количество которых больше вычислительных ядер, требует остановок и Context Switching. Потому априори, на 2х процессорах с 2 ядрами будут быстрее работать 4 потока с очередью задач, чем 160 и переключением. Это основа серверного программирования — не выделять никогда каждому подключенному клиенту по одному потоку, не выделять никогда одной мелкой задаче по одному потоку.
Не зря в .Net 2.0 в Thread Pool был жесткий лимит на 25 потоков на ядро. В 4.0 уже пошла какая-то гибкая формула, что поощряет разработчиков не думая об архитектуре, а кидать сразу свои задачи в ThreadPool, а затем в реальных условиях начинаются тормоза, но код уже написан и оплачен, потому стараются масштабировать уже железо, а заодно ругать фреймворки, админов, инопланетян с Марса и пр.
Странно. В точности, как у .NET CLR, как будто он возвращает освободившиеся локальные переменные сразу в соответствующий пул, не дожидаясь GC
Уверен, так оно и есть. JIT может по своему усмотрению вызывать Gen 0 сборку для локальных out-of-scope объектов.
Generation 0 collections are the most frequently occurring type of collection and clean up short-lived objects such as local variables.
Что интересно, еще Рихтер писал, что если мы добавим для проверки финалайзер в наш класс (~Node()), то объект будет уже попадать в Gen 1, потому ничего толкового не выйдет.
Хорошо бы проверить с помощью Performance Counters, сколько было Gen 0 сборок на весь цикл. Ну и по-честному, надо было объекты добавлять в массив, чтобы избежать ситуации, когда на самом деле все 10000000 раз объект «создавался» по одному и тому же адресу.
Отдельное «фе» о цикле в С++, где мы создаем 10000000 объектов и теряем на них указатели. В статье об управлении памятью такой код должен быть помечен большими красными буквами: ТАК ДЕЛАТЬ НЕЛЬЗЯ.
Я извиняюсь, а зачем вообще не-серверной программе создавать 90+ потоков? Если они все работают одновременно, то ничего хорошего на 2-4 ядрах из этого не выйдет. Если они постоянно спят, то это просто ugly design. Если же потоки нужны для асинхронных вызовов (а-ля .Net I/O Thread Pool, где разрешено 1000 потоков), то возникает вопрос, почему так много вызовов не успело завершиться и вернуть поток в пул. К примеру, в .Net 1.1 было такое при зависании сокетов.
Как по мне, решение для Non-Consumable продаж есть довольно простое: никто не станет вечно пользоваться подставным DNS сервером, а значит программе достаточно раз в N дней обращаться к verifyRecipt странице, если есть подозрения на валидность покупки. Отличить подставную покупку от нормальной можно по app_id, который известен только разработчику.
Причем, если форсировать события и проверять при каждом запуске, мы только разозлим юзера провоцируя пользоваться «плохим» DNS, качать новые хаки, джейлить устройство и пр. Злость юзера уж точно денег не принесет, а так мы как-бы предоставляем ему N дней триала без карательных мер.
Update:
Пруф с IL листингом: abi.exdream.com/Blog/post/2009/04/22/For-vs-Foreach-Performance.aspx
Библиотеки NDK x86 сделаны в ходе сотрудничества Intel и Google и специально оптимизированы под Atom, да и некоторые энтузиасты уже пытаются собирать части своих NDK библиотек под icc
В любом случае, никто не утверждает, что кодить игру будет именно Bethesda. С тем же успехом это может оказаться и GSC, и аутсорс в 4a games (они ближе к этому проекту, чем кто-либо еще), и какая-нибудь студия, поглощенная беседкой для таких вот разработок.
Пример не ахти, производительность его будет не то, чтобы «не на высоте», а просто «ниже плинтуса». Зато, все I/O операции рано или поздно будут выполнены, хотя скорее «поздно». Асинхронное I/O тут гораздо уместнее.
Чуть более удачный пример это вызов тысяч БД запросов в куче потоков — при большом количестве insert/update/delete блокировки заставят большую часть потоков ждать и разблокироваться при необходимости. Правда, практика показывает, что все-равно это довольно медленно и если отсортировать команды на 3-4 потока, то можно получить гораздо лучшую производительность.
Ну а тестирование серверного софта на ноутбуке вообще вызывает сомнения. Судя по тексту статьи, автор как раз писал о юзерском ноутбуке.
Правда, все-равно бесполезно оказалось, потому что
«Номер PUK(указан на стартовом пакете)» за последние 10 лет уже как-то затерялся )
А если оператор не предоставляет личный кабинет? «На глаз» не всегда и определишь, как деньги со счета уходят (
Это как в раме картины оставлять справа немного места для списка других картин, биографии автора и покупки пиццы.
Во-вторых, одновременное выполнение потоков, количество которых больше вычислительных ядер, требует остановок и Context Switching. Потому априори, на 2х процессорах с 2 ядрами будут быстрее работать 4 потока с очередью задач, чем 160 и переключением. Это основа серверного программирования — не выделять никогда каждому подключенному клиенту по одному потоку, не выделять никогда одной мелкой задаче по одному потоку.
Не зря в .Net 2.0 в Thread Pool был жесткий лимит на 25 потоков на ядро. В 4.0 уже пошла какая-то гибкая формула, что поощряет разработчиков не думая об архитектуре, а кидать сразу свои задачи в ThreadPool, а затем в реальных условиях начинаются тормоза, но код уже написан и оплачен, потому стараются масштабировать уже железо, а заодно ругать фреймворки, админов, инопланетян с Марса и пр.
Уверен, так оно и есть. JIT может по своему усмотрению вызывать Gen 0 сборку для локальных out-of-scope объектов.
Что интересно, еще Рихтер писал, что если мы добавим для проверки финалайзер в наш класс (~Node()), то объект будет уже попадать в Gen 1, потому ничего толкового не выйдет.
Хорошо бы проверить с помощью Performance Counters, сколько было Gen 0 сборок на весь цикл. Ну и по-честному, надо было объекты добавлять в массив, чтобы избежать ситуации, когда на самом деле все 10000000 раз объект «создавался» по одному и тому же адресу.
Отдельное «фе» о цикле в С++, где мы создаем 10000000 объектов и теряем на них указатели. В статье об управлении памятью такой код должен быть помечен большими красными буквами: ТАК ДЕЛАТЬ НЕЛЬЗЯ.
Причем, если форсировать события и проверять при каждом запуске, мы только разозлим юзера провоцируя пользоваться «плохим» DNS, качать новые хаки, джейлить устройство и пр. Злость юзера уж точно денег не принесет, а так мы как-бы предоставляем ему N дней триала без карательных мер.