Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Мне охота посмотреть возможно ли на Шарпе эффективно писать generic код, работающий с value-типами, и если возможно, насколько легко это дается. Пока, кажется, что нелегко.

Я не сказал бы, что в этом вообще есть смысл. С точки зрения разных контейнеров — проблем особых нет. И эффективность высокая. С алгоритмами все сложенее. Абстракция в Шарпе вся динамическая и есть соттвествующие накладные расходы.

Но в рельном коде вообще по жизни приволируют классы. Уж не знаю почему, но структуры обычно вылезают там где нужна оптимизация и очень часто создают проблемы дизайна. Я не раз выкидывал структуры и заменял их на классы просто ради гибкости. Причем разницы в скорости при этом не ощущал (хотя потенциально она есть).

>> ты меряешь на грани разумного. Здесь любая мелочь может дать разницу в два-три раза.

ПК>Для C++ это не так: обычно abstraction penalty колеблется в пределах десятка процентов, если вообще присутствует.

Тут не причем С++. Ты погляди на код быстрой сортировки и прикинь, что чаще всего выполняется?... Правильно, сравнение! А так как это самая частая операция, то начинает серьезно играть роль банальная скорость вызова метода, инлайнинг, выравнивание кода и т.п. Может случиться так, что переставление переменных местами или добавление новой даст выигрыш в скорости.

Ну, и опять же. Что за зверь такой С++? Есть разные компиляторы. Один прекрасно справляется с устранением накладных расходов вызываемых абстракцией, а другой не очень. Разница тоже может составить разы.

Я еже кажется приводил пример с qsort и С. Так можно из-за того, что qsort оказывается не быстрой делать выводы о всем языке?

>> Это уже не архитектурная разница, а борьба команд оптимизаторов.

ПК>Для меня больше вопрос не в абсолютных цифрах C# vs. C++, а в относительных: насколько падает быстродействие C# для арифметики и около того при использовании мало-мальской абстракции над встроенными типами и попытках повторного использования кода. Пока результаты не радуют.

Опять та же песня. Да от оптимизатора это зависит. Ну, и опять же где ты видел подобную работу с вэйлью-типами?

ПК>Я выложил полные листинги всех файлов, которые использовал.

1. Нахрена мучиться с копированием отдельных фрагментов когда можно скачать проект в зипе?
2. Где код С++-ного проекта? Или нужно по бырому его переписать?

ПК>Для этих тестов мне вполне достаточно используемой точности.

И все же. Это намного удобнее и точнее.

ПК>Гм... В том же сообщении полный код на C++

Где?

ПК>С удовольствием, если руки дойдут.

Давай, двай. Народу интересно. Темболее, что тебе доступен больший список компиляторов.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Что значит "сложности"? Я хочу повторно использовать один раз написанные функции, а не плодить вместо них "ускорители" В голове в качестве "жизненного" примера я держу шаблоны классов, встречавшихся в реальных проектах: "маленькие" вектора:Vector2<T>, Vector3<T>, Vector4<T> (можно еще обобщить, сделав Vector<dimension,T>);

Пош, раскажи мне идиоту, чем List<T> тебя не устраивает? И чем он может быть медленнее чем какой-нибудь вектор?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Пока планов писать что-нибудь кроме тестов на C# у меня нет (разве что, если в web какой-нить занесет). (По крайней мере пока) к C# у меня интерес исключительно академический. Интересно смотреть на все (новые) языки. Просто, наконец, получилось немного с C# generics поиграться, а не только в черновиках стандарта читать. Соответственно, и вопросы появились практического характера.

Забавно, что совсем необоснованых суждений стало мнеьше. Теперь ты уже в основном напираешь на скорость. То ли еще будет.

VladD2,

> ПК> В голове в качестве "жизненного" примера я держу шаблоны классов, встречавшихся в реальных проектах: "маленькие" вектора:Vector2<T>, Vector3<T>, Vector4<T> (можно еще обобщить, сделав Vector<dimension,T>);

> Пош, раскажи мне идиоту, чем List<T> тебя не устраивает? И чем он может быть медленнее чем какой-нибудь вектор?

Это векторы линейной алгебры. Vector2<T> — вектор двумерного пространства, Vector3<T> — трехмерного и т.п. Для этих классов определены соответствующие операции. Например, умножения на матрицу, афинные преобразования и т.п. List<T> сюда никаким боком.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это векторы линейной алгебры. Vector2<T> — вектор двумерного пространства, Vector3<T> — трехмерного и т.п. Для этих классов определены соответствующие операции. Например, умножения на матрицу, афинные преобразования и т.п. List<T> сюда никаким боком.

Понял. Просто смутило похожее на СТЛ-евский вектор название. Что-то по матрицам я в сети встречал. Но сейчас уже не припомню.

В общем, если что никогда не поздно подключить генератор кода. Не та это проблема.

Добрый день!
Уважаемый Павел Кузнецов, я знаю что вы профессионал, но высказывание типа: "вот это тормозит в 2 раза" очень некорректно, и очень далеко от истины, чтобы языку присваивать клеймо — "в 2 раза медленней!".
(Особенно было смешно про видео-плейер.)

Наберите в C# код:

for(int i = 0; i < 10000000; i++)
{
    string s = "123456789012345678901234567890";
    s += "1";
}

и наберите в C++ тот же самый код с использованием любого класса типа string.
Вы скорее всего предпочтете std::string.

for(int i = 0; i < 100000000; i++)
{
    std::string s = "123456789012345678901234567890";
    s += "1";        
}

Теперь скомпилируйте в release и сравните.

Я использовал:
MS VS C++ 7.0 и MS VS C#.

На моей машине Cel2500 такие показатели:
C++ — 46 сек.
C# — 18 сек.

Тогда я могу сделать однозначный вывод по поводу производительности?
Конечно, нет. Где-то быстрее, а где-то медленнее. Линейной и тем-более константной зависимости тут нет, и быть не может, Вы как профессионал должны это понимать.
Ясно одно, что в достаточно крупных приложениях очень часто используется дин. память, поэтому в словах Влада истина в том, что зачастую при миграции более менее крупного проекта с C++ на C# заметно повышение производительности на глаз.
Вообще суть то не в самом C#, а в dotNET, т.к. сборщик мусора включает в себя "грамотный" диспетчер дин. памяти, а отсюда и выигрыш в конечной производительности.
Страуструп очень умный человек и позволил переопределять оператор "new" как на локальном так и на глобальном уровне, что позволяет писать при надобности свои менеджеры дин. памяти, а не использовать встроенные в систему.
Но вопрос в том кто это делает?

Денис,

> высказывание типа: "вот это тормозит в 2 раза" очень некорректно, и очень далеко от истины, чтобы языку присваивать клеймо — "в 2 раза медленней!".

Я нигде не говорил, что язык в 2 раза медленней (такое высказывание с моей точки зрения вообще не имеет смысла). Я измерял конкретные test cases, которые, да, примерно в 2 раза медленнее.

> (Особенно было смешно про видео-плейер.)

Это была иллюстрация того, что может означать замедление в 2 раза в ответ на совершенно конкретный вопрос Тимофея: "Два раза это так плохо?". Это не означает, что использование C# вообще или generics в частности означает обязательное замедление в 2 раза.

> На моей машине Cel2500 такие показатели:
> C++ — 46 сек.
> C# — 18 сек.
> Тогда я могу сделать однозначный вывод по поводу производительности?

Да, конечно, можно сделать однозначный вывод о том, что данный фрагмент кода на VC++ выполняется в два с половиной раза медленнее, чем на C#. Более того, можно даже объяснить, почему это происходит, и что по этому поводу можно сделать. На мой взгляд, любые шаги на пути к пониманию подобных моментов полезны.

> Линейной и тем-более константной зависимости тут нет, и быть не может

Речь идет о зависимости падения производительности от повышения уровня абстракции, т.е. в данном случае количества "слоев" использования generics и разнообразных оберток вокруг простых типов. Эта зависимость вполне может быть как константной, так и линейной, равно как и фактически любой другой. Правда, подозреваю, что дальше линейной на практике дело не пойдет.

> Ясно одно, что в достаточно крупных приложениях очень часто используется дин. память, поэтому в словах Влада истина в том, что зачастую при миграции более менее крупного проекта с C++ на C# заметно повышение производительности на глаз.

Еще раз: я не делаю никаких общих выводов. Речь о стоимости использования конкретных техник. А именно, применения generic программирования к абстракциям уровня value-классов. Производительность подсистемы управления памятью меня в данных test cases вообще не интересует, т.к. код был специально написан таким образом, чтобы по возможности исключить выделение/освобождение памяти в замеряемых фрагментах.