kirill_rrr

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

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

Так там лагов в пару-тройку или может десяток тактов! А переключение контекста ядра это тысячи тактов через процедуру «остановить процесс, подгрузить планировщик, передать ему управление, произвести рассчёты, подгрузить поток, передать ему управление и продолжить работу. Всё это с 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 раз легче и быстрее. Но ещё в сеть не срёт и данных не сливает.

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

А ещё в исходной статье, где «забыли про специфику взаимодействия» есть ссылка на некую работу:

>> Для оценки последствий удара частицы в поверхность можно использовать формулу, предложенную специалистом по этим вопросам Ф.Уипплом ([13], стр.134), согласно которой размеры образовавшегося кратера равны

хотя и с оговоркой

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

… и скорее всего никто и правда не знает на самом деле! Сколько раз уже было, что при выходе за практически изученные пределы появлялся какой нибудь сверхзвуковой удар или фазовый переход олова в неизвестную ранее форму.

46% света просто пройдут насквозь.

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

Но что бросается в глаза — человек показывает что пылинка отдаёт лишь 2% энергии, но он напрочь игнорирует сопромат, заявляя что энергия равномерно распределится внутри щита и масса не покинет канал толщиной 0.5 мкм. Но это будет взрыв чудовищной интенсивности рвущий в пыль кристаллическую решётку такого несокрушимого материала как графит. Для того чтобы превратить килограм графита в мелкую крошку достаточно пары ваттчасов энергии. Одна такая средняя пылинка несёт порядка 1,1 Втч и если отдаст на взрыв 0,1% своей энергии то будет выбивать до грамма графита на штуку.

Внимание, вопрос: достаточно ли скорости в 0,94с при столкновении двух ядер например углерода или кислорода чтобы инициировать реакцию синтеза ядер? Если да то всё становится ОЧЕНЬ интересно.

Чтобы хоть что то заработало. Андроиды после 13 версии все как один убогое уродское днище.

А мне очень нравились 10,1 нетбуки. Больше всего напрягало не то что мелко, а то что некоторый софт отказывался работать на 600р-экране.

Очки не помогут, только качество сетчатки глаза. Ты либо видишь, либо нет.

Доса!
Но в данном случае они дополнительно использовали 4 виртуальных машины чтобы там было 4-е копии ОС с 4-я графическими подсистемами. Потому что 400 окон с движущимся изображеением для ОС это ППЦ. Их все нужно пропихнуть в 1 поток!

>>У вас все приложения включая игры однопоточные? Нет.

Не достаточно быть многопоточным. Нужно быть 16+ поточным, а ещё лучше неограниченно-поточным. Но это также неверно.

>>Итог выйгрыш в энергоэффективности

Это очень даже требует доказательств. Всегда с появления многоядерных цпу было наоборот — больше ядер — быстрее — горячее.

>>Само собой разумеющееся это то что при параллелизме задачи выполняются не последовательно, а параллельно.

Как часто вы видели идеальный параллизм? Возьмём HL2. Появление «многоядерной оптимизации» примерно в 3-4 раза повысило требования к цпу, чуть-чуть повысило фпс… и наградило нас дикими инпут-лагами, фризами и нестабильным фпс до очень мерзких микрофризов. И где то с той эпохи обе эти проблемы продолжают нас сопровождать. Просто где то один хрен все эти массивы рассчётов надо собрать вместе, а для этого надо подождать отстающих потоков и тут уже хз как звёзды сойдутся.
Возьмём казалось бы идеально многопоточный тест, 7-zip. Который на самом деле реально грузит 80-90% доступных потоков, причём чем больше объём памяти (выше уровень сжатия) которую надо чесать тем ниже падает загрузка, вплоть до 50%, а в особо хреновых случаях до всего 1,8 потока. А больше — не просто не создаёт нагрузки!
Возьмём браузер. 1 поток выделяется под интерфейс и копозитинг вкладок в окна (тоже бывает тяжёлой задачей). 1-2 потока могут отдаваться под всякие БД, работу с ГПУ, дополнения и ещё хзч. И процесс вкладки при отрисовке в среднем создаёт 1,5-2 потока, причём это очень современные достижения новых движков. А больше — хрен. Ну или если уже откомпилированная вкладка крутит какие то интерактивные скрипты, которые специально написаны многопоточным кодом… А так в среднем это 3 потока + 1-1,5 потока на каждую новую открывающуюся вкладку. Учитывая абсолютно средненькие 20-и поточные интелы это почти что однопоточность, а суммарный результат всё равно упирается во время самого длинного потока. Он же самый сложный и важный.

>>Вообще плевать как бустим… У вас 2 источника тепла суммарной мощностью 100вт равной площади или один мощностью те же 100вт. Где будет горячее?

Но у нас 2/1 источника тепла неизвестной мощности! В простое мы получим соответственно ~2+2 Вт против просто 2Вт. В синтетике полной загрузки мы действительно получим 100+100 против 100. А в 4-х поточной игре мы очень вероятно получим 30+30 против 50Вт.

>>Итог так холоднее.

До определённого уровня температуры в примерно 65-70 градусов холоднее не значит лучше. Например ризен 2600 под нагрузкой от игр 5-7-и летней давности прогревается примерно до 60, причём на минимальных оборотах кулера.

Очень жаль что я не знаю (и не умею пользоваться) профессиональных трассеров нагрузки цпу, которые показали бы милисекундные графики занятости каждого из ядер. Средняя температура по больнице в условных 23% это ни о чём, то ли 1 поток по всем ядрам скачет, то ли там короткие вспышки 100% загрузки на все ядра, то ли ещё какая хрень.

Это конечно плохо, но ничто по сравнению со свежей версией андроида.

И кстати, Слака — откровенно ужастный выбор дистрибутива для массового пользователя. Много настройки для админа.

Дело ведь не в Слаке, дело в том что им надо использовать одну софтину вместо другой. Лично я не знаю как это в винде делается! Если они знают и не хотят по другому — надо заставить. Там ведь нет ничего сложнее инструкции на 5-10 строк «нажми на эту кнопку, потом на эту».

>>Выгоднее после некоторого порога распространение по ядрам если возможно.
Именно что невозможно! А если попытаться, то планировщик начнёт кидать поток с нагретого высокочастотного ядра (которое ещё некоторое время провисит на высокой частоте) на свободное, находящееся на низкой частоте. Лаг на переключение, «турбояма». Будет ли выигрыш по энергии? Думаю в случае игр нет, там в среднем 4-6 потоков и скорее выгодней гнать их скорость. Во всех тестах типовые показатели загрузки 25-30%. Если надо экономить энергию то можно было бы ограничить максимумы частот. Лучше иметь стабльный пониженный фпс чем всокий но с фризами.
>>И тепло таки распределяют. Из за чего его в принципе проще отводить.
Да, но это ведь совсем дргая стратегия! Не «экономим энергию снижая частоты», а «бустим по максимуму чтобы упереться в потолок охлаждения, переключаем ядра чтобы остыли».
>>Т.е. как не крути не грелся бы меньше. Либо так же, либо больше. Ведь теплопакет тот же, так как кто не работает тот не ест!
Только если требуется агресивный буст. И он требовался всяким амд FX и ризенам до 3-5 поколения. Но тут же самые свежие ядра, они натягивают интела даже без Х3Д и разогнанных Х-версий. Можно вообще прижать частоты и сидеть на тех же самых ядрах просто не делая лишних телодвижений и не включая ненужного.

В кои то веки клавиатурой можно пользоваться. Так что теперь зачётно.