Скорость C# это что-то непонятное - .NET

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

N>а я слышал что С++ больше не поддерживается МС. так что там тотже самый старый С++. Что касается компилятора то он не претерпивал серьезных изменений с тех пор как он был написанн, под x86.

На КРИ 2006 на одном из семинаров представитель компании Intel Виктория Жислина сказала, что "в 2005 студии компания Microsoft сделала компилятор, который практически не уступает компилятору от Intel, но все же уступает". Из чего можно сделать вывод, что с++ МСом таки поддерживается и даже развивается

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

NC>>1. Сделал простенький тест

Ну сделал и сделал — чего кричать-то?

Как я понял, ты сравнил C#-прогу с аналогичной, но под Win32. Так?

MS>JIT имеет больше возможностей для оптимизации, чем C++ компилятор.

С какой стати? C# делает псевдокод, потом JIT его перемалывает в машинный. А Ц++ сразу имеет право генерить x86.
Т.е. там, где у JIT идёт абстрактный поток команд, у Ц++ полная инфа об алгоритме.

MS>Это я не помню как оптимизация называется. Но на семинаре по гайдам МС всегда приводят эту строку в пример — говорят, не пытайтесь думать за компилятор — он неплохо соображает и знает что делать... В данном случае вроде как он исключает проверку выход за пределы массива, так как по объявлению цикла видит, что он никогда не выйдет.

Значит парень просто недотумкал с ключами компилера — мог бы оптимизировать.

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

T>С какой стати? C# делает псевдокод, потом JIT его перемалывает в машинный. А Ц++ сразу имеет право генерить x86.
T>Т.е. там, где у JIT идёт абстрактный поток команд, у Ц++ полная инфа об алгоритме.

Мне нравится. Абстрактный поток команд значит... 5 баллов.
У C++ идет алгоритм, а IL код это абстракционизм и вообще не алгоритм...

T>Значит парень просто недотумкал с ключами компилера — мог бы оптимизировать.

"Парень" сказал, что настроил по максимуму. Что там тумкать — в большинстве случаев компилятор С++ делает все что может...
Откуда такая уверенность, что конечно C++ компиляторы по определению лучше? Потому что их писали умнее люди, что-ли?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

MS>Мне нравится. Абстрактный поток команд значит... 5 баллов.

А чего ёрничать? Если не понял ответа, подумай второй раз.
JIT на входе получает, скажем так, "почти ассемблер". Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию.
Я доходчив?

T>>Значит парень просто недотумкал с ключами компилера — мог бы оптимизировать.

MS>"Парень" сказал, что настроил по максимуму.

Он сказал, а я проверил на деле — ОПТИМИЗАЦИЯ БЫЛА ВЫКЛЮЧЕНА. Правда, после включения результат был не лучше.

MS>Откуда такая уверенность, что конечно C++ компиляторы по определению лучше?

А разве я говорил, что они лучше?

Если договорить мою мысль, то я уверен в следущем: хороший компилятор выдаёт программу, которая ВСЕГДА БЫСТРЕЕ любого jit'а.
Разумеется, если мелкософт не научилась делать Ц++ компилеры, это не повод говорить, что C# лучше.

Правда, стоит отметить, что вообще сами по себе ООП языки — костыли ещё те. Если уж чешется сравнивать, то надо брать простой Си и Цэшарп.

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

T>JIT на входе получает, скажем так, "почти ассемблер". Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию.
T>Я доходчив?

Не совсем. Приведи, пожалуйста, пример "сложной операции".

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Элементарно! Свежий пример буквально из личных алгоритмов:
Делал конвертер из "бинарного" формата в "читабельный" (Base64), но байты декомпозицировал не как длинную цепочку бит, а просто отрезал от каждого байта "верхушку" и сунул в четвёртую. Не суть. Факт тот, что мне понадобился флаг CF, который В ПРИНЦИПЕ не может существовать в "виртуальной машине" или псевдокоде. Ну то есть ввести его можно, но выглядеть он будет глупо.

Я соглашусь, это не совсем те условия, что были в оригинале. Но если допустить, что в языке будет операция a = #(массив); (некая абстр. запись Base64), то увы, "псевдокодная" реализация операции никогда не будет реализована через x86-шный CF, а значит всё что остаётся jit'у — это оптимизировать то, что налабали мелкомягкие в качестве псевдокодной реализации #().

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

MS>>Мне нравится. Абстрактный поток команд значит... 5 баллов.

T>А чего ёрничать? Если не понял ответа, подумай второй раз.
T>JIT на входе получает, скажем так, "почти ассемблер". Т.е. если идёт команда "op_Addition a, b", то ему всё равно, кто там и что складывал. А если это делает Ц++, то он может проверить — вдруг это не просто ADD, а сложная операция, которую можно завернуть в одну процессорную инструкцию.
T>Я доходчив?

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

T>Он сказал, а я проверил на деле — ОПТИМИЗАЦИЯ БЫЛА ВЫКЛЮЧЕНА. Правда, после включения результат был не лучше.

Ну так и вот я о том же. Я в свое время наигрался с этими ключами — толку мизерно мало.

MS>>Откуда такая уверенность, что конечно C++ компиляторы по определению лучше?

T>А разве я говорил, что они лучше?

Если договорить мою мысль, то я уверен в следущем: хороший компилятор выдаёт программу, которая ВСЕГДА БЫСТРЕЕ любого jit'а.

JIT не компилятор или плохой и IL не код, а машинные команды. Ну вообще вернулись к тому с чего начали...

T>Разумеется, если мелкософт не научилась делать Ц++ компилеры, это не повод говорить, что C# лучше.

Как-то не знаю... Вот мой опыт показывает, что у них отличные C++ компиляторы.

T>Правда, стоит отметить, что вообще сами по себе ООП языки — костыли ещё те. Если уж чешется сравнивать, то надо брать простой Си и Цэшарп.

Щас я вам ссылку дам. Правда это под дебиан тесты и .нет там моновский...

http://shootout.alioth.debian.org/debian/benchmark.php?test=binarytrees&lang=all

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

NC>Исходники проектов и файл, на котором проводился тест здесь

При отценке време нельзя использовать функцию GetSystemTimeAsFileTime() так как во время выполнения сортировки планировщик может переключится на другую задачу. Нужно использовать функцию GetThreadTimes().

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

T>Делал конвертер из "бинарного" формата в "читабельный" (Base64), но байты декомпозицировал не как длинную цепочку бит, а просто отрезал от каждого байта "верхушку" и сунул в четвёртую.

В "четвёртую" что?

T>Не суть. Факт тот, что мне понадобился флаг CF, который В ПРИНЦИПЕ не может существовать в "виртуальной машине" или псевдокоде. Ну то есть ввести его можно, но выглядеть он будет глупо.

А что за флаг CF есть в C++?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Вот доказательства того что надо использовать GetThreadTimes() а не GetSystemTimeAsFileTime(). При сортировке файла размером 54528 байт результат был такой:
count: 54528

bubble : 17.385 — GetThreadTimes()
bubble(bad) : 24.9058 — GetSystemTimeAsFileTime()
разница = 7,5208

stl : 0.0100144 — GetThreadTimes()
stl(bad) : 0.0100144 — GetSystemTimeAsFileTime()

NovaCxarmulo ты из Ярославля?

iix пишет:
> Вот доказательства того что надо использовать GetThreadTimes() а не GetSystemTimeAsFileTime(). При сортировке файла размером 54528 байт результат был такой:
> count: 54528
>
> bubble : 17.385 — GetThreadTimes()
> bubble(bad) : 24.9058 — GetSystemTimeAsFileTime()
> разница = 7,5208

bubble и bubble(bad) это одна и та же ф-ция?

> stl : 0.0100144 — GetThreadTimes()
> stl(bad) : 0.0100144 — GetSystemTimeAsFileTime()
>

> NovaCxarmulo ты из Ярославля?
да

а про GetThreadTimes() буду знать...

Posted via RSDN NNTP Server 2.0

Max.Subpixel пишет:
> "Парень" сказал, что настроил по максимуму. Что там тумкать — в большинстве случаев компилятор С++ делает все что может...
так, к слову... у "Парня" ник есть....

Posted via RSDN NNTP Server 2.0

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

[]

Имхо, не на тех задачах меряешь. В c# тесте везде value-типы и jit'у ничего не мешает сгенерить хороший машинный код. GC практически не используется и все те фичи managed-языков, которые их тормозят( тут сразу камнями не забрасывать. согласитесь, что пусть чуть-чуть, но медленне unmanaged-языков. ), не используются.

Да и это не новость. Еще пару лет назад читал про замеры. Так там и fw 1.1 при отключенной проверке выхода за пределы массива практически не уступал с++

Непонятно почему:
for( int i = 0; i < arr.Length; ++i )

работает быстрее, чем
int len = arr.Length;
for( int i = 0; i < len; ++i )

причем значительно....

Posted via RSDN NNTP Server 2.0

Здравствуйте, 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>причем значительно....

Запускай релиз и без дебаггинга — тогда все встанет на свои места

MatFiz пишет:
> Запускай релиз и без дебаггинга — тогда все встанет на свои места

ну.... вообще говоря я так и запускал...

Posted via RSDN NNTP Server 2.0

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

NC>bubble и bubble(bad) это одна и та же ф-ция?

Да. Проста засекал время сразу двумя функциями.

   GetThreadTimes(GetCurrentThread(),&ft_tmp,&ft_tmp,&ft_kbegin,&ft_ubegin);
   GetSystemTimeAsFileTime( &ft_begin); 
   Sort(arr, file_size );
   GetSystemTimeAsFileTime( &ft_end );
   GetThreadTimes(GetCurrentThread(),&ft_tmp,&ft_tmp,&ft_kend,&ft_uend);

>> NovaCxarmulo ты из Ярославля?
NC>да

Заархивированный файл тебя здал(7z).

	От:	ka1eka
	Дата:	18.04.06 06:53
	Оценка:

	От:	Lloyd
	Дата:	18.04.06 07:47
	Оценка:	+1

	От:	Thornik
	Дата:	19.04.06 14:02
	Оценка:	-4

	От:	Max.Subpixel
	Дата:	19.04.06 14:09
	Оценка:	+1

	От:	Thornik
	Дата:	19.04.06 14:58
	Оценка:	-6

От:	NovaCxarmulo	http://timofey.koolin.ru
Дата:	19.04.06 17:12
Оценка:

	От:	Константин Л.
	Дата:	19.04.06 17:16
	Оценка: