Здравствуйте, NovaCxarmulo, Вы писали:
NC>MatFiz пишет: >> Запускай релиз и без дебаггинга — тогда все встанет на свои места
NC>ну.... вообще говоря я так и запускал...
Сказали же — потому что автоматом исключаются проверки выхода за пределы массива при каждом обращении.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Непонятно почему: NC> for( int i = 0; i < arr.Length; ++i )
NC>работает быстрее, чем NC> int len = arr.Length; NC> for( int i = 0; i < len; ++i )
NC>причем значительно....
Потому что не надо делать вид, что ты умнее компилятора.
P.S. Ничего личного.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Скорость C# это что-то непонятное
От:
Аноним
Дата:
20.04.06 08:50
Оценка:
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, NC>проекты компилировались в Visual Studio 2005 Express Edition, в C++ все NC>оптимизации выставлены на скорость.
NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек.
NC>Пробовали запускать тест на другом компе — резуотат тот же... Шарп NC>оказался быстрее...
NC>Именно так — C# справился быстрее.... сортировал один и тот же массив NC>(читал из файла), запускал тесты несколько раз, алгоритм сортировки один NC>и тот же (отличаются только синтаксические детали языков).
NC>2. На этой же сортировке с удивлением обнаружил, что цикл for(int i = 0; NC>i < arr.Length; ++i) выполняется быстрее, чем если длину массива NC>записать в отдельную переменную... (после вынесения arr.Length в NC>отдельную переменную время сортировки увеличилось с 86 до 116 сек).
А просто компилятор си шарпа очень хорошо оптимизирует код, а в данном случае так как ясно что за границы массива
индекс не вылезет то проверку на выход за границы убирают
Здравствуйте, <Аноним>, Вы писали:
А>А просто компилятор си шарпа очень хорошо оптимизирует код, а в данном случае так как ясно что за границы массива А>индекс не вылезет то проверку на выход за границы убирают
Все верно, только это заслуга не компилятора си шарпа, а jit-а.
Здравствуйте, Thornik, Вы писали:
T>А чего ёрничать? Если не понял ответа, подумай второй раз. T>JIT на входе получает, скажем так, "почти ассемблер". Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию. T>Я доходчив?
Мда... Полное не понимание того как работают оптимизаторы. Очень рекомендую почитать чтонибудь на эту тему.
При переводе из C# в IL с точки зрения оптимизатора не происходит потери информации.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Скорость C# это что-то непонятное (собственно что неп
Lloyd пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>Непонятно почему: > NC> for( int i = 0; i < arr.Length; ++i ) > > NC>работает быстрее, чем > NC> int len = arr.Length; > NC> for( int i = 0; i < len; ++i ) > > NC>причем значительно.... > > Потому что не надо делать вид, что ты умнее компилятора. > P.S. Ничего личного.
я бы не удивился если б результат был бы одинаковый — ну запрашивается
переменная через св-во и всё.... но почему идет замедление цикла?
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, NovaCxarmulo, Вы писали:
NC>я бы не удивился если б результат был бы одинаковый — ну запрашивается NC>переменная через св-во и всё.... но почему идет замедление цикла?
ну тебе же ответили уже... исключаются проверки выхода за диапазон.
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, NovaCxarmulo, Вы писали:
NC> NC>я бы не удивился если б результат был бы одинаковый — ну запрашивается NC>переменная через св-во и всё.... но почему идет замедление цикла?
Потому что ты тем самым запутал jit-компилятор и он не смог выбросить из цикла проверку выхода зы границу массива.
WH>Мда... Полное не понимание того как работают оптимизаторы.
Послушайте, милейший, вы словами не бросайтесь, ладно? А то как-то тошнит от выпендрёжей.
Если умеете выражаться кратко и по существу — велкам, а если надо понты кидать — для этого есть другой форум.
WH>При переводе из C# в IL с точки зрения оптимизатора не происходит потери информации.
Для оптимизатора IL может так оно и есть. Выше я привёл пример с CF — по этому поводу есть что сказать?
Re[3]: Скорость C# это что-то непонятное (собственно что неп
L>Потому что не надо делать вид, что ты умнее компилятора.
А вы считаете себя глупее компилятора?
Знаете, может вам и импонирует политика майкрософт "Юзеры — дураки, им нужна только одна кнопка", но я предпочитаю следовать здравой логике и считать, что компилятор делает ИМЕННО ТО, что я прошу.
Если человек ЗАРАНЕЕ ВЫЧИСЛИЛ длинну массива и далее использует её как константу, это есть метод УСКОРЕНИЯ приложения, но никак не наоборот!!!
То, что у мелкомягких проблемы с таким глупым примером, говорит только об одном — в погоне за оптимизацией они забывают про основной алгоритм.
Хуже того: а что если у меня в цикле используется индексатор не i, а (i + j % 7) ?
По-моему, человек вполне законно апеллирует к тому, что его оптимизированный код должен работать как минимум НЕ ХУЖЕ исходного алгоритма.
И потом, неплохо бы иметь такие директивы, которые позволяют персонально каждому массиву задавать параметр — нужна ему эта долбаная проверка выхода за границы или нет (нормальная программа 100% в ней не нуждается).
Здравствуйте, californie, Вы писали:
C>а уж если c# приложение вначале сконвертить ngen.exe то скорость еще выше станет...
Скорость загрузки и потребление памяти при множественном использовании библиотеки.
Еще скорость выше станет на редковызываемых методах. В остальном не станет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, Thornik, Вы писали:
L>>Потому что не надо делать вид, что ты умнее компилятора.
T>А вы считаете себя глупее компилятора?
T>Знаете, может вам и импонирует политика майкрософт "Юзеры — дураки, им нужна только одна кнопка", но я предпочитаю следовать здравой логике и считать, что компилятор делает ИМЕННО ТО, что я прошу. T>Если человек ЗАРАНЕЕ ВЫЧИСЛИЛ длинну массива и далее использует её как константу, это есть метод УСКОРЕНИЯ приложения, но никак не наоборот!!!
Ну это потому что вы предпочитаете не читать что пишут производители компиляторов. В С++ произойдет тоже самое.
T>То, что у мелкомягких проблемы с таким глупым примером, говорит только об одном — в погоне за оптимизацией они забывают про основной алгоритм.
Это у всех одинаково.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[4]: Скорость C# это что-то непонятное (собственно что неп
Здравствуйте, Thornik, Вы писали:
T>А вы считаете себя глупее компилятора?
T>Знаете, может вам и импонирует политика майкрософт "Юзеры — дураки, им нужна только одна кнопка", но я предпочитаю следовать здравой логике и считать, что компилятор делает ИМЕННО ТО, что я прошу.
Следуй. Но не жалуйся тогда на производительность.
Здравствуйте, Thornik, Вы писали:
WH>>При переводе из C# в IL с точки зрения оптимизатора не происходит потери информации.
T>Для оптимизатора IL может так оно и есть. Выше я привёл пример с CF — по этому поводу есть что сказать?
Здравствуйте, Thornik, Вы писали:
T>Знаете, может вам и импонирует политика майкрософт "Юзеры — дураки, им нужна только одна кнопка", но я предпочитаю следовать здравой логике и считать, что компилятор делает ИМЕННО ТО, что я прошу.
если компилятор будет делать только то, что его просят (как это делали самые ранние компиляторы), то производительность будет очень низкой (никаких оптимизаций не будет)
T>Если человек ЗАРАНЕЕ ВЫЧИСЛИЛ длинну массива и далее использует её как константу, это есть метод УСКОРЕНИЯ приложения, но никак не наоборот!!!
это есть попытка оптимизации, которая может и провалиться. А оптимизировать что-то как известно надо только тогда, когда производительность не удовлетворительна. При этом надо производить тесты и замеры. До этого надо выбирать более читабельный вариант.
T>То, что у мелкомягких проблемы с таким глупым примером,
у них нет проблем с этим примером
T>По-моему, человек вполне законно апеллирует к тому, что его оптимизированный код должен работать как минимум НЕ ХУЖЕ исходного алгоритма.
вот именно, оптимизированный (JIT`ом) код работает быстрее
T>И потом, неплохо бы иметь такие директивы, которые позволяют персонально каждому массиву задавать параметр — нужна ему эта долбаная проверка выхода за границы или нет
курить unchecked keyword
T>(нормальная программа 100% в ней не нуждается).
спорное утверждение, но в любом случае проверки можно отключить и для всей программы в целом
