HugoRandomBenchmark

[rmn]

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

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

Цитата: rmn, поэтому собственно и возникает вопрос, что он там меряет и от каких факторов зависит результат. На этот вопрос я так и не нашёл ответа, поэтому и спрашиваю, что же вы все тут измеряете?

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

Цитата: С вашим предположением о том что основным фактором является частота процессора я наполовину согласен. Я считаю частоту важным фактором, но далеко не определяющим, иначе как объяснить, что P-III 900MHz показывает схожие результаты с Celeron 1715MHz.

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

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

Цитата: Известно правда, что у P-III числодробилка мощнее чем у P-IV. Но неизвестно (ну мне неизвестно, а собирать perl в отладочном режиме лень), что там делает perl при выполнении данного кода. Пока не станет ясно какие факторы определяют результат придётся записывать этот benchmark в ряд обычных "пиписькомеров" (о чём собственно и было упомянуто в названии темы)

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

Цитата: наряду со сравнением производительности ФС путём разархивирования линукс ядра (это вообще из разряда "для ламеров", настоящие мужики так не меряют).

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

[XeNoN]

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

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

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

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

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

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

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

Спойлер

CPU: Intel(R) Celeron(R) CPU 1.70GHz (1715.89-MHz 686-class CPU)
35.357u 0.007s 0:40.43 87.4% 10+368k 0+0io 0pf+0w

Спойлер

model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 935.481
cache size : 256 KB

Total time : 0:39.14m
Time spent in user mode (CPU seconds) : 38.970s
Time spent in kernel mode (CPU seconds) : 0.028s
CPU utilisation (percentage) : 99.6%

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

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

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

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

[rmn]

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

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

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

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

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

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

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

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

Цитата: Примеры нормальных замеров производительности я могу привести.

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

[XeNoN]

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

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

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

Спойлер

------------------------------------------------------------------------------
P-III
------------------------------------------------------------------------------
user:~ > uptime
10:40am ####### 31 #### 11:01, 10 #############, ####### #############: 0,00,
0,02, 0,05
user:~ > time perl -e 'for($i=0;$i<1e8;$i++){}'

Total time : 0:39.27m
Time spent in user mode (CPU seconds) : 38.910s
Time spent in kernel mode (CPU seconds) : 0.028s
CPU utilisation (percentage) : 99.1%
Times the process was swapped : 0
The number of input operations : 0
The number of output operations : 0
The number of system calls performed :
The total space used in Kbytes : 0
The maximum memory the process had
in use at any time in Kbytes : 0
user:~ > uptime
10:42am ####### 31 #### 11:02, 10 #############, ####### #############: 0,62,
0,18, 0,10
user:~ >

------------------------------------------------------------------------------
Celeron 1.7 GHz
------------------------------------------------------------------------------
[XeNoN:~]# uptime
10:34 up 10 mins, 3 users, load averages: 0,16 0,14 0,09
[XeNoN:~]# time perl -e 'for($i=0;$i<=1e8;$i++){}'
35.304u 0.022s 0:37.34 94.5% 10+365k 14+0io 21pf+0w
[XeNoN:~]# uptime
10:35 up 11 mins, 3 users, load averages: 0,48 0,22 0,12
[XeNoN:~]#

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

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

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

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

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

[greiv]

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

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

[mxx]

Оффтоп

Оффтоп

Сообщение от greiv Получается так, что народ сидит в своей "песочницы", что там меряет и радаются(типа) мол какой проц у меня мощный, комп быстрый, а тех кто пытается до них достучаться мол вы хоть сами-то понимаете чем занимаеетесь, отвечают - пшел вон, ненадо рушить наш мирок, нам и так хорошо... грустно что тут скажешь меня всегда удивляет, почему люди всегда, ну или почти всегда, считают, что они лучше знают, что для других хорошо, а что плохо я к тому, что создали люди мирок, рады этому - зачем им мешать, если их всё устраивает и им в нём очень даже хорошо? радоваться за них надо, что у них всё без проблем и они живут счастливой жизнью. ну это меня уже понесло...

[XeNoN]

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

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

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

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

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

Большинство "пиписькометров" отпадают по всем пунктам.
Вот это:

Цитата: time perl -e 'for($i=0;$i<=1e8;$i++){}'

в большей степени противоречит пунктам 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.

[greiv]

Оффтоп

Оффтоп

Цитата: я к тому, что создали люди мирок, рады этому - зачем им мешать, если их всё устраивает и им в нём очень даже хорошо? радоваться за них надо, что у них всё без проблем и они живут счастливой жизнью. Вот это и напрягает, что живут без проблем, счастливой жизнью. Такое бывает? Да и мирок-то получается навязанный со стороны, ложный, т.е. люди неконтролируют ситуацию, какое тут счатье...

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