Уже жалею, что снова ввязался в обсуждение. Мне кажется, ты споришь сам с собой, подразумевая какой-то свой прошлый опыт (неизвестный более никому), но зато чуть менее, чем полностью игнорируя то, что я тебе пытаюсь рассказывать про этот вполне конкретный случай. После мощного передергивания про «надо изгаляться над данными и выбрать другую метрику» (а этот бред придумал ты, но зачем-то немедленно приписал его мне) продолжать общение вообще, честно говоря, сразу неохота. Так что повторюсь последний раз, чисто для протокола, и хватит.
Да, вообще в произвольном общем случае с неизвестным распределением нижний outlier как показатель брать нельзя, так как иногда может подвести. Да, нужно как-нибудь фильтровать. Да, для финального мега-бенчмарка необходимо и качественно фильтровать, и вообще смотреть и анализировать распределение, и данные мерить не случайные, а несколько наоборов реальных плюс несколько специально сконструированных, итд итп. Все так, отличные верные общие выводы. Никто с ними как бы не спорит и обратного нигде никогда не писал.
Но мы говорим про конкретный и нередкий частный случай!
Нет, и в этом конкретном и в куче подобных частных случаев можно для ежеминутных итераций над фиксированными данными взять таки минимум. Это потому, что распределение скошено, нижних outliers нету (я типа смотрел свои данные), и минимум практически равен медиане. Алле, распределение известно, условия идеализированы (длинное линейное чтение из памяти), время исполнения тут вообще должно быть константой, те. наблюдаемое время t = T + random_noise, где нас интересует фактическое время T. Очевидно, что min(t) = T + min(random_noise) >= T, ситуация «min(t) маленький, но фактическое T большое» невозможна. Подчеркиваю: в данном конкретном классе случаев.
Есть красивые примеры, что в других классах бенчмарков все бывает сильно не так? Есть убедительные доказательства, что даже в данном классе бенчмарков min(random_noise) бывает сравним по порядку величины с T? Вперед, пиши статью, будет очень интересно почитать.
Знание затем, чтобы оперативно сравнивать две версии функции на микробенчмарке, в ходе работы над ними.
Еще раз: случай абсолютно одинаковый, но время одного исполнения сильно дрожит. По понятным вполне причинам, но с этим нельзя работать. Один (один) долбаный пик иногда сильно сбивает среднее, а он вдобавок не один. Представь ситуацию: в 70% повторов выходит 120+-1 мс, именно это значение (120 мс) и интересует. По существу, медианное. Еще в 30% повторов выходит что угодно от 130 до 150 мс, потому что наведенное (!) разными внешними (!) причинами дрожание. Внезапно, среднее колбасит от 123 до 129 мс, и внезапно, все отдельные изменения в ходе работы, которые реально убирают по 1 мс, бенчмаркать невозможно. А с минимумом возможно, и при этом итерация НЕ должна длиться 1000 повторов.
Вот можно, кстати, попробовать медиану считать. Этим разом я не попробовал. Но минимум считать еще проще, результат отличается незначительно, и главное: выходит крайне стабильным и эксперименты БЫСТРЫЕ, те. с ним можно ежеминутно работать. А для окончательного мега-бенчмарка, разумеется, нужно и кучу прогонов, и дисперсию, и вообще распределение лучше бы глянуть. Вот и все.
Дисперсия там и так маленькая (теоретически вообще 0, все полностью детерминировано же). Так что фокус про «нагрев» и минимум не дисперсию прячет, а решает вообще другую проблему: нестабильные результаты от запуска к запуску на коротких бенчмарках. Результаты хочется стабильные, а не плюс-минус 20%, иначе как сравнивать. Но и получать их хочется за 10 прогонов, а не 1000, иначе каждый запуск больно долго ждать. Получилось вот так.
> Развитие ветки обсуждения спровоцировало всё же то, что
«обсуждать» тут было сразу нечего после 2го моего комментария, а теперь уже абсолютно нечего
> защищать свой… способ… Хабр… модно ругать,
глаза на лоб еще сильнее
лишний раз убеждаюсь, что чего и как не напиши — кто-нибудь обязательно все поймет настолько наоборот, что просто слов нет
остается только надеяться, что большая часть посетителей Хабра — все еще способна без особых усилий понять, что такое «во1х», отличает пояснения от оправданий, иронию от ругани, итд итп
и потому и не пишет ничего, слава Кришне, в эту замечательную подветку ;)
Ошибся в обоих пунктах, увы!
1) пишется в 3 клика, а не 2, ибо скобки набираются с зажатым shift.
2) чтение в 1000 раз быстрее пробенчмаркано только на одной платформе; на моей микроархитектуре различий нет, все исполняется за одинаковое время.
А если серьезно, от всей этой ветки обсуждения у меня глаза слегка на лоб.
Количество людей, которых, хм, легкое отклонение графематики от привычной им беспокоит достаточно для того, чтобы писать комментарии, активничать с плюсиками и минусиками и, может, еще как то проявлять активную гражданскую позицию, выходит неожиданно большое — отличается от нуля.
Технический (вроде) ресурс, техническая (точно) статья, оформлена в целом, простите, не сказать, чтобы нечитаемо — а обсуждаем варианты написания «во-первых» — а еще 4 опечатки, которые я только что заодно с этим Чудовищным Отклонением от ХаброНормы исправил, не заметил почему-то никто.
Привет, дивный новый Хабр — чую, еще пара лет эволюции в этом направлении и если хоть одну запятую не там поставишь, то берегись! Буря, пусть сильнее грянет буря!!! :)
Скопировал из статьи заново, результаты начали сходиться. С любым размером блока ускорение есть, однако ни разу не 10 раз. Вот например с блоком 16 мб выходит около 2.1 раз.
Лучше на ты. Да, уверен. В дебажном билде результаты расчетов такие же, в дизасме наглядно видать 3 цикла и честные вызовы функций.
Ну и эта, пример не мой ;) практически чистый cut/paste плюс пачка незначащих правок типа замены tprintf на printf. И одна значащая, вынос rand() за цикл с целью мерить именно оптимизируемую функцию, а не воздух.
«нижних outliers нету (я типа смотрел свои данные)»
комментарий не читай @ собеседника сразу обсирай
Да, вообще в произвольном общем случае с неизвестным распределением нижний outlier как показатель брать нельзя, так как иногда может подвести. Да, нужно как-нибудь фильтровать. Да, для финального мега-бенчмарка необходимо и качественно фильтровать, и вообще смотреть и анализировать распределение, и данные мерить не случайные, а несколько наоборов реальных плюс несколько специально сконструированных, итд итп. Все так, отличные верные общие выводы. Никто с ними как бы не спорит и обратного нигде никогда не писал.
Но мы говорим про конкретный и нередкий частный случай!
Нет, и в этом конкретном и в куче подобных частных случаев можно для ежеминутных итераций над фиксированными данными взять таки минимум. Это потому, что распределение скошено, нижних outliers нету (я типа смотрел свои данные), и минимум практически равен медиане. Алле, распределение известно, условия идеализированы (длинное линейное чтение из памяти), время исполнения тут вообще должно быть константой, те. наблюдаемое время t = T + random_noise, где нас интересует фактическое время T. Очевидно, что min(t) = T + min(random_noise) >= T, ситуация «min(t) маленький, но фактическое T большое» невозможна. Подчеркиваю: в данном конкретном классе случаев.
Есть красивые примеры, что в других классах бенчмарков все бывает сильно не так? Есть убедительные доказательства, что даже в данном классе бенчмарков min(random_noise) бывает сравним по порядку величины с T? Вперед, пиши статью, будет очень интересно почитать.
Еще раз: случай абсолютно одинаковый, но время одного исполнения сильно дрожит. По понятным вполне причинам, но с этим нельзя работать. Один (один) долбаный пик иногда сильно сбивает среднее, а он вдобавок не один. Представь ситуацию: в 70% повторов выходит 120+-1 мс, именно это значение (120 мс) и интересует. По существу, медианное. Еще в 30% повторов выходит что угодно от 130 до 150 мс, потому что наведенное (!) разными внешними (!) причинами дрожание. Внезапно, среднее колбасит от 123 до 129 мс, и внезапно, все отдельные изменения в ходе работы, которые реально убирают по 1 мс, бенчмаркать невозможно. А с минимумом возможно, и при этом итерация НЕ должна длиться 1000 повторов.
Вот можно, кстати, попробовать медиану считать. Этим разом я не попробовал. Но минимум считать еще проще, результат отличается незначительно, и главное: выходит крайне стабильным и эксперименты БЫСТРЫЕ, те. с ним можно ежеминутно работать. А для окончательного мега-бенчмарка, разумеется, нужно и кучу прогонов, и дисперсию, и вообще распределение лучше бы глянуть. Вот и все.
«обсуждать» тут было сразу нечего после 2го моего комментария, а теперь уже абсолютно нечего
> защищать свой… способ… Хабр… модно ругать,
глаза на лоб еще сильнее
лишний раз убеждаюсь, что чего и как не напиши — кто-нибудь обязательно все поймет настолько наоборот, что просто слов нет
остается только надеяться, что большая часть посетителей Хабра — все еще способна без особых усилий понять, что такое «во1х», отличает пояснения от оправданий, иронию от ругани, итд итп
и потому и не пишет ничего, слава Кришне, в эту замечательную подветку ;)
1) пишется в 3 клика, а не 2, ибо скобки набираются с зажатым shift.
2) чтение в 1000 раз быстрее пробенчмаркано только на одной платформе; на моей микроархитектуре различий нет, все исполняется за одинаковое время.
А если серьезно, от всей этой ветки обсуждения у меня глаза слегка на лоб.
Количество людей, которых, хм, легкое отклонение графематики от привычной им беспокоит достаточно для того, чтобы писать комментарии, активничать с плюсиками и минусиками и, может, еще как то проявлять активную гражданскую позицию, выходит неожиданно большое — отличается от нуля.
Технический (вроде) ресурс, техническая (точно) статья, оформлена в целом, простите, не сказать, чтобы нечитаемо — а обсуждаем варианты написания «во-первых» — а еще 4 опечатки, которые я только что заодно с этим Чудовищным Отклонением от ХаброНормы исправил, не заметил почему-то никто.
Привет, дивный новый Хабр — чую, еще пара лет эволюции в этом направлении и если хоть одну запятую не там поставишь, то берегись! Буря, пусть сильнее грянет буря!!! :)
__m128i tmp1 = _mm_mul_epu32(a,b); /* mul 2,0*/
__m128i tmp2 = _mm_mul_epu32( _mm_srli_si128(a,4), _mm_srli_si128(b,4)); /* mul 3,1 */
return _mm_unpacklo_epi32(_mm_shuffle_epi32(tmp1, _MM_SHUFFLE (0,0,2,0)), _mm_shuffle_epi32(tmp2, _MM_SHUFFLE (0,0,2,0))); /* shuffle results to [63..0] and pack */
Но это сейчас у меня лично первый раз в жизни, когда кто-то не понял, что значит «во1х», «во2х», итп :)
(*) авторская транскрипция; автор в курсе, что в словаре пишут «сейчас»; заранее спасибо, неизвестный кэп ;)
gist.github.com/anonymous/5604401
Ну и эта, пример не мой ;) практически чистый cut/paste плюс пачка незначащих правок типа замены tprintf на printf. И одна значащая, вынос rand() за цикл с целью мерить именно оптимизируемую функцию, а не воздух.
И ускорение не в 10 раз, и… тупо не сходятся результаты расчетов.
C:\Temp\hey>1
0.954874 sec, x=-1132049649
0.381489 sec, x=-1903287257
0.452164 sec, x=971761649
gist.github.com/anonymous/5601991
Что я делаю не так??