HugoRandomBenchmark
 

Читал статью про KVM и натолкнулся на забавный бенчмарк ;)
http://www.hants.lug.org.uk/cgi-bin/...andomBenchmark

Предлагаю внести лепту - пополнить результаты. :)

Кто желает, запустите бенчмарк
Свой процессор
и лучший из 5 замеров (где время будет наименьшее) публикуйте в тэге SP :) Потом внесу их в вики по ссылке выше.

Сделал.

Но это с зарущенными иксами и всякими другими приложениями, можно было вырубить иксы и большинство процессов; поднять частоту процессора.

Вот что у меня вышло.

Мои пять копеек

Пока что самая длинная <censored> у Frosty... :)

tmp0000, дык неудивительно. :) В этом тесте мегагерцы решают, а у Frosty их больше всех.

На батле их больше, но постоянную нагрузку, искажающую результаты, не снять. Так что и бенчмарк не прогнать. :D

Там на сайте, кстати, есть более крутой <censored>омер - UNIXBench :]

Только что прогнал

и на закуску ;)

а вообще бенчмарк довольно странный и результат вроде не зависит от размера кеша.

Добавлено через 50 минут
забыл ещё про пару железок... впрочем они далеко не мои :rolleyes:


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

MaXx, как бы не спалить... :unsure:

Ага, мне он тоже показался очень забавным. Такое ощущение - он измеряет площадь поверхности "сферического коня в вакууме". Вы тут всё измеряете, да измеряете, а хоть кто-то разобрался что этот тест измеряет? И главное, какие факторы больше всего влияют на результат?

P.S. Я пока лишь обаружил, что он меряет тормоза perl на не лучшей для него задаче.

запустил на kappa.cs.karelia.ru

XeNoN, это бенчмарк. Очень условный, но тем не менее, имеющий право на существование. Какая разница, на Perl он или на том же Си? :] Соотношения между результатами все равно будут одинаковыми независимо от того, на чем этот цикл прогоняют.


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

Да, бедная каппа, ее многие имеют даже по ночам...

rmn, ну если на то пошло, то компилятор си бадяжит код прямиком в бинарный вид(да и вообще без особых проблем можно узнать что бадяжит и как) а в случае перла совсем не так. Поэтому и возникает ощущение, что меряются тормоза перла, а никак не частоты процов. Да и за примером далеко ходить не надо(если сравнивать с Си=) ) на сихе такой цикл меньше чем за секунду выполнится, а на Perl'е как видно совсем иннная ситуация, вот тут и возникает вопрос, что он там делает, как?

Право на существование никто отменять и не собирается, это как у Маяковского - значит даже такой непонятный benchmark кому-то нужен.:)

Соотношения между результатами Си и Perl будут разными. На это greiv дал прекрасный ответ.

rmn, поэтому собственно и возникает вопрос, что он там меряет и от каких факторов зависит результат. На этот вопрос я так и не нашёл ответа, поэтому и спрашиваю, что же вы все тут измеряете? С вашим предположением о том что основным фактором является частота процессора я наполовину согласен. Я считаю частоту важным фактором, но далеко не определяющим, иначе как объяснить, что P-III 900MHz показывает схожие результаты с Celeron 1715MHz. Известно правда, что у P-III числодробилка мощнее чем у P-IV. Но неизвестно (ну мне неизвестно, а собирать perl в отладочном режиме лень), что там делает perl при выполнении данного кода. Пока не станет ясно какие факторы определяют результат придётся записывать этот benchmark в ряд обычных "пиписькомеров" (о чём собственно и было упомянуто в названии темы), наряду со сравнением производительности ФС путём разархивирования линукс ядра (это вообще из разряда "для ламеров", настоящие мужики так не меряют).;)

:) Бенчмарк как бенчмарк. Задача, по времени исполнения которой можно расставить относительные оценки.

Измеряем время исполнения конкретной задачи. Разве не так?

Да нет, тактовая частота - определяющий фактор, иначе бы смысла в бенчмарке не было совсем.

Про "схожие" результаты, собственно, где они?

А не логично ли было выбрать список рассылки / irc-канал / форум / etc с концентрацией Perl-гуру в разы большей, чем тут, и задать вопрос там, если так интересуют технические детали работы perl? :)

нормальное сравнение на реальных задачах (правда, тут не только в производительности ФС дело). ;] Не все же вам bonnie++ подавай. :D

Нет, не можем, т.к мы не знаем отчего наши оценки зависят. Иначе необходимо было бы указывать полностью программно-аппаратную конфигурацию и оценивать её целиком, а не только процессор.

Если конкретика заключается во времени исполнения данного кода perl, то да. Иначе - меряем чтобы мерять.

Почему нет, а какже узнать сколько времени исполняется неизвестно что? И померять как что-то загадочное на это влияет? :D





P-III - это капповская машина. Как объяснить?

Что? Постоянно разархивируете ядро линукса?:D bonnie++ мне не нужен, но мир бы стал ярче и лучше если бы во всех тестах было бы понятно какие факторы влияют на результат. А ярче он бы стал потому что меньше криков было бы по типу: "Наша Генту быстрее вашей Убунту, т.к. CD-диски с ней дальше кинуть можно" Или как некоторые сравнивают производительность ФС так, что у них нет разницы при синхронной записи и ассинхронной - это как раз на вашей "реальной" задаче по разархивированию ядра. (зачем придумали журналирование в ФС надо объяснять?)

P.S. rmn, цель моих постов была не "обосрать" данный benchmark, а привлечь внимание к проблеме тестирования. Примеры нормальных замеров производительности я могу привести.

Пусть будет так. :]

Так я предложил выше, как можно разобраться. Понятно, что "тормоза" Perl - это от природы. Природу бы знающие люди и объяснили.


а какая загрузка у этой машины? load average в uptime до и после работы скрипта какой? И какая она у celeron?

Проблему тестирования увидит любой, кто знает что такое Perl и кому приходилось на нем хоть что-либо значительное писать. Другое дело - дать техническое объяснение этих самых "тормозов". Тут уже нужна совсем другая квалификация.

ok. я всё внимание. :)

Так я тоже предложил - надо собрать perl с опциями -pg и всё станет ясно. Но я считаю, что создатели данного теста и люди предлагающие им воспользоваться, должны были это сделать сами и всё описать.



Ничерта не понял, как проблемы тестирования связаны с perl? Помоему это некая общая проблема.

Вы с экспериментальной физикой знакомы?

Ну раз "всё", то вечером расскажу.:)

Какой четкий вопрос задал XeNoN(блин, опередил). Я как раз хотел написать про тест и физический эксперимент. В том смысле, что по сути создать тест, это значит соблюсти все теже условия для постановки физ. эксперимента(даже хотел превести пример из своей курсовой=) ). Иначе же получается, что здесь меряют ради того, чтобы мерят. Получается так, что народ сидит в своей "песочницы", что там меряет и радаются(типа) мол какой проц у меня мощный, комп быстрый, а тех кто пытается до них достучаться мол вы хоть сами-то понимаете чем занимаеетесь, отвечают - пшел вон, ненадо рушить наш мирок, нам и так хорошо... грустно что тут скажешь

Рассказываю.

Во-первых примеры нормальных тестов можно посмотреть на сайтах Intel, AMD, Sun, IBM, и т. д. и т. п. Все эти фирмы делали тесты-числодробилки, тесты ФС (у Sun ZFS присутствует целый набор различных стресс-тестов и тестов производительности). Можно поглядеть тесты входящие в MySQL. Также множество методов тестирования рассмотрены в публикациях различных университетов.

Во-вторых для нормального процесса измерения/тестирования минимум необходимо:
1. Понимание процессов происходящих в измеряемой системе.
2. Учёт и определение степени влияния различных факторов на измеряемую величину.
3. Средства измерения.
4. Построение схемы измерения, позволяющей с достаточной точностью провести эксперимент.
5. Чёткое понимание того, зачем всё это делается.

Естественно, что всё вышеприведённое - это мой краткий пересказ, не на что не притендующий. На этот счёт разработана целая теория, с которой можно ознакомиться в различной литературе.

Большинство "пиписькометров" отпадают по всем пунктам.
Вот это:
в большей степени противоречит пунктам 2 и 5. Потому как никто в данной теме не знает зачем нужен этот тест (вернее использует не по назначению), непонимает какие факторы влияют на его результат (все приводят как определяющий фактор процессор).

В сравнении производительности ФС по времени разархивирования ядра Linux не учитывается время работы архиватора(это самое долгое что здесь вполняется) и время работы дисковой подсистемы. Но утверждают почему-то что основную работу делает ФС.

(Чаще кстати измеряют не время выполнения чего-то, а количество выполненых операций за некоторое время)

Примеры нормальных тестов и их правильного использования:
1. Тесты MySQL. С их помощью например исследовалось поведения нового планировщика FreeBSD - ULE2 на SMP системе в сравнении с предыдущими версиями - ULE, 4BSD и планировщиком Linux. В результате новый планировщик показал лучшие результаты чем предыдущие, а также чем планировщик Linux. Таким образом разработчики FreeBSD - убедились в правильности выбора направления развития, а разработчики Linux смогли выявить и устранить проблему в своем планировщике. (А что ваш тест показал? Что Intel впустую потратили столько сил на увеличение частоты своих процессоров?)

2. При разработке UFS2 была разработана альтернативная к журналированию и COW система поддержания согласованного состояния дискового хранилища - Soft Updates (SU). Необходимо было оценить её производительность. В качестве худшего по производительности варианта взяли синхронный режим записи (S) на диск, а режим асинхронного (A) как самый производительный. Был написан набор тестов:
-> 1-й тест состоял из 1000 запусков контрольной задачи Эндрю: 1000 копирований и удалений /etc со случайно выбранными паузами от 0 до 60 секунд между каждым удалением и копированием и 500 исполнений утилиты find / со случайно выбранными паузами в 100 сек. между каждым запуском. Измерялось количество синхронных и асинхронных записей на диск и время прогона. Время прогона для ФС в режиме S - 27ч. 54мин. , для A - 19ч. 43мин., а для SU - 19ч. 50мин.
-> 2-й тест состоит из построения и инсталяции FreeBSD. Т.е задача является практически примером среды разработки программ. В результате время прогона и соотношение синхронных записей к асинхронным для S - 2ч. 12мин. 162410 к 39924, для A - 1ч. 44мин. 0 к 38262, для SU - 1ч. 44мин. 1124 к 48850
-> 3-й тест сравнивает производительность основного почтового сервера BSDI, запущенного с SU и S (МакКузик говорит, что там админ испугался в асинхронном режиме запускать:) ). Статистика была собрана путём усреднения результатов операций за 30!!! рабочих дней в каждом режиме. Результаты: S - 1877794 к 1613465, SU - 118102 к 946519. Вывод: для этого практического приложения SU требуют на 70 процентов меньше записей, что утраивает способность машины к обработке почты.

Так же неплохая методика тестирования описана на сайте SGI про тестирование XFS.

Вобщем надеюсь суть ясна, что измерение/тестирование требует подключение дополнительных возможностей мозга к тем, которые требуются для поиска в google и щёлканья по ссылкам. Особенно важно понимать зачем оно вообще нужно. Лично для меня это не "пиписькомер", а метод/средство позволяющее лучше понять зависимость между различными вещами и выявить узкие участки. В benchmark'е с которого началась данная темя я таких возможностей без доп. исследования не заметил. Но всё равно "спасибо" rmn за убитое свободное время, которое я провёл с различными эксперементами на разных языках, на разных машинах и может всё-таки соберу perl в отладочном режиме и попробую понять чё он там делает этот benchmark.:D

Приминительно к теме. Вот щапривиду пример тех за счет кого строятся счастливые мирки=). Есть такой пользователь юникс-подобных систем со стажем! как X(не буду писать его фамилю) много статей написал про линукс и фряху. Решил как-то протестировать производительность UFS2(фс во фряхе). Значит, что он сделал взял исходники фряхи разархивировал с асинхронной записью на диск и с синхорнной. И о чудо(ну он подумал нихера себе чудо). Результаты получаются одни и теже, что с асинхоронной, что с синхронной. Оболдеть тестер нашелся, блин даже не смешно, лучше бы писал и дальше свои статейки как mc раскрасить, консоль руссифицировать и т.д. А ведь народ-то поверить, как же так такой уважаемый автор не мог нам соврать. Другой пример. челс решил измерить производительность фряхи и нетбсд на многопроцессорных тачках. Взял скомпилил исходники нетбсд(с соотвествующими опциями для многопроцессорной байды) сначала на нетбсд, а затем ее же исходники на фряхе и оказалось, нетбсд производительней!!!(хотя с SMP у нетбсдяшников ) Я чуть не слег после такого теста... Я думаю, говорить о том что каждый уважаемый себе линуксойд тестить фс разархивированием линукс ядра вообще излишне. Вот такие вот личности создают счастливые мирки. Если вас устраивать, то живите наздоровье=)