насколько адекватен тест «процессор-память» dd if=/dev/zero of=/dev/null?

параметр команды: dd if=/dev/zero of=/dev/null bs=1M count=32000

parallel забыл, процессоры же в этом парке не одноядерные.

У меня 13 GB/c. А в случае если bs=1G, то 7.4 GB/c.

Память у меня ddr3 на частоте 1600 в двухканальном режиме, т.е. 128 бит шина. Получается 1600*128/8=25600 MB/с или 25 GB/с. Мне уже начинать переживать или стоит погонять специализированные тесты из какого-нибудь похороникса?

Ни на сколько.

работать с памятью через системные вызовы?
наркоман штоле?

Тут нет никакой работы с памятью, кроме косвенной. null, zero — специальные файлы, которые никуда не пишут, и ниоткуда не читают.

А почему не хочешь использовать md5sum на помещённом в tmpfs файле?

никуда не пишут, и ниоткуда не читают

ага, а почему тогда скорость не бесконечная, раз ничего не делается?
здесь на каждом цикле работы происходит заполнение нулями куска юзерской памяти объемом 1МБ, и делает это ядро; это и является полезной частью для измерения скорости работы с памятью
но кроме этого дополнительно выполняются лишние действия, на которые тоже тратится время, что приводит к погрешности измерения: двойной свитч-контекст в/из кернел-спейс на вызов read() и двойной свитч-контекст в/из кернел-спейс на вызов write()
конечно, если абсолютные значения не важны, а требуется только сравнивать разные конфигурации между собой, то предложенные лапти вполне годятся

А проц какой? У Меня 18 GB/s на памяти 1333 и, скорее всего, одноканальном режиме.

60GB похоже на правду. Примерно там потолок для четырёх каналов DDR3, у DDR4 чуть повыше.

Слишком много энтропии и слишком мало работы с памятью.

об чем и речь

У меня процессор i5 750 на 3.6 ггц и судя по всему все упирается в него. Т.е. то что скорость меньше теоретической пропускной способности - это по-идее нормально. Другой вопрос если больше, тогда получается память вообще не используется, а все гонится через кэш проца?

Нинасколько не адекватен. Как уже выше отметили, ты меряешь время четырёх переключений контекста и записи небольшого количества нулей в кэш с памятью. Во-первых, чтения не происходит, во-вторых, кэши в современных системах вполне себе writeback (а 1M блока вполне себе влезает в L3), а в-третьих, у тебя оверхеда асимптотически столько же, сколько и нагрузки: O(n).

А вдруг там sendfile под низом.

dd if=/dev/zero of=/dev/null bs=1M count=32000
32000+0 записей получено
32000+0 записей отправлено
скопировано 33554432000 байт (34 GB), 4,0707 c, 8,2 GB/c

dd if=/dev/zero of=/dev/null bs=64M count=500
500+0 записей получено
500+0 записей отправлено
скопировано 33554432000 байт (34 GB), 7,85108 c, 4,3 GB/c

При разных размерах блока у кого-то становится быстрее, а у меня медленнее. Не похоже на адекватный тест, хотя может при одинаковых bs=1M покатит...

А почему не хочешь использовать md5sum на помещённом в tmpfs файле?

Кста, идея хороша :)

вот пример,

X3450 @ 2.67GHz + DDR3 1333 MHz - 33554432000 bytes (34 GB) copied, 0,651094 секунд, 51,5 GB/s

AMD Opteron(tm) Processor 6380 + DDR3 1600 MHz - 33554432000 байт (34 GB), 3,96953 c, 8,5 GB/c

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

amd cheats and actually is slow, intel is mind-bogglingly faster and clearly winz 100% legict confirmed

я просто не могу понять

Тест говно. Как тебе ещё понятнее написать?