kirill_rrr

Надо сначала узнать где у них бутылочные горлышки. Явно не в самой игре, там полных системных треования ДОС+Дум настолько мало, что одного ядра зен5 должно хватить на 1000 копий.

Боюсь тут нужен 18-и ядерный процессор. Или 37-ядерный. Иначе порталы в ад не откроются.

После Рождественных Подарков микрокод начали писать (наконец то!) так, чтобы все эти кеши кода для разных процессов не пересекались. Так что ему придётся без чудес быстро-быстро переключать и перекешировать по 4 скопейками потоков на ядро (что кстати не много, у меня даже кортекс-А53 справляется).

>>но и за счёт многоядерности и даже многопроцессорности.

Чем ещё надо грамотно и с пользой распорядиться! Что на самом деле встречается редко. Да собственно и задача то не простая и сам по себе паралелизм даётся не бесплатно — кучу работы надо сделать чтобы породить поток, поделить данные и объединить результаты.

>>Опять же сам факт внедрения таких ядер показывает что так наращивать производительность эффективней.

В каком нибудь 7-зипе да...
Но вот игровая производительность интелов 12-14 поколений i5-i7-i9 (заметь, как 6-и, так и 8-и ядерных!) распределялась практически идентично однопоточной производительности Р-ядра, которая в свою очередь зависела от того максимума частоты, который мог взять данный конкретный чип в силу настроек и качества кристалла.

А у амд — куча факторов, но в итоге всё сводилось к «бери самый быстрый одночиплетный». Что дошло до маразма в ризен 7900Х3Д, в котором для УСКОРЕНИЯ игровой производительности лишний чиплет и 8 ядер отключали. Официально одобренным способом! Я просто не в курсе подробностей 9950Х3Д, отключают или нет и какая разница.

>>При этом для работы на подобных скоростях у нас нынче 4 32 битных канала.
>>Вы эти каналы ещё развести на плате должны. Но и phy т.е. физический интерфейс в чипе.

Тут есть противоречие! С одной стороны гоняем данные пакетами по 4-8 байт с 64-битным адресом, а с другой начинаем изобретать режимы как бы поделить эти лишние провода на 4 канала поменьше...

Я не слышал чтобы там пробовали использовать всякие разные асинхронные варианты, деление на регионы, страничный доступ, физическое деление на мелкие каналы (логическое требует больше рассчётов, да и объединение малых каналов в большой всегда было проще), сжатие адреса или передачу адрес-данные за 2 такта.
Или например можно бы уже оптику применить. С одной стороны частоты ± сравнялись, а с другой оптика позволяет физически по 1 линии одновременно передавать 1 бит в одну сторону + 1 бит в обратную.

>>И этот алгоритм учитывает нагрев просто факт. Как и учитывает маркировку ядер.

Вы крайне сильно переоцениваете планировщики. Во первых там не какие то боги их делают и на проверку оказывается что интел внедряет самоочевидные вещи по 3-5 лет (например на релизе 12 поколения планировщик винды бодро кидал задачи на Е-ядра при пустых Р-ядрах)(а для вин10 так и не вышло финальной версии планировщика с грамотным порядком распределния) и только на 1 ОС из ~4, а во вторых там объективные требования чтобы алгоритм планировщика не был сложнее и дольше микро- или нано-секунд.

>>я никаких фризов при бусте не припомню.

Если у вас и так частота 120+, то лаги до 60 могут быть не заметны глазу. Но если настройки графики выставлены так, что там 60 с трудом, тогда лаги и фризы становятся болезнью.

И больше всего лагов и фризов я огрёб в 2-х играх, многопоточной версии HL2 под линукс и Ассасин БлэкФлаг под виндой, обе на амд А6 2,9ГгЦ с бустом до 3,5. Таким жирным бустом, что прям вентилятор прыгал на 1 дополнительный режим вверх. Отключение буста настолько явно увеличивало плавность. что снижение потребления было вообще второстепенным.

Вообще в принципе, любые непредсказуемые скачки производительности потока дают в играх фризы. Также экспериментально подтверждено (знакомым, которому 100% доверяю), что игры уровня киберпанка2077 на ризен 2600 идут значительно плавнее при отключении гиперпоточности. Некоторые, с очень малой нагрузкой на цпу в 1-2 потока — не подвержены эффекту, но большинство да.

>>А я открою вам тайну она всегда не стабильная. То что вы видите в мониторинге это не фактическая частота

Если ты отключаешь полностью автоматический режим и ставишь жёсткие лимиты вместо буста — она становится стабильной в пределах 0,1% колебаний. И производительность потока тоже почти не прыгает. И планировщику не надо перекидывать задачи с тротлящих ядер на полноскоросные. И вообще физически становится возможным распаралелить задачи так, чтобы они предсказуемо завершились.

>>Концентрация тепла на единицу площади ниже, отводить с большей площади проще = холоднее.

Ты не думаешь, что важной единицей площди может стать радатор а не термоинтерфейс чиплет-крышка? И тогда этобудет экономия на спичках, а особенно неважным это становится при температурах ниже 70-75.

>>Условные несколько потоков на 40… 60 остальные по 20...30

Хочешь сказать ни одного потока на 100%? Или ты простосмотришь на 1-секундном интервале? Или там реально процессор 40% времени нихрена не делает?
И нет, я не побегу ставить недогта с требованиями киберпанка. Слишком жирно и долго на просто посмотреть, да и цпу-трассера у меня нету.

Кстати, держать ядро под 20% нагрузкой это энергитически очень накладно во все времена и на любых архитектурах. Ну кроме нескалярных 8086...80286

>>Задержка у памяти в достигает ну 70нс. 5ггц это 5 тактов за 1нс. Итого 350 тактов.

Подожди, а как же тайминги памяти порядка 30-50? Если это конечно не самая форсированная ддр5 с собственным таймером, берущая рубеж 8ГГц. Да, это такты памяти, но сейчас такты процессора где то близко. а не в соотошении 50 к 350.

>>Если что межъядерная задержка внутри чиплета 20нс, при обращении ко второму чиплету 70нс. Все. Т.е. разница меньше чем при доступе к ОЗУ.

Да, а какой она должна быть? Особенно когда интел в 13-14 поколениях стабильно держал 15-20мс от любого ядра к любому независимо от чиплетов.

>>А тренингом зачем вам заниматься?

Не трейнингом а трекингом. Чтобы в очень малом масштабе увидеть как именно грзился цпу и в каких режимах частот. Подробные достоверные данные, а не средняя температура по больнице.

>>это точно. И тут даже обсуждать то нечего. У вас каждый проц многоядерный так ещё и суперсеплярный.

Суперскаляр суперскаляру рознь. Какой нибудь атом n270 мог выполнять 2 инструкци на такт в теории, а на практике в среднем мог только 1,1 т.к. всякие предсказатели и переупорядочивали были порезаны в ноль, а конвееры в жёстком дефиците. А вот например ФХ-8150 в синтетической задаче «много раз посчитать x+1 над ячейками огромного массива» показал уже 10,5 циклов чтение-сложение-запись на 1 такт процессора. После чего ядра стали ещё раз в 10 круче.

Но внутренняя кухня ядра по извращениям над кодом не имеет отношенния к вопросу. В ядро подаётся последовательный поток команд и оно всеми силами делает вид как будто он там последовательно выполняется. Вот и мы можем смотреть на 1 поток на 1 ядре как на однопоточный процесс.

Если какая то там игра грузит 16 потоков это не значит что хотя бы половина грузит 8. Правило «90% игр не получают заметного буста выше 6 ядер» всё ещё действует.

ВАУ…

Именно это они и хотели сделать в ~2020 году. Добротный кастомизируемый каркасник со средненькой батареей и мотором где то между 50 и 100 лошадей. Цену обещали куда то в район Весты или чуть дороже, выглядело в принципе приемлимым. И машинка была не жирной а примерно с Гетз.

Гуглодизайн не отменили, темы не вернули, цвета не вернули, значит уродское.

Если смартфон 2009 на 2 порядка удобнее смартфона из 2025… то смартфон из 2009 просто на 2 порядка удобнее смартфона из 2025. Это факт. Можно смириться с этим и жрать говно или попытаться хоть что то сделать со смартфоном 2025 года.

>>Андроид уже сто лет полностью настраиваемый из коробки

Будь добр, или не звизди, или покажи мне в своём полностью настраиваемом переключалку тем оформления с настройкой масштаба, шрифта и цветов. Или хотя бы где в ланчере включается вызов меню приложений в 1 касание кнопки.

>>Там нет ничего уродского и при желании можно всё настроить.

Там есть гугловский дизайн, а они самые худшие в этом за последние 10 лет с появление Материал Десигн. А ещё с андроид5 там вообще нет никаких настроек кроме обоины.

>>Стоковый в Андроид файервол и так полноценный прекрасно блокирует всем приложениям лезть в сеть.

А должен блокировать процессы а не права приложений! Не забывай что андроид это джава-машина над юниксом. Сеть на уровне юниикса, приложения внутри джава-машины. Права приложений не распостраняются на сетевую подсистему. И кстати, в стоковом андроиде ВООБЩЕ нет интерфейса к файерволу.

Что ещё хуже — в стоковом андроиде есть приложения, которые равнее прочих, их права запрещено менять или они вообще игнорирют систему прав, или ты их тупо не видишь в списке приложений (хочешь увидеть — ставь сторонний рутовый софт или подключайся к ADB).

>>и не потребляют более 0,2W при серфинге

И поэтому нагревают корпус до 40 и выше? И имеют официальный ТПД в 2-3-5Вт? Может быть 6 Ач батареи перестали быть нормой и 1,5 Ач снова достаточно? Когда ты вообще видел холодный снапдрагон?

>>и даже наоборот система начнёт работать менее плавно при любых ограничениях.

А нахрена мне плавность? Мне нужны мгновенные реакции а не ждать пока оно там прорисует анимацию. Это кстати ещё одна причина поставить кастом — vyjubt штатные прошивки и стоковый андроид в принципе имеет 150мс лаг перед любой анимацией абсолютно независимо от железа — он просто хером а не руками делался. Есть всякие ГармоньОС с крутой переработкой далвик-машины и там эта задержка снижена до 20-50мс, но это всё равно сорта говна. Анимаций быть не должно везде где без них можно обойтись.

Для этого ещё в вин7 масштаб придумали.

Кстати, там же сказано, что лишившись электронов и получив возможность проходить через материалы как гамма, пучок положительных ионов начнёт отталкиваться сам от себя и получит вполне заметный конус рассеивания, что сильно помешает его отклонять. Но свой отклонитель он описывает так, как будто эти ионы полктят прежним линейным курсом.

И ещё одно соображение! Когда через высокоинтенсивное электрическое поле полетят очень быстрые заряды, то кроме отклонения их траектории, какие там электрические противо-токи возникнут и что будут делать?

>>мы до бесконечности зарядить не можем себя.

А вот до полного песца — легко и непринуждённо! Всю электронику в минус, да и биохимию наверняка подредактирует только так. А может и химию с механикой тоже, тут я не знаю.

Как раз опираясь на наше знание именно этот вариант мы и должны взять наиболее приоритетным до тех пор пока не появится более проверенного знания. «как жидкости» это то самое выбивание кратера согласно формулам Ф.Уиппла. Оно же — взаимодействие кумулятивной струи или «ударного ядра» (которое никак не связано с чугунными шариками и пороховой мортирой).

>>Вот вы видите инпут лаги при каждом кеш промахе и обращении даже к ОЗУ? Нет. Мы вообще почти ничего не видим.

Так там лагов в пару-тройку или может десяток тактов! А переключение контекста ядра это тысячи тактов через процедуру «остановить процесс, подгрузить планировщик, передать ему управление, произвести рассчёты, подгрузить поток, передать ему управление и продолжить работу. Всё это с 2-3-4 сбросами кешей как минимум L1+L2.
Это всё ещё недостаточно чтобы увидеть, жалкие доли милисекунды, но предстаавь себе что идёт трешинг с постоянными прерываниями потока на переброски. Серия переключений контекста вполне себе увидится как фризы и микролаги в игре. Или будет сглажено, но за счёт инпут-лага.

>>За счёт которого так или иначе мы и развиваемся последние лет так 20 точно.

Это не точно. Иначе 32 Е-ядра (или зен-с) уделывали бы 8 Р-ядер как стоячих. И уделывают в серверных и рабочих нагрузках, но точно не в играх. И скорость оперативки наращивали бы не частотой в 8Ггц (реально 4*2 канала если не ошибаюсь), а 16 каналов по 1000Мгц. Это дешевле и энергоэффективней.
А ещё разработчики цпу не расшибались бы в лепёшку чтобы ускорить флагманское ядро с 400 гикбенч попугаев до 3000 на поток.

>>И повторюсь планировщик распределяет нагрев. Вне зависимости от того сколько у вас там программа умеет создавать потоков.

Планировщик подбирает лучший алгоритм переброски задач для данной конкретной нагрузки. Но если у тебя всего 4 потока то откуда у 16-ядерника взяться преимуществам над 8-и ядерником? Ты даже 1 чиплет разогреть как следует не можешь!
В конце концо всё уже упёрлось в кеш, а это он самое горячее место, оно одно и гнать там нечего.

То что интел ставит на i9 более элитные чиплеты, способные брать большую частоту при том же напряжении не значит что дополнительные 8 Е-ядер дают процессору преимущество. А у АМД ещё с 3000 линейки ризен-7 лучше себя показывает в играх чем ризен-9. Кстати, у ФХ и А-серии было то же самое. Меньше ядер могли взять большую частоту.

>>И да следуя то вашей логике выше простой турбобуст должен был бы сегодня вызывать лаги.

»сейчас" не знаю, но с самого его появления и до ризен 2600 буст вызывал лаги. Средний фпс растёт, а 1% худших кадров не растёт или даже падает. Нестабильная частота так же плохо как и низкая.

>>Тдп нам известен.

Зато нам не известно какое реальное потребление даёт эта нагрузка на этот процессор. Слишком комплексный вопрос с дохренилиардом переменных. Вот просто тупо Распберри-4, 4*кортекс-А72. Если сжимать /dev/zero через pbzip2 то одно потребление, а если сжимать /dev/urandom — на 1,5Вт больше. А если браузер или 7-zip на все 4 ядра то ещё +0,5Вт.

>>Так что вот в вашем примере что лучше 2600 при ста градусах или при 60? Ответ очевиден.

А при 55 или 65 градусах — вообще без разницы. И даже 65 и 70 можо смело считать что без раницы. И джае 55 от 75 будут отличаться только лет через 10, если/когда чип успеет немного деградировать.

>>23% вы увидите распределение по всем ядрам.

В 7-зипе, упёршимся в диск — да. В игрушке, например Sereos Sam 4 — без 0,1мс трассера не разберёшь. А в каком нибудь unigine Valley — всё 100% однозначно — нагружено 1 ядро полностью и ещё 0,5 ядра куда то размазано. Браузер? Упор в 2 главных потока. Низкая загрузка цпу в может говорить или о бутылочном горлышке, или о том что нагрузка упирается в 1 единственный поток и все прочие ядра бесполезны.

Очень вероятно что новой версией приложения один хрен нельзя пользоваться.

Вы знаете толк в извращениях! Я бы предпочёл оживить современный смарт поставив туда четвёрку.

Это намного более адекватная реализация гуглосервисов. Хотя бы потому что примерно в 100 раз легче и быстрее. Но ещё в сеть не срёт и данных не сливает.

Уродские там шторка, ланчер, вместопанель и все системные приложения от настроек до галереи. И всё это надо заменить настолько насколько вообще возможно. И с оформлением надо что то делать чтобы не тошнило бать в руки (хотя тут сложно, вроде больше не делают).
А ещё нужен полноценный файлменеджер (естественно рутовый), какое то вменяемое управление приложениями (т.е. стороннее рутовое) и если ты собираешься вставлять туда симку то крайне желательно полноценный файервол (т.е. рутовый). А чтобы не заниматься обезьяней работой и не бегать с горящим задом — нужна какая нибудь система бэкапов к которой есть доступ (естественно не гугловская, там нет доступа так что это даже не бэкапер).
З.Ы. И если подумать — то к настройкам частот цпу надо получить доступ. А то все современные смартфоны настроены чтобы быть печками.