И тем не менее у старших моделей AMD Ryzen четырёх канальная.
На современном софте никакого кеша не хватит, софт ест не просто много а очень много памяти, даже банальный браузер не говоря о более сложном ПО. Тоесть любой софт обращается к ОЗУ, только сейчас это происходит по очерёдности. Тут обсуждают как запустить в работу второе и последующие ядра, ну допустим запустили, и эти ядра создают очерёдность доступа к ОЗУ, ускоряет это это обработку данных? Иными словами получилось бутылочное горлышко и сверху хоть бочку поставь но вытекать бысрее не будет.
При двенадцати ядрах, тоесть в очереди к памяти стоит не два ядра а три, круто!
Уже не один обзор был про то как геймеры тестировали многоядерные серверные процы в играх, оказывается они проигрывают по ФПС "обычным" процам у которых ядер в два-три раза меньше.
Последний раз редактировалось AlexanderT; 04.09.2020 в 08:30.
Конечно.За то ядро линукс компилируется за 22 секунды. А игры. Ну они могут и не уметь работать с таким количеством ядер. Этоhttps://www.phoronix.com/scan.php?pa...er-linux&num=8
Последний раз редактировалось Max1980; 04.09.2020 в 10:00.
Чем больше ядер и потоков, тем выше потребляемая мощность и помехи от системного блока. В том числе акустические от вентиляторов которые видны на спектрах.
Тем не менее в среднем выигрыш получается, многие алгоритмы берут данные последовательно, и тут кеш начинает работать на упреждение, заполняя целые строки. А в таких архитектурах как GPU есть и локальная память каждого ядра и группы ядер, и инструменты разработки типа OpenCL позволяют все это контролировать на стадии написания кода
Давайте вернёмся к главному потоку - потоку данных с ЗК. Вот Сергей привёл таблицу
Я не знаю, какая потребность измерений при количестве точек более одного миллиона, а при 1 миллионе на всё про всё уходит менее 0,1 сек, вполне приемлемо кмк.
Но дело даже не в этом, чтобы увидеть стационарный спектр, а не переходной процесс, данные с ЗК должны обновиться полностью. Даже при 1 миллионе точек на это уйдёт 5 сек. Тогда зачем нам время обработки этих данных уменьшать и уменьшать, пусть даже мгновенно они обрабатываются, что это даст для данной задачи - измерение шумов генераторов?
наверно реальный реалтайм, если окно не заполнять каждый раз новыми данными, а сдвигать и освободившееся место дописывать
хотя лично я не вижу разницы 30 кадров в секунду или 10, для отладочных целей хватает, а для измерений я вообще от реалтайма отказался
как по мне, то гораздо важнее "правильный" размер окна, чтобы был 1 бин на герц (или один герц на бин, это кому как больше нравится) при любой частоте дискретизации
тогда сравнивать графики намного удобнее
кстати, baudline реально многопоточный и использует все ядра, но работает через oss, которую сломали и сомнительно что починят
Получается, но глядя на графики ФПС (и прочих попугаев) разного свежего железа вижу разницу в единицы процентов при увеличении количества ядер в два раза. Не хочется спорить на эту тему, просто вижу как за вычислительную отрасль взялись маркетологи, печальное зрелище. Вот сейчас сижу в инете, ядер много, частоты бешеные, оперативки страшно подумать сколько, и вспоминаю как с десяток лет назад, сидел на этом-же сайте, на одном ядре 700мГц и 512мБ оперативки. Что изменилось за это время, что заставило меня уже несколько раз поменять железо?
Эту тему просматривают: 2 (пользователей: 1 , гостей: 1)