Пара интересных фактов:
В свое время был удивлен, что select в fd_set для индексации использует номер сокета сиречь файлового дескриптора, т.е. если открыть сначала 512 файлов, то под сокеты останется также 512 бит из fd_set. Кроме того
подправив __FD_SETSIZE в kernel/include/linux/posix_types.h и пересборав ядро это ограничение можно приподнять.
И ещё факт про epoll. Буква e — появилась от сочетания «edge triggered» срабатывание по фронту — антоним «level triggered» срабатывание по уровню. Poll срабатывает «по уровню» — по наличию данных. Epoll — по добавлению данных. Если зациклить poll и не вычитывать данные — получится бесконечный цикл, в случае с epoll, такого не получится. Если новых поступлений нет — epoll не разблокируется. Т.е. epoll позволяет перенести этап копирования данных(kernel space ->user space) из мультиплексирующей нити в нити обработчики.
и еще. Правильно ли я понял, что входные последовательности независимы для разных тактов? Как, в таком случае, быть с шаблоном, который найдется на совмещении двух последовательностей, но не найдется в каждой из них? Например шаблон ш=10 для последовательностей п1=111, п2=000.
Совсем не понял что значит фраза «нейрон имеет шаблон» и как вычисляется функция «нейрон встретил шаблон». В классическом нейроне вычисляется функция перехода от взвешенной суммы входов. Какие операции проводятся с массивом значений на входе описанного нейрона?
Уверен, обзор и сравнение межнитевых очередей, построенных на различных механизмах синхронизации — будь-то мутексы, семафоры или CAS — нашел бы свою аудиторию.
Слышал, что google против исключений в C++. Почитал мануал — оказалось что они, в целом, за исключения, но не используют их т.к. не хотят вставлять обработку исключений в свой старый код.
>Блин, вы всё ещё не понимаете.
Я согласен с вашим предыдущим постом, что эксперимент был спланирован не очень удачно. И я признал это выше.
Но качество самого теста никак к этому не относится.
>Про распределения — это всё отмазки.
Если быть последовательно точным, то точным до конца, и получить честные результаты. ИМХО.
>НЕЛЬЗЯ взять два сэмпла из случайной величины, и на основании только этих двух сэмплов судить об их распределениях
О том и речь, что нельзя. Если использовать закон больших чисел, то и не нужно. Если проводить измерение много раз, то среднее арифметческое будет стремиться к матожиданию независимо от закона распределения. Лишь бы он не изменялся в процессе измерений.
>Ваш же бенчмарк публичным не является
Мой тест открыт и публичен. Вот исходный код. Он оценивает зависимость времени затрачиваемого на N операций от числа нитей выполняющие эти операции. Единичный запуск теста реализует одно испытание. Статистическая обработка выборки из нескольких испытаний в пакет не входит.
>Вы бы внимательнее прочитали статейку про FTQ, особенно последний абзац про «Validating Data»
И что? Там вычисляются статистические моменты на основе результатов теста.:
«Load the FTQ time output files, process the data, and print out the statistics..»
Да, вычисляются с помощью специального сценария, но то же самое можно проделать и с результатами моего теста и с результатами линпака.
Отсутствие такого скрипта никак не влияет на сам тест.
Замечу, что нужно разделять тест, эксперимент и результаты эксперимента. Статистическая обработка обычно проводится над результатами эксперимента. Эксперимент состоит из одного или нескольких испытаний.
Итак, доверительные интервалы. Чтобы посчитать доверительный интервал, нужно заранее знать закон распределения случайной величины и иметь результаты нескольких испытаний.
Если закон не известен, то придется подбирать распределение, которое лучше всего подходит для данного случая. И не факт, что распределения будут одинаковы для разных машин.
Т.е. чтобы посчитать доверительный интервал, придется выполнить много разнообразной работы, и не факт что получится правдоподобный результат, т.к. запутаться проще простого.
Гораздо выгоднее следовать принципу KISS и использовать закон больших чисел, который не зависит от распределения. Не нужно оценивать распределение, не нужно формировать выборки — делаете один длительный замер и всё.
Единственным слабым местом, которое я готов признать, является выбор Большого_Числа, которое проводилось «на глаз». Но опять же это недостаток эксперимента, а не теста.
Если вы и после этих доводов считаете тест несостоятельным, давайте обратимся к авторитету мировой общественности.
Вот нашел несколько тестов. Максимальная обработка которая здесь проводится — нахождения среднего: FTQ HPL, STREAM
На основании результатов HPL, формируется Top500. HPL формирует большую случайную систему линейных уравнений, решает её, замеряет время решения. Делит размерность задачи (ширина матрицы в кубе) на время и получает флопсы.
Говорят «получено N гигафлопс на линпаке». Всё. Никаких исключений случайных факторов типа промахов кэша или коллизий в сети. Никакой статистической обработки в тесте.
Повторю, что считаю приведенный тест решает поставленные перед ним задачи. Если же нужна особо точная обработка результатов её можно выполнить отдельно! Надеюсь, вы согласитесь с этим.
У оперонов несколько необычные конфигурации получились, но сходные. Т.е. опять же случайно так не получится. Явно видны особые точки, одновременно для нескольких механизмов:
Можно, и это сделано — но уж слишком много изображений, поэтому здесь их выкладывать не стал — оставил вместе с исходниками
Могу все вывалить :)
Вот парочка интересных:
Они не виноваты, они просто не сделали :).
Ну если бы в результатах приведенных тут, большое значение играла случайность, закономерностей в графиках, как вы понимаете, не было бы. А в них, проглядывается, монотонность и некоторые общие тенденции. Шум может и есть, но он не велик, а большинство графиков, так вообще почти константы. Получается, что общая оценка зависимости задержек от количества нитей вполне возможна.
Может быть получить точную оценку латентности заданного механизма и для заданной машины не получится, но она и не нужна.
В общем считаю, что поставленные перед тестом задачи он решает.
Если же вы не согласны, то какова должна быть обработка на ваш взгляд?
Если вы пишете тесты, также как умеете критиковать, то цены вам нет :).
Тесты — не моя рыба.
Я сделал эту работу, т.к. не нашел удовлетворяющих меня готовых программ. Видимо специалисты по тестам не создали.
>Т.е. мне дали тест, попросили его запустить, и мне же ещё надо и разбираться, чтобы он нормально запустился. У меня вот в лабе 256-ядерный сервак, и если я даже объясню себе, что неплохо этот тест прогнать, для меня затруднительно понять, что мне же его придётся и допиливать.
Тогда почему бы и не допилить — раз вы столь хороши в тестах производительности? Лицензия GPL, открытых аналогов вроде нет. Получился бы интересный инструмент.
Тада-ам! Теперь обещанные результаты тестов, в том числе на ARM.
Расшифровка:
2xE5345: Intel® Xeon® CPU E5345 @ 2.33GHz 8 of 8 cores online
2xOpteron2220: Dual-Core AMD Opteron(tm) Processor 2220 4 of 4 cores online
4xOpteron6136: AMD Opteron(tm) Processor 6136 32 of 32 cores online
4xOpteron8354: Quad-Core AMD Opteron(tm) Processor 8354 16 of 16 cores online
ARM_Cortex_A9__Toshiba_AC100: ARM_Cortex_A9__Toshiba_AC100 2 of 2 cores online
C2Q_E6600: Intel® Core(TM)2 Quad CPU Q6600 @ 2.40GHz 4 of 4 cores online
E8400: Intel® Core(TM)2 Duo CPU E8400 @ 3.00GHz 2 of 2 cores online
i5-700: CPU model name: Intel® Core(TM) i5 CPU 760 @ 2.80GHz 4 of 4 cores online
P8600: Intel® Core(TM)2 Duo CPU P8600 @ 2.40GHz 2 of 2 cores online
Q8200-1core: Intel® Core(TM)2 Quad CPU Q8200 @ 2.33GHz 1 of 4 cores online
XeonE5520: Intel® Xeon® CPU E5520 @ 2.27GHz 8 of 8 cores online
Матриалы предоставлены пользователями gribozavrVassgelas
и еще один пользователь, хабраник которого я не знаю.
Огромное им спасибо и 10000 плюсов к карме.
Графики отдельных серверов можно посмотреть на гитхабе. Добавил туда, также скрипты автогенерации графиков. Комитты результатов все ещё приветствуются.
12-и и 80-и ядерных процессоров, пока нет.
Просторечие неприемлемо? Попытаюсь ответить строже:
to TheShade:
>Штука в том, что все мои доводы есть доводы в пользу несостоятельности теста. И пока не доказано обратное по каждому из доводов, тест не состоятелен.
В действительность, большинство ваших утверждений, относятся к области личных предпочтений, но ни как не к сущности теста. Переформулирую свои ответы в более понятной форме.
1.Как форма представления результатов влияет на состоятельность теста? Никак.
2.Как отсутствие статистической обработки влияет не состоятельность теста? Статистику составляют по результатам теста, а не до и не во время.
3.Этот тест не измеряет латентность, он её оценивает с позиции обычного программиста, для которого консоль любой linux машины выглядит одинаково, не зависимо от процессора.
4.В тесте, есть специальный параметр — мерь сколько хочешь. Как это влияет на состоятельность теста? Никак.
5.Абсолютная синхронизация все равно не возможна, даже с использованием барьеров или условных переменных. Так для сравнения муравейников, не нужно взвешивать каждого муравья, достаточно взвесить весь муравейник, пусть даже туда попадет дюжина сверчков. На относительных весах муравейников это мало скажется. Надеюсь, здесь понятно.
Про «не научность».
>Ваше «не научно» ломает вообще всякий повод тестом заниматься. «Научно» нужно не для того, чтобы этим гордиться, а для того, чтобы предубеждения по поводу теста, которые вы изложили в качестве доводов в ответном комментарии, отделить от объективных фактов. Пока вы это не сделаете, тестом заниматься смысла нет.
Не хотелось бы опускаться до «сам дурак», поэтому назову исходные обвинения софизмами без существенных оснований. А вообще, это не научная статья, скорее техническая, а если посмотреть ещё глубже, то это запрос к общественности предоставить интересующие меня данные. Но если для вас лично нет смысла заниматься моим тестом :) я скорее обрадуюсь, чем расстроюсь.
>Т.е. компилятор потенциально может сделать эту трансформацию, ещё больше искажая результат.
Потенциально может, но ведь не делает. Появятся оптимизаторы — придется подправить тест, если он будет ещё востребован.
to mikhanoid
> выводы и так очевидны, их можно сделать из особенностей реализации каждого из методов.
Возможно, они очевидны для опытного человека, часто имеющим дело с разными механизмами блокировки. Для того кто впервые задумался об альтернативах для mutex, все не так просто.
Может работать как с терминальными серверами, так и с множеством SOL IPMI соединений.
В свое время был удивлен, что select в fd_set для индексации использует номер сокета сиречь файлового дескриптора, т.е. если открыть сначала 512 файлов, то под сокеты останется также 512 бит из fd_set. Кроме того
подправив __FD_SETSIZE в kernel/include/linux/posix_types.h и пересборав ядро это ограничение можно приподнять.
И ещё факт про epoll. Буква e — появилась от сочетания «edge triggered» срабатывание по фронту — антоним «level triggered» срабатывание по уровню. Poll срабатывает «по уровню» — по наличию данных. Epoll — по добавлению данных. Если зациклить poll и не вычитывать данные — получится бесконечный цикл, в случае с epoll, такого не получится. Если новых поступлений нет — epoll не разблокируется. Т.е. epoll позволяет перенести этап копирования данных(kernel space ->user space) из мультиплексирующей нити в нити обработчики.
Раз
Два
И вот ещё
Я согласен с вашим предыдущим постом, что эксперимент был спланирован не очень удачно. И я признал это выше.
Но качество самого теста никак к этому не относится.
Если быть последовательно точным, то точным до конца, и получить честные результаты. ИМХО.
>НЕЛЬЗЯ взять два сэмпла из случайной величины, и на основании только этих двух сэмплов судить об их распределениях
О том и речь, что нельзя. Если использовать закон больших чисел, то и не нужно. Если проводить измерение много раз, то среднее арифметческое будет стремиться к матожиданию независимо от закона распределения. Лишь бы он не изменялся в процессе измерений.
>Ваш же бенчмарк публичным не является
Мой тест открыт и публичен. Вот исходный код. Он оценивает зависимость времени затрачиваемого на N операций от числа нитей выполняющие эти операции. Единичный запуск теста реализует одно испытание. Статистическая обработка выборки из нескольких испытаний в пакет не входит.
>Вы бы внимательнее прочитали статейку про FTQ, особенно последний абзац про «Validating Data»
И что? Там вычисляются статистические моменты на основе результатов теста.:
«Load the FTQ time output files, process the data, and print out the statistics..»
Да, вычисляются с помощью специального сценария, но то же самое можно проделать и с результатами моего теста и с результатами линпака.
Отсутствие такого скрипта никак не влияет на сам тест.
Итак, доверительные интервалы. Чтобы посчитать доверительный интервал, нужно заранее знать закон распределения случайной величины и иметь результаты нескольких испытаний.
Если закон не известен, то придется подбирать распределение, которое лучше всего подходит для данного случая. И не факт, что распределения будут одинаковы для разных машин.
Т.е. чтобы посчитать доверительный интервал, придется выполнить много разнообразной работы, и не факт что получится правдоподобный результат, т.к. запутаться проще простого.
Гораздо выгоднее следовать принципу KISS и использовать закон больших чисел, который не зависит от распределения. Не нужно оценивать распределение, не нужно формировать выборки — делаете один длительный замер и всё.
Единственным слабым местом, которое я готов признать, является выбор Большого_Числа, которое проводилось «на глаз». Но опять же это недостаток эксперимента, а не теста.
Если вы и после этих доводов считаете тест несостоятельным, давайте обратимся к авторитету мировой общественности.
Вот нашел несколько тестов. Максимальная обработка которая здесь проводится — нахождения среднего:
FTQ
HPL, STREAM
На основании результатов HPL, формируется Top500. HPL формирует большую случайную систему линейных уравнений, решает её, замеряет время решения. Делит размерность задачи (ширина матрицы в кубе) на время и получает флопсы.
Говорят «получено N гигафлопс на линпаке». Всё. Никаких исключений случайных факторов типа промахов кэша или коллизий в сети. Никакой статистической обработки в тесте.
Повторю, что считаю приведенный тест решает поставленные перед ним задачи. Если же нужна особо точная обработка результатов её можно выполнить отдельно! Надеюсь, вы согласитесь с этим.
Могу все вывалить :)
Вот парочка интересных:
Ну если бы в результатах приведенных тут, большое значение играла случайность, закономерностей в графиках, как вы понимаете, не было бы. А в них, проглядывается, монотонность и некоторые общие тенденции. Шум может и есть, но он не велик, а большинство графиков, так вообще почти константы. Получается, что общая оценка зависимости задержек от количества нитей вполне возможна.
Может быть получить точную оценку латентности заданного механизма и для заданной машины не получится, но она и не нужна.
В общем считаю, что поставленные перед тестом задачи он решает.
Если же вы не согласны, то какова должна быть обработка на ваш взгляд?
Тесты — не моя рыба.
Я сделал эту работу, т.к. не нашел удовлетворяющих меня готовых программ. Видимо специалисты по тестам не создали.
Тогда почему бы и не допилить — раз вы столь хороши в тестах производительности? Лицензия GPL, открытых аналогов вроде нет. Получился бы интересный инструмент.
Расшифровка:
2xE5345: Intel® Xeon® CPU E5345 @ 2.33GHz 8 of 8 cores online
2xOpteron2220: Dual-Core AMD Opteron(tm) Processor 2220 4 of 4 cores online
4xOpteron6136: AMD Opteron(tm) Processor 6136 32 of 32 cores online
4xOpteron8354: Quad-Core AMD Opteron(tm) Processor 8354 16 of 16 cores online
ARM_Cortex_A9__Toshiba_AC100: ARM_Cortex_A9__Toshiba_AC100 2 of 2 cores online
C2Q_E6600: Intel® Core(TM)2 Quad CPU Q6600 @ 2.40GHz 4 of 4 cores online
E8400: Intel® Core(TM)2 Duo CPU E8400 @ 3.00GHz 2 of 2 cores online
i5-700: CPU model name: Intel® Core(TM) i5 CPU 760 @ 2.80GHz 4 of 4 cores online
P8600: Intel® Core(TM)2 Duo CPU P8600 @ 2.40GHz 2 of 2 cores online
Q8200-1core: Intel® Core(TM)2 Quad CPU Q8200 @ 2.33GHz 1 of 4 cores online
XeonE5520: Intel® Xeon® CPU E5520 @ 2.27GHz 8 of 8 cores online
Матриалы предоставлены пользователями
gribozavrVassgelas
и еще один пользователь, хабраник которого я не знаю.
Огромное им спасибо и 10000 плюсов к карме.
Графики отдельных серверов можно посмотреть на гитхабе. Добавил туда, также скрипты автогенерации графиков. Комитты результатов все ещё приветствуются.
12-и и 80-и ядерных процессоров, пока нет.
Спасибо и удач.
to TheShade:
>Штука в том, что все мои доводы есть доводы в пользу несостоятельности теста. И пока не доказано обратное по каждому из доводов, тест не состоятелен.
В действительность, большинство ваших утверждений, относятся к области личных предпочтений, но ни как не к сущности теста. Переформулирую свои ответы в более понятной форме.
1.Как форма представления результатов влияет на состоятельность теста? Никак.
2.Как отсутствие статистической обработки влияет не состоятельность теста? Статистику составляют по результатам теста, а не до и не во время.
3.Этот тест не измеряет латентность, он её оценивает с позиции обычного программиста, для которого консоль любой linux машины выглядит одинаково, не зависимо от процессора.
4.В тесте, есть специальный параметр — мерь сколько хочешь. Как это влияет на состоятельность теста? Никак.
5.Абсолютная синхронизация все равно не возможна, даже с использованием барьеров или условных переменных. Так для сравнения муравейников, не нужно взвешивать каждого муравья, достаточно взвесить весь муравейник, пусть даже туда попадет дюжина сверчков. На относительных весах муравейников это мало скажется. Надеюсь, здесь понятно.
Про «не научность».
>Ваше «не научно» ломает вообще всякий повод тестом заниматься. «Научно» нужно не для того, чтобы этим гордиться, а для того, чтобы предубеждения по поводу теста, которые вы изложили в качестве доводов в ответном комментарии, отделить от объективных фактов. Пока вы это не сделаете, тестом заниматься смысла нет.
Не хотелось бы опускаться до «сам дурак», поэтому назову исходные обвинения софизмами без существенных оснований. А вообще, это не научная статья, скорее техническая, а если посмотреть ещё глубже, то это запрос к общественности предоставить интересующие меня данные. Но если для вас лично нет смысла заниматься моим тестом :) я скорее обрадуюсь, чем расстроюсь.
>Т.е. компилятор потенциально может сделать эту трансформацию, ещё больше искажая результат.
Потенциально может, но ведь не делает. Появятся оптимизаторы — придется подправить тест, если он будет ещё востребован.
to mikhanoid
> выводы и так очевидны, их можно сделать из особенностей реализации каждого из методов.
Возможно, они очевидны для опытного человека, часто имеющим дело с разными механизмами блокировки. Для того кто впервые задумался об альтернативах для mutex, все не так просто.