Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0,
проекты компилировались в Visual Studio 2005 Express Edition, в C++ все
оптимизации выставлены на скорость.
1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов
Время сортировки на
C#: 86.26 сек.
C++: 98 сек.
Пробовали запускать тест на другом компе — резуотат тот же... Шарп
оказался быстрее...
Именно так — C# справился быстрее.... сортировал один и тот же массив
(читал из файла), запускал тесты несколько раз, алгоритм сортировки один
и тот же (отличаются только синтаксические детали языков).
2. На этой же сортировке с удивлением обнаружил, что цикл for(int i = 0;
i < arr.Length; ++i) выполняется быстрее, чем если длину массива
записать в отдельную переменную... (после вынесения arr.Length в
отдельную переменную время сортировки увеличилось с 86 до 116 сек).
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, NovaCxarmulo, Вы писали:
NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов NC>Время сортировки на NC>C#: 86.26 сек. NC>C++: 98 сек.
Щас тут многие скажут "ну дык".
Но вообщем-то ничего непонятного. Разница не велика. Так что особо не о чем говорить.
То, что не медленнее, это было понятно — в конечном итоге все-равно машинный код.
JIT имеет больше возможностей для оптимизации, чем C++ компилятор.
Так что неудивительно.
NC>2. На этой же сортировке с удивлением обнаружил, что цикл for(int i = 0; NC>i < arr.Length; ++i) выполняется быстрее, чем если длину массива NC>записать в отдельную переменную... (после вынесения arr.Length в NC>отдельную переменную время сортировки увеличилось с 86 до 116 сек).
Это я не помню как оптимизация называется. Но на семинаре по гайдам МС всегда приводят эту строку в пример — говорят, не пытайтесь думать за компилятор — он неплохо соображает и знает что делать... В данном случае вроде как он исключает проверку выход за пределы массива, так как по объявлению цикла видит, что он никогда не выйдет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re: Скорость C# это что-то непонятное
От:
Аноним
Дата:
13.04.06 19:32
Оценка:
Здравствуйте, 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 сек).
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Пробовали запускать тест на другом компе — резуотат тот же... Шарп NC>оказался быстрее...
Не первый такой случай. Чего удивляться-то — когда такой делающий банальные вычисления байт-код компилится в машинный — компилятор имеет информацию о процессоре, может всякие продвинутые инструкции использовать. А ещё скорее — JIT местами действует умнее чем VC++ компилятор (обогнать С++ скомпилированный Intel-овским компилятором НЕТ-у вроде ещё никогда не удавалось).
Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка, тупой GC, жирные (чересчур)высокоуровневые конструкции для всего на свете, низкая квалификация типичного .НЕТ-програмера — именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем. С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать. А память нынче более доступна в цене, чем хорошие программеры.
У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает, тупых сажают документацию писать или же они менеджерскую/архитекторскую/аналитическую карьеру делают, в общем, не пишут код своими кривыми руками. А в .НЕТ таким кадрам многое по-плечу, они и наяривают. Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
Здравствуйте, NovaCxarmulo, Вы писали:
NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, проекты компилировались в Visual Studio 2005 Express Edition, в C++ все оптимизации выставлены на скорость.
Когда публикуешь орезультаты тестов то публикуй и исходники этих тестов. Иначе никто ничего сказать не сможет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, NovaCxarmulo, Вы писали:
NC>>Пробовали запускать тест на другом компе — резуотат тот же... Шарп NC>>оказался быстрее...
А>Не первый такой случай. Чего удивляться-то — когда такой делающий банальные вычисления байт-код компилится в машинный — компилятор имеет информацию о процессоре, может всякие продвинутые инструкции использовать. А ещё скорее — JIT местами действует умнее чем VC++ компилятор (обогнать С++ скомпилированный Intel-овским компилятором НЕТ-у вроде ещё никогда не удавалось).
Я конечно не знаю. Но что-то раньше было такое впечатление, что компилятор Microsoft C++ был прилично шустрее того от Интела.
Так что это вроде как байки, либо уж точно были компиляторы быстрее (статистику не видел). Но в любом случае, разница не такая, чтобы прямо интеловский компилятор был всегда быстрее .NET. Ссылку в студию! Мне интересно откуда дрова...
А>Тормоза .НЕТ совсем в другом: бесконечное создание объектов в куче и её тасовка,
Бесконечное создание объектов? Это что такое? А где вы обычно объекты держите, если не в куче?
Можете в стеке создавать... Вот вам структуры.
Что такое тасовка? Управление? Так оно и быстрее частенько, чем ручная манипуляция...
А> тупой GC
Мне прямо даже обидно за людей. Вот так делали, делали, столько там навернули, а вы прямо так его "тупой". Это в чем же? И как бы вы сделали его умнее? Только не говорите мне про счетчик ссылок — проверено, это гораздо медленнее.
А>жирные (чересчур)высокоуровневые конструкции для всего на свете
Это вы так объекты называете? Или что? О чем речь то?
А>низкая квалификация типичного .НЕТ-програмера
Низкая квалификация? Откуда дрова? Типа "если с трактором не умеешь обращаться, то гонщиком не быть"?
А>именно из-за этого средняя .НЕТ-программа в разы (десятки раз, если "мастера" писали) медленнее средней С(++)-шной при потреблении памяти в разы (десятки раз, если "мастера" писали) большем.
Т.е. неквалифицированный программист С++ в среднем делает код, который работает в разы быстрее и в разы меньше памяти ест?
А>С другой стороны, большинство аппликаций не предъявляют вообще никаких требований к производительности, производительность — вообще очень относительное понятие — если все программы медленные — никто об это не знает, пока нет быстрой, чтобы сравнивать.
А зачем сравнивать? Меня не напрягает, что моя машина не развивает 300км/час. А должно? Может просто бывают требования к производительности, которым надо удовлетворять, а все остальное никому не нужная трата времени?
А> А память нынче более доступна в цене, чем хорошие программеры.
Хороший программист это не тот, кто умеет память экономит. Я уверен.
А>У С/С++ есть большое преимущество — код написанный совсем уж тупым программером просто не работает
Ну почему, он может еще работать хреново. Так и в чем тут преимущество — по вашей логике — так был бы код и работал бы. А так вообще ничего. Вот тебе плюс...
А>тупых сажают документацию писать
Вы любитель тупой документации? Хуже не бывает...
А> или же они менеджерскую/архитекторскую/аналитическую карьеру делают
Это что же хорошо, если архитектор или менеджер тупой? Это будет еще хуже тупого программиста...
А>А в .НЕТ таким кадрам многое по-плечу, они и наяривают.
А знаете, иногда больше и не надо. И слава богу, что теперь не надо помнить коды перфокарт.
А>Если ещё и про Design Patterns книжку осилят — вообще караул ("Для преобразования символов в нижний регистр мы используем паттерн Интерпретатор реализованный как синглтон и создаваемый с помощью фабрики классов"). Результат — плачевный.
Я с вами согласен — плохой программист — это плохо. Но язык должен быть чем проще, тем лучше. Есть и другие важные факторы, но простота использования языка важна как хорошему, так и плохому программисту в равной степени.
В остальном же я вообще не понимаю. Вы видимо на C++ пишите, и здесь читаете, чтобы знать врага в лицо.
Здравствуйте, Max.Subpixel, Вы писали:
MS>Щас тут многие скажут "ну дык".
Дык, и будут правы. Особенно если учесть невироятное количество фобий порождаемых по этому вопросу.
Только давича нам рассказывали, что дотнет интерпретатор, и вообще сравнение байтов нужно писать на С++.
MS>Но вообщем-то ничего непонятного. Разница не велика. Так что особо не о чем говорить.
+1
MS>То, что не медленнее, это было понятно — в конечном итоге все-равно машинный код. MS>JIT имеет больше возможностей для оптимизации, чем C++ компилятор. MS>Так что неудивительно.
Вообще-то у джита куча мест усложняющих потимизацию. Но потенциально все именно так как ты говоришь.
MS>Это я не помню как оптимизация называется. Но на семинаре по гайдам МС всегда приводят эту строку в пример — говорят, не пытайтесь думать за компилятор — он неплохо соображает и знает что делать... В данном случае вроде как он исключает проверку выход за пределы массива, так как по объявлению цикла видит, что он никогда не выйдет.
Небольшое уточнение. Не "исключает", а выносит за пределы цикла. То есть проверка все же есть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
не вопрос... где публиковть? просто в тесте сообщения конечно могу, но
думаю это не оч. красиво будет
WolfHound пишет: > Здравствуйте, NovaCxarmulo, Вы писали: > > NC>Проверял на: P4 2.4ГГц, 1.25ГБ памяти, WinXP Home SP2, FrameWork 2.0, проекты компилировались в Visual Studio 2005 Express Edition, в C++ все оптимизации выставлены на скорость. > Когда публикуешь орезультаты тестов то публикуй и исходники этих тестов. Иначе никто ничего сказать не сможет.
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, NovaCxarmulo, Вы писали:
NC>не вопрос... где публиковть? просто в тесте сообщения конечно могу, но NC>думаю это не оч. красиво будет
На RSDN можно заливать файлы. В форме отправки сообщения есть кнопка "загрузить".
ЗЫ Не отвечай сверху сообщения. Здесь так не принято. И следи за цитированием. Ибо за оверквотинг тут иногда даже банят.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А что вы удивляетесь? Сколько лет назад последний раз обновлялся С++ компилер? вот-вот а JIT компилер вышел совсем недавно, это к тому прогеры-компиляторщики тоже улучшают свои качества, и вкладывают их в новые компилеры.
Max.Subpixel пишет: > Здравствуйте, <Аноним>, Вы писали: > > А>отключите safe режим и собирите C++ еще раз > > Мне казалось, человек вообще не в МС++ делал, а в С++...
Да, именно в Native C++, вообще без поддержки CLR, ссылка на исходники в
другой ветке висит.
Posted via RSDN NNTP Server 2.0
Сражение выигрывает тот, кто твердо решил его выиграть
(с) Л.Н. Толстой
Здравствуйте, Nimnul, Вы писали:
N>А что вы удивляетесь? Сколько лет назад последний раз обновлялся С++ компилер?
В конце 2005-го?
N>вот-вот а JIT компилер вышел совсем недавно
В конце 2005-го?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Скорость C# это что-то непонятное
От:
Аноним
Дата:
18.04.06 03:06
Оценка:
а я слышал что С++ больше не поддерживается МС. так что там тотже самый старый С++. Что касается компилятора то он не претерпивал серьезных изменений с тех пор как он был написанн, под x86.
