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

K>Не факт. Разница в большинстве случаев очень незначительная. Для FW 2.0 по крайней мере. Разве только загрузку ускоряет.

Не разве, а только лишь — что еще оно может улучшить?
в ngen используется в точности тот же компилятор.

Хуже того — mSDN говорит о каких-то дополнительных возможностях jit, недоступных при ngen.. не знаю, реальных или теоретических, но, в общем, использование ngen теоретически может даже _замедлить_ выполнение программы.

В юбом случае — ускорение — _только_ загрузки.

Ryf пишет:
> Здравствуйте, NovaCxarmulo, Вы писали:
>
> NC>я бы не удивился если б результат был бы одинаковый — ну запрашивается
> NC>переменная через св-во и всё.... но почему идет замедление цикла?
> ну тебе же ответили уже... исключаются проверки выхода за диапазон.

да, я тот ответ прочитал после того, как в эту ветку написал...

Posted via RSDN NNTP Server 2.0

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

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

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

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

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

T>А чего ёрничать? Если не понял ответа, подумай второй раз.

Ой я тут очень понимаю Max.Subpixel-а. Я когда отровенную глупость слышу, тоже тянет поерничать. Вот такой дурной характер.

T>JIT на входе получает, скажем так, "почти ассемблер".

Ассемблер говоришь? Ты Рефлектором мользушся? Видил как он декомпилирует этот ассемблер во вполне читаемый код? Как думашь, что мешает тогда и JIT-у разобраться в этом "ассемблере"?

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

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

Чтобы быть в теме очень советую покурить на досуге Phoenix.

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

Очень доходчиво... и красноречиво показал, что не владешь темой.

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

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

Обоснования этому утверждению будут?

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

T>Послушайте, милейший, вы словами не бросайтесь, ладно? А то как-то тошнит от выпендрёжей.
T>Если умеете выражаться кратко и по существу — велкам, а если надо понты кидать — для этого есть другой форум.
Когда появляется человек и говорит что белое это черное то не остается ничего кроме как отправить его почитать о том как называются цвета.

T>Для оптимизатора IL может так оно и есть.
Так оно и есть для любого оптимизатора. Получить информации о коде написанном на C# больше чем из IL не возможно. При компиляции теряется форматирование и комментарии(надеюсь ты не станешь утверждать что это может повлиять на оптимизацию). Вся остальная информация сохраняется в IL. То что оптимизатор IL пока не очень умный не значит что он теоритически не в состоянии оптимизировать не хуже чем оптимизатор С++.
T>Выше я привёл пример с CF — по этому поводу есть что сказать?
Приведи код того что ты имеешь в виду. И за одно потрудись объяснить в чем у С++ преймущество перед IL.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, 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 сек.

Хмм... Очень странно. Думается мне, что Visual C++ не смог правильно соптимизировать ваш алгоритм пузырька (какой-то он странный). Попробуйте заменить функцию сортировки в обоих исходниках на такую:

void Sort(byte* arr, int size)
{
    for(int i = 0; i < size; i++)
    {
        for(int j = 0; j < i; j++)
        {
            if(arr[i] < arr[j])
            {
                byte tmp = arr[i];
                arr[i]   = arr[j];
                arr[j]   = tmp;
            }
        }
    }
}

В таком виде у меня время на C++ упало с 73 до 17 секунд. Интересно, как это повлияет на C#.

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

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

+1

Курица не пртица. JIT не компилятор. Баба не человек...

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

T>Послушайте, милейший, вы словами не бросайтесь, ладно? А то как-то тошнит от выпендрёжей.
T>Если умеете выражаться кратко и по существу — велкам, а если надо понты кидать — для этого есть другой форум.

Твое поведение — это поведение воинствующего ламера. Сам в вопросе не понимаешь и набирашся наглости на других оскорблять.

Уж если споришь, то спорь корректно.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

WH>Так оно и есть для любого оптимизатора. Получить информации о коде написанном на C# больше чем из IL не возможно. При компиляции теряется форматирование и комментарии(надеюсь ты не станешь утверждать что это может повлиять на оптимизацию). Вся остальная информация сохраняется в IL. То что оптимизатор IL пока не очень умный не значит что он теоритически не в состоянии оптимизировать не хуже чем оптимизатор С++.

На самом деле теряется чуть больше. Теряется, например, информация о структурных конструкциях вроде for, if и т.п., но оптимизатору эта информация не так уж и нужна.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

T>>И потом, неплохо бы иметь такие директивы, которые позволяют персонально каждому массиву задавать параметр — нужна ему эта долбаная проверка выхода за границы или нет
SAV>курить unchecked keyword

unchecked к массивам отношения не имеет. Это возможность игнорировать переполнение при вычислениях. А вот отказаться от проверок выхода за пределы массива можно только если перейти на unsafe и указатели. Вот только это редко когда дает реальные приемущества. Тот же вынос проверки за пределы циклов устраняет оверхэд возникающий от зашиты предоставляемой дотнетом.

T>>(нормальная программа 100% в ней не нуждается).
SAV>спорное утверждение, но в любом случае проверки можно отключить и для всей программы в целом

Нельзя. А утверждение более чем спорное.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов
NC>Время сортировки на
NC>C#: 86.26 сек.
NC>C++: 98 сек.

Несколько советов эксперементаторам.
1. Измерять время в дотнете лучше с помощью класса System.Diagnostics.Stopwatch. Это и проще и точнее.
2. GC.Collect() вызывать не только глупо но и вредно. GC.Collect() только запускает сборку мусора, и она может идти параллельно. Так что уж если вызывашь GC.Collect(), то стоит вызвать и GC.WaitForPendingFinalizers().
3. Перед запуском первого теста (а лучше вообще между каждым вложенным тестом) следует вызывать Thread.Sleep() со значением 100-300. Это даст CLR сделать всю теневую работу и тест будет более точным. Например, у тебя первый тест вообще не дает реальных результатов.
4. Данные для теста лучше генерировать одинаковым алгоритмом генерации случайных цифр. Это позволит другим не искать разные бинарные файлы, да и упростит сам код.
5. Делая тесты обязательно нужно делать проверку истинности результата. В твоем случае проверять, что массив отсортирован. При этом нельзя использовать общие функции и объекты (вроде компораторов), так как в них могут быть ошибки.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Да, твои unsafe-тесты вообще никуда не годятся, так как кроме ключевого слова unsafe в них ничего болше нет.

Смысл unsafe-режима в том, что в нем можно использовать указатели. Так что код надо было переписать хотя бы так:

unsafe static void UnsafeSort2(byte[] arr)
{
    int len = arr.Length;
    if (len < 2)
        return;

    fixed (byte* p = &arr[0])
    {
        for (int i = 0; i < len; ++i)
            for (int j = 1; j < len; ++j)
                if (p[j] < p[j - 1])
                {
                    byte tmp = p[j - 1];
                    p[j - 1] = p[j];
                    p[j] = tmp;
                }
    }
}

А по уму код надо было вообще переписать так чтобы он использовал вычисления указателей. Но при этом С++-ный вариант уже скорее всего не проиграл бы.

... << RSDN@Home 1.2.0 alpha rev. 637>>

VladD2 пишет:
> Здравствуйте, NovaCxarmulo, Вы писали:
>
> NC>1. Сделал простенький тест: пузырьковая сортировка 150-160тыс. элементов
> NC>Время сортировки на
> NC>C#: 86.26 сек.
> NC>C++: 98 сек.
>
> Несколько советов эксперементаторам.
> 1. Измерять время в дотнете лучше с помощью класса System.Diagnostics.Stopwatch. Это и проще и точнее.
ок, буду знать на будущее...

> 2. GC.Collect() вызывать не только глупо но и вредно. GC.Collect() только запускает сборку мусора, и она может идти параллельно. Так что уж если вызывашь GC.Collect(), то стоит вызвать и GC.WaitForPendingFinalizers().
тоже учту, не знал...

> 4. Данные для теста лучше генерировать одинаковым алгоритмом генерации случайных цифр. Это позволит другим не искать разные бинарные файлы, да и упростит сам код.
этот тест не предполагал какого-то полного, строгого тестирования двух
языков большим количеством народа, просто надо было быстренько сравнить
два языка (изначально C# и C#2) и писать придумывать для этого свой
алгоритм генерации случайных чисел, думаю, было бы нерационально

> 5. Делая тесты обязательно нужно делать проверку истинности результата. В твоем случае проверять, что массив отсортирован. При этом нельзя использовать общие функции и объекты (вроде компораторов), так как в них могут быть ошибки.
про проверку — согласен, про компараторы — не согласен:
1. Я исхожу из того, что компилятор и все стандартные библиотеки
работают правильно (обратное конечно бывает, но крайне редко, мне еще не
попадалось)
2. Если не доверять стандартным библиотекам, то придется весь FW
переписывать самому (лично я использую C# из-за большого набора
встроенных в FW велосипедных классов)... уверен глюков будет значительно
больше, чем есть сейчас

Posted via RSDN NNTP Server 2.0

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

VD>На самом деле теряется чуть больше. Теряется, например, информация о структурных конструкциях вроде for, if и т.п., но оптимизатору эта информация не так уж и нужна.
Она может понадобится только для примитивных шаблонных оптимизаторов. А от них толку мало.
Сейчас JIT шаблонит по черному по тому и

for( int i = 0; i < arr.Length; ++i )

работает быстрее, чем

int len = arr.Length;
for( int i = 0; i < len; ++i )

А еслибы он не шаблонил, а честно просчитывал потоки данных и исполнения то и таких проблем бы небыло.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

L>>И все-таки, кто такой CF?

T>Опять в первый класс?

Объяснил же, см. выше:

T>http://www.rsdn.ru/Forum/Message.aspx?mid=1849446&all=1 (ищи по подстроке "CF")

Это мне напомнило Лема с его секпульками...
На вопрос что такое CF посылать в ветку, где первое упоминание CF это "Факт тот, что мне понадобился флаг CF...", а последукющие посты вида "Выше я привёл пример с CF ... " выглядит по крайней мере странно.

Я облазил все ветку, но так и не нашел ответа на вопрос, что же такое CF? Может быть это CompactFlash ( первые строчки при гуглении здесь )? Я весь в недоумении, при чем тут CompactFlash и оптимизация.. Поясните, пожалуйста, что вы подразумеваете под буквами CF?

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

В>Я облазил все ветку, но так и не нашел ответа на вопрос, что же такое CF? Может быть это CompactFlash
Я поначалу подумал про Compact Framework.

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

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

L>>>И все-таки, кто такой CF?

T>>Опять в первый класс?

Объяснил же, см. выше:

T>>http://www.rsdn.ru/Forum/Message.aspx?mid=1849446&all=1 (ищи по подстроке "CF")

В>Это мне напомнило Лема с его секпульками...
В>На вопрос что такое CF посылать в ветку, где первое упоминание CF это "Факт тот, что мне понадобился флаг CF...", а последукющие посты вида "Выше я привёл пример с CF ... " выглядит по крайней мере странно.

В>Я облазил все ветку, но так и не нашел ответа на вопрос, что же такое CF? Может быть это CompactFlash ( первые строчки при гуглении здесь )? Я весь в недоумении, при чем тут CompactFlash и оптимизация.. Поясните, пожалуйста, что вы подразумеваете под буквами CF?

Ну это типа крутые программеры знают, но молчат (нам до них далеко). Я так думаю, это какой-то бит из регистра флагов процессора.

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

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

VD>>На самом деле теряется чуть больше. Теряется, например, информация о структурных конструкциях вроде for, if и т.п., но оптимизатору эта информация не так уж и нужна.
WH>Она может понадобится только для примитивных шаблонных оптимизаторов. А от них толку мало.
WH>Сейчас JIT шаблонит по черному по тому и
WH>

WH>for( int i = 0; i < arr.Length; ++i )
WH>

WH>работает быстрее, чем
WH>

WH>int len = arr.Length;
WH>for( int i = 0; i < len; ++i )
WH>

WH>А еслибы он не шаблонил, а честно просчитывал потоки данных и исполнения то и таких проблем бы небыло.

Ну, здесь ведь палка о двух концах — надо и на ель залезть, и ж..у не поцарапать. Компиляторы типа C++ вобще могут развлекаться сколько угодно времени, а типа JIT — вся оптимизация происходит во время запуска приложения (или я неправ?). Ну представьте, например, 15 сек на запуск, а?

	От:	klapaucius
	Дата:	20.04.06 12:03
	Оценка:

	От:	Аноним
	Дата:	20.04.06 12:33
	Оценка:	+1

От:	NovaCxarmulo	http://timofey.koolin.ru
Дата:	20.04.06 15:27
Оценка:

От:	IT	linq2db.com
Дата:	20.04.06 15:37
Оценка:

От:	VladD2	www.nemerle.org
Дата:	20.04.06 17:43
Оценка:	+1

	От:	WolfHound
	Дата:	21.04.06 05:50
	Оценка:

	От:	Ведмедь
	Дата:	21.04.06 08:38
	Оценка:

	От:	Lloyd
	Дата:	21.04.06 10:07
	Оценка:

	От:	_d_m_
	Дата:	21.04.06 10:16
	Оценка: