У организаторов было куча времени что бы все проанализировать и сделать тестирование как им хочется.
Да, у них было много времени (если учесть, что они по праздникам работают), но они этого почему-то не сделали.
Элемент неожиданности должен быть только в тестовых данных (количество условий, значения), а не в методах тестирования, иначе это не конкурс, а рулетка какая-то. Некорректный метод тестирования вносит слишком большую погрешность, согласитесь с этим. А теперь поймите людей у которых действительно интересные и эффективные решения практически на любых типах и размерах входных данных, а они почему-то занимают 50+ место, хотя реально должны входить в тройку победителей. И всё из-за того, что они и представить себе не могли, что тестирование будет проводиться именно так (проблема не в тестовых данных, а в том каким образом запускают эти тесты).
Если вы уверены в том, что ваш алгоритм действительно быстрее всех, то вам не стоит беспокоиться о том, что кто-то может вас сместить с 1-го места.
Но вообще, по-честному, замеры были произведены некорректно, это объективная оценка и с ней согласились организаторы конкурса. Надо смириться с этим.
А самое оригинальное решение тоже будет пересмотрено? Чтобы не разбираться в чужом коде, может попросить людей прислать описания их алгоритмов человечьим языком?
Думаю, что это серьёзный повод пересмотреть результаты. Заодно и методику замера изменить. И запускать по 10 итераций на каждое решение и запустить так все решения 10 раз. В итоге будет по 10 лучших результатов на каждое решение и из них выбрать лучшее. Так будет справдливее! А то я сейчас тесты гоняю и время от времени некоторые тесты на 30-40% быстрее начинают работать, а некоторые наоборот медленнее… И всё это на одном и том же наборе данных (на том, что предложено организаторами конкурса).
И самое оригинальное решение надо тоже пересмотреть, как мне кажется, оно никапли не оригинальное, оно слишком простое и просто маленькое по размеру, но никак не оригинальное. Но последнее это моя субъективная точка зрения.
Как обещал, альтернативные результаты конкурса. github.com/zbitname/hola_nodejs_challenge
Заранее прошу не бить. Сделал это только лишь для того, чтобы показать на сколько сильно могут отличаться результаты в зависимости от методики тестирования.
Кстати, когда вы писали про виртуальную машину в условиях конкурса, я подумал о нормальной виртуальной машине, а не о модуле vm… Думаю, что с этим лоханулся не я один…
Минут 5 назад свой бенчмарк запустил, по 1 разу каждое решение, Roman Pletnev с лучшим результатом, причём с хорошим отрывом от второго места. Сейчас запустил тот же бенчмарк, только по 50 раз каждое решение и выбирается лучшее время. Использовал исходные данные из тех что были на конкурсе. Учитывая, что некоторые решения ну очень уж медленные — результат по всем конкурсантам будет часа через 2-3…
Запустил на виртуалке на DO (1 GB Memory / 30 GB Disk / NYC3 / Ubuntu 14.04 x64 vmlinuz-3.13.0-71-generic / nodejs v5.0.0-x64).
Постараюсь сегодня успеть опубликовать результаты своего тестирования на гитхабе.
19 место.
Прогнал все решения по своим тестам на корректность, которые были проверены по «эталонной реализации», получилось -19 человек из тех что заняли хоть какое-то место. Т.е. не у всех ещё «по-настоящему» корректно работает фильтр.
Сейчас сижу выбираю где виртуалку поднять, чтобы тест на производительность по моему бенчмарку прогнать с теми тестовыми данными, что были сгенерированы для конкурса организатором. Посмотрим что выйдет :)
Хорошо, я и не спорю, хочу только мысль свою донести.
Случайно ссылкой ошибся выше. Сейчас добрался до компа, обновил всё, добавил ваш тестовый набор данных, запустил bash-скрипт.
Итог
$ ./run4.bash ./submissions/Sergey\ Golub/filter.js
AVG = .78901676
BEST = .771083600
$ ./run4.bash ./submissions/Yuri\ Kilochek/filter.js
AVG = .76020389
BEST = .735113200
$ ./run4.bash ./submissions/Ilya\ Makarov/filter-with-memo.js
AVG = .85580227
BEST = .820365600
$ ./run4.bash ./submissions/Denis\ Kreshikhin/kreshikhin-filter.js
AVG = .82748225
BEST = .812334200
Проверил только призёров и результат уже другой, тот кто на втором месте оказался на первом. Если интересно, то могу моим способом всех остальных тоже проверить и выложить результат, мне не сложно. Но тут время зависит ещё от некоторых факторов, загруженность процессора и прочее, т.к. выполнял на своём ноуте из под рут-системы. Думаю, что на выделенной виртуалке на свободном новеньком серваке результаты будут более показательыми.
Я лишь хочу сказать, что результат зависит ещё и от метода тестирования. Я считаю, что выбранный вами способ бенчмаркинга «трушным» способом протестировать производительность. Считаю, что правильнее перезапускать скрипт полностью для каждой итерации. Не прошу соглашаться со мной, не пытаюсь спорить, не жду пересмотра результатов, не жду ответа и понимания, не разжигаю межрассовые войны, просто делюсь мыслями и рассказываю о своей точке зрения, о том как я бы реализовал бенчмарк на вашем месте. Ну и итераций взял бы не 10, а штук 50, чтобы выборка была более репрезентативной.
Да не в наборе тестовых данных дело, а в методике тестирования. Прошу прощения, если написал так, что вы подумали, что я жалуюсь на набор тестовых данных.
К сожалению, нет возможности сейчас откорректировать свой вариант бенчмарка и добавить в него ваш набор тестовых данных… Поэтому предложил это сделать вам. Там изменять надо всего ничего, одну или 2 строчки, ну и файлы с данными рядом положить.
Вы запускаете фильтр 10 раз с одними и теми же тестовыми данными. Вы думаете в реальной ситуации вам шлют по 10 раз одно и то же письмо всегда? Я тоже считаю, что нет. Поэтому, думаю, что нужно было исключить оптимизацию V8 между запусками фильтра по одному и тому же набору данных. Если бы это было 10 запусков фильтра по разным наборам данных, то всё нормально.
Каждая итерация теста производительности у нас ассоциируется с временем жизни почтового ящика. У вас этот почтовый ящик проживает 10 одинаковых жизней.
Это исключит не только оптимизацию движком, но и кеш внутри самого фильтра. Например, я все регулярки кеширую и при повторном использовании фильтра с тем же набором тестовых данных он отработать немного быстрее, т.к. всё что нужно уже будет в кеше, что тоже считаю не очень честным решением, т.к. именно такой подход к тестированию как у вас позволяет немножечко читерить и уже не важно на сколько хорош твой алгоритм с теоретической точки зрения, а важно угадал ты или нет с тем как будут проводить тестирование.
Ну самый простой способ узнать про оптимизацию V8 — погуглить.
В процессе выполения скрипта движок V8 умеет определять какие функции можно оптимизировать, вывести их выполнение на более низкий уровень, что увеличивает скорость выполнения этих функций в разы.
Взяты из открытых источников. Не в этом суть. Вы свой тестовый набор данных подставьте, посмотрите разницу, это если интересно :) Я не намекаю, что должен быть в тройке призёров, я только лишь хочу сказать, что методика измерения производительности может сильно влиять на результат. В случае с bash скриптами на 100% исключается оптимизация движком, правда появляется время загрузки тестовых данных, но это время у всех будет примерно одинаковым и на большом количестве выборок можно посчитать avg и судить по нему.
Элемент неожиданности должен быть только в тестовых данных (количество условий, значения), а не в методах тестирования, иначе это не конкурс, а рулетка какая-то. Некорректный метод тестирования вносит слишком большую погрешность, согласитесь с этим. А теперь поймите людей у которых действительно интересные и эффективные решения практически на любых типах и размерах входных данных, а они почему-то занимают 50+ место, хотя реально должны входить в тройку победителей. И всё из-за того, что они и представить себе не могли, что тестирование будет проводиться именно так (проблема не в тестовых данных, а в том каким образом запускают эти тесты).
Но вообще, по-честному, замеры были произведены некорректно, это объективная оценка и с ней согласились организаторы конкурса. Надо смириться с этим.
И самое оригинальное решение надо тоже пересмотреть, как мне кажется, оно никапли не оригинальное, оно слишком простое и просто маленькое по размеру, но никак не оригинальное. Но последнее это моя субъективная точка зрения.
github.com/zbitname/hola_nodejs_challenge
Заранее прошу не бить. Сделал это только лишь для того, чтобы показать на сколько сильно могут отличаться результаты в зависимости от методики тестирования.
Запустил на виртуалке на DO (1 GB Memory / 30 GB Disk / NYC3 / Ubuntu 14.04 x64 vmlinuz-3.13.0-71-generic / nodejs v5.0.0-x64).
Постараюсь сегодня успеть опубликовать результаты своего тестирования на гитхабе.
Прогнал все решения по своим тестам на корректность, которые были проверены по «эталонной реализации», получилось -19 человек из тех что заняли хоть какое-то место. Т.е. не у всех ещё «по-настоящему» корректно работает фильтр.
Сейчас сижу выбираю где виртуалку поднять, чтобы тест на производительность по моему бенчмарку прогнать с теми тестовыми данными, что были сгенерированы для конкурса организатором. Посмотрим что выйдет :)
Это быстрее чем у всех призовых.
Случайно ссылкой ошибся выше. Сейчас добрался до компа, обновил всё, добавил ваш тестовый набор данных, запустил bash-скрипт.
Проверил только призёров и результат уже другой, тот кто на втором месте оказался на первом. Если интересно, то могу моим способом всех остальных тоже проверить и выложить результат, мне не сложно. Но тут время зависит ещё от некоторых факторов, загруженность процессора и прочее, т.к. выполнял на своём ноуте из под рут-системы. Думаю, что на выделенной виртуалке на свободном новеньком серваке результаты будут более показательыми.
Я лишь хочу сказать, что результат зависит ещё и от метода тестирования. Я считаю, что выбранный вами способ бенчмаркинга «трушным» способом протестировать производительность. Считаю, что правильнее перезапускать скрипт полностью для каждой итерации. Не прошу соглашаться со мной, не пытаюсь спорить, не жду пересмотра результатов, не жду ответа и понимания, не разжигаю межрассовые войны, просто делюсь мыслями и рассказываю о своей точке зрения, о том как я бы реализовал бенчмарк на вашем месте. Ну и итераций взял бы не 10, а штук 50, чтобы выборка была более репрезентативной.
Каждая итерация теста производительности у нас ассоциируется с временем жизни почтового ящика. У вас этот почтовый ящик проживает 10 одинаковых жизней.
Это исключит не только оптимизацию движком, но и кеш внутри самого фильтра. Например, я все регулярки кеширую и при повторном использовании фильтра с тем же набором тестовых данных он отработать немного быстрее, т.к. всё что нужно уже будет в кеше, что тоже считаю не очень честным решением, т.к. именно такой подход к тестированию как у вас позволяет немножечко читерить и уже не важно на сколько хорош твой алгоритм с теоретической точки зрения, а важно угадал ты или нет с тем как будут проводить тестирование.
В процессе выполения скрипта движок V8 умеет определять какие функции можно оптимизировать, вывести их выполнение на более низкий уровень, что увеличивает скорость выполнения этих функций в разы.