Да, тесты, как и сами выводы, которые были сделаны из-за кривых тестов меня поразили... Методика тестирования вообще на высшем уровне
Все чё-то тестируют, кто, как, на чём, вместе с чем, при каких условиях... ни слова. ЛОЛ
Проводить тест длительностью 1-3 сотни мс в многопоточной ОС(Windows не является ОС реального времени!) с таймером у которого погрешность составляет десятки процентов от общего времени эксперимента, а потом на основе этого извергнуть приговор всей технологии или компилятору etc... это сила, воистину
Я уверен, здесь все считают, что среднее значение времени в тестах на скорость CPU есть самое верное.
Печально это всё, к чему мы идём? Сегодняшние прикладные программисты настолько абстрагированы от этого всего, что даже понятия не имеют об элементарных особенностях работы компьютера и системы.
Сегодня стукнул один С++ программист, пишет в BDS. Понадобилось ему написать консольное приложение, так он растерялся, спрашивал где там события, куда будут приходить сообщения. Печальная картина.
Все чё-то тестируют, кто, как, на чём, вместе с чем, при каких условиях... ни слова. ЛОЛ
почему не сказано? Приведены исходные коды, среды, версии, все в релизе...
Проводить тест длительностью 1-3 сотни мс в многопоточной ОС(Windows не является ОС реального времени!) с таймером у которого погрешность составляет десятки процентов от общего времени эксперимента
GetTickCount - назови более точную функцию для проверки, SetTimer? Не верю
Печально это всё, к чему мы идём? Сегодняшние прикладные программисты настолько абстрагированы от этого всего, что даже понятия не имеют об элементарных особенностях работы компьютера и системы.
Сегодня стукнул один С++ программист, пишет в BDS. Понадобилось ему написать консольное приложение, так он растерялся, спрашивал где там события, куда будут приходить сообщения. Печальная картина.
почему не сказано? Приведены исходные коды, среды, версии, все в релизе...
А система? А спецификация оборудования? А методика измерения? К тому я не увидел, чтобы вы ставили процессам REAL_TIME приоритет. Может у тебя при работе СPP'шного примера фильм копировался, а при работе .NET система простаивала.
Время исполнения программы нужно увеличить минимум раз в 100. Из получившихся значений брать самое маленькое(процессор не ошибается). Измерения проводить на максимально чистой системе(многие защиты перехватывают массу функций, при определённом стечении обстоятельств ты будешь мерить время ещё исполнения и их обработчика). В общем, ньюансов много.
GetTickCount - назови более точную функцию для проверки, SetTimer? Не верю
Да не, не угадал. На NT ядре GetTickCount использует APIC-таймер(реже PIT, от железа зависит), поэтому рзрешение у неё 15 мс. Но бывает такое, что тики не обрабатываются, поэтому фактически погрешность 30мс. (тут в топике кто-то приводил результат 78 мс. Грубо говоря, погрешность 50. Ну это всё при условии, что твой поток не будет прерван по время выполнения.
Наиболее точный таймер в системе - HPET(ну разве, что у вас не какой-нибудь Celeron 466, тна старых материнках его нет). Частота обновления 10MHz, т.е. 0.1мс и при этом очень маленькая погрешность. На win2k и более поздник(насчёт более ранних из линейки NT информации не имею) этот таймер использует функция QueryPerfomanceCounter. Именно с помощью неё(в связке с QueryPerformanceFrequency можно перевести в привычный вид) можно получить самые точные результаты.
Есть ещё внутрипроцессорный счётчик в регистре MSR10h, считывается командой процессора RDTSC. Инкрементируется после каждого такта. Тоже часто используется. Например, раньше, в старых ОС, QueryPerfomanceCounter возвращал значение этого счётчика. Я в равной степени считаю эффективными оба счётчика, но данные от HPET можно перевестив привычные единицы измерения, а RDTSC даёт относительные единицы, т.н. тики.
все развиваются от простого к сложному
Ага, всё идёт по-плану.
ZagZag, вот тебе цитата:
Dom
я никогда с таким не сталкивался, вот щас надо написать приложение, без интерфейса вообще, потом чистый. Нужно класс написать, в котором будет там события загрузки, движения мыши и тд, я немогу въехать как присобачить эти события
Мдя... народ отстраняется от архитектуры ПК, переходя на красивые оболочки. Я сам от части такой. Пасиба за это Микрософту
Я раньше на СЮБОР'е игрушки писал (денди с клавиатурой + бейсик). Так вот - небыло там никаких событий - все ручками делать приходилось, меня поймут те, кто на QBasic'e программировал.
А система? А спецификация оборудования? А методика измерения? К тому я не увидел, чтобы вы ставили процессам REAL_TIME приоритет.
Ну... мы не претендовали на абсолютную, объективную точность, для меня было важно относительное сравнение, поэтоу система - для меня была не принципиальной. У vito,который проводил измерения скорости на яве, система послабее разогнана (у меня тоже атлон 3000 64-бит, сокет 754,мать - епокс, какой, не помню: думаю, не принципиально..., ОЗУ 512 DDR, и т д и т п., но система разогнана за счет отключения некоторых служб, возможно поэтому бегает оператива быстрее). Но на мой взгляд это тоже не важно: Мы сравнили соотношения результатов у него и у меня на .НЕТ и уже ясно соотнощение, пропорция, котороой можно придерживаться.
По поводу REAL_TIME приоритет. Я хотел проверить скоростьвыполнения операций в обычных условиях. Вряд ли в будущем все программы на практике будут иметь реал-тайм приоритет. Фильмов - не копировалось , работала аська и опера - максимум (ну и Visual Studio само собой)... Хотя на будущее учту, и попробую и так и так, спасибо за подсказку
Время исполнения программы нужно увеличить минимум раз в 100.
тоже приму к сведению
Из получившихся значений брать самое маленькое(процессор не ошибается).
ура! хоть что-то я делал правильно
Да не, не угадал. На NT ядре GetTickCount использует APIC-таймер(реже PIT, от железа зависит), поэтому рзрешение у неё 15 мс. Но бывает такое, что тики не обрабатываются, поэтому фактически погрешность 30мс. (тут в топике кто-то приводил результат 78 мс. Грубо говоря, погрешность 50. Ну это всё при условии, что твой поток не будет прерван по время выполнения.
Наиболее точный таймер в системе - HPET(ну разве, что у вас не какой-нибудь Celeron 466, тна старых материнках его нет). Частота обновления 10MHz, т.е. 0.1мс и при этом очень маленькая погрешность. На win2k и более поздник(насчёт более ранних из линейки NT информации не имею) этот таймер использует функция QueryPerfomanceCounter. Именно с помощью неё(в связке с QueryPerformanceFrequency можно перевести в привычный вид) можно получить самые точные результаты.
Есть ещё внутрипроцессорный счётчик в регистре MSR10h, считывается командой процессора RDTSC. Инкрементируется после каждого такта. Тоже часто используется. Например, раньше, в старых ОС, QueryPerfomanceCounter возвращал значение этого счётчика. Я в равной степени считаю эффективными оба счётчика, но данные от HPET можно перевестив привычные единицы измерения, а RDTSC даёт относительные единицы, т.н. тики.
Полагаю, W[4Fh]LF имел в виду создать из консльного приложения окно, программно задать ему интерфейс, отловить вручную все сообщения окна и всего что на нем лежит...
В написании консолек ничего сложного не вижу, хоть писал их только на паскеле под ДОС
А в написании простых консолек, дык там вообще событий нет, потому они и называются консольными
Уже приняли. Я ж не просто так поднял количество итераций до 1 000 000.
Про объективность (и серьезную подготовку) теста никто и не говорит. Но практически все тесты которые я смотрел, подтверждают полученные результаты.
W[4Fh]LF
И что в выводах не понравилось?
В чем необъективность результатов?
Началось: "Ну... мы не претендовали на абсолютную, объективную точность"; "Про объективность (и серьезную подготовку) теста никто и не говорит."
Ну если Вы сами считаете свои тесты неабсолютными, необъективными и несерьёзными, то о чём вообще речь может идти
Зато ваши выводы послушаешь, так и дивишься. Строго говоря, по логике с компилятора спросить нечего в ваших тестах, он на место цикла мог бы засунуть хоть что.
W[4Fh]LF
Меня удивила слишком большая шустрость НЕТа (в наиболее слабой части - в графике). Подумал - может из - за 64 проца?
Обещано -то MS сие было. Но оказолось, что только Java толково использует железо, компиля машинный код для нужной платформы, потому как не зависит от винды (это мое предположение).
Далее было показано, что Борланд (при всей моей многолетней любви к нему) устарел. И показана мощь современных С++ компилеров.
Сравнительные мат. тесты мы порвели чтобы убедиться, что системы более- менее сопоставимы.
Что не так?
То что циклы, С++ сводил к обычному присвоению?
Нас интересовала сопоставимость систем в НЕТ.
//------------
Вывод который я для себя сделал - MS уж слишком выпендривается и врет по поводу NET.
Кстати Java обходил НЕТ(или шел один в один) и в других, более серьезных, но не менее "безграмотных" тестах (на RSDN).
Ну если Вы сами считаете свои тесты неабсолютными, необъективными и несерьёзными, то о чём вообще речь может идти
Зато ваши выводы послушаешь, так и дивишься. Строго говоря, по логике с компилятора спросить нечего в ваших тестах, он на место цикла мог бы засунуть хоть что.
Тебе нужны асолютно точные тесты в идеальных условиях, которых на практике не существует или те, которые проводятся в реальных условиях??? Вторые так или иначе всегда будут решающими, мы их и провели и сделали соответствующие выводы...
Несмотря на все те ошибки, которые ты мне/нам указал, я отнюдь не забраковал результаты того, что мы делали, поскольку они проведены в реальных условиях... Другое дело, если сравнение скоростей проходит не в релизе или действительно в разных условиях, но этого не было. Тесты достаточно объективны, пусть в них есть погрешность, не претендуем на что-то абсолютное, но относительное - удалось.