Или, пока вынуть один процессор, что бы они жопами на шине на толкались.

Лучше чем вот так сделать вряд-ли получится. С двумя процами либо лэйтенси, либо пропускная способность, но не то и другое одновременно.
Вангую что у тебя половина каналов памяти в отвале.

Всё оказалось предельно просто - NUMA бала выключена в биосе. Прошивка последняя 1.3 с таймингами и ReBar'ом с китайской части офф сайта. Видать в ней почему-то так. Я только частоту на 2400 с АВТО менял. На реддите подсказали посмотреть сколько НУМА нод, а у меня опция их просмотра вообще серая была. Теперь их два и скорости как надо для чистого стока:

И за скрин с Синебенчем тож спасибо, пойду сверю стою считалку с Вашей о) (Добавлено: R20 выдал 10319 и 10157 очков за два прохода подряд, R23 - 26493 и 25736).

Осталось узнать почему сходу не пашет Смартфан. Не после сна, а вообще. Датчики показывают нормальные температуры в АИДЕ. Так то не критично, он всё равно будет спать всегда, я его буду будить через сеть, слать ему работу, он её будет делать на 100% проца, и потом сразу снова спать.

И ещё. Сначала был вопрос почему процы работают на 2.9ггц вместо 3.1ггц при загрузке всех ядер на 100%. Потом оказалось, что так делает только Cinebench 2024 и только во время прогона, а во время подготовки к нему так же занимает все ядра но на 3.1ггц. И с ним как раз возник ещё вопрос: с отключенным NUMA в нём у станции 1260 баллов, а с включенным - только ~900, но частота в обоих случаях 2.9ггц во время прогона. При этом в Cinebench R23 и R20 результаты не меняются, а в CPU-Z v2.10 наоборот без NUMA - 7500, с ней - 8300 (один проц тестит? версия 2.05 выдаёт 13500). Это нормально, или надо ещё что-то в биосе посмотреть?

3.1 без AVX
2.9 с AVX
3.6 буст на одно ядро
Запусти HWInfo да посмотри политику турбобуста.
Cinebench тут точно не причём

Засади ему Prime95 по самые абрикосы, и он вообще свалится до 2,7 примерно, упёрвшись в свой теплопакет.

Нашёл, всё так. AVX там целых два даже. Но остался вопрос про NUMA + Cinebench 2024 = 900 очков, а Cinebench 2024 без NUMA = 1200. Мне не столь важно "почему так", сколько "так и должно быть?" В смысле не надо ли чего ещё где-то включить?

И ещё тут осенило:
зеоновая станция: два проца по 16 физических ядер по 2.9ггц в бенчмарках = 2 * 16 * 2.9 = 92.8ггц
рабочий/игровой комп: один проц 6 физических ядер по 3.95 в бенчмарках = 6 * 3.95 = 23.7ггц
Разница между ними в гигагерцах: 92.8 / 23.7 = 3.91
А разница между ними и в очках и во времени прогона 4рёх циклов (засекал) лишь 2.85. Т.е. 27% в рабочей станции как бы расходуется, процы же заняты на 100%, но при этом куда-то хрен знает куда. Четверть. Четверть станции тарабанит впустую? Игровому/рабочему компу надо на четверть меньше гигагерц, чтобы сделать ту же работу. Жесть.


Поверю на слово. Вопрос то был почему не 3.1, а не как сжечь дешмансткую китайскую материнку за 12к рублей о) Меня уже радует, что в стресс тесте АИДЫ и в Cinebench 2024 второй проц в станции греется лишь до 58-60с спустя 10 минут (а игровой/рабочий комп до 80с).

поделитесь ссылочкой на HUANANZHI X99 F8D PLUS на алике
я нашел за 18тр - вдруг они дешевле ?
да и продавец там без покупок - я конечн опонимаю все,но вдруг у кого то есть где он сам покупал
вот что я нашел :

разные задачи будут разную производительность показывать с NUMA и без NUMA. Где-то будет быстрее первый вариант, где-то - второй. Зависит от того, каким образом запрашивается память, и от того, как организован процесс работы с данными программе. С NUMA у вас общий пул памяти на оба процессора, а без NUMA - два пула памяти для каждого процессора. Самый быстрый доступ у какого-либо процессора к своей памяти без NUMA, на втором месте доступ любого процессора к общему пулу памяти с NUMA, и самый медленный - доступ процессора к чужой памяти без NUMA. Отсюда вылезают пенальти.


Ну потому что есть еще разная пропускная способность памяти, и пенальти, о которых я написал выше. Вы не можете так вот в лоб сравнивать двухсокетную архитектуру и односокетную, и ожидать, что потерь из-за двухсокетности не будет. Но можете поиграться с конфигурациями, выяснить, какой из конфигов более эффективен именно в вашей задаче. И там, и там процы будут молотить под 100%, но по времени исполнения будет заметная разница. Часто выгоднее изолировать два процессора, выключив NUMA, и запускать два процесса на каждом из процессоров, чтобы они при этом работали каждый со своей памятью. И там потери не будет.

Выключите NUMA, и потестируйте, запуская тест лишь на одном из процессоров.

Надо у офф продавана ссылку просить. У них там в других товарах прямо написано типа "Дорогие покупатели из России, ввиду политики площадки не все товары видны. Если вы чего-то хотите но не видите - напишите нам в чат". Я написал, скинули ссылку на плату на складе в МСК. Ссылка на продавана: https://aliexpress.ru/store/1102459270 . Сейчас у них есть Плюс за 17к, но попробовать написать всё равно стоит. В чате у алика стоит авто гугл транслейт, можно по-русски писать - ответят по китайски и оно переведётся о)

Добавлено спустя 4 минуты 20 секунд:


Вот тут у меня непонятки: если доступ медленный к памяти, то куда тратятся гигагерцы проца, т.е. операции оного? Он, по идее, должен просто тупить и ждать пока дадут = не занят на 100%? Или он умеет тратить операции чтобы компенсировать медленный доступ к памяти? И бенчмарк же одним ядром рендерит конкретный кусочек картинки, там по идее у каждого ядра свой кусочек в памяти откуда он берёт что пожевать и свой кусочек куда покакать - это я про бенчмарки, где NUMA не влияет, т.е. всё читается и пишется каждым процом из своей памяти (да?).

Ядра работают с кэшами. И лишь когда им нужно заменить страницы кэшей, идет обращение к памяти. И тут NUMA всегда влияет, т.к. ядро либо лезет только в свою память, либо одновременно лезет сразу и в свою, и в чужую c NUMA. В бенчмарках или в задачах влияния от этого, как и от всего прочего, может не быть заметно, если канала обмена достаточно для данного бенчмарка, ну или для вашей задачи. Ровно как и в каких-то играх достаточно пропускной PCI-e 3.0 x8, или пропускной способности двухканального доступа к памяти.

Гигагерцы проца тратятся... Ну он да, занят на 100%, потому что кэши забиты мусором, и надо вычитать страницы памяти, что и происходит. Для вас он занят. Он программу выполняет, просто выполнение отдельных инструкций, для которых оказался нужен доступ к памяти, растянуто во времени. Время потрачено, да. Ну, возможно, на нагреве и потреблении позитивно скажется, например.

В нулевых- кроме NUMA есть ещё COD и он тоже чуть влияет.(ещё и vmx vtx txt и прочая лабуда для виртуальных машин -ИНОГДА меняет скорости НЕКОторых задач...)
А вот теперь во-первых, по Вашей математике:
Вот ЕСЛИ БЫ, но оно Не ЕСЛИ....
Если подробнее- работай така математика производители процев так бы и писали производительность, но нет.
Как Вам уже пытались объяснить - влияет много факторов.
Можно совсем коротко : если бы CPU был изолированной системой и всё делал внутри себя- может АК и получилось.
Но Вы забываете, что есть "накладные расходы" на распараллеливание задачи, на синхронизацию по тактам с контроллером ОЗУ(были процы у которых можно было ставить частоту 1:1 или 1:2 - получалась прелесть в обмене с памятью и некоторых чувствительных задачах) у Вас проц скачит 3.6 3.1 2.9 и контроллер 3.1 либо ниже. Соответственно чтобы получить данные процессор должен дождаться синхронности, а это такты. Кто бы чё не говорил, а в современных процах пока всё привязано к клокинггенератору... Частота памяти у Вас максимум 2.4 то есть опять теряются такты... В десктопе другие значения, и они влияют. Ядер меньше - процесс распараллеливания тоже другой... нет необходимости лезти к памяти соседнего процессора по кольцевой шине...
В общем Вы "помножили сферического коня в вакууме и натянули на глобус..."
ИМХО

Omnilord спасибо

Жаль тебя расстраивать но виноват ты сам. Брать два сокета - это ошибка в большинстве случаев даже для рабочих задач. Я тут выше рекомендовал утилиту core to core latency запускать, но что-то народ не понял смысла. У тебя никогда не будет нормально работать двухсокетная сборка над одной задачей. Ядра одного процессора в одном кристалле и быстро друг с другом взаимодействуют, а задержки между двумя процами будут конские и будут тормозить всю работу. Двухсокетная плата будет нормально работать только когда на каждом проце своя задача, потому это и создано для серверов.

2 MichaelF, TerminX
В целом понял. Даже складывается ощущение, что 27% налогов на производительность - это ещё по божески о) До своих задач дойду только через несколько дней - есть чо разворачивать, десятки гигобайтов заливать, всё такое. Если будет х2.85 по сравнению с рабочим, то это в целом успех, расчитывал на х3 примерно.


Тут стоит вспомнить с чем я пришёл на этот форум - цена/качество для 100+ потоков о) Докинув 4к на материнку, получилось всунуть второй комплект оперативы и второй проц. Работает не в два раза быстрее, буду знать, но и экономия на всём остальном так же очевидна - и корпус красивый тонированный, и БП не дешман, и NVME быстрые для 3.0, доп. кулера беленькие светящиеся, ну и работать с одной машиной в два раза проще.

Может в синебенче заработает и в два раза. Но куча софта не умеет в два сокета работать вообще.

Занять 100% невозможно, иначе бы вы просто не увидели таких данных! При самых крутых задачах процы у меня работали максимум на 82%. А то что показывается, это так для вида!

Софту и не надо ничего уметь, по большей части... Ему дела нет до сокетов, в основном... Софт тупо запускает потоки, винда тупо включает их исполнение на виртуальных ЦП, занимая сначала нечетные потоки всех процессоров, чтобы не ронять однопоточную производительность Гипертредингом, потом четные, чтобы активировался Гипертрединг, и более эффективно использовались ресурсы процессоров в угоду многопоточной производительности, но в ущерб однопоточной. И всем при этом без разницы, на каком они из процессоров исполняются, если юзер прямо не назначил... И все исправно будет работать на паре сокетов, за исключением случая, который я ранее описывал, т.е. когда на борту более 64 потоков, и Виндовс работает в режиме процессорных групп, в этом случае да, работать будет на одном из процессоров, или на одном узле NUMA, если разработчик софта костылей не настроил там, запуская два процесса, и гоняя между ними данные. Но это частный случай, и его стоит избегать.

ну окей -

Добавлено спустя 7 минут 29 секунд:

и для серверных осей.
Все так. Больше накладных расходов. Больше коллизий. Больше затрат времени. + Синхронизация на уровне LLC. Адские задержки. Двух и четырех головые - для узкого спектра задач.
Добавлено спустя 2 минуты 37 секунд:

не умеет в многопоток/"полноценный многопоток".
Взять к примеру фотошоп на 2011v3 - https://www.pugetsystems.com/labs/articles/adobe-photoshop-cc-multi-core-performance-625/ и здесь второй камень (двухсокет) дает только тормоз.
даже в более продвинутых unix/linux в ряде случаев многопоток софтине приходится задавать в явном виде.

А кто картинку рисует, если загрузка 100%? Вы в программировании вообще разбираетесь? В какой операционной системе и на каких процах?