Для работы проектов iXBT.com нужны файлы cookie и сервисы аналитики.
Продолжая посещать сайты проектов вы соглашаетесь с нашей
Политикой в отношении файлов cookie
Тут смотреть надо. Делитель то определённо подъест производительность. Вопрос сколько мы получим от DDR5 8000 для CPU. И понятное дело в каких задачах.
Так что победа, но такая с вопросительным знаком.
Вы кое в чём ошибаетесь.
У нас 3! опорных частоты в данном случае.
FCLK.
UCLK.
MCLK.
FCLK. Это частота внутренней шины IF.
UCLK. Это уже частота работы контроллера памяти.
MCLK. Это частота соответственно памяти.
До сих пор 7000 райзены работали 1 к 1.
UCLK 3000 и MCLK 3000, что и есть DDR5 6000. В режиме 1к1.
А новость как раз про то, что UCLK 2000, а MCLK 4000, что собственно и даёт DDR5 8000.
На АМ4 работало зачастую 1к1к1.
«выше стандартных 2Ггц.» А оно и не будет работать выше. Проблема одна, подложка. На данный момент, она не позволяет нам поднять частоты шины IF выше. По крайней мере при текущих задержках же. Как мы понимаем в нашем случае делать нельзя.
Не знаю можно сделать ли подложку лучше. Но мы знаем наверняка, что можно использовать interposer. Как например в GPU амд. Но оно блин денег стоит.
Поздравляю вас поимели. Нет там 1,4в!
Мem vddio и VDDQ в случае АМД относятся к напряжениям DRAM.
Я не вижу VDDCR SoC < именно это напряжение нас интересует.
(На всякий случай залезаем на сайт AMD)
https://www.amd.com/system/files/documents/ryzen-master-quick-reference-guide.pdf
24 Слайд Где явно видно куда относится контроллер.
https://www.amd.com/system/files/2017-03/AMD-Ryzen-Processor-and-AMD-Ryzen-Master-Overclocking-Users-Guide.pdf
Ещё дополнительно 25 стр
«Note that Memory VTT voltage will automatically be set to half of Memory voltage
(MEM VDDIO).»
Открыв первый источник videocardz, что ж я вижу
https://cdn.videocardz.com/1/2023/07/ASUS-DDR5.jpg
VSOC (SMU) 1.2999V
(DDR5-8000, Source: k_mic)
Читаем такую строку
«The new BIOS is said to maintain the 1.3 SOC voltage, but it is possible to run high-speed memory even at 1.2V. This is still within the limits advised by AMD. According to the post on AMD Subreddit, the company has been working on the AGESA 1007B update for 2 months now. It is confirmed that many Ryzen 7000 systems will now be able to run 6400 MT/s memory with a 1:1 IC ratio.»
И очевидно там не будет 1,4в режим то изёвый в смысле 1к2.
Иначе бы UCLK была б 1 к 1 с MCLK.
Собственно КП и работает на частоте в 2ГГц, в место 3ГГц в режиме 1к1
«Казахстан на стороне США?»
Вообще нет. Казахстан на стороне, Казахстана. А ещё Казахстан ведёт тесное партнёрство с Китаем.
Нет тут никаких однозначных сторон. Дело в выгоде.
Так там ещё и VRAM очень мало. Будь 8ГБ, т.е. будь у нас излишек, игры могли бы кешировать данные сверхнеобходимого, что сильно бы уменьшило просадки на шине, если б вовсе не свело их на нет.
Каким золотом кек? Вы отстали от жизни лет так на 60. Золотой стандарт это Бреттон-Вудская система принятая в 44г. Которую в 70х сменила Ямайская валютная система.
По итогу рубль лет 30 точно золотом не обеспечен.
А бегство при том. Что огромная масса рублей меняется на доллары и выводится из страны же. От рублей толку за пределами страны особо нету. Как следствие эта масса, обваливает курс на бирже.
Тут кстати печально что память осталась +- та же, на 6400. 7500 была б бодрее.
Экран похоже тоже не поменялся
Так что можете поискать обзоры RedmiBook Pro 15 Ryzen Edition 2022.
«sunny cove такого прироста не давало»
Уууу на целый 1% меньше.
«нет в ядре радикальных улучшений,»
А их негде нет. Радикально, это революционный путь, т.е. качественные улучшения. Как я и сказал, последнее такое это ядро ZEN где +40% Где переделали всё ядро от и до.
«во многом за счет роста кэшей»
Все остальные улучшения, от предсказателя переходов, буфера переупорядочивания, планировщика, регистров и т.д. да пошли ж они в .....
Ах да фон неймановская архитектура всё ещё с нами, ваш кэп.
Sunny Cove это вообще-то ноутбучное ядро
Ровно настолько же насколько Golden Cove, Skylake и т.д.
Ах да это ваше «ноутбучное ядро» хоба и в серверах Ice Lake-SP. А потом хоба и его бекпортировали на 14нм, с обрезанием и назвали это cypress cove.
А так конеееечно ноутбучное. При том дайте мне точно определение что такое это ваше «ноутбучное ядро»
Эт нормально. Для того ж у нас есть большие ядра, которые в целом имеют очень даже хорошую производительность на ядро.
В остальном же, если уж мы можем масштабировать многопоточку, пусть и малыми ядрами, почему бы и нет.
«IPC это не характеристика процессора»
Его родимая. Или что у нас микроархитектура не является частью процессора? А именно IPC, как мы видим, производители меряют её производительность.
«прыжок у алдер лейка был аномалией»
Враньё чистой воды. Т.к. предыдущее ядро Sunny Cove которое дало сопоставимый прирост, мы в упор не видим?
«из-за проблем техпроцесса.»
У вас 2 аномалии к ряду?
Смотрю память у вас никакая. Ядро Sunny Cove вышло на 10нм ещё в 19г
После же выпустили ядро Golden Cove, тоже на 10нм.
И никакого торможения.
Фактически вы несёте чушь. Т.к. никто не тормозил развитие микроархитектуры от слова совсем. Тем более когда начали разработку микроархитектуры Интел ещё не знали, что обкекаются с тех процессом же.
Вот как выглядит революция же или как вы выразились «аномалия»
https://www.techpowerup.com/img/16-08-24/105a.jpg
+40% между поколениями. И все мы знаем почему так много.
А не +19%.
" радикальному увеличению производеительности без увеличения числа ядер?"
За счёт увеличения частот и IPC. При том второе основополагающее.
Для того и меняют микроархитектуру.
Я вам тут напомню
Golden Cove дал в среднем +19% IPC относительно Sunny Cove
Sunny Cove +18% относительно Skylake
Ещё раз повторюсь речь о IPC. Т.е. если процессоры зафиксировать на одной частоте. А частоты тоже растут.
И так для наглядности как оно выглядело
Golden Cove
https://images.anandtech.com/doci/16881/46.jpg
Sunny Cove
https://fuse.wikichip.org/wp-content/uploads/2019/05/intel-sunny-cove-ipc-claim.png
При том как видим, набор задача примерно совпадает.
А тут получаем 13,3% производительности, не IPC, относительно 13900к т.е. через поколение же.
А вот вы зря сюда вкидываете priority. Мы же можем его вообще не трогать. Для того, что бы игра не запускалась на тех же малых ядрах понятное дело.
А с вопросом на какие, давайте разбираться.
https://www.intel.com/content/www/us/en/developer/articles/guide/12th-gen-intel-core-processor-gamedev-guide.html
Кроссплатформенно мы можем обратиться только к CPUID по идее.
Обратившись к флагу типа ядра. Предварительно можно посмотреть на флаг гибридный ли процессор.
По идее готово.
И по идее теперь можно написать приложение, которое привяжет нужный процесс, например игру, через affinity, к P ядрам процессора, на основе флага CPUID.
Мы ведь можем сделать что-то подобное на C например? Это к слову о стандартных способах и кросплатформенности.
Так что как по мне сценарий в общем 1. Который нужно реализовать под 2 OC.
И для того, что бы например игра не фризила из за малых ядер условно. Нам же не нужно выставлять приоритет, нам не нужно думать о SMT. Нужно просто привязать данный процесс к большим ядрам. И это хватит. Остальное за нас автоматически сделает планировщик же. Ну эт если со стороны пользователя. Да здравствую варварские методы :)
Конечно для разработчика приложения это такой себе вариант. Д
ля разработчика игры, точнее его движка, не всё так плохо, т.к. имеем несколько разных нагрузок же. Т.е. часть задач, мы можем таки отдать на откуп малым ядрам. Т.е. draw call'ы на большие ядра, а допустим декомпрессию на малые.
И по идее, я описываю лишь вершину айсберга. Т.е. достаточно глобальные вещи, допустим макроуровень, которые не дадут нам большой выигрыш. А если спустится на микроуровень и попытаться выжать всё.
То тут да, практически реально придётся писать для приложения свой планировщик, с микроменджментом и куртизанками xD
Это явно очень сложная задача же.
P.s. Надеюсь мне удалось хоть немного передать идею. А то по ощущениям справился я так себе.
affinity есть и под другими ОС.
Вот например под линукс
https://manned.org/taskset.1
или
https://manned.org/sched_setaffinity.2
Из того что ещё удалось найти
https://www.gnu.org/software/libc/manual/html_node/CPU-Affinity.html
.
В принципе да не очень-то и удобно. Но в данном случае, у нас всего 2 ОС и пара команд. Что позволит решить, вот прям здесь и сейчас проблему малых ядер, которые делают что-то не то.
Так что победа, но такая с вопросительным знаком.
У нас 3! опорных частоты в данном случае.
FCLK.
UCLK.
MCLK.
FCLK. Это частота внутренней шины IF.
UCLK. Это уже частота работы контроллера памяти.
MCLK. Это частота соответственно памяти.
До сих пор 7000 райзены работали 1 к 1.
UCLK 3000 и MCLK 3000, что и есть DDR5 6000. В режиме 1к1.
А новость как раз про то, что UCLK 2000, а MCLK 4000, что собственно и даёт DDR5 8000.
На АМ4 работало зачастую 1к1к1.
«выше стандартных 2Ггц.» А оно и не будет работать выше. Проблема одна, подложка. На данный момент, она не позволяет нам поднять частоты шины IF выше. По крайней мере при текущих задержках же. Как мы понимаем в нашем случае делать нельзя.
Не знаю можно сделать ли подложку лучше. Но мы знаем наверняка, что можно использовать interposer. Как например в GPU амд. Но оно блин денег стоит.
Мem vddio и VDDQ в случае АМД относятся к напряжениям DRAM.
Я не вижу VDDCR SoC < именно это напряжение нас интересует.
(На всякий случай залезаем на сайт AMD)
https://www.amd.com/system/files/documents/ryzen-master-quick-reference-guide.pdf
24 Слайд Где явно видно куда относится контроллер.
https://www.amd.com/system/files/2017-03/AMD-Ryzen-Processor-and-AMD-Ryzen-Master-Overclocking-Users-Guide.pdf
Ещё дополнительно 25 стр
«Note that Memory VTT voltage will automatically be set to half of Memory voltage
(MEM VDDIO).»
Открыв первый источник videocardz, что ж я вижу
https://cdn.videocardz.com/1/2023/07/ASUS-DDR5.jpg
VSOC (SMU) 1.2999V
(DDR5-8000, Source: k_mic)
Читаем такую строку
«The new BIOS is said to maintain the 1.3 SOC voltage, but it is possible to run high-speed memory even at 1.2V. This is still within the limits advised by AMD. According to the post on AMD Subreddit, the company has been working on the AGESA 1007B update for 2 months now. It is confirmed that many Ryzen 7000 systems will now be able to run 6400 MT/s memory with a 1:1 IC ratio.»
И очевидно там не будет 1,4в режим то изёвый в смысле 1к2.
Иначе бы UCLK была б 1 к 1 с MCLK.
Собственно КП и работает на частоте в 2ГГц, в место 3ГГц в режиме 1к1
Вообще нет. Казахстан на стороне, Казахстана. А ещё Казахстан ведёт тесное партнёрство с Китаем.
Нет тут никаких однозначных сторон. Дело в выгоде.
Вообще пофигу ж. NUC это форм фактор. Т.е. никто особо не помешает тем же китайцам клепать свои NUCи.
Ещё точнее, это вообще не частоты.
Тоже не является узким местом, в отличии от цены < вот это реально Ж.
По итогу рубль лет 30 точно золотом не обеспечен.
А бегство при том. Что огромная масса рублей меняется на доллары и выводится из страны же. От рублей толку за пределами страны особо нету. Как следствие эта масса, обваливает курс на бирже.
Экран похоже тоже не поменялся
Так что можете поискать обзоры RedmiBook Pro 15 Ryzen Edition 2022.
Уууу на целый 1% меньше.
«нет в ядре радикальных улучшений,»
А их негде нет. Радикально, это революционный путь, т.е. качественные улучшения. Как я и сказал, последнее такое это ядро ZEN где +40% Где переделали всё ядро от и до.
«во многом за счет роста кэшей»
Все остальные улучшения, от предсказателя переходов, буфера переупорядочивания, планировщика, регистров и т.д. да пошли ж они в .....
Ах да фон неймановская архитектура всё ещё с нами, ваш кэп.
Sunny Cove это вообще-то ноутбучное ядро
Ровно настолько же насколько Golden Cove, Skylake и т.д.
Ах да это ваше «ноутбучное ядро» хоба и в серверах Ice Lake-SP. А потом хоба и его бекпортировали на 14нм, с обрезанием и назвали это cypress cove.
А так конеееечно ноутбучное. При том дайте мне точно определение что такое это ваше «ноутбучное ядро»
В остальном же, если уж мы можем масштабировать многопоточку, пусть и малыми ядрами, почему бы и нет.
Его родимая. Или что у нас микроархитектура не является частью процессора? А именно IPC, как мы видим, производители меряют её производительность.
«прыжок у алдер лейка был аномалией»
Враньё чистой воды. Т.к. предыдущее ядро Sunny Cove которое дало сопоставимый прирост, мы в упор не видим?
«из-за проблем техпроцесса.»
У вас 2 аномалии к ряду?
Смотрю память у вас никакая. Ядро Sunny Cove вышло на 10нм ещё в 19г
После же выпустили ядро Golden Cove, тоже на 10нм.
И никакого торможения.
Фактически вы несёте чушь. Т.к. никто не тормозил развитие микроархитектуры от слова совсем. Тем более когда начали разработку микроархитектуры Интел ещё не знали, что обкекаются с тех процессом же.
Вот как выглядит революция же или как вы выразились «аномалия»
https://www.techpowerup.com/img/16-08-24/105a.jpg
+40% между поколениями. И все мы знаем почему так много.
А не +19%.
За счёт увеличения частот и IPC. При том второе основополагающее.
Для того и меняют микроархитектуру.
Я вам тут напомню
Golden Cove дал в среднем +19% IPC относительно Sunny Cove
Sunny Cove +18% относительно Skylake
Ещё раз повторюсь речь о IPC. Т.е. если процессоры зафиксировать на одной частоте. А частоты тоже растут.
И так для наглядности как оно выглядело
Golden Cove
https://images.anandtech.com/doci/16881/46.jpg
Sunny Cove
https://fuse.wikichip.org/wp-content/uploads/2019/05/intel-sunny-cove-ipc-claim.png
При том как видим, набор задача примерно совпадает.
А тут получаем 13,3% производительности, не IPC, относительно 13900к т.е. через поколение же.
А с вопросом на какие, давайте разбираться.
https://www.intel.com/content/www/us/en/developer/articles/guide/12th-gen-intel-core-processor-gamedev-guide.html
Кроссплатформенно мы можем обратиться только к CPUID по идее.
Обратившись к флагу типа ядра. Предварительно можно посмотреть на флаг гибридный ли процессор.
По идее готово.
И по идее теперь можно написать приложение, которое привяжет нужный процесс, например игру, через affinity, к P ядрам процессора, на основе флага CPUID.
Мы ведь можем сделать что-то подобное на C например? Это к слову о стандартных способах и кросплатформенности.
Так что как по мне сценарий в общем 1. Который нужно реализовать под 2 OC.
И для того, что бы например игра не фризила из за малых ядер условно. Нам же не нужно выставлять приоритет, нам не нужно думать о SMT. Нужно просто привязать данный процесс к большим ядрам. И это хватит. Остальное за нас автоматически сделает планировщик же. Ну эт если со стороны пользователя. Да здравствую варварские методы :)
Конечно для разработчика приложения это такой себе вариант. Д
ля разработчика игры, точнее его движка, не всё так плохо, т.к. имеем несколько разных нагрузок же. Т.е. часть задач, мы можем таки отдать на откуп малым ядрам. Т.е. draw call'ы на большие ядра, а допустим декомпрессию на малые.
И по идее, я описываю лишь вершину айсберга. Т.е. достаточно глобальные вещи, допустим макроуровень, которые не дадут нам большой выигрыш. А если спустится на микроуровень и попытаться выжать всё.
То тут да, практически реально придётся писать для приложения свой планировщик, с микроменджментом и куртизанками xD
Это явно очень сложная задача же.
P.s. Надеюсь мне удалось хоть немного передать идею. А то по ощущениям справился я так себе.
Вот например под линукс
https://manned.org/taskset.1
или
https://manned.org/sched_setaffinity.2
Из того что ещё удалось найти
https://www.gnu.org/software/libc/manual/html_node/CPU-Affinity.html
.
В принципе да не очень-то и удобно. Но в данном случае, у нас всего 2 ОС и пара команд. Что позволит решить, вот прям здесь и сейчас проблему малых ядер, которые делают что-то не то.