Здравствуйте, CoderMonkey, Вы писали:
_>>Ты это вот сейчас всерьёз написал? ))) CM>Абсолютно. Тебе надо объяснить на пальцах, почему GC может вызываться через раз?
Эээ, не увиливай. Речь шла не двойном запуске, а о запуске по случайному закону. Так ты значит всерьёз считаешь, что сборщики мусора работают на основание некого случайного значения? )))
_>>Эм, ты не понимаешь смысл термина "истинного значения"? ) А как ты тогда вообще можешь говорить о таких понятиях как погрешность измерения и т.п? ))) CM>Может, и не понимаю. Расскажи мне, что такое по твоему "истинное значение" в нашем случае.
В нашем случае (когда нет влияния внешних устройств) это будет просто время исполнения нашего кода без влияния всех посторонних процессов. Т.е. в случае запуска нашего кода без ОС мы всегда будем получать именно это значение, без всяких разбросов.
Здравствуйте, alex_public, Вы писали:
_>Эээ, не увиливай. Речь шла не двойном запуске, а о запуске по случайному закону.
Сам не увиливай. В реальной работе, сборшик мусора может вызваться в любой момент. И если мы хотим получить близкую к реальности оценку производительности, а не синтетику ради синтетики, то его влияние надо учитывать. Потому что в противном случае, у разработчиков рантайма появляется соблазн отложить сборку мусора как можно сильнее и сделать результаты своих бенчмарков намного красивее. Что они, скорее всего, и сделали.
_>Так ты значит всерьёз считаешь, что сборщики мусора работают на основание некого случайного значения? )))
straw man
_>В нашем случае (когда нет влияния внешних устройств) это будет просто время исполнения нашего кода без влияния всех посторонних процессов. Т.е. в случае запуска нашего кода без ОС мы всегда будем получать именно это значение, без всяких разбросов.
Ага, и без влияния сборшика мусора. Для пущей красоты.
Сферический конь в вакууме.
Здравствуйте, CoderMonkey, Вы писали:
_>>Эээ, не увиливай. Речь шла не двойном запуске, а о запуске по случайному закону. CM>Сам не увиливай. В реальной работе, сборшик мусора может вызваться в любой момент.
С чего ты взял подобные глупости? )
CM>И если мы хотим получить близкую к реальности оценку производительности, а не синтетику ради синтетики, то его влияние надо учитывать. Потому что в противном случае, у разработчиков рантайма появляется соблазн отложить сборку мусора как можно сильнее и сделать результаты своих бенчмарков намного красивее. Что они, скорее всего, и сделали.
Безусловно надо учитывать. Только с чего ты взял, что вносимая им задержка будет отличаться между разными запусками одного и того же приложения в одних и тех же условиях? )
_>>Так ты значит всерьёз считаешь, что сборщики мусора работают на основание некого случайного значения? ))) CM>straw man
Так ты определись уже, сборщик мусора — это некая магия, работающая по случайным законам, или же это просто ещё один обычный детерминированный алгоритм.
_>>В нашем случае (когда нет влияния внешних устройств) это будет просто время исполнения нашего кода без влияния всех посторонних процессов. Т.е. в случае запуска нашего кода без ОС мы всегда будем получать именно это значение, без всяких разбросов. CM>Ага, и без влияния сборшика мусора. Для пущей красоты. CM>Сферический конь в вакууме.
Ну это твои фантазии очередные. Сборщик мусора — это очевидно часть приложения, так что никто не предлагал его не учитывать.
Здравствуйте, alex_public, Вы писали:
_>С чего ты взял подобные глупости? )
Объясняю на пальцах, для самых распальцованных В реальных условиях, ты не знаешь, что было до вызова твоего куска кода. Возможно, там уже успели забить хип практически полностью. А может быть, нет.
_>Так ты определись уже, сборщик мусора — это некая магия, работающая по случайным законам, или же это просто ещё один обычный детерминированный алгоритм.
Детерминированный алгоритм у тебя будет, когда ты запустишь его на голой железке без оси, других процессов, диспетчера задач и прерываний. А в обычных условиях, про детерминированность и прочих сфероконей забудь.
_>Ну это твои фантазии очередные. Сборщик мусора — это очевидно часть приложения, так что никто не предлагал его не учитывать.
Если брать из всех замеров минимальное время, то это будет, скорее всего, именно вариант без сборки мусора — или с их минимальным количеством, по сравнению с остальными.
Здравствуйте, CoderMonkey, Вы писали:
_>>С чего ты взял подобные глупости? ) CM>Объясняю на пальцах, для самых распальцованных В реальных условиях, ты не знаешь, что было до вызова твоего куска кода. Возможно, там уже успели забить хип практически полностью. А может быть, нет.
Какие ещё реальные условия? Мы говорим о разбросе значение при запуске одного конкретного приложения (нашего теста).
_>>Так ты определись уже, сборщик мусора — это некая магия, работающая по случайным законам, или же это просто ещё один обычный детерминированный алгоритм. CM>Детерминированный алгоритм у тебя будет, когда ты запустишь его на голой железке без оси, других процессов, диспетчера задач и прерываний. А в обычных условиях, про детерминированность и прочих сфероконей забудь.
Опять у тебя всё в голове спуталось. То, что ты сейчас описал — это действительно идеальные условия для тестирования, позволяющие получать сразу (и всегда) истинный результат, без всяких погрешностей. Но к сборщику мусора это никакого отношения не имеет, т.к. он является детерминированным в любом случае, в том числе и при запуске под ОС. Т.е. ты тут снова спутал реальные причины погрешностей (некоторые из которых наконец то смог перечислить) и непонятно зачем притащенный тобой в данную дискуссию сборщик мусора, который никакие случайные погрешности в тест не вносит.
_>>Ну это твои фантазии очередные. Сборщик мусора — это очевидно часть приложения, так что никто не предлагал его не учитывать. CM>Если брать из всех замеров минимальное время, то это будет, скорее всего, именно вариант без сборки мусора — или с их минимальным количеством, по сравнению с остальными.
Т.е. ты по прежнему придерживаешься своих глупых фантазий о том, что поведение сборщика мусора у одного и того же приложения на одной и той же машине отличается от запуска к запуску? )))
Здравствуйте, alex_public, Вы писали:
_>Какие ещё реальные условия? Мы говорим о разбросе значение при запуске одного конкретного приложения (нашего теста).
То есть о том, как сделать тест как можно ближе к сферовакуумной синтетике. Вопросов больше не имею.
_>Т.е. ты по прежнему придерживаешься своих глупых фантазий о том, что поведение сборщика мусора у одного и того же приложения на одной и той же машине отличается от запуска к запуску? )))
А ты по прежнему придерживаешься своих безграмотных фантазий, что в работе современного PC есть какой-то детерминизм по времени и "одинаковые условия"?
Здравствуйте, CoderMonkey, Вы писали:
_>>Т.е. ты по прежнему придерживаешься своих глупых фантазий о том, что поведение сборщика мусора у одного и того же приложения на одной и той же машине отличается от запуска к запуску? )))
CM>А ты по прежнему придерживаешься своих безграмотных фантазий, что в работе современного PC есть какой-то детерминизм по времени и "одинаковые условия"?
Алё, ты забыл свои претензии ? JS работает как — первый прогон сортировки в тесте примерно на четверть быстрее второго и последующих ?
Ты ж два месяца орал, что де это ужос-ужос и обман-враньё
Вот это и есть тот самый детерминизм. Аналогично будет и в дотнете и в джаве, только там характер влияния GC будет другой.
Представь на секундочку, что никто, кроме тебя, не пишет код вида GC.Collect(randint() % 3)
Здравствуйте, CoderMonkey, Вы писали:
_>>Какие ещё реальные условия? Мы говорим о разбросе значение при запуске одного конкретного приложения (нашего теста). CM>То есть о том, как сделать тест как можно ближе к сферовакуумной синтетике. Вопросов больше не имею.
Ты бредишь? ) Код теста в данной дискуссии вообще не обсуждается (бери например любой из десятков вариантов предложенных в данной ветке выше). Здесь речь о том, как правильно измерить время выполнения уже заданного теста, откуда берётся погрешность измерения и как её уменьшать.
_>>Т.е. ты по прежнему придерживаешься своих глупых фантазий о том, что поведение сборщика мусора у одного и того же приложения на одной и той же машине отличается от запуска к запуску? ))) CM>А ты по прежнему придерживаешься своих безграмотных фантазий, что в работе современного PC есть какой-то детерминизм по времени и "одинаковые условия"?
К чему эти убогие риторические приёмы на уровне детского сада? Очевидно же, что если бы работа подобных тестов была бы полностью детерминирована, то и самого данного обсуждения просто не было бы — все тесты всегда выдавали бы один и тот же результат. Однако причины разброса в результатах одного и того же теста, запущенного на одной и той же машине очевидно являются следствием не работы сборщика мусора (как почему-то привиделось тебе в неких воспалённых фантазиях), а совершенно других причин. Более того, на краткий момент просветления ты даже смог перечислить некоторых из них. Ещё бы несколько маленьких шагов в правильном направление размышлений и ты смог бы попробовать представить себе как эти причины влияют на вид функции распределение нашей случайной ошибки, что мы собственно и обсуждали. Однако тебя понесло в какие-то бредовые размышления о рандомных сборщиках мусора и прочих сомнительных фантазиях...
Здравствуйте, Ikemefula, Вы писали:
I>Алё, ты забыл свои претензии ? JS работает как — первый прогон сортировки в тесте примерно на четверть быстрее второго и последующих ?
Неа. Выглядит, как будто в сраном JS реально стоит рандом
Здравствуйте, alex_public, Вы писали:
_>Здесь речь о том, как правильно измерить время выполнения уже заданного теста, откуда берётся погрешность измерения и как её уменьшать.
Вот именно. Представим себе, что GC срабатывает по израсходованию первых 500 мб, а твой тест выделяет 490. Делаем 10 прогонов, берем минимальное время — вау, как быстро работает JS!!!111
Потом запускаем тот же код из какого-то более крупного приложения, и абсолютно тот же же код на таких же данных выполняется уже раза так в 2 медленнее. Вот так, на ровном месте, твоё "истинное значение" оказывается полной туфтой.
_>Однако причины разброса в результатах одного и того же теста, запущенного на одной и той же машине очевидно являются следствием не работы сборщика мусора (как почему-то привиделось тебе в неких воспалённых фантазиях), а совершенно других причин.
Расскажи мне о причинах, которые приводят в JS к разбросу от 1264 до 4227 миллисекунд при запусках одного и того же теста в цикле. А то я такого не видел больше нигде, приходится только догадываться о причинах такого цирка с конями. Но ты то самый умный, наверняка всё точно знаешь
Здравствуйте, CoderMonkey, Вы писали:
I>>Алё, ты забыл свои претензии ? JS работает как — первый прогон сортировки в тесте примерно на четверть быстрее второго и последующих ?
CM>Неа. Выглядит, как будто в сраном JS реально стоит рандом
Интересное у тебя понимание рандома — первый замер гарантировано ниже второго и последующих примерно на четверть
Здравствуйте, CoderMonkey, Вы писали:
CM>Расскажи мне о причинах, которые приводят в JS к разбросу от 1264 до 4227 миллисекунд при запусках одного и того же теста в цикле.
На этот раз ты спутал замеры сортировки и инициализации. Ты можешь хоть раз внятно показать чего именно ты намерял ?
>А то я такого не видел больше нигде
Возможно дело именно в этом — что ты где то чего то не видел. Может опыт ограниченый, может особенности восприятия. Мне, например, удавалось заставить GC .Net виснуть на 30 секунд и больше.
Здравствуйте, CoderMonkey, Вы писали:
_>>Здесь речь о том, как правильно измерить время выполнения уже заданного теста, откуда берётся погрешность измерения и как её уменьшать. CM>Вот именно. Представим себе, что GC срабатывает по израсходованию первых 500 мб, а твой тест выделяет 490. Делаем 10 прогонов, берем минимальное время — вау, как быстро работает JS!!!111 CM>Потом запускаем тот же код из какого-то более крупного приложения, и абсолютно тот же же код на таких же данных выполняется уже раза так в 2 медленнее. Вот так, на ровном месте, твоё "истинное значение" оказывается полной туфтой.
Я так понимаю, что если мы возьмём этот твой гипотетический тест, но с выделением 510 МБ, то он будет с твоей точки зрения уже верным? Ну вот тогда давай его и обсудим...
1. Будут ли различаться значения между запусками такого теста?
2. Если будут, то имеет ли к этому какое-то отношение сборщик мусора?
3. Если будут, то какие ещё причины могут быть?
4. К какому виду функции распределения ошибки могут привести эти причины?
_>>Однако причины разброса в результатах одного и того же теста, запущенного на одной и той же машине очевидно являются следствием не работы сборщика мусора (как почему-то привиделось тебе в неких воспалённых фантазиях), а совершенно других причин. CM>Расскажи мне о причинах, которые приводят в JS к разбросу от 1264 до 4227 миллисекунд при запусках одного и того же теста в цикле. А то я такого не видел больше нигде, приходится только догадываться о причинах такого цирка с конями. Но ты то самый умный, наверняка всё точно знаешь
У меня подобных разбросов нет. Не знаю что ты там и как измерял....
Здравствуйте, Ikemefula, Вы писали:
I>На этот раз ты спутал замеры сортировки и инициализации.
А точно, спутал. На самом деле, разброс всего лишь от 1271 до 1987.
То есть, на 44% от среднего.
I>Ты можешь хоть раз внятно показать чего именно ты намерял ?
Я уже постил сюда весь лог.
I>Возможно дело именно в этом — что ты где то чего то не видел. Может опыт ограниченый, может особенности восприятия. Мне, например, удавалось заставить GC .Net виснуть на 30 секунд и больше.
Сдуру можно заставить виснуть что угодно. Вопрос — как сделать, чтобы такого странного разброса в JS не было. И второй вопрос — почему, собственно, он происходит. На кэш и прочие мелочи такой огромный разброс не спишешь.
Здравствуйте, alex_public, Вы писали:
_>Я так понимаю, что если мы возьмём этот твой гипотетический тест, но с выделением 510 МБ, то он будет с твоей точки зрения уже верным? Ну вот тогда давай его и обсудим...
На самом деле, там еще есть поколения, фрагментация хипа, влияние состояния кэша, NUMA и прочие вещи, которые предсказать невозможно. Так что нет, результат одного (любого) замера не будет верным никогда.
_>У меня подобных разбросов нет. Не знаю что ты там и как измерял....
Да, ошибся. На самом деле, разброс от 1271 до 1987. А теперь всё же хотелось бы увидеть объяснение этого разброса от Самого Умного И Всё Знающего.
Здравствуйте, CoderMonkey, Вы писали:
I>>первый замер гарантировано ниже второго и последующих примерно на четверть
CM>Гарантировано кем, тобой что ли?
Забыл, что именно такая особенность вызывала у тебя попа-боль ? Позапускай еще раз с десяток, если память короткая. Такое поведение на любом железе и всех версиях нода.
Здравствуйте, CoderMonkey, Вы писали:
I>>На этот раз ты спутал замеры сортировки и инициализации.
CM>А точно, спутал. На самом деле, разброс всего лишь от 1271 до 1987. CM>То есть, на 44% от среднего.
Непонятно. По твоим логам наименьшее ~1500, и дальше колебания от ~1700 до ~2500. Где тут 44% от среднего ? Откуда взялось 1271 ?
I>>Возможно дело именно в этом — что ты где то чего то не видел. Может опыт ограниченый, может особенности восприятия. Мне, например, удавалось заставить GC .Net виснуть на 30 секунд и больше.
CM>Сдуру можно заставить виснуть что угодно. Вопрос — как сделать, чтобы такого странного разброса в JS не было. И второй вопрос — почему, собственно, он происходит.
На все эти вопросы ответ даден.
>На кэш и прочие мелочи такой огромный разброс не спишешь.
И давно у тебя GC превратился в "кэш и прочие мелочи" ?
Здравствуйте, CoderMonkey, Вы писали:
_>>Я так понимаю, что если мы возьмём этот твой гипотетический тест, но с выделением 510 МБ, то он будет с твоей точки зрения уже верным? Ну вот тогда давай его и обсудим...
CM>На самом деле, там еще есть поколения, фрагментация хипа, влияние состояния кэша, NUMA и прочие вещи, которые предсказать невозможно. Так что нет, результат одного (любого) замера не будет верным никогда.
И поэтому мы видим одну и ту же картину от запуска к запуску ?
