Тестирование производительности компиляторов - Философия программирования

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, _vovin, Вы писали:

VD>Чушь это а не доказательство. Создай реальный пример требующий полиморфизма и проверь. А так же вспомни, что делать методы виртуальными в С++ не нужно в отличии от Смолтока, где сообщения виртуальны по поределению.

Я уже не раз говорил, что в Шустриках тест виртуального вызова в действительности не меряет реальный виртуальный вызов. Он меряет способность процессора запомнить последний адрес перехода.
Реальное же назначение виртуального вызова — переходить на различные методы в зависимости от ситуации.
Вот так выглядит тест сейчас:

        void VirtualMehodCallClick(int iInitVal)
        {
            CTest2 test2 = new CTest2();
            CTest1 test1 = test2;
            m_spIUtility.TimerStart();
            for(int i = 0; i < iInitVal; i++)
            {
                test1.TestVirtual(i, 3.123, 1, "Some string");
            }
            m_spIUtility.TimerEnd(/*sbsInfo*/);
        }

В такой ситуации время выполнения получается 0.59 секунды (iInitVal = 100000000).
Если тест модифицировать следующим образом:

        void VirtualMehodCallClick(int iInitVal)
        {
            CTestA testA = new CTestA();
            CTestB testB = new CTestA();
            CTestC testC = new CTestA();
            CTest1 test1;

            m_spIUtility.TimerStart();
            for(int i = 0; i < iInitVal; i++)
            {
                testA.TestVirtual(i, 3.123, 1, "Some string");
                test1 = testA;
                testA = testB;
                testB = testC;
                testC = test1;
            }
            m_spIUtility.TimerEnd(/*sbsInfo*/);
        }

Где CTestA, CTestB, CTestC определены точно так же как и Test2, то получается 1.9 секунды. Более чем трехкратное замедление.
И это отражает более реальную ситуацию использования виртуальных вызовов, а в Шустриках фактически тестируется статический метод завернутый в виртуальный вызов, где основные потери от загрузки адресов VMT и метода.
Так что предлагаю модифицировать в Шустриках этот тест.

P.S. Для сравнения посылка сообщения в этих тестах показала 0.9 и 1.1 соответственно.

Здравствуйте, _vovin, Вы писали:

_>

_>Статья с примером есть — бери проверяй.

Зачем? Эдак можно начать проверять все вечные двигатели. Да и надыбать компилирующий Солток не так то просто.

Если же хочешь честного сравнения, то бери любой пример и я тебе гаратирую, что над на С++ откомпилированный на приличном компиляторе покажет как минимум не худший результат.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, _vovin, Вы писали:

_>И это отражает более реальную ситуацию использования виртуальных вызовов,

Ничего это не отражает. Мерять нужно реальные алгоритмы.

_> а в Шустриках фактически тестируется статический метод завернутый в виртуальный вызов,

Шустрики содержат как сентетические тесты, так и более раельные. Согласен, что синтетика превращается в профанацию при тестировании на серьезных оптимизирующих компиляторах. Однако реальные тесты компилятор испортить не может.

_>где основные потери от загрузки адресов VMT и метода.
_>Так что предлагаю модифицировать в Шустриках этот тест.

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

_>P.S. Для сравнения посылка сообщения в этих тестах показала 0.9 и 1.1 соответственно.

Еще раз повторяю. Это не тест. Это чушь. Тут нужны тесты вроде реализации паттернов ГоФ.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, VladD2, Вы писали:

_>> а в Шустриках фактически тестируется статический метод завернутый в виртуальный вызов,

VD>Шустрики содержат как сентетические тесты, так и более раельные. Согласен, что синтетика превращается в профанацию при тестировании на серьезных оптимизирующих компиляторах. Однако реальные тесты компилятор испортить не может.

Говори что хочешь, но сделать в цикле один виртуальный вызов с одним адресом назначения и назвать это тестированием виртуального вызова — полный идиотизм.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, _vovin, Вы писали:

_>>И это отражает более реальную ситуацию использования виртуальных вызовов,

VD>Ничего это не отражает. Мерять нужно реальные алгоритмы.

Это микро-тест. Он тебе ничего дополнительного отражать не должен. Нужен виртуальный вызов — получите результаты.

_>> а в Шустриках фактически тестируется статический метод завернутый в виртуальный вызов,

VD>Шустрики содержат как сентетические тесты, так и более раельные. Согласен, что синтетика превращается в профанацию при тестировании на серьезных оптимизирующих компиляторах. Однако реальные тесты компилятор испортить не может.

Возвращаемся к теме. Микро-тест виртульного вызова в Шустриках — полный отстой. Возражения будут?

_>>где основные потери от загрузки адресов VMT и метода.
_>>Так что предлагаю модифицировать в Шустриках этот тест.

VD>Ты выполни хотя бы тесты без виртуальности. И если они будут иметь хотя бы те же порядки, то можно будет задуматься над разработкой специального теста на алгоритм основанный на виртуальных вызвоах. Но обязает алгоритм. Иначе нелозя гарантировать защиты от дешевых трюков оптимизаторов.

Причем тут это. Обсуждаются Шустрики — там хоть хоть один тест, реально задействующий полиморфизм? Нету — отстой это, а не тестирование объектно-ориентированного языка.

_>>P.S. Для сравнения посылка сообщения в этих тестах показала 0.9 и 1.1 соответственно.

VD>Еще раз повторяю. Это не тест. Это чушь. Тут нужны тесты вроде реализации паттернов ГоФ.

Демонстрирую главную чушь (заодно замечаем как записано Mehod; и зачем в имени метода Click, это часть его ответственности?):

        void VirtualMehodCallClick(int iInitVal)
        {
            CTest2 test2 = new CTest2();
            CTest1 test1 = test2;
            m_spIUtility.TimerStart();
            for(int i = 0; i < iInitVal; i++)
            {
                test1.TestVirtual(i, 3.123, 1, "Some string");
            }
            m_spIUtility.TimerEnd(/*sbsInfo*/);
        }

И эта *грандиознейшая* чушь назвается тестированием виртуального вызова?!

Ладно, попытаемся разобраться, что тут предполагалось сделать. Видимо, это должен был быть микро-тест виртуального вызова метода. Научный подход подсказывает нам, что любое тестирование должно происходить при различных условиях и различных входных параметрах для составления общей картины.
Если же оказывается, что по некоторым параметрам выстраивается хорошая зависимость (лучше всего линейная), то объем тестов можно уменьшить с указанием этой зависимости.

Что мы видим в приведенном выше тесте — имеется только один тестовый сценарий — один вызов на большом количестве итераций. Больше никаких результатов или зависимостей не приведено. Полагаясь на совесть авторов можно предположить, что другие результаты должны линейно зависеть от полученных. Т.е. можно расчитывать на то (как бы это интуитивно понятно, и нас в этом никто не разуверяет), что при одном и том же количестве виртуальных вызовов потери должны быть константными.
Но не получается так. Стоит лишь сделать вызов с циклически меняющимся адресом вызова, как производительность просядет очень даже нелинейно.

Значит то, что громко названо тестом виртуальных вызовов является полной чушью, и даже на звание микро-теста виртуального вызова никак не годится. Материал не изучен, тема не раскрыта, два балла.

А то что ты называешь чушью, это демонстрация того, что тема виртуального вызова несколько богаче, чем может показаться на первый взгляд. Более того, существуют синтетические и реальные тесты, близкие к нему по структуре (при более богатом наполнении). Например, все тот же Visitor, который по сути, это последовательность полиморфных вызовов с разными адресами назначения.

Так как, сделаем наконец хоть один тест с реальным полиморфизмом (Visitor)?

Здравствуйте, _vovin, Вы писали:

_>Говори что хочешь, но сделать в цикле один виртуальный вызов с одним адресом назначения и назвать это тестированием виртуального вызова — полный идиотизм.

Это синтетика. Тебя не сильно задевают разные синтетические тесты вроде Винсона?

Тебе же говорят, что если хочешь что-то продемонстрировать, то сделай соотвествующий тест. Я согласен, что тесты из Шустриков не демонстрируют качество работы с виртуальными вызовами, но тест на который указываешь ты — это полнейшая профанация сделанная явными фанатами который честность результатов не нужна.

Если сделашь, хороший тест, обещаю включить его в шустрик. Кстати, вообще, было бы здорово если бы ты или кто другой сделал вариант тестов шустриков для Смолтока. Да и для того же Питона тоже было бы интересно. Добавим к этим тестам новые и сделаем нового шустрика. Более полного и пушистого. Но не профанацию вроде этого теста. Синтетику можно вообще убрать так как она доказала свою нежизнеспособность.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, _vovin, Вы писали:

_>Это микро-тест. Он тебе ничего дополнительного отражать не должен. Нужен виртуальный вызов — получите результаты.

Еще раз. Это профанация. Или делай алгоритм, с проверкой результатов. Или закончим это бессмысленное обсуждение, так как повлиять на мое мнение ты не сможешь.

_>Возвращаемся к теме. Микро-тест виртульного вызова в Шустриках — полный отстой. Возражения будут?

Нет. В смысле не будут. Я уже и сам не раз говорил, что в виду оптимизаций компилятора и процессоров на синтетические тесты лучше вообще не смотреть. В следующей версии видимо я их вообще выкину.

_>Причем тут это. Обсуждаются Шустрики

Нет. Обсуждается тест на кторый ты постоянно даешь ссылки и на базе которого ты и дуругие приверженцы Смолтока делаете выводы об общей производительности Смолтоковских рантаймов. Вот я и предлагаю сделать более честный тест на виртуальные вызовы и так же реализовать тесты на другие фичи рантаймов/компиляторов. Вот тогда можно будет говорить о чем-то серьезно.

_>- там хоть хоть один тест, реально задействующий полиморфизм?

Только синтетические. Вот и сделай нормальный, если тебе это действительно интересно.

_> Нету — отстой это, а не тестирование объектно-ориентированного языка.

Хочу заметить, что тестировались в основном компиляторы. Винтуальные вызовы в них сделаны приблизительно одинаково, так что измерять это было не особо интересно. К тому же все охватить нельзя. Я сделал то что мог.

Подключайся и помогай. Возьмем тебя в соавторы следующей версии. Я как раз хотел к выходу новой версии дотнета состряпать новую врсию. В нее точно будет включен тест приведенный тут: Снова шустрики или о предъвзятости тестов. Если сделаешь полноценный тест для виртуальных вызовов (акцентирующийся на нем, но с полноценным алгоритмом кторый нельзя просто так выбросит по паттерну), то включим и его.

Если за одно реализуешь и другие тесты на Смолтоке, то включим и их. Только дай хорошую инструкцию на чем нужно мерить (самый быстрый рантайм) и как нужно мерить.

_>>>P.S. Для сравнения посылка сообщения в этих тестах показала 0.9 и 1.1 соответственно.

VD>>Еще раз повторяю. Это не тест. Это чушь. Тут нужны тесты вроде реализации паттернов ГоФ.

_>Демонстрирую главную чушь (заодно замечаем как записано Mehod; и зачем в имени метода Click, это часть его ответственности?):
_>

_>        void VirtualMehodCallClick(int iInitVal)
_>        {
_>            CTest2 test2 = new CTest2();
_>            CTest1 test1 = test2;
_>            m_spIUtility.TimerStart();
_>            for(int i = 0; i < iInitVal; i++)
_>            {
_>                test1.TestVirtual(i, 3.123, 1, "Some string");
_>            }
_>            m_spIUtility.TimerEnd(/*sbsInfo*/);
_>        }
_>

_>И эта *грандиознейшая* чушь назвается тестированием виртуального вызова?!

_>Ладно, попытаемся разобраться, что тут предполагалось сделать. Видимо, это должен был быть микро-тест виртуального вызова метода. Научный подход подсказывает нам, что любое тестирование должно происходить при различных условиях и различных входных параметрах для составления общей картины.
_>Если же оказывается, что по некоторым параметрам выстраивается хорошая зависимость (лучше всего линейная), то объем тестов можно уменьшить с указанием этой зависимости.

_>Что мы видим в приведенном выше тесте — имеется только один тестовый сценарий — один вызов на большом количестве итераций. Больше никаких результатов или зависимостей не приведено. Полагаясь на совесть авторов можно предположить, что другие результаты должны линейно зависеть от полученных. Т.е. можно расчитывать на то (как бы это интуитивно понятно, и нас в этом никто не разуверяет), что при одном и том же количестве виртуальных вызовов потери должны быть константными.
_>Но не получается так. Стоит лишь сделать вызов с циклически меняющимся адресом вызова, как производительность просядет очень даже нелинейно.

_>Значит то, что громко названо тестом виртуальных вызовов является полной чушью, и даже на звание микро-теста виртуального вызова никак не годится. Материал не изучен, тема не раскрыта, два балла.

_>А то что ты называешь чушью, это демонстрация того, что тема виртуального вызова несколько богаче, чем может показаться на первый взгляд. Более того, существуют синтетические и реальные тесты, близкие к нему по структуре (при более богатом наполнении). Например, все тот же Visitor, который по сути, это последовательность полиморфных вызовов с разными адресами назначения.

_>Так как, сделаем наконец хоть один тест с реальным полиморфизмом (Visitor)?

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, _vovin, Вы писали:

_>>Говори что хочешь, но сделать в цикле один виртуальный вызов с одним адресом назначения и назвать это тестированием виртуального вызова — полный идиотизм.

VD>Это синтетика. Тебя не сильно задевают разные синтетические тесты вроде Винсона?

Это микро-тест. Берем только лишь одну операцию — и долбим ее тестом до упаду. Какая уж тут синтетика?

VD>Тебе же говорят, что если хочешь что-то продемонстрировать, то сделай соотвествующий тест. Я согласен, что тесты из Шустриков не демонстрируют качество работы с виртуальными вызовами, но тест на который указываешь ты — это полнейшая профанация сделанная явными фанатами который честность результатов не нужна.

Еще раз — это микро-тест, выполненный в различных режимах. В принципе и его можно сделать более "чистым" — запускать такой же, но пустой цикл и вычитать это время.
Получится таблица: Чистый виртуальный вызов, количество polymorphic call sites — 1, 3, 5, ...

Теперь еще раз по шагам:
1) Тест в шустриках неадекватен
2) Его нужно заменить подобным тестом, или даже более проработанным вариантом
3) Четко назвать его *микро-тестом* виртуального вызова

Чувствуешь подвох? Этот тест не пытается доказать, что какой-то язык быстрее или медленнее. Он показывает, что микро-операция виртуального вызова ведет себя по-разному на разных компиляторах и при разном количество call sites.
Микро-тест вообще ничего не должен доказывать. Он всего лишь пища для размышлений.

Хочешь синтетику — бери любой алгоритм с визитором, причем этот визитор должен вносить заметный оверхед. Тогда будет синтетика для виртуального вызова.

VD>Если сделашь, хороший тест, обещаю включить его в шустрик. Кстати, вообще, было бы здорово если бы ты или кто другой сделал вариант тестов шустриков для Смолтока. Да и для того же Питона тоже было бы интересно. Добавим к этим тестам новые и сделаем нового шустрика. Более полного и пушистого. Но не профанацию вроде этого теста. Синтетику можно вообще убрать так как она доказала свою нежизнеспособность.

А кто будет запускать их всех? Скачивание солидных дистрибутивов и настройка не напряжет?

Здравствуйте, _vovin, Вы писали:

_>Это микро-тест. Берем только лишь одну операцию — и долбим ее тестом до упаду. Какая уж тут синтетика?

Такая же как в первых тестах из шустрика. Бессмысленные действия дают бессмысленный и не проверяемый результат. Нужен алгоритм. При этом гарантируется что:
результаты теста будут осмысленными и их можно проверить;
компилятор/рантайм не сможет просто выкинуть виртуальность.

Естественно над алгоритмом тоже нужно как следует подумать.

_>Еще раз — это микро-тест,

Прекрати, пожалуйста, повторять эти слова. Твой микротест == синтетика.

_> выполненный в различных режимах. В принципе и его можно сделать более "чистым" — запускать такой же, но пустой цикл и вычитать это время.

Это тоже бессмыслнно. Нужен именно алгоритм требующий виртуального вызова. Например, та же сортировка но со сменным компарером передающимся через поле (при этом заинлайнить его будет не просто).

_>Чувствуешь подвох?

Чувствую, что ты меня не слышишь. Остается только понять только, специально ты это делаешь, или просто недопонимашь моих слов.

Шустрики просто не содержут серьезного теста в данной области. Ну, не очень это было интересно. Что касается синтетики (они же микротесты), то они ровным счетом ничего не показывают.

_> Этот тест не пытается доказать, что какой-то язык быстрее или медленнее.

К сожалению, на его базе это пытаются сделать люди.

_> Он показывает, что микро-операция виртуального вызова ведет себя по-разному на разных компиляторах и при разном количество call sites.

Ничего он не показывает. Скорее всего в компилятор вставлена мелкая заплатка (паттерн) устраняющая виртауьный вызов. На вопрос "Насколько она эффективна?" это тест не отвечает. Я уже устал говори. Сделай тест с рельным алгоритмом. Вот тогда можно будет о чем-либо говорить. А так в некоторых случаях VC и тоже устраняет виртуальные вызовы. И что тогда измеряется?

_>Микро-тест вообще ничего не должен доказывать. Он всего лишь пища для размышлений.

Он пища для инсинуаций. По "микротестам" из шутстрика VC вообще не требует времени на виртуальные вызовы. Так что какова бы ни была скорость вызова в Смолтоковских рантаймах VC все равно заткнет его за пояс.

В общем, что делать я уже сказал. Так что или сделай, или давай закроем эту тему. Мое мнение — это тест == инсинуация, подлог или просто глупость.

_>Хочешь синтетику — бери любой алгоритм с визитором, причем этот визитор должен вносить заметный оверхед. Тогда будет синтетика для виртуального вызова.

Это уже будет не синтетика. Синтетика тем и отличается, что не имеет осмысленного результата (измерение кокретного параметра).

Что касается "бери"... у меня сейчас времени нет. Можешь "взять" эту идею сам. Вот глядя на реализацию Посетителя я действительно соглашусь с выводами и не буду называть тест профанацией. А этот уж извини полная профанация.

_>А кто будет запускать их всех?

Я буду. Если ты из Москвы, то могу и тебя пригласить как экспетра по Смолтоку и независимого наблюдателя. У меня нет задачи сделать лучшим своего любимчика. Тольно нужны толковые инструкции, как на чем...

Ну, и вообще любая помощь приветсвтвуется.

_> Скачивание солидных дистрибутивов и настройка не напряжет?

Это не проблема. Было бы чего качать.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, _vovin, Вы писали:

_>>Это микро-тест. Берем только лишь одну операцию — и долбим ее тестом до упаду. Какая уж тут синтетика?

VD>Такая же как в первых тестах из шустрика. Бессмысленные действия дают бессмысленный и не проверяемый результат. Нужен алгоритм. При этом гарантируется что:
VD>результаты теста будут осмысленными и их можно проверить;
VD>компилятор/рантайм не сможет просто выкинуть виртуальность.

VD>Естественно над алгоритмом тоже нужно как следует подумать.

_>>Еще раз — это микро-тест,

VD>Прекрати, пожалуйста, повторять эти слова. Твой микротест == синтетика.

Твой виртуальный тест — не синтетика?

_>> выполненный в различных режимах. В принципе и его можно сделать более "чистым" — запускать такой же, но пустой цикл и вычитать это время.

VD>Это тоже бессмыслнно. Нужен именно алгоритм требующий виртуального вызова. Например, та же сортировка но со сменным компарером передающимся через поле (при этом заинлайнить его будет не просто).

И где этот тест? Почему ничего незначащий виртуальный вызов есть, а теста нет?

_>>Чувствуешь подвох?

VD>Чувствую, что ты меня не слышишь. Остается только понять только, специально ты это делаешь, или просто недопонимашь моих слов.

VD>Шустрики просто не содержут серьезного теста в данной области. Ну, не очень это было интересно. Что касается синтетики (они же микротесты), то они ровным счетом ничего не показывают.

_>> Этот тест не пытается доказать, что какой-то язык быстрее или медленнее.

VD>К сожалению, на его базе это пытаются сделать люди.

_>> Он показывает, что микро-операция виртуального вызова ведет себя по-разному на разных компиляторах и при разном количество call sites.

VD>Ничего он не показывает. Скорее всего в компилятор вставлена мелкая заплатка (паттерн) устраняющая виртауьный вызов. На вопрос "Насколько она эффективна?" это тест не отвечает. Я уже устал говори. Сделай тест с рельным алгоритмом. Вот тогда можно будет о чем-либо говорить. А так в некоторых случаях VC и тоже устраняет виртуальные вызовы. И что тогда измеряется?

Из всего вышесказанного по логике выходить то, что текущий виртуальный тест вообще должен быть выброшен, и вообще подобные тесты не должны больше приводиться.
Иначе... ты становишься на горло своей песне.

_>>Микро-тест вообще ничего не должен доказывать. Он всего лишь пища для размышлений.

VD>Он пища для инсинуаций. По "микротестам" из шутстрика VC вообще не требует времени на виртуальные вызовы. Так что какова бы ни была скорость вызова в Смолтоковских рантаймах VC все равно заткнет его за пояс.

А это уже явная тенденциозность. В любой ситуации ты не допускаешь, чтобы VC и компания выглядели хуже.
Открою секрет — рантайм Smalltalk-а (за исключением Strongtalk-а) в большинстве случаев будет проигрывать. Но по причине большего оверхеда при передаче параметров, конструкции цикла, и т.д. В этом случае выигрыш от полиморфного выигрыша полностью нивелируется.
Но надо быть справедливым — если говоришь А, говори и Б — приводи все тесты, которые не могут быть аппроксимированы другими тестами.
Или выкидывай вообще.

VD>В общем, что делать я уже сказал. Так что или сделай, или давай закроем эту тему. Мое мнение — это тест == инсинуация, подлог или просто глупость.

А это уже абсолютно зря. Тест абсолютно правдив — достаточно запустить и проверить. Более того — он надмножество твоего теста, позволяющий увидеть картуну в комплексе.
Подмножество "глупости" — более узколобая глупость. Соглашаешься, что твой тест бОльшая глупость?

И вообще "инсинуация, подлог или просто глупость" — это результат интерпретаций. Интерпретаций, благодаря которым ты остаиваешь право не рассматривать тот факт, что виртуальный вызов во многих случаях ведет себя не так, как говорит твой тест.

_>>Хочешь синтетику — бери любой алгоритм с визитором, причем этот визитор должен вносить заметный оверхед. Тогда будет синтетика для виртуального вызова.

VD>Это уже будет не синтетика. Синтетика тем и отличается, что не имеет осмысленного результата (измерение кокретного параметра).

Какой осмысленный результат ожидался от твоего виртуального теста? Обычно напрашивается такой — пропорциональный результат в реальных задачах, где оверхед от полиморфизма превалирует, так?
Фигушки.

VD>Что касается "бери"... у меня сейчас времени нет. Можешь "взять" эту идею сам. Вот глядя на реализацию Посетителя я действительно соглашусь с выводами и не буду называть тест профанацией. А этот уж извини полная профанация.

У тебя ж явно в ршарп-е куча примеров визиторов. Кому-кому а тебе уже давно следовало извлечь такой тест на свет.

_>>А кто будет запускать их всех?

VD>Я буду. Если ты из Москвы, то могу и тебя пригласить как экспетра по Смолтоку и независимого наблюдателя. У меня нет задачи сделать лучшим своего любимчика. Тольно нужны толковые инструкции, как на чем...

Если есть идеи по новой версии шустриков, то помогу.

Но там должны быть решены сл. вопросы:
1) Либо выкинуть виртуальный вызов, либо приводить результаты для 1, 3, 5 полиморфных вызовов.
2) Придумать тест с визитором или любой другой алгоритм с большим оверхедом из-за полиморфизма.
3) Решить нужно либо приводить синтетику. Если да — то привести richards benchmark как синтетику для объектно-ориентированных языков.
4) Протестировать микро-операции с массивами, словарями и пр.
5) Добавить популярные динамические/скриптовые языки. Возможно выделить их в отдельную категорию.

VD>Ну, и вообще любая помощь приветсвтвуется.

_>> Скачивание солидных дистрибутивов и настройка не напряжет?

VD>Это не проблема. Было бы чего качать.

Здравствуйте, _vovin, Вы писали:

_>Твой виртуальный тест — не синтетика?

Синтетика.

_>И где этот тест? Почему ничего незначащий виртуальный вызов есть, а теста нет?

Потому что не все предположения оправдываются. Когда я делал этот тест, то думал аналогично тебе. Теперь уже думаю иначе. Видимо надо было выкинуть этот тест еще во втором шустрики. Ну, да если их читать внимательно, то не трудно найти слова предостерегающие от серьезного восприятия синтетики.

_>Из всего вышесказанного по логике выходить то, что текущий виртуальный тест вообще должен быть выброшен,

В шустриках? В общем, да.

_> и вообще подобные тесты не должны больше приводиться.

По крайней мере на их основе не стоит делать далеко идущих выводов.

_>Иначе... ты становишься на горло своей песне.

Дык я не супермен.

Ошибаюсь как все если не больше. Но стараюсь честно говорить об этом. Например, вот цитата из второго шустрика:

Еще раз напомним, что не стоит обращать особого внимания на синтетические тесты, ибо выигрыш в данном тесте зачастую достигается не оптимальностью вызова метода, а другими оптимизациями (раскрутка цикла, inline-подстановки...), и тем, что время, затрачиваемое на вызов, относительно невелико. Удивительно то, что это время оказалось на треть больше, чем у Delphi, также продукта этой фирмы. Видимо недаром бытует мнение, что Borland невзлюбил C++.

VD>>Он пища для инсинуаций. По "микротестам" из шутстрика VC вообще не требует времени на виртуальные вызовы. Так что какова бы ни была скорость вызова в Смолтоковских рантаймах VC все равно заткнет его за пояс.

_>А это уже явная тенденциозность.

Это был явный стеб. Причем со смайликом.

_> В любой ситуации ты не допускаешь, чтобы VC и компания выглядели хуже.

Я вообще пытаюсь анализировать результаты. Компания мне монопенесуальна. Просто я тебе пытался продемонстрировать обсурдность твоего подхода.

_>Открою секрет — рантайм Smalltalk-а (за исключением Strongtalk-а) в большинстве случаев будет проигрывать. Но по причине большего оверхеда при передаче параметров, конструкции цикла, и т.д. В этом случае выигрыш от полиморфного выигрыша полностью нивелируется.

Я так же открою сикрет... мне в общем-то пофигу что к чему приводит. Я просто указал, на то что подобные выводы на подобных тестах делать некорректно. А так же предложил сделать более менее честное сравнение. Мне опять таки пофигу результат который покажет Смолток, так как работать я лично на нем скорее всего никогда не буду, даже если он заткнет за пояс всех. Однако чисто по человечески мне интересны любые результаты. Я хочу не превознести какой либо продукт. Я хочу знать рельное положение дел и понимать что сколько стоит.

_>Но надо быть справедливым — если говоришь А, говори и Б — приводи все тесты, которые не могут быть аппроксимированы другими тестами.

Я бы с радостью. Но это огромный объем работы. Да и голова не резиновая. Подгключайся... подумаем вместе и сделаем шустрика-4 который будет лучше чем 1-2. Правда и тогда кто-нибудь вроде тебя скажет что тесты не полные и т.п. но я уже буду не одинок.

_>А это уже абсолютно зря. Тест абсолютно правдив

Тест не может быть правдив. Он может быть ошибочен или нет. Но то что он не ошибочен еще ничего не значит. Важно какие выводы делаются на его основе. Если ты разбирашь, что произошло и пыташся анализировать как это влияет на общую производительность реальных приложений, то никаких притензий нет. А вот когда он суется в качестве объяснения преимущества (в скорости) передачи сообщений Смолтока — это точно некорректное применение тесту.

_>Подмножество "глупости" — более узколобая глупость. Соглашаешься, что твой тест бОльшая глупость?

Ты статьи то читал?

_>И вообще "инсинуация, подлог или просто глупость" — это результат интерпретаций. Интерпретаций, благодаря которым ты остаиваешь право не рассматривать тот факт, что виртуальный вызов во многих случаях ведет себя не так, как говорит твой тест.

Я уже устал повторять. И повторять не буду. Если ты хотил услышать что я гворю, то услышал. Так что...

_>Какой осмысленный результат ожидался от твоего виртуального теста?

Какого? Ты тут вроде сам предложил реализовать паттерн Посетитель и померить скорость на его основе. Вот это дело.

_> Обычно напрашивается такой — пропорциональный результат в реальных задачах, где оверхед от полиморфизма превалирует, так?

Какой-то приступ глухоты.

_>У тебя ж явно в ршарп-е куча примеров визиторов. Кому-кому а тебе уже давно следовало извлечь такой тест на свет.

Когда тесты писались визиторов еще небыло. К тому же они есть для Шарпа. Ну, для плюсов я их перепишу относительно быстро. Но уж для Солтока я точно их написать не смогу. К тому же нужно придумать негое разумное дерево которое можно будет воспроизвести на всех языках. Тот же АСТ явно не годится. Очень большое количество классов.

_>Но там должны быть решены сл. вопросы:
_>1) Либо выкинуть виртуальный вызов, либо приводить результаты для 1, 3, 5 полиморфных вызовов.

Думаю синтетику оставлять смысле нет. Споров много, а толку чуть.

_>2) Придумать тест с визитором или любой другой алгоритм с большим оверхедом из-за полиморфизма.

Согласен, но нужно убедиться, что этот тест не тратит много времени на что-либо еще.

_>3) Решить нужно либо приводить синтетику.

Думаю не стоит. Лучше подискать алгоритмы максимально нагружащиющие конкретные фичи. В общем-то у нас почти так и получилось за исключением некоторых промахов. Один из них — это ситетика. Второй — это сортировка дерева. Я думал измерить скорость сборки мусора, но измерил скорость работы райт-барьера. По делу дерево нужно было делать очень маленьки, но это поять была бы синтетика. В общем опять же нужно подобрать алгоритм требующий интенсивного выделения памяти. Сейчас я уже довольно неплохо знаком с особенностями ЖЦ и можно было бы подобрать тесты как выгодные для ЖЦ, так и не выгодные. За одно объяснить народу как создавать эффективные управляемые приложения.

_> Если да — то привести richards benchmark как синтетику для объектно-ориентированных языков.

Я не силен в названиях. Сылку можно?

_>4) Протестировать микро-операции с массивами, словарями и пр.

Это бессмысленно. Это снова лотерея с оптимизаторами. Тогда уж есть смысл делать тесты на конкретную оптимизацию. Ну, там вынесение инварианта из цикла. Устранение виртуальности. Но это очень сложно. Чтобы понять что происходит нужно убдет дезасемблировать результат. Что вообще невозможно для интерпретаторов.

_>5) Добавить популярные динамические/скриптовые языки. Возможно выделить их в отдельную категорию.

Согласен. По крайней мере Питон и Руби я бы добавил. Однако это все объем работы. И нужны помощники.

ЗЫ

Ну, что может создать отдельную ветку и попытаться сформулировать требования?

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

VladD2 wrote:

[skip]

Короче закрыли тему как исчерпавшую себя, всякие виртуальные вызовы
должны быть выброшены.

>
> _>У тебя ж явно в ршарп-е куча примеров визиторов. Кому-кому а тебе уже давно следовало извлечь такой тест на свет.
>
> Когда тесты писались визиторов еще небыло. К тому же они есть для Шарпа. Ну, для плюсов я их перепишу относительно быстро. Но уж для Солтока я точно их написать не смогу. К тому же нужно придумать негое разумное дерево которое можно будет воспроизвести на всех языках. Тот же АСТ явно не годится. Очень большое количество классов.

Можно взять дерево с небольшой грамматикой и сделать ему pretty-printing.
Дерево можно создавать максимально просто, например подать ему некоторый
lisp-овый исходник, парсинг там ну очень простой.

>
> _>Но там должны быть решены сл. вопросы:
> _>1) Либо выкинуть виртуальный вызов, либо приводить результаты для 1, 3, 5 полиморфных вызовов.
>
> Думаю синтетику оставлять смысле нет. Споров много, а толку чуть.
>
> _>2) Придумать тест с визитором или любой другой алгоритм с большим оверхедом из-за полиморфизма.
>
> Согласен, но нужно убедиться, что этот тест не тратит много времени на что-либо еще.

И неизбежно получится синтетика.

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

>
> _>3) Решить нужно либо приводить синтетику.
>
> Думаю не стоит. Лучше подискать алгоритмы максимально нагружащиющие конкретные фичи. В общем-то у нас почти так и получилось за исключением некоторых промахов. Один из них — это ситетика. Второй — это сортировка дерева. Я думал измерить скорость сборки мусора, но измерил скорость работы райт-барьера. По делу дерево нужно было делать очень маленьки, но это поять была бы синтетика. В общем опять же нужно подобрать алгоритм требующий интенсивного выделения памяти. Сейчас я уже довольно неплохо знаком с особенностями ЖЦ и можно было бы подобрать тесты как выгодные для ЖЦ, так и не выгодные. За одно объяснить народу как создавать эффективные управляемые приложения.

В том-то и дело, что в современных рантаймах все очень связано.
Невозможно независимо загрузить только одну конкретную фичу. А если и
получится, то только для одной конкретной среды. Так же и с алгоритмами
— определенные среды будут лучше себя вести на определенных алгоритмах.
Поэтому в общем случае синтетика имеет ровно столько смысла сколько и
конкретный алгоритм.

>
> _> Если да — то привести richards benchmark как синтетику для объектно-ориентированных языков.
>
> Я не силен в названиях. Сылку можно?

Я уже как-то приводил ссылки
http://research.sun.com/people/mario/java_benchmarking/richards/richards.html
http://pws.prserv.net/dlissett/ben/bench1.htm

И ты уже высказывался против таких тестов.

>
> _>4) Протестировать микро-операции с массивами, словарями и пр.
>
> Это бессмысленно. Это снова лотерея с оптимизаторами. Тогда уж есть смысл делать тесты на конкретную оптимизацию. Ну, там вынесение инварианта из цикла. Устранение виртуальности. Но это очень сложно. Чтобы понять что происходит нужно убдет дезасемблировать результат. Что вообще невозможно для интерпретаторов.

Смысл не в этом. Ты говоришь о тестировании компилятора. Здесь же речь
идет об эффективности стандартной библиотеки.
Я, например, на два порядка чаще использую упорядоченную коллекцию и
словарь, чем какие-то численные алгоритмы. Поэтому производительность
стандартных классов мне более интересна. Как и многим другим.
Думаю эту потребность стоит как-то отразить в тестах?

>
> _>5) Добавить популярные динамические/скриптовые языки. Возможно выделить их в отдельную категорию.
>
> Согласен. По крайней мере Питон и Руби я бы добавил. Однако это все объем работы. И нужны помощники.
>
> ЗЫ
>
> Ну, что может создать отдельную ветку и попытаться сформулировать требования?

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

Posted via RSDN NNTP Server 1.9

Здравствуйте, _vovin, Вы писали:

_>Можно взять дерево с небольшой грамматикой и сделать ему pretty-printing.
_>Дерево можно создавать максимально просто, например подать ему некоторый
_>lisp-овый исходник, парсинг там ну очень простой.

И писать парсер для всех языков? Может проще тогда уж ХМЛ?

_>И неизбежно получится синтетика.

Почему это? Например, достаточно подсчитать количество АСТ-веток. Уже будет реальный алгоритм. Синтетика — это бессмысленное выполнение в цикле конкретной операции. А когда операция является частью алгоритма, то это уже не синтетика.

_>Потому что любой мало-мальски полезный алгоритм будет иметь большую
_>содержательную часть, так что на диспетчеризацию будет уходить
_>незначительное время.

Ну, подсчет веток АСТ — это одна операция сложения и одна загрузка переменной. Думаю, по сравнению с двумя виртуальными вызовами Посетителя — это просто не будет заметно.

_>В том-то и дело, что в современных рантаймах все очень связано.
_>Невозможно независимо загрузить только одну конкретную фичу. А если и
_>получится, то только для одной конкретной среды. Так же и с алгоритмами
_>- определенные среды будут лучше себя вести на определенных алгоритмах.
_>Поэтому в общем случае синтетика имеет ровно столько смысла сколько и
_>конкретный алгоритм.

И все же алгоритм упирающийся в конкретную фичу найти можно всегда. Например, меня удовлетворяют тесты:
* Быстрая сортировка (работа с большими массивами вэлью-типов)
* Пузырьковая сортировка (работа с малыми массивами)
* Подсчет Пи (целочисленные вычисления)
* Tree sort (модификация ссылок, ЖЦ, райт-барьер)
* Float-тест (вычисления с плавающей точкой)

_>Смысл не в этом. Ты говоришь о тестировании компилятора. Здесь же речь
_>идет об эффективности стандартной библиотеки.
_>Я, например, на два порядка чаще использую упорядоченную коллекцию и
_>словарь, чем какие-то численные алгоритмы. Поэтому производительность
_>стандартных классов мне более интересна. Как и многим другим.
_>Думаю эту потребность стоит как-то отразить в тестах?

Это отдельный вопрос. Все же кривое исполнение того или иного контейнера не так страшно при условии, что язык позволяет создать свой контейнер.

Хотя в качестве расширения конечно можно было бы сделать подобные тесты.

_>Я бы предложил сделать очень простую вещь — запостить в форум (rsdn?)
_>клич с целью найти по ответственному лицу для каждого языка. После этого
_>ты пишешь тест на шарпе, остальные пишут его на своих языках, создают
_>подробные инструкции как это дело запустить и отсылают тебе (всем).
_>Кроме этого всеми может быть сделано ревью, чтобы убедиться, что разные
_>реализации не выполняют существенно различное число действий, т.е. не
_>содержат алгоритмической оптимизации.

Можно и так. В общем, нужно или эту ветку выделять, или создавать новую тему.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

VladD2 wrote:

> Здравствуйте, _vovin, Вы писали:
>
> _>Можно взять дерево с небольшой грамматикой и сделать ему pretty-printing.
> _>Дерево можно создавать максимально просто, например подать ему некоторый
> _>lisp-овый исходник, парсинг там ну очень простой.
>
> И писать парсер для всех языков? Может проще тогда уж ХМЛ?

Грамматика сложнее. Парсер для всех языков в любом случае придется
писать. Потому что стандартные парсеры явно имеют различное число
операций для одного и того же входного потока.

>
> _>И неизбежно получится синтетика.

>
> Почему это? Например, достаточно подсчитать количество АСТ-веток. Уже будет реальный алгоритм. Синтетика — это бессмысленное выполнение в цикле конкретной операции. А когда операция является частью алгоритма, то это уже не синтетика.

Ну разве что подсчет веток.

>
> _>Потому что любой мало-мальски полезный алгоритм будет иметь большую
> _>содержательную часть, так что на диспетчеризацию будет уходить
> _>незначительное время.
>
> Ну, подсчет веток АСТ — это одна операция сложения и одна загрузка переменной. Думаю, по сравнению с двумя виртуальными вызовами Посетителя — это просто не будет заметно.
>
> _>В том-то и дело, что в современных рантаймах все очень связано.
> _>Невозможно независимо загрузить только одну конкретную фичу. А если и
> _>получится, то только для одной конкретной среды. Так же и с алгоритмами
> _>- определенные среды будут лучше себя вести на определенных алгоритмах.
> _>Поэтому в общем случае синтетика имеет ровно столько смысла сколько и
> _>конкретный алгоритм.
>
> И все же алгоритм упирающийся в конкретную фичу найти можно всегда. Например, меня удовлетворяют тесты:
> * Быстрая сортировка (работа с большими массивами вэлью-типов)
> * Пузырьковая сортировка (работа с малыми массивами)
> * Подсчет Пи (целочисленные вычисления)
> * Tree sort (модификация ссылок, ЖЦ, райт-барьер)
> * Float-тест (вычисления с плавающей точкой)

При этом только tree sort имеет хоть какой-то смысл для скажем Python-а.
В остальных случаях либо подобные алгоритмы на нем не пишут
(float-test), либо уже есть встроенные, которые с большой долей
вероятности реализованы на C (quick-sort).
Опять же только tree sort не имеет дело с value-типами, а в динамических
языках с ними много не возятся. Если из-за них возникает затык, то
алгоритм реализовывается на том же C.

>
> _>Смысл не в этом. Ты говоришь о тестировании компилятора. Здесь же речь
> _>идет об эффективности стандартной библиотеки.
> _>Я, например, на два порядка чаще использую упорядоченную коллекцию и
> _>словарь, чем какие-то численные алгоритмы. Поэтому производительность
> _>стандартных классов мне более интересна. Как и многим другим.
> _>Думаю эту потребность стоит как-то отразить в тестах?
>
> Это отдельный вопрос. Все же кривое исполнение того или иного контейнера не так страшно при условии, что язык позволяет создать свой контейнер.

Вопрос не в теоретической возможности, а в 95% сценариев. Т.е. берем
бомбим приложение принятым в этом языке способом. Какую
производительность мы от него ожидаем?
Я не уверен, что хотя бы 5% проектов делаются с собственными контейнерами.

>
> Хотя в качестве расширения конечно можно было бы сделать подобные тесты.
>
> _>Я бы предложил сделать очень простую вещь — запостить в форум (rsdn?)
> _>клич с целью найти по ответственному лицу для каждого языка. После этого
> _>ты пишешь тест на шарпе, остальные пишут его на своих языках, создают
> _>подробные инструкции как это дело запустить и отсылают тебе (всем).
> _>Кроме этого всеми может быть сделано ревью, чтобы убедиться, что разные
> _>реализации не выполняют существенно различное число действий, т.е. не
> _>содержат алгоритмической оптимизации.
>
> Можно и так. В общем, нужно или эту ветку выделять, или создавать новую тему.

Давай новую тему.

Posted via RSDN NNTP Server 1.9

Здравствуйте, _vovin, Вы писали:

_>Грамматика сложнее. Парсер для всех языков в любом случае придется
_>писать. Потому что стандартные парсеры явно имеют различное число
_>операций для одного и того же входного потока.

А не пофигу если все равно делать дерево?

_>Ну разве что подсчет веток.

Дык пофигу что. Главное, чтобы разумное и чтобы результат был бы осязаемым.

_>При этом только tree sort имеет хоть какой-то смысл для скажем Python-а.
_>В остальных случаях либо подобные алгоритмы на нем не пишут
_>(float-test), либо уже есть встроенные, которые с большой долей
_>вероятности реализованы на C (quick-sort).

Это тест на производительность рантайма/компилятора. А не рандомная раздача подарков.
Ну, а "не пишут" — это скорее всего потому, что хреново получается. Вот пусть и покажут на что способны.

Я вот выбирая ЯП пытаюсь найти тот компромис, чтобы было и удобно, и просто и быстро. Причем все факторы для меня важны. Пускай дотнет пока не дает мне всегда супер оптимизированное решение, но и провалов в 10 раз я не получаю. При этом мне не приходится трахаться с неинициализированными переменными и ручным контроляем памяти.

Питон делает ставку на еще большую гибкость. Прекрасно! Но для осознанного выбора Питоня я хочу знать во что мне все это выльется. Вот тест и должен это показать.

Тесты не просто осмысленны. Они показывают применимость/предпочтительность того или иного средства для той или иной задачи.

_>Опять же только tree sort не имеет дело с value-типами, а в динамических
_>языках с ними много не возятся. Если из-за них возникает затык, то
_>алгоритм реализовывается на том же C.

Здорово. Вот только получается, что 90% алноритмов нужно писать на С. Ну, и зачем мне тогда Питон? Я уж лучше С++ возму.

И опять таки, люди должны знать что можно на Питоне, а что нужно оформлять в виде библиотеки на С. Тест это и выявляет.

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

Если делать более широкий охват, то разумно добавить и другие тесты. Только эти трогать не надо. Они более чем разумны и показательны. И если они не выгодны Питону, то это проблемы питона.

_>Вопрос не в теоретической возможности, а в 95% сценариев. Т.е. берем
_>бомбим приложение принятым в этом языке способом. Какую
_>производительность мы от него ожидаем?
_>Я не уверен, что хотя бы 5% проектов делаются с собственными контейнерами.

Разумные люди делая приложение требовательное к времени выполнения делают тесты и проганяют получившийся код под профайлерами. Узкие места устраняются и получается выскоая скорость. Если таким узким местом становится кривой контейнер или алгоритм, то он попросту заменяется на собственный. Но для этого нужно иметь возможность создать на выбранном ЯП этот самый эффективный контейнер.

Я вот вижу, что любые вычисления для Питона — это проблема. Значит в задачах с большим их количеством его лучше вообще не применять. Если будут и другие тесты, то можно будет выделить область где его применение оправдано. Надеюь, что она не локализуется до тестовых скриптов.

_>Давай новую тему.

ОК.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

От:	VladD2	www.nemerle.org
Дата:	29.01.05 01:33
Оценка:	+1

От:	_vovin	http://www.pragmatic-architect.com
Дата:	29.01.05 06:40
Оценка:	+2

От:	_vovin	http://www.pragmatic-architect.com
Дата:	29.01.05 07:52
Оценка:	8 (1)

От:	VladD2	www.nemerle.org
Дата:	07.02.05 13:18
Оценка:

От:	VladD2	www.nemerle.org
Дата:	07.02.05 13:18
Оценка:	-1

От:	Gaperton	http://gaperton.livejournal.com
Дата:	13.02.05 15:21
Оценка:

	От:	Павел Кузнецов
	Дата:	13.02.05 18:30
	Оценка:	+3