Изменения: - добавлена возможность запустить тестирование на заданный временной интервал и новое выпадающее меню для переключения между двумя режимами (разы/минуты) - небольшие изменения/улучшения пользовательского интерфейса - окна графиков теперь корректно сохраняют свои позиции при выходе из программы - исправлен не очень частый баг с ошибками LinX при сильной загрузке процессора - добавлены новые параметры командной строки, исправлены найденные ошибки в старых (LinX.exe -help для вывода доступных параметров) - добавлены секунды в имена файлов для избежания переименования.
Теоретичеcкий пик определяется по следующим простым формулам:
для Athlon XP, P4, K8 - умножить реальную частоту на 2.
Для Core2, K10 -умножить реальную частоту на 4.
Реально достижимая эффективность от пика-
AXP, P4 ~ 75-80%
K8 ~85-90%
Core2 ~80-90%
K10 - to be found
Краткая инструкция:
В папке benchmarks\linpack надо пускать runme_xeon32.bat для x86 и x64 Windows, или runme_xeon64.bat для x64 Windows. 64-битная версия должна работать быстрее.
Перед запуском этот файл надо открыть в редакторе и изменить значение OMP_NUM_THREADS на полное количество ядер, реально присутствующих в компьютере, 2 для С2D, 4 для С2Q и т.д. Для нового Linpack 10 этого делать не надо!
После этого надо отредактировать файл lininput_xeon32 или lininput_xeon64 соответcтвенно.
В этом файле нас интересует -
1) # number of tests - количество различных размеров матриц, которые будут считатся. Должно соответствовать количеству чисел в следующей строке #problem sizes. Имеет смысл поставить просто 1 и в следующей строке указать максимальный размер который влезет в оперативную память
2) # problem sizes -размеры матриц систем линейных уравнений. Чем это число больше, тем больше получится результат. Начиная с некоторого значения (примерно 10000), рост замедлится. Обьем памяти, который нужно для запуска, можно посчитать по формуле 8*N^2. Для 10000 получим 800Mb. Если задать больше чем реально установлено памяти, будет своп и тормоза -этого делать не стоит. Также стоит оставить что-то системе для работы, скажем 0.5 -1GB.
3) #leading dimensions -повторить вторую строку
4) #times - каждая задача с размером матрицы из соответствующего столбца #problem sizes будет повторена times раз.
5) #alignment -оставить 4
Результат будет в файле win_xeon32.txt или win_xeon64.txt
Этот тест может также использоватся для проверки правильности выполнения вычислений, подобно Prime.
Для этого надо обратить внимание на значение поля Residual(norm). По моему опыту с этим тестом (под Linux), при "переразгоне" происходят 3 вещи
1) При сильном переразгоне будет BSOD
2) Далее, тест может завершится, но значение Residual(norm) будет большим, много больше 1.
3) Наконец, при совсем небольшом переразгоне значение Residual может быть маленьким, но оно будет заметно менятся от запуска к запуску -для одной и той же problem size (для разных это нормально). Поэтому, лучше оставить всего одно значение размера матрицы (максимальное), но прогнать его несколько раз (число прогонов задается в поле #times)
Пример входного файла для тестирования стабильности для 2GB памяти:
Sample Intel(R) LINPACK data file (lininput_xeon64)
Intel(R) LINPACK data
1 # number of tests
13700 # problem sizes
13700 # leading dimensions
200 #times to run a test
4 # alignment values (in KBytes)
Для 4GB вместо 13700 ставим 21000. Для 8GB -30000 и т.д.
Linpack 10 в некоторых случаях может выводить дополнительную строчку
Error: info returned =***
Это безопасный "глюк", не обращаем на него внимания.
Последний раз редактировалось Cronos 19.01.2008 15:07, всего редактировалось 7 раз(а).
http://www.intel.com/cd/software/produc ... 363184.htm Для интела вот... Добавлено спустя 34 минуты, 53 секунды Если будешь использовать для винды програмку, то рекомендую запускать батник runme_xeon32 ну или какой-то другой, только предварительно поправь в нем значение OMP_NUM_THREADS на нужное, по умолчанию там 2 стоит. Результаты тестов выведутся в win_xeon32.txt идут довольно долго. У меня выходило около 12.5гф на моем e4300@2700MHz, но чисто не тестировал. Добавлено спустя 1 час, 4 минуты, 50 секунд Вот мой результат, в пике 12.9362 GFlops (советую отрубать файл подкачки при работе теста, или самому задавать значения тестов):
Цитата:
Intel(R) LINPACK data
Intel(R) Optimized LINPACK Benchmark 9.1 Current date/time: Mon Oct 22 09:17:44 2007
CPU frequency: 2.700 GHz Number of CPUs: 2 Number of threads: 2 Parameters are set to:
Number of tests : 9 Number of equations to solve (problem size) : 15000 14000 13000 12000 11000 10000 8000 6000 1000 Leading dimension of array : 15000 14008 13000 12008 11000 10008 8008 6008 1000 Number of trials to run : 1 2 2 2 2 2 2 3 4 Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4
Maximum memory requested that can be used = 1569180224, at the size = 14000 ============= Timing linear equation system solver =================
Member
Статус: Не в сети Регистрация: 24.10.2003 Откуда: Novosibirsk
Потестил. Машина в профиле.
Цитата:
Intel(R) LINPACK data
Intel(R) Optimized LINPACK Benchmark 9.1 Current date/time: Tue Oct 23 19:56:35 2007
CPU frequency: 3.600 GHz Number of CPUs: 4 Number of threads: 4 Parameters are set to:
Number of tests : 1 Number of equations to solve (problem size) : 29000 Leading dimension of array : 29000 Number of trials to run : 4 Data alignment value (in Kbytes) : 4
Maximum memory requested that can be used = 2433616800, at the size = 29000 ============= Timing linear equation system solver =================
Size LDA Align. Average Maximal 29000 29000 4 48.2759 48.5351
End of tests 23.10.2007 20:22
Отдельное спасибо sashar2 за ссылку на экзешник под Windows. Если бы я не запустил ее под Windows, то не обратил бы внимание на температуры, а тут действительно есть на что обратить внимание!
Температуры в максимуме более чем на 10С выше чем c 4x Prime Small FFTs -это был предыдущий лидер по нагреву! Это просто невероятно, такой нагрев 72С - под водой. Можно утверждать что мы нашли самый сильно греющий тест для Core2, на 10С опережающий все что было до сих пор!
Обратить внимание на напряжение в cpu-z. Показания правильные. Проседает до 1.392, тогда как под 4x Prime Small FFTs меньше 1.400 не бывает.
Cюрприз номер два. Высокая эффективность.
48.535 Gigafops, 84.3% от теоретического пика=57.6Gigaflops. Впечатляет. Видимо сказывается высокоэффектинвый контроллер памяти в P35.
Какие то немного странные результаты, у меня квад на 3400 работает, но в итоге результат хуже почти в 1,8 раза.
Intel(R) LINPACK data
Intel(R) Optimized LINPACK Benchmark 9.1
Current date/time: Tue Oct 23 21:12:14 2007
CPU frequency: 3.402 GHz
Number of CPUs: 4
Number of threads: 4
Parameters are set to:
Number of tests : 9
Number of equations to solve (problem size) : 15000 14000 13000 12000 11000 10000 8000 6000 1000
Leading dimension of array : 15000 14008 13000 12008 11000 10008 8008 6008 1000
Number of trials to run : 1 2 2 2 2 2 2 3 4
Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4
Maximum memory requested that can be used = 1800304096, at the size = 15000
============= Timing linear equation system solver =================
Member
Статус: Не в сети Регистрация: 24.10.2003 Откуда: Novosibirsk
froz-777 Я написал инструкцию в процессорах, скопирую ее сюда.
Установи максимальный возможный размер матрицы, и -если возможно- используй 64-битную версию.
ALL Этот тест может также использоватся для проверки правильности выполнения вычислений, подобно Prime.
Для этого надо обратить внимание на значение поля Residual(norm). По моему опыту с этим тестом (под Linux), при "переразгоне" происходят
3 вещи
1) При сильном переразгоне будет BSOD
2) Далее, тест может завершится, но значение Residual(norm) будет большим, много больше 1.
3) Наконец, при совсем небольшом переразгоне значение Residual может быть маленьким, но оно будет заметно менятся от запуска к запуску -для одной и той же problem size (для разных это нормально). Поэтому, лучше оставить всего одно значение размера матрицы (максимальное), но прогнать его несколько раз (число прогонов задается в поле #times)
Intel(R) Optimized LINPACK Benchmark 9.1 Current date/time: Tue Oct 23 22:55:42 2007
CPU frequency: 3.608 GHz Number of CPUs: 4 Number of threads: 4 Parameters are set to:
Number of tests : 9 Number of equations to solve (problem size) : 15000 14000 13000 12000 11000 10000 8000 6000 1000 Leading dimension of array : 15000 14008 13000 12008 11000 10008 8008 6008 1000 Number of trials to run : 1 2 2 2 2 2 2 3 4 Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4
Maximum memory requested that can be used = 1569180224, at the size = 14000 ============= Timing linear equation system solver =================
Cronos Греет действительно очень сильно (82 в пике под СВО), но как программа для проверки систем охлаждения не подойдет, т.к. нагрузка скачкообразная, а не линейная. Кроме того, идут постоянные обращения к винчестеру. Кстати, скорее всего и результат у тебя выше т.к. памяти больше.
Member
Статус: Не в сети Регистрация: 24.10.2003 Откуда: Novosibirsk
Jordan писал(а):
Cronos Греет действительно очень сильно (82 в пике под СВО), но как программа для проверки систем охлаждения не подойдет, т.к. нагрузка скачкообразная, а не линейная. Кроме того, идут постоянные обращения к винчестеру. Кстати, скорее всего и результат у тебя выше т.к. памяти больше.
Настоятельно рекомендую прочитать инструкцию которую я написал (второй пост сверху).
Чтобы не было обращений к диску, надо задать максимальный размер матрицы соответственно доступному обьему памяти. Им же рекомендую и ограничится, тестировать меньшие не имеет большого смысла.
Для примера, для 2 GB, можно выделить 1.5GB на тест, тогда максимальный размер матрицы будет Sqrt(1 500 000 000/8 ) =13 700.
Для 15000 нужно 8*15000^2=1.8GB. Будет своп, так как на нужды системы 200MB не хватит.
Для тестирования СВО этот тест идеален. При исполоьзовании матриц с размером выбранным по вышеприведенным правилам нагрузка будет достаточно равномерной. Конечно, лучше чтобы памяти было 4GB.
Кстати, максимальное теоретическое значение определится как Частота*(Количество ядер)*4.
*Cofradia Intel*
Статус: Не в сети Регистрация: 20.07.2006 Откуда: Донецк
Intel(R) LINPACK data
Intel(R) Optimized LINPACK Benchmark 9.1
Current date/time: Mon Oct 29 18:21:24 2007
CPU frequency: 3.200 GHz
Number of CPUs: 4
Number of threads: 4
Parameters are set to:
Number of tests : 9
Number of equations to solve (problem size) : 15000 14000 13000 12000 11000 10000 8000 6000 1000
Leading dimension of array : 15000 14008 13000 12008 11000 10008 8008 6008 1000
Number of trials to run : 1 2 2 2 2 2 2 3 4
Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4
Maximum memory requested that can be used = 1569180224, at the size = 14000
============= Timing linear equation system solver =================
mike02 Да, у тебя не стабильно на этой частоте ведет себя проц...
Cootri Linpackом и измеряют гигафлопсы, теоритический предел на нем не найти. К примеру у mike02 на 3.2 должно быть 3.2x4x4=51.2, а у него даже до 30 не дотянуло, хотя тут наверное сказалсь нестабильность.
linpack это весчь!
кстати скопирую сюда свой пост из процессоров,
"Кстати, вот есть такой бенч - LINPACK, основанный на популярной математической библиотеке с одноименным названием (решение линейных уравнений), с помощью ее меряются реальными (не теоритическими) Гигафлопсами производители мощных вычислительных систем с давних времен.
тест скомпилирован и оптимизирован Intel под ее процессоры, качать Windows package:
http://www.intel.com/cd/software/produc ... 363184.htm
для квадов в батнике runme_xeon32.bat изменить OMP_NUM_THREADS с 2 на 4 (иначе будет только 2 потока!)
тест linpack_xeon64.bat (пойдет естественно только на Win64) жрет очень много памяти, резирвирует сразу 7Гигов, у меня с размера задачи 30000 начался дикий своп, и я его прервал. Можно скорректировать файл заданий lininput_xeon64, изменив number of tests и уменьшив соответственно позиции в нижних строчках.
после теста формируется текстовик win_xeon32/64.txt там в зависимости от размера задачи выводится время, гигафлопсы, ошибка (должна быть очень маленькая величина около нуля).
греет проц очень сильно! OCCT вообще фигня по сравнению с этим. И в отличии от OCCT, TAT и других искуственных тестов стабильности/грелок, тут реальный код, реальная используемая и известная библиотека, откомпилированная производителем процев на его компиляторе, со всеми оптимизациями.
Тест можно превратить легко в лучший тест стабильности CPU/RAM, чуть изменив файл заданий lininput_xeon32/64 (выбрав максимальную задачу для вашей системы, и побольше раз повторить, задав побольше поле в строчке times to run). Я словил синий экран, и прошлось понизить частоты памяти, хотя на других тестах такого не было, а тут всего за 10 минут.
----
пример теста, со стабильного тщательно оттестированного "тихого" режима 3.24ГГц 1.32В, погнал до стабильных 3.33 (ранее долгими прогонами OCCT выяснял нужное напряжения питания которое равно 1.362В)
размер системы 20000, 3Гига юзается памяти, тестится в Win64
файл задание:
Sample Intel(R) LINPACK data file (lininput_xeon64)
Intel(R) LINPACK data
1 # number of tests
20000# problem sizes
20000# leading dimensions
1 # times to run a test
4 # alignment values (in KBytes)
прогоны:
1) 3.33 напряжение, 1.32В = синий экран
2) ---, 1.35 все посчитала, но невязка (Residual) равна 5, очень большое число, т.е. посчитала неверно
3) 1.362, невязка ~1e-10 т.е. все ок
на все ушло максимум 10 минут!" Добавлено спустя 11 минут, 5 секунд надо еще покопать как убрать проверку процессора, так как на AMD тест не запускается...
*Cofradia Intel*
Статус: Не в сети Регистрация: 20.07.2006 Откуда: Донецк
sashar2 писал(а):
mike02 Да, у тебя не стабильно на этой частоте ведет себя проц...
Cootri Linpackом и измеряют гигафлопсы, теоритический предел на нем не найти. К примеру у mike02 на 3.2 должно быть 3.2x4x4=51.2, а у него даже до 30 не дотянуло, хотя тут наверное сказалсь нестабильность.
Я не знаю насчет нестабильности, могЁт быть, но смотри другое: 3,6*4*4=57,6 а у Jordan'а получилось 33,8. Так что тут скорее дело не в нестабильности а в ошибочности оценки в формуле.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 15
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения