С# vs C++, голые цифры
От: IID Россия  
Дата: 19.05.09 20:30
Оценка: 11 (6) +5 -1 :))
В соселней ветке "Работа — с чего начать: С++ или С#?" было озвучено мнение
Автор: samius
Дата: 19.05.09
, что C# немного медленее С++. И даже предложен код на C#
Автор: IID
Дата: 19.05.09
.

Я привёл код в компилябельное состояние. Вот C# вариант, а вот C++ вариант. Для компиляции использовалась MSVS2008 со всеми обновлениями.
— компилятор C# версии 3.5 Настроки релизной сборки — дефолтные. (Там-то и настраивать особо нечего).
— компилятор Intel С++ 11.0.072. Релизная сборка кастомизирована. Впрочем, разница между дефолтной релизной сборкой и кастомизированной невелика, порядка 10-15%. Ключи компиляции:

/c /O2 /Og /Oi /Ot /Oy /Qipo /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /EHsc /MD /GS- /Gy /fp:fast /Yu"StdAfx.h" /Fp"Release/SpeedTestCpp.pch" /Fo"Release/" /W3 /nologo /Zi /QxSSSE3 /Qparallel /Qprof_use /Qprof_dir "Release"


Тестовая машина: Intel Core2 Q6600, 800mhz RAM 8Gb. ОС — Windows 7 RC1 x64. Программы собирались для x86.
Условия прогона: в диапазонах, указанных автором оригинального C# кода. Шаг по X/Y составляет 0.001 (всего за прогон обсчитывается 9млн пикселей). Делается 100(сто) прогонов подряд. Вычисляется суммарное время.
Побочные эффекты: практически исключены. Сторонней нагрузки не было, taskmgr показывал загрузку только одного ядра во время прогонов. Т.е. гипотеза о том что интел компилер сумел заюзать несколько ядер отпадает.

Результаты:
С#: 2m 14s (134 секунды)
С++: 27 секунд

С++ показал практически пятикратное преимущество (496%), обеспечив обсчёт ~33.33млн пикселей в секунду. C# осилил только ~6.71млн пикселей в секунду. (что довольно близко к результату автора в 5.9млн пикселей)

Итог: подавляющее превосходство С++. Не "немного быстрее", как утверждал автор, а в разы. Причём задача сводилась, фактически, только к грамотному распихиванию FPU команд. Интересно было бы посмотреть на работу с битами. Думаю, тут интел смог бы обеспечить ещё больший отрыв.
kalsarikännit
Re: С# vs C++, голые цифры
От: Alexander G Украина  
Дата: 19.05.09 20:41
Оценка: :))
Здравствуйте, IID, Вы писали:

IID>Причём задача сводилась, фактически, только к грамотному распихиванию FPU команд.


Вот именно. Посмотрим что С++ покажет, если задача будет сводится к поседовательности вызовов new
Re: С# vs C++, голые цифры
От: Antikrot  
Дата: 19.05.09 20:44
Оценка: +2
Здравствуйте, IID, Вы писали:

IID>В соселней ветке "Работа — с чего начать: С++ или С#?" было озвучено мнение
Автор: samius
Дата: 19.05.09
, что C# немного медленее С++. И даже предложен код на C#
Автор: IID
Дата: 19.05.09
.


IID>Я привёл код в компилябельное состояние. Вот C# вариант, а вот C++ вариант. Для компиляции использовалась MSVS2008 со всеми обновлениями.


тест некорректен, результат вызова внутри циклов нигде не используется, компилятор мог там выкинуть что угодно (DCE, фигли, на таком-то уровне оптимизации да еще с проф-юзом), ограничившись парой вызовов time и cout<<

посему надо либо переделать, либо доказывай по асмовому коду что ничего не выкинуто
Re[2]: С# vs C++, голые цифры
От: IID Россия  
Дата: 19.05.09 21:13
Оценка:
Здравствуйте, Antikrot, Вы писали:


A>тест некорректен, результат вызова внутри циклов нигде не используется, компилятор мог там выкинуть что угодно (DCE, фигли, на таком-то уровне оптимизации да еще с проф-юзом), ограничившись парой вызовов time и cout<<


Тогда что он делал 27 секунд ?

A>посему надо либо переделать, либо доказывай по асмовому коду что ничего не выкинуто


Я, вообще-то в первоначальном топике так и предлагал — генерировать массивы чисел и проверять их на совпадение. Ок, аргумент уместен. Но это уже завтра.
kalsarikännit
Re[3]: С# vs C++, голые цифры
От: Antikrot  
Дата: 19.05.09 21:15
Оценка:
Здравствуйте, IID, Вы писали:

A>>тест некорректен, результат вызова внутри циклов нигде не используется, компилятор мог там выкинуть что угодно (DCE, фигли, на таком-то уровне оптимизации да еще с проф-юзом), ограничившись парой вызовов time и cout<<

IID>Тогда что он делал 27 секунд ?
ну, возможно, он выкинул *не всё*. но мне сейчас несподручно ставить нужную версию компилятора для проверки
Re[2]: С# vs C++, голые цифры
От: IID Россия  
Дата: 19.05.09 21:21
Оценка: +1
Здравствуйте, Alexander G, Вы писали:

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


IID>>Причём задача сводилась, фактически, только к грамотному распихиванию FPU команд.


AG>Вот именно. Посмотрим что С++ покажет, если задача будет сводится к поседовательности вызовов new


Давай C# вариант. Перепишем на С++ и поглядим. Есс-но аллокацию памяти я буду использовать такую, какую захочу.
kalsarikännit
Re[3]: С# vs C++, голые цифры
От: Sorantis Швеция sorantis.blogspot.com
Дата: 19.05.09 21:32
Оценка: 1 (1)
Здравствуйте, IID, Вы писали:

Запустил С++ вариант под МС компиллер.
Время показало 3 секунды. ЧЯДНТ?
Время шарпов такое же как у тебя.
As long as there is life, there is hope
Re: С# vs C++, голые цифры
От: criosray  
Дата: 19.05.09 21:43
Оценка: 3 (3) +2 -1
Здравствуйте, IID, Вы писали:

IID>В соселней ветке "Работа — с чего начать: С++ или С#?" было озвучено мнение
Автор: samius
Дата: 19.05.09
, что C# немного медленее С++. И даже предложен код на C#
Автор: IID
Дата: 19.05.09
.


IID>Я привёл код в компилябельное состояние. Вот C# вариант, а вот C++ вариант. Для компиляции использовалась MSVS2008 со всеми обновлениями.

IID>- компилятор C# версии 3.5 Настроки релизной сборки — дефолтные. (Там-то и настраивать особо нечего).
IID>- компилятор Intel С++ 11.0.072. Релизная сборка кастомизирована. Впрочем, разница между дефолтной релизной сборкой и кастомизированной невелика, порядка 10-15%. Ключи компиляции:

Во-первых, Вы понимаете, что это синтетическая числодробилка меряет не более, чем попугайчики?
Во-вторых, почему в С++ варианте у Вас floor, а в С# Math.Round(x,1) ?

Потратив десять минут на оптимизацию этого гения числодробильной мысли получил результат:

Elapsed 00:00:27.2390376 sec.

К сожалению на руках нет Intel С++ компиллятора, чтоб сравнить.

Код:

    class Aux
    {
        public double x, y, z;

        double ZzzFunc()
        {
            double xmy = x - y; 
            
            return xmy - Math.Floor(xmy);
        }
        double Spiral_()
        {
            double xk = x * 20; 
            const double a = 0.2; 
            const double b = 1.5;

            double y1 = y * b - a * Math.Sin(xk);
            double z1 = z * b - a * Math.Cos(xk);
            
            return y1 * y1 + z1 * z1;
        }

        public bool Golova()
        {
            return x < 0.0 && x * x + y * y + z * z < 1.0 && !Shliz();
        }
        
        private bool Spiral()
        {
            return x > 0.0 && x < 1.75 && Math.Abs(Spiral_()) < 0.5;
        }

        private bool Shliz()
        {
            return x < -0.4 && y < 0.1 && y > -0.1;
        }

        private bool Strokes()
        {
            return (Math.Abs(0.5 - x) < 0.02
                    || (x > 0.5 && Math.Abs(ZzzFunc()) < 0.005))
                   && !Spiral() && !Golova();
        }

        private bool Wall()
        {
            return x > 0.5 && !Strokes() && !Spiral();
        }

        public int GetColor()
        {
            if (Golova()) return 1;
            if (Spiral()) return 2;
            if (Strokes()) return 3;
            if (Wall()) return 4;
            return 0;
        }
    };

    class Program
    {
        static void Main(string[] args)
        {
            var a = new Aux();
            
            var stopWatch = new System.Diagnostics.Stopwatch();

            stopWatch.Start();

            Parallel.For(0, 100, i =>
                         {
                             a.z = 0;
                             for (a.y = -1.5; a.y < 1.5; a.y += 0.001)
                             {
                                 for (a.x = -1; a.x < 2; a.x += 0.001)
                                 {
                                     int c = a.GetColor();
                                 }
                             }
                             
                         });

            stopWatch.Stop();

            Console.WriteLine("Elapsed {0} sec.\n", stopWatch.Elapsed);
            Console.ReadKey();
        }


Что поменял:
1) сменил бредовое использование параметров во внутренних методах классов на использование полей класса;
2) заменил Math.Round на Math.Floor
2) самое значимое — так как алгоритм явно элементарно параллелится, то раскидал его на все доступные (их два у меня) ядра процессора с помощью Parallel.For

Вы скажете, что ах ну конечно я тоже мог бы использовать OpenMP и распаралеллить — могли, но не использовали.
Предпологаю, что у меня более быстрый процессор (Core2Duo 3GHz), чем у Вас, и что вариант на С++ отработал бы быстрее, чем за 27 секунд. Да. Но даже если бы он отработал в два раза быстрее (что сомнительно), все-равно мы видим, что "тормозной дотнет" на самом синтетичном и выигрышном для Intel C++ (самого мегаоптимизирующего С++ компиллятора с оптимизациями под Ваш процессор) тесте отстает-то в лучшем случае в два раза, а в худшем — так вообще ноздря в ноздрю.

Вот так "интерпретируемый язык" (с) Шеридан соперничает на числодробильном тесте с Intel C++
Re: С# vs C++, голые цифры
От: Lloyd Россия  
Дата: 19.05.09 21:44
Оценка: :)
Здравствуйте, IID, Вы писали:

IID>Итог: подавляющее превосходство С++. Не "немного быстрее", как утверждал автор, а в разы. Причём задача сводилась, фактически, только к грамотному распихиванию FPU команд. Интересно было бы посмотреть на работу с битами. Думаю, тут интел смог бы обеспечить ещё больший отрыв.


Не "превосходство С++", а превоходство интеловского компилятора перед MS-овским jit-ом.
Для корректного сравнения компилируйте C++-код MS-компилятором и сравнивайте.
Re[2]: С# vs C++, голые цифры
От: Sorantis Швеция sorantis.blogspot.com
Дата: 19.05.09 21:49
Оценка:
Здравствуйте, Lloyd, Вы писали:

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


IID>>Итог: подавляющее превосходство С++. Не "немного быстрее", как утверждал автор, а в разы. Причём задача сводилась, фактически, только к грамотному распихиванию FPU команд. Интересно было бы посмотреть на работу с битами. Думаю, тут интел смог бы обеспечить ещё больший отрыв.


L>Не "превосходство С++", а превоходство интеловского компилятора перед MS-овским jit-ом.

L>Для корректного сравнения компилируйте C++-код MS-компилятором и сравнивайте.

ну я и говорю.
3 секунды под МС компиллер.
As long as there is life, there is hope
Re[3]: С# vs C++, голые цифры
От: Antikrot  
Дата: 19.05.09 22:03
Оценка:
Здравствуйте, Sorantis, Вы писали:

S>ну я и говорю.

S>3 секунды под МС компиллер.
у меня за 0 секунд
Re: С# vs C++, голые цифры
От: Antikrot  
Дата: 19.05.09 22:04
Оценка:
Здравствуйте, IID, Вы писали:

IID>

IID>/c /O2 /Og /Oi /Ot /Oy /Qipo /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /EHsc /MD /GS- /Gy /fp:fast /Yu"StdAfx.h" /Fp"Release/SpeedTestCpp.pch" /Fo"Release/" /W3 /nologo /Zi /QxSSSE3 /Qparallel /Qprof_use /Qprof_dir "Release"

просто из интереса — замени O2 на O3
Re[3]: С# vs C++, голые цифры
От: midcyber
Дата: 19.05.09 22:06
Оценка:
Здравствуйте, Sorantis, Вы писали:

S>ну я и говорю.

S>3 секунды под МС компиллер.

Дай угадаю — если результат вычислений сохранять куда-либо, например в массив, то будет 60..90 секунд?
Re[2]: С# vs C++, голые цифры
От: Хвост  
Дата: 19.05.09 22:13
Оценка:
Здравствуйте, criosray, Вы писали:

C>2) самое значимое — так как алгоритм явно элементарно параллелится, то раскидал его на все доступные (их два у меня) ядра процессора с помощью Parallel.For

а можно узнать результаты теста без Parallel.For? меня терзают смутные сомнения что вы преувеличили лёгкость распараллеливания алгоритма и он у вас просто некорректно работает.
People write code, programming languages don't.
Re[3]: С# vs C++, голые цифры
От: criosray  
Дата: 19.05.09 22:18
Оценка: +1 -1 :))
Здравствуйте, Sorantis, Вы писали:

L>>Не "превосходство С++", а превоходство интеловского компилятора перед MS-овским jit-ом.

L>>Для корректного сравнения компилируйте C++-код MS-компилятором и сравнивайте.

S>ну я и говорю.

S>3 секунды под МС компиллер.

Потому что он умный и не станет гонять пустой цикл (а цикл пустой, т.к. результат расчетов нигде не используется, о чем, кстати, меня предупреждает среда Visual C#).

Если поменять код вот так, то получаем очень даже замечательный результат


            int x = 0;
            Parallel.For(0, 100, i =>
                         {
                             a.z = 0;
                             for (a.y = -1.5; a.y < 1.5; a.y += 0.001)
                             {
                                 for (a.x = -1; a.x < 2; a.x += 0.001)
                                 {
                                     x += a.GetColor();
                                 }
                             }
                         });

Elapsed 00:00:28.1069964 sec.

    int x = 0;

    for(int i = 0; i < 100; i++)
    {
        a.z = 0;
        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
        {
            for(a.x = -1; a.x < 2; a.x += 0.001)
            {
                 x += a.GetColor();
            }
        }
    }


elapsed: 77 seconds.

Оба-на! Вот и приехали. Замечательный язык С++ не менее замечательно продул.

Уверен, что результат с OpenMP был бы на уровне шарпового, но проверить не могу — лень возиться и разбираться с OMP.
Re[3]: С# vs C++, голые цифры
От: midcyber
Дата: 19.05.09 22:26
Оценка:
Здравствуйте, Хвост, Вы писали:

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


C>>2) самое значимое — так как алгоритм явно элементарно параллелится, то раскидал его на все доступные (их два у меня) ядра процессора с помощью Parallel.For

Х>а можно узнать результаты теста без Parallel.For? меня терзают смутные сомнения что вы преувеличили лёгкость распараллеливания алгоритма и он у вас просто некорректно работает.

Ну если учесть, что C++ алгоритм из примера ВООБЩЕ не работает
Re[4]: С# vs C++, голые цифры
От: Sorantis Швеция sorantis.blogspot.com
Дата: 19.05.09 22:27
Оценка:
Здравствуйте, midcyber, Вы писали:

M>Здравствуйте, Хвост, Вы писали:


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


C>>>2) самое значимое — так как алгоритм явно элементарно параллелится, то раскидал его на все доступные (их два у меня) ядра процессора с помощью Parallel.For

Х>>а можно узнать результаты теста без Parallel.For? меня терзают смутные сомнения что вы преувеличили лёгкость распараллеливания алгоритма и он у вас просто некорректно работает.

M>Ну если учесть, что C++ алгоритм из примера ВООБЩЕ не работает


Вобщем ветка создана потому что уж очень много страниц в предыдущей.
Ложный вызов товарищи
As long as there is life, there is hope
Re[4]: С# vs C++, голые цифры
От: Antikrot  
Дата: 19.05.09 22:34
Оценка:
Здравствуйте, criosray, Вы писали:

C>Оба-на! Вот и приехали. Замечательный язык С++ не менее замечательно продул.

C>Уверен, что результат с OpenMP был бы на уровне шарпового, но проверить не могу — лень возиться и разбираться с OMP.
распечай "х", чтобы убедиться что результат одинаковый. завтра буду уделывать с#
Re[4]: С# vs C++, голые цифры
От: Хвост  
Дата: 19.05.09 22:35
Оценка:
Здравствуйте, midcyber, Вы писали:

M>Ну если учесть, что C++ алгоритм из примера ВООБЩЕ не работает

надеюсь вы находитесь в трезвом уме и твёрдой памяти и понимаете разницу между "алгоритм был изменён человеком так что исключена его корректная работа" и "в целях оптимизации, код алгоритма не был сгенерирован компилятором"
People write code, programming languages don't.
Re[3]: С# vs C++, голые цифры
От: criosray  
Дата: 19.05.09 22:39
Оценка:
Здравствуйте, Хвост, Вы писали:

C>>2) самое значимое — так как алгоритм явно элементарно параллелится, то раскидал его на все доступные (их два у меня) ядра процессора с помощью Parallel.For

Х>а можно узнать результаты теста без Parallel.For? меня терзают смутные сомнения что вы преувеличили лёгкость распараллеливания алгоритма и он у вас просто некорректно работает.

Elapsed 00:01:26.8746531

86 секунд — то есть примерно на 10-12% медлененнее С++ варианта.

На счет Parallel.For Вы правы — работает некорректно. Каюсь, час ночи + спешка — преувеличил легкость распараллеливания.

Завтра на свежую голову посмотрю внимательнее как его распараллелить.
Re[5]: С# vs C++, голые цифры
От: midcyber
Дата: 19.05.09 22:51
Оценка:
Здравствуйте, Хвост, Вы писали:

Х>надеюсь вы находитесь в трезвом уме и твёрдой памяти и понимаете разницу между "алгоритм был изменён человеком так что исключена его корректная работа" и "в целях оптимизации, код алгоритма не был сгенерирован компилятором"


Разницу между "ложью" и "ошибкой", ты хотел сказать? Ключи оптимизации не взялись из ниоткуда

Впрочем, поскольку "ошибки" исходного поста устранены в тестах criosray, мы имеем
C++ — 77 секунд
С# — 86 секунд

ЧТД
Re[6]: С# vs C++, голые цифры
От: Хвост  
Дата: 19.05.09 23:02
Оценка:
Здравствуйте, midcyber, Вы писали:

M>Здравствуйте, Хвост, Вы писали:


Х>>надеюсь вы находитесь в трезвом уме и твёрдой памяти и понимаете разницу между "алгоритм был изменён человеком так что исключена его корректная работа" и "в целях оптимизации, код алгоритма не был сгенерирован компилятором"


M>Разницу между "ложью" и "ошибкой", ты хотел сказать? Ключи оптимизации не взялись из ниоткуда


M>Впрочем, поскольку "ошибки" исходного поста устранены в тестах criosray, мы имеем

M>C++ — 77 секунд
M>С# — 86 секунд

M>ЧТД


ето показывает лишь то что MS-компилятор генерит не самый быстрый во вселенной код, кстати скомпилируйте С++ код не с оптимизацией по скорости и с оптимизацией по размеру кода (/O1 у MS-компилятора), результат кого-то удивит.

я думаю что Intel'овский компайлер ничего не выкинул, а честно фигачил 27 секунд бесцельные циклы, а то что он оказался в разы быстрее MS-компилятора — так ето и не удивительно, учитывая что он на порядок дольше компилит.
People write code, programming languages don't.
Re[4]: С# vs C++, голые цифры
От: landerhigh Пират http://www.blinnov.com
Дата: 20.05.09 05:59
Оценка:
Здравствуйте, criosray, Вы писали:

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


L>>>Не "превосходство С++", а превоходство интеловского компилятора перед MS-овским jit-ом.

L>>>Для корректного сравнения компилируйте C++-код MS-компилятором и сравнивайте.

S>>ну я и говорю.

S>>3 секунды под МС компиллер.

Ключевые моменты выделены.
98 секунд на Коре Дуо 2.4

основное время, понятное дело — синус с косинусом.

 Aux a;
    time_t t1, t2;
    time(&t1);
    int b = 0;
    
    for(int i = 0; i < 100; i++)
    {
        a.z = 0;
        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
        {
            for(a.x = -1; a.x < 2; a.x += 0.001)
            {

                b += a.GetColor();
            }
        }

    }
    time(&t2);
    cout << "elapsed: " << difftime(t2, t1) << " seconds.; b = " << b << endl;
www.blinnov.com
Re: С# vs C++, голые цифры
От: NikeByNike Россия  
Дата: 20.05.09 06:13
Оценка:
Здравствуйте, IID, Вы писали:

А почему ты применил даблы, а не флоаты?
Нужно разобрать угил.
Re[2]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 07:05
Оценка:
Здравствуйте, NikeByNike, Вы писали:

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


NBN>А почему ты применил даблы, а не флоаты?


Потому что так было в оригинальном коде.
kalsarikännit
Re[4]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 08:14
Оценка: 2 (1) +1
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Хвост, Вы писали:


C>>>2) самое значимое — так как алгоритм явно элементарно параллелится, то раскидал его на все доступные (их два у меня) ядра процессора с помощью Parallel.For

Х>>а можно узнать результаты теста без Parallel.For? меня терзают смутные сомнения что вы преувеличили лёгкость распараллеливания алгоритма и он у вас просто некорректно работает.

C>Elapsed 00:01:26.8746531


C>86 секунд — то есть примерно на 10-12% медлененнее С++ варианта.


C>На счет Parallel.For Вы правы — работает некорректно. Каюсь, час ночи + спешка — преувеличил легкость распараллеливания.


C>Завтра на свежую голову посмотрю внимательнее как его распараллелить.


Распараллелил. Топорно и наверняка не оптимально, но нет времени на лучшее.

Результат

Elapsed 00:00:45.3581939 sec.
1813065000

Подсчитанно корректно. В полтора раза быстрее С++ варианта без параллелинга, как видим.

Код (как видим я создаю объекты на куче в цикле, что очень не рационально):

...
            Parallel.For(0, 100, i =>
                         {
                             var a = new Aux();
                             int b = 0;

                             for (a.y = -1.5; a.y < 1.5; a.y += 0.001)
                             {
                                 for (a.x = -1; a.x < 2; a.x += 0.001)
                                 {
                                     
                                     b += a.GetColor();
                                 }
                             }

                             spinlock.Enter();
                             x += b;
                             spinlock.Exit();
                         });

            stopWatch.Stop();

            Console.WriteLine("Elapsed {0} sec.", stopWatch.Elapsed);
            Console.WriteLine(x);
Re: С# vs C++, голые цифры
От: frogkiller Россия  
Дата: 20.05.09 08:18
Оценка:
Здравствуйте, IID, Вы писали:

IID>Я привёл код в компилябельное состояние. Вот C# вариант, а вот C++ вариант. Для компиляции использовалась MSVS2008 со всеми обновлениями.


А почему в плюсовом варианте используется си-шный abs() он же вроде как возвращает int. Или в stdfx.h включён ещё и <cmath>?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[5]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 08:30
Оценка: 1 (1) +1
Здравствуйте, criosray, Вы писали:

C>Распараллелил. Топорно и наверняка не оптимально, но нет времени на лучшее.

C>Результат
C>Elapsed 00:00:45.3581939 sec.
C>1813065000
C>Подсчитанно корректно. В полтора раза быстрее С++ варианта без параллелинга, как видим.

ну, продолжим я сегодня выступаю на стороне C++
(cpu: core2 2.4GHz — T7700 два ядра ноутбук 32bit winxp)

изначальный тест показывает 0 секунд на icc (ровно той же версии что и у топикстартера)
(всё собираю из комстроки)

твой вариант с распечаткой результата:
icl -fast test.cpp

test.exe
elapsed: 32 seconds.
1813065000

мой вариант с openmp:

#pragma omp parallel for reduction(+:x)
    for(int i = 0; i < 100; i++)
    {
        a.z = 0;
        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
        {
            for(a.x = -1; a.x < 2; a.x += 0.001)
            {
                x += a.GetColor();
            }
        }

    }


icl -fast -Qopenmp test.cpp

запуск на два потока будет
test.exe
elapsed: 18 seconds.
1813065000

твой ход
Re[2]: С# vs C++, голые цифры
От: frogkiller Россия  
Дата: 20.05.09 08:56
Оценка:
Здравствуйте, frogkiller, Вы писали:

F>А почему в плюсовом варианте используется си-шный abs() он же вроде как возвращает int. Или в stdfx.h включён ещё и <cmath>?


Кстати, в указанном варианте со стандартным abs у меня даже и не скомпилялось, ругнулось на неопределённость перегрузки.

ЗЫ. На моей слабенькой машинке с линуксом и gcc замена <cmath> на <math.h> (и соответсвенно abs на fabs) сократило время работы в дебажной версии с 178 сек до 157 сек, т.е на 12%.
При -O2 времена составили, соответсвенно, 111 сек и 112 сек (т.е. с cmath даже быстрее)
При -O3 времена составили, соответсвенно, 111 сек и 111 сек.

Результат везде: 1813065000
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[6]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 09:37
Оценка:
Здравствуйте, Antikrot, Вы писали:

C>>Распараллелил. Топорно и наверняка не оптимально, но нет времени на лучшее.

C>>Результат
C>>Elapsed 00:00:45.3581939 sec.
C>>1813065000
C>>Подсчитанно корректно. В полтора раза быстрее С++ варианта без параллелинга, как видим.

A>ну, продолжим я сегодня выступаю на стороне C++

A>(cpu: core2 2.4GHz — T7700 два ядра ноутбук 32bit winxp)

A>изначальный тест показывает 0 секунд на icc (ровно той же версии что и у топикстартера)

A>(всё собираю из комстроки)

A>твой вариант с распечаткой результата:

A>icl -fast test.cpp

A>test.exe

A>elapsed: 32 seconds.
A>1813065000

A>мой вариант с openmp:


Хм, не понял, а каким образом лочится состояние объекта а в Вашем варианте?

A>
A>#pragma omp parallel for reduction(+:x)
A>    for(int i = 0; i < 100; i++)
A>    {
A>        a.z = 0;
A>        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
A>        {
A>            for(a.x = -1; a.x < 2; a.x += 0.001)
A>            {
A>                x += a.GetColor();
A>            }
A>        }

A>    }
A>
Re[7]: С# vs C++, голые цифры
От: frogkiller Россия  
Дата: 20.05.09 09:50
Оценка:
Здравствуйте, criosray, Вы писали:

A>>мой вариант с openmp:


A>>
A>>#pragma omp parallel for reduction(+:x)
A>>    for(int i = 0; i < 100; i++)
A>>    {
A>>        a.z = 0;
A>>        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
A>>        {
A>>            for(a.x = -1; a.x < 2; a.x += 0.001)
A>>            {
A>>                x += a.GetColor();
A>>            }
A>>        }

A>>    }
A>>


C>Хм, не понял, а каким образом лочится состояние объекта а в Вашем варианте?


А зачем его лочить? Во внутреннем цикле a.y не изменяется, можно спокойно запускать в нескольких потоках со всеим значением a.y, а потом собрать полученный результат в переменную x.

Интересно было посмотреть, что будет, если суммировать не в переменную на стеке, а в такой же член класса:
a.sum += a.GetColor();

А в сам класс добавить vtable, для запутывания, так сказать Сможет в этом случае компилятор понять, что a.sum так же будет аддитивной?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[7]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 10:16
Оценка:
Здравствуйте, criosray, Вы писали:

C>Хм, не понял, а каким образом лочится состояние объекта а в Вашем варианте?


A>>
A>>#pragma omp parallel for reduction(+:x)
A>>    for(int i = 0; i < 100; i++)
A>>    {
A>>        a.z = 0;
A>>        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
A>>        {
A>>            for(a.x = -1; a.x < 2; a.x += 0.001)
A>>            {
A>>                x += a.GetColor();
A>>            }
A>>        }

A>>    }
A>>


не понял, состояние чего? переменной x? или a? x указан в reduction, так что это проблема openmp, уж позвольте опустить объяснение как оно внутри работает.
что касается a, раз ты его втащил в Parallel.For, так я его буду делать private
#pragma omp parallel for reduction(+:x) private(a)

так он будет свой для каждого потока, и ничего лочить не надо.
Re[8]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 10:23
Оценка:
Здравствуйте, Antikrot, Вы писали:

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


C>>Хм, не понял, а каким образом лочится состояние объекта а в Вашем варианте?


A>>>
A>>>#pragma omp parallel for reduction(+:x)
A>>>    for(int i = 0; i < 100; i++)
A>>>    {
A>>>        a.z = 0;
A>>>        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
A>>>        {
A>>>            for(a.x = -1; a.x < 2; a.x += 0.001)
A>>>            {
A>>>                x += a.GetColor();
A>>>            }
A>>>        }

A>>>    }
A>>>


A>не понял, состояние чего? переменной x? или a?

Я не спрашивал про х. Про х я и так вижу, что там аналог Incremental.Add

A>что касается a, раз ты его втащил в Parallel.For, так я его буду делать private

A>
A>#pragma omp parallel for reduction(+:x) private(a)
A>

A>так он будет свой для каждого потока, и ничего лочить не надо.
Ок, замечательно. А как в предыдущем тесте у Вас получился корректный результат без private(a)? Потрудитесь объяснить. А заодно приведите замеры с исправленным кодом — где добавлено private(a).
Re[8]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 10:30
Оценка:
Здравствуйте, frogkiller, Вы писали:


A>>>мой вариант с openmp:


A>>>
A>>>#pragma omp parallel for reduction(+:x)
A>>>    for(int i = 0; i < 100; i++)
A>>>    {
A>>>        a.z = 0;
A>>>        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
A>>>        {
A>>>            for(a.x = -1; a.x < 2; a.x += 0.001)
A>>>            {
A>>>                x += a.GetColor();
A>>>            }
A>>>        }

A>>>    }
A>>>


C>>Хм, не понял, а каким образом лочится состояние объекта а в Вашем варианте?


F>А зачем его лочить? Во внутреннем цикле a.y не изменяется, можно спокойно запускать в нескольких потоках со всеим значением a.y, а потом собрать полученный результат в переменную x.


Потому, что параллелится внешний цикл.

Поток 1: вызывает a.GetColor со значениями a.y = -1.5, a.x = -1
Поток 1: Golova() возвращает false
Поток 1: предположим, Spiral() должен был бы вернуть true, но ДО того, как он будет вызван:
Поток 2 перезаписывае a.y и a.x соответствующими инкрементами!
Поток 1: Spiral() возвращает false и объект а теперь в таком состоянии, что только Golova вернула бы true — все проверки возвращают false, GetColor — возвращает 0.


F>Интересно было посмотреть, что будет, если суммировать не в переменную на стеке, а в такой же член класса:

F>
a.sum += a.GetColor();

F>А в сам класс добавить vtable, для запутывания, так сказать Сможет в этом случае компилятор понять, что a.sum так же будет аддитивной?
Хороший вопрос...
Re[9]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 10:54
Оценка:
Здравствуйте, criosray, Вы писали:

F>>Интересно было посмотреть, что будет, если суммировать не в переменную на стеке, а в такой же член класса:

F>>
a.sum += a.GetColor();

F>>А в сам класс добавить vtable, для запутывания, так сказать Сможет в этом случае компилятор понять, что a.sum так же будет аддитивной?
C>Хороший вопрос...
всё конечно интересно, но компилятор ничего не понимает, ему явно указано что аддитивное. да и указать a.sum в reduction как-то не получается...
лочить же a.sum += a.GetColor() с помощью omp critical сильно всё затормаживает (у меня почти в восемь раз)
Re[9]: С# vs C++, голые цифры
От: frogkiller Россия  
Дата: 20.05.09 10:54
Оценка:
Здравствуйте, criosray, Вы писали:


C>>>Хм, не понял, а каким образом лочится состояние объекта а в Вашем варианте?


F>>А зачем его лочить? Во внутреннем цикле a.y не изменяется, можно спокойно запускать в нескольких потоках со всеим значением a.y, а потом собрать полученный результат в переменную x.


C>Потому, что параллелится внешний цикл.


C>Поток 1: вызывает a.GetColor со значениями a.y = -1.5, a.x = -1

C>Поток 1: Golova() возвращает false
C>Поток 1: предположим, Spiral() должен был бы вернуть true, но ДО того, как он будет вызван:
C>Поток 2 перезаписывае a.y и a.x соответствующими инкрементами!
C>Поток 1: Spiral() возвращает false и объект а теперь в таком состоянии, что только Golova вернула бы true — все проверки возвращают false, GetColor — возвращает 0.

Это всё понятно. Я к тому, что нужно не лочить, а создавать копию. Более корректным было бы описать методы класса Aux как константные, но тут компилятор сам об этом догадался.


F>>Интересно было посмотреть, что будет, если суммировать не в переменную на стеке, а в такой же член класса:

F>>
a.sum += a.GetColor();

F>>А в сам класс добавить vtable, для запутывания, так сказать Сможет в этом случае компилятор понять, что a.sum так же будет аддитивной?
C>Хороший вопрос...

Подозреваю, что без помощи в виде явной спецификации константных методов не обойтись. Но проверить ме могу, под рукой только gcc, да и он не самый новый.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[3]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 10:57
Оценка:
Здравствуйте, frogkiller, Вы писали:

F>ЗЫ. На моей слабенькой машинке с линуксом и gcc замена <cmath> на <math.h> (и соответсвенно abs на fabs) сократило время работы в дебажной версии с 178 сек до 157 сек, т.е на 12%.


Видимо библиотечная функция кривая... ABS в представлении с плавающей точкой это всего лишь безусловный сброс старшего бита, тормозить там (алгоритмически) нечему. Даже целочисленный ABS тормознее (условный NEG), если не реализован в железе.
kalsarikännit
Re[4]: С# vs C++, голые цифры
От: frogkiller Россия  
Дата: 20.05.09 11:05
Оценка:
Здравствуйте, IID, Вы писали:

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


F>>ЗЫ. На моей слабенькой машинке с линуксом и gcc замена <cmath> на <math.h> (и соответсвенно abs на fabs) сократило время работы в дебажной версии с 178 сек до 157 сек, т.е на 12%.


IID>Видимо библиотечная функция кривая... ABS в представлении с плавающей точкой это всего лишь безусловный сброс старшего бита, тормозить там (алгоритмически) нечему. Даже целочисленный ABS тормознее (условный NEG), если не реализован в железе.


Ну, помимо abs там ещё поменялись, очевидно, и всякие cos/sin
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[10]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 11:11
Оценка:
Здравствуйте, frogkiller, Вы писали:


F>Это всё понятно. Я к тому, что нужно не лочить, а создавать копию.

Да, я именно это подразумевал.

Еще десять минут на оптимизацию и с 45 сек уменьшил время до 32 сек:


        private bool Strokes()
        {
            return (Math.Abs(0.5 - x) < 0.02
                    || (x > 0.5 && Math.Abs(ZzzFunc()) < 0.005))
                   /* && !Spiral() && !Golova() */;
        }

        private bool Wall()
        {
            return x > 0.5 /* && !Strokes() && !Spiral() */;
        }

        public int GetColor()
        {
            if (Spiral())
            {
                return 2;
            }

            if (Golova())
            {
                return 1;
            }

            if (Strokes())
            {
                return 3;
            }

            if (Wall())
            {
                return 4;
            }
            
            return 0;
        }
Re[11]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 11:23
Оценка: :)
Здравствуйте, criosray, Вы писали:

C>Еще десять минут на оптимизацию и с 45 сек уменьшил время до 32 сек:



C>
C>        private bool Strokes()
C>        {
C>            return (Math.Abs(0.5 - x) < 0.02
C>                    || (x > 0.5 && Math.Abs(ZzzFunc()) < 0.005))
C>                   /* && !Spiral() && !Golova() */;
C>        }
C>


Это что ещё за самодеятельность ?

C>
C>        private bool Wall()
C>        {
C>            return x > 0.5 /* && !Strokes() && !Spiral() */;
C>        }
C>


и тут

C>
C>        public int GetColor()
C>        {
C>            if (Spiral())
C>            {
C>                return 2;
C>            }

...skip... 

C>            return 0;
C>        }
C>


А вот это — всегда пожалуйста. Только удивительно что компилятор C# такое не осиливает, если это правда дало какой-то выигрыш.
Попытки упростить вычисления не годятся. Мы ведь можем и поменять пределы изменения пары x,y. И "упрощённый" код станет давать неверные варианты. (В суть закомментированного лень вчитываться, но этот код явно влияет на результат)
kalsarikännit
Re[12]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 11:38
Оценка:
Здравствуйте, IID, Вы писали:

IID>А вот это — всегда пожалуйста. Только удивительно что компилятор C# такое не осиливает, если это правда дало какой-то выигрыш.


Компиллятор не обладает интеллектом человека. Впрочем, Вы не сильно далеко ушли, раз написали это:

IID>Попытки упростить вычисления не годятся. Мы ведь можем и поменять пределы изменения пары x,y. И "упрощённый" код станет давать неверные варианты. (В суть закомментированного лень вчитываться, но этот код явно влияет на результат)


А вот Вы вчитайтесь. Может и поймете почему оптимизированный мною вариант будет давать идентичный неоптимизированному результат на любом наборе входных данных.
Re[9]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 11:41
Оценка:
Здравствуйте, criosray, Вы писали:

A>>что касается a, раз ты его втащил в Parallel.For, так я его буду делать private

A>>
A>>#pragma omp parallel for reduction(+:x) private(a)
A>>

A>>так он будет свой для каждого потока, и ничего лочить не надо.
C>Ок, замечательно. А как в предыдущем тесте у Вас получился корректный результат без private(a)? Потрудитесь объяснить.
если нет возражений, вечером попробую объяснить (сейчас по уши в линуксе сижу)

C>А заодно приведите замеры с исправленным кодом — где добавлено private(a).

те же 18 секунд. на самом деле, разницы-то — дважды скопировать объект с тремя полями (не в циклах).

было бы еще интересно на кваде проверить опенмпишный вариант
Re[10]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 11:59
Оценка:
Здравствуйте, Antikrot, Вы писали:


A>>>что касается a, раз ты его втащил в Parallel.For, так я его буду делать private

A>>>
A>>>#pragma omp parallel for reduction(+:x) private(a)
A>>>

A>>>так он будет свой для каждого потока, и ничего лочить не надо.
C>>Ок, замечательно. А как в предыдущем тесте у Вас получился корректный результат без private(a)? Потрудитесь объяснить.
A>если нет возражений, вечером попробую объяснить (сейчас по уши в линуксе сижу)

Какие могут быть возражения...

Ок, включил OMP, полную оптимизацию, поотключал всякие проверки, включил оптимизацию под SSE и т.д.
Вариант с
#pragma omp parallel for reduction(+:x) private(a)

отработал за 18 сек.

Теперь проведу те же оптимизации, что и в дотнет варианте
....

13 секунд.

Что ж, неплохо. Выявили узкое место, собрали dll`ку, подцепили ее к менеджед проекту и все пучком.
Re[13]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 12:00
Оценка:
Здравствуйте, criosray, Вы писали:

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


IID>>А вот это — всегда пожалуйста. Только удивительно что компилятор C# такое не осиливает, если это правда дало какой-то выигрыш.


C>Компиллятор не обладает интеллектом человека.

С++ компилятор прекрасно справляется с тривиальной задачей заменить switch на if. И с переставлением вызовов местами — тоже (смотри внимательно ключи компиляции в первом посте). Так что не надо тут оправдывать убогость C# оптимизатора.

C>Впрочем, Вы не сильно далеко ушли, раз написали это:

Переход на личности и нарушение правил форума.

IID>>Попытки упростить вычисления не годятся. Мы ведь можем и поменять пределы изменения пары x,y. И "упрощённый" код станет давать неверные варианты. (В суть закомментированного лень вчитываться, но этот код явно влияет на результат)


C>А вот Вы вчитайтесь. Может и поймете почему оптимизированный мною вариант будет давать идентичный неоптимизированному результат на любом наборе входных данных.

Обязательно. Но позже. И горе тебе, если окажется что закомментированные функции влияют на результат для других диапазонов (x,y)
kalsarikännit
Re[10]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 12:02
Оценка:
Здравствуйте, Antikrot, Вы писали:

A>было бы еще интересно на кваде проверить опенмпишный вариант


Вечером заценю на домашнем Q6600. И опенмпшный, и сишарповский
kalsarikännit
Re[10]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 12:04
Оценка:
Здравствуйте, Antikrot, Вы писали:

A>если нет возражений, вечером попробую объяснить (сейчас по уши в линуксе сижу)


А вот вариант без private(a) дает некорректный результат (что вполне ожидаемо)
elapsed: 22 seconds.
1679567250

Еще и дольше отрабатывает...
Re[14]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 12:08
Оценка: -1
Здравствуйте, IID, Вы писали:

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


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


IID>>>А вот это — всегда пожалуйста. Только удивительно что компилятор C# такое не осиливает, если это правда дало какой-то выигрыш.


C>>Компиллятор не обладает интеллектом человека.

IID>С++ компилятор прекрасно справляется с тривиальной задачей заменить switch на if. И с переставлением вызовов местами — тоже (смотри внимательно ключи компиляции в первом посте). Так что не надо тут оправдывать убогость C# оптимизатора.

Не справляется. Ни один компилятор не догадается, что Spiral будет возвращать true значительно чаще, чем Golova.

Так что оставьте свои фантазии при себе, ок.

IID>>>Попытки упростить вычисления не годятся. Мы ведь можем и поменять пределы изменения пары x,y. И "упрощённый" код станет давать неверные варианты. (В суть закомментированного лень вчитываться, но этот код явно влияет на результат)


C>>А вот Вы вчитайтесь. Может и поймете почему оптимизированный мною вариант будет давать идентичный неоптимизированному результат на любом наборе входных данных.

IID>Обязательно. Но позже. И горе тебе, если окажется что закомментированные функции влияют на результат для других диапазонов (x,y)

Горе Вам, что Вы лезете на форум и пишете всякую чушь вместо того, чтоб потратить 2 минуты и вчитаться в код.
Re[15]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 12:11
Оценка: +2 -1
Здравствуйте, criosray, Вы писали:

C>Не справляется. Ни один компилятор не догадается, что Spiral будет возвращать true значительно чаще, чем Golova.

C>Так что оставьте свои фантазии при себе, ок.

Подсказываю: ключ /Qprof_use. В этом режиме требуется две компиляции фазы-1, в которых код иструментируется. С последующими прогонами. На основании полученных данных в фазе-2 собирается окончательный вариант.
kalsarikännit
Re[16]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 12:21
Оценка: -1
Здравствуйте, IID, Вы писали:


C>>Не справляется. Ни один компилятор не догадается, что Spiral будет возвращать true значительно чаще, чем Golova.

C>>Так что оставьте свои фантазии при себе, ок.

IID>Подсказываю: ключ /Qprof_use. В этом режиме требуется две компиляции фазы-1, в которых код иструментируется. С последующими прогонами. На основании полученных данных в фазе-2 собирается окончательный вариант.


Н-да. Ну проверьте. Увидите сами.
Re[17]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 12:43
Оценка:
Здравствуйте, criosray, Вы писали:

IID>>Подсказываю: ключ /Qprof_use. В этом режиме требуется две компиляции фазы-1, в которых код иструментируется. С последующими прогонами. На основании полученных данных в фазе-2 собирается окончательный вариант.

C>Н-да. Ну проверьте. Увидите сами.

хотелось бы знать, на чем основан такой вывод. Проверяли?
Re[4]: С# vs C++, голые цифры
От: NikeByNike Россия  
Дата: 20.05.09 13:00
Оценка:
Здравствуйте, IID, Вы писали:

IID>Видимо библиотечная функция кривая... ABS в представлении с плавающей точкой это всего лишь безусловный сброс старшего бита,

Это невыгодная операция. Тебе нужно из fpu перегнать переменную в cpu, а потом обратно. На этот случай есть fpu-шная версия abs.
Нужно разобрать угил.
Re[5]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 13:20
Оценка:
Здравствуйте, NikeByNike, Вы писали:


IID>>Видимо библиотечная функция кривая... ABS в представлении с плавающей точкой это всего лишь безусловный сброс старшего бита,

NBN>Это невыгодная операция. Тебе нужно из fpu перегнать переменную в cpu, а потом обратно. На этот случай есть fpu-шная версия abs.

Выгодно, не выгодно... тоже мне теоретики. Замена abs на fabs привела к увеличению времени с 11 сек до 12 сек.
Re[14]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.05.09 13:28
Оценка: +1
Здравствуйте, IID, Вы писали:

IID>Так что не надо тут оправдывать убогость C# оптимизатора.

Смешной ты парень. В компиляторе C# вообще нету оптимизатора. Компилятор один-в-один преобразует исходник на C# в IL, так что обратный процесс вполне возможен. JIT в свою очередь не занимается такими хардкорными оптимизациями, как помилятор С++, у него времени нету.

Есдинственное что ты доказал своим постом, что оптимизаторы современных компиляторов C++ лучше JITа работают. Но это вроде и так все знают.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[15]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 13:58
Оценка: :)
Здравствуйте, gandjustas, Вы писали:



IID>>Так что не надо тут оправдывать убогость C# оптимизатора.

G>Смешной ты парень. В компиляторе C# вообще нету оптимизатора. Компилятор один-в-один преобразует исходник на C# в IL, так что обратный процесс вполне возможен. JIT в свою очередь не занимается такими хардкорными оптимизациями, как помилятор С++, у него времени нету.

G>Есдинственное что ты доказал своим постом, что оптимизаторы современных компиляторов C++ лучше JITа работают. Но это вроде и так все знают.


Да и к тому же там, где программа на С# заработает без перекомпиляции, программа на С++, собранная с использованием инструкций SSE3, например, попросту не заведется на более старых процессорах.
Re[16]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 14:07
Оценка: +2
Здравствуйте, criosray, Вы писали:

C>Да и к тому же там, где программа на С# заработает без перекомпиляции, программа на С++, собранная с использованием инструкций SSE3, например, попросту не заведется на более старых процессорах.


ну это как собрать... можно например с /QaxSSE3 (для icl), всё заведется
Re[6]: С# vs C++, голые цифры
От: NikeByNike Россия  
Дата: 20.05.09 14:09
Оценка:
Здравствуйте, criosray, Вы писали:

IID>>>Видимо библиотечная функция кривая... ABS в представлении с плавающей точкой это всего лишь безусловный сброс старшего бита,

NBN>>Это невыгодная операция. Тебе нужно из fpu перегнать переменную в cpu, а потом обратно. На этот случай есть fpu-шная версия abs.

C>Выгодно, не выгодно... тоже мне теоретики. Замена abs на fabs привела к увеличению времени с 11 сек до 12 сек.


Ты не понимаешь о чём говоришь Сначала попробовал бы посмотреть дизасм
Я молчу про измерение времени выполнения этого теста в секундах! И уж тем более однократное.
Нужно разобрать угил.
Re[7]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 14:25
Оценка: +1
Здравствуйте, NikeByNike, Вы писали:

NBN>Я молчу про измерение времени выполнения этого теста в секундах!


А вот тут ты не совсем прав, асимптотику прекрасно видно, +- секунда погоды не делает.
kalsarikännit
Re[17]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 14:45
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>Н-да. Ну проверьте. Увидите сами.


Читайте доки, они рулез. (тыкаю пальцем: Profile-Guided Optimization)
kalsarikännit
Re[18]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 14:58
Оценка: -4 :))
Здравствуйте, IID, Вы писали:

C>>Н-да. Ну проверьте. Увидите сами.


IID>Читайте доки, они рулез. (тыкаю пальцем: Profile-Guided Optimization)


Месье — теоретик? Доки эти я читал за долго до того, как Вы программированием занялись. И знаю всяко лучше Вашего, что этой оптимизации компиллятор не сделает. Не верите — проверьте и убедитесь.
Re[7]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 15:00
Оценка: -2 :)
Здравствуйте, NikeByNike, Вы писали:


IID>>>>Видимо библиотечная функция кривая... ABS в представлении с плавающей точкой это всего лишь безусловный сброс старшего бита,

NBN>>>Это невыгодная операция. Тебе нужно из fpu перегнать переменную в cpu, а потом обратно. На этот случай есть fpu-шная версия abs.

C>>Выгодно, не выгодно... тоже мне теоретики. Замена abs на fabs привела к увеличению времени с 11 сек до 12 сек.


NBN>Ты не понимаешь о чём говоришь Сначала попробовал бы посмотреть дизасм

NBN>Я молчу про измерение времени выполнения этого теста в секундах! И уж тем более однократное.

Что мне смотреть дизассемблером, если я вижу, что время выполнения ухудшилась?

Вам и господину IID надо поменьше заниматься теорией и по больше практикой, чтоб не писать такой чуши.
Re[8]: С# vs C++, голые цифры
От: NikeByNike Россия  
Дата: 20.05.09 15:13
Оценка: -1
Здравствуйте, criosray, Вы писали:

NBN>>Я молчу про измерение времени выполнения этого теста в секундах! И уж тем более однократное.


C>Что мне смотреть дизассемблером,

А ты не посмотрел, что это одна и та же функция?

C>если я вижу, что время выполнения ухудшилась?

Имел бы практический опыт — знал бы что синтетические тесты имею мало смысла, тем более в такой примитивной реализации.

C>Вам и господину IID надо поменьше заниматься теорией и по больше практикой, чтоб не писать такой чуши.

(С) Я матлибами занимался ещё до того как ты программировать начал
Нужно разобрать угил.
Re[9]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 15:19
Оценка:
Здравствуйте, NikeByNike, Вы писали:

C>>Вам и господину IID надо поменьше заниматься теорией и по больше практикой, чтоб не писать такой чуши.

NBN>(С) Я матлибами занимался ещё до того как ты программировать начал

Очень рад, что Вы не работаете в моей команде. Если человек не понимает элементарной оптимизации и называет это "упрощением вычислений с некорректными результатами" или с умным видом предлагает заменить abs на fabs, когда это не имеет ровным счетом никакой практической пользы.

Re[10]: С# vs C++, голые цифры
От: NikeByNike Россия  
Дата: 20.05.09 18:49
Оценка: +2
Здравствуйте, criosray, Вы писали:

C>Очень рад, что Вы не работаете в моей команде.

Я тоже

C>Если человек не понимает элементарной оптимизации

Замещение фпу-шных abs логикой — была уместна лет 6-7 назад. Однако с тех пор оно стало антиоптимизацией.

C>и называет это "упрощением вычислений с некорректными результатами"

Ты читать-то сначала научись, а потом с мнением лезь

C>или с умным видом предлагает заменить abs на fabs

Ты уже о себе в третьем лице начал говорить?

C>когда это не имеет ровным счетом никакой практической пользы.

Ещё бы, грамотный программист знает, что с некоторых пор это одна и та же функция

C>

Ага, может прекратишь пургу гнать?
Нужно разобрать угил.
Re[19]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 21:08
Оценка: 11 (7) +1
Здравствуйте, criosray, Вы писали:

C>Месье — теоретик? Доки эти я читал за долго до того, как Вы программированием занялись. И знаю всяко лучше Вашего, что этой оптимизации компиллятор не сделает. Не верите — проверьте и убедитесь.


раз ВАм практика интересна

вот ВАши слова:

Не справляется. Ни один компилятор не догадается, что Spiral будет возвращать true значительно чаще, чем Golova.


а теперь немного ассемблера, я уверен все в этой теме его знают
0. будем выключать инлайнер — -Ob0, чтобы легче искать нужные функции в листинге. кроме того, я убрал из листинга Wall() и Strokes() и return 0 и соответствующий код, будем сравнивать Spiral и Golova

1. простой случай
icl -fast -Qopenmp -FAs -Ob0 test.cpp


?GetColor@Aux@@QAEIXZ    PROC NEAR PRIVATE
.B2.1:                          ; Preds .B2.0
;;;     {
        push      ebx                                           ;52.5
        sub       esp, 8                                        ;52.5
        mov       ebx, ecx                                      ;52.5
;;;         if ( Golova() ) return 1;
        call      ?Golova@Aux@@QAE_NXZ                          ;53.14
                                ; LOE eax ebx ebp esi edi
.B2.12:                         ; Preds .B2.1
        movzx     eax, al                                       ;53.14
        test      eax, eax                                      ;53.14
        je        .B2.3         ; Prob 43%                      ;53.14
                                ; LOE ebx ebp esi edi
.B2.2:                          ; Preds .B2.12
        mov       eax, 1                                        ;53.32
        add       esp, 8                                        ;53.32
        pop       ebx                                           ;53.32
        ret                                                     ;53.32
                                ; LOE
.B2.3:                          ; Preds .B2.12
;;;         if ( Spiral() ) return 2;
        mov       ecx, ebx                                      ;54.14
        call      ?Spiral@Aux@@QAE_NXZ                          ;54.14
                                ; LOE eax ebx ebp esi edi
.B2.13:                         ; Preds .B2.3
        movzx     eax, al                                       ;54.14
        test      eax, eax                                      ;54.14
        je        .B2.5         ; Prob 43%                      ;54.14
                                ; LOE ebx ebp esi edi
.B2.4:                          ; Preds .B2.13
        mov       eax, 2                                        ;54.32
        add       esp, 8                                        ;54.32
        pop       ebx                                           ;54.32
        ret                                                     ;54.32



прошу обратить внимание на комментарий компилятора "Prob 43%", означающий как раз вероятность того что вызов Golova() или Spiral() вернул false.
В примере выше вероятность в обоих случаях 43%, то есть компилятор действительно не знает какой вызов что чаще возвращает.

а теперь перейдем к другим баранам, а точнее к упомянутой profile guided optimization:

2. сложный случай
icl -fast -Qopenmp -Qprof-gen test.cpp
test.exe
icl -fast -Qopenmp -FAs -Qprof-use test.cpp


?GetColor@Aux@@QAEIXZ    PROC NEAR PRIVATE
; parameter 1: ecx
.B2.1:            ; 897169792   ; Preds .B2.0
;;;     {

        push      edi                                           ;52.5
        sub       esp, 8                                        ;52.5
        mov       edi, ecx                                      ;52.5
;;;         if ( Golova() ) return 1;
        call      ?Golova@Aux@@QAE_NXZ                          ;53.14
                                ; LOE eax ebx ebp esi edi
.B2.12:           ; 897169792   ; Preds .B2.1
        movzx     eax, al                                       ;53.14
        test      eax, eax                                      ;53.14
        jne       .B2.9         ; Prob 16%                      ;53.14
                                ; LOE ebx ebp esi edi
.B2.2:            ; 750015232   ; Preds .B2.12
;;;         if ( Spiral() ) return 2;
        mov       ecx, edi                                      ;54.14
        call      ?Spiral@Aux@@QAE_NXZ                          ;54.14
                                ; LOE eax ebx ebp esi edi
.B2.13:           ; 750015232   ; Preds .B2.2
        movzx     eax, al                                       ;54.14
        test      eax, eax                                      ;54.14
        jne       .B2.8         ; Prob 21%                      ;54.14
                                ; LOE ebx ebp esi edi
.B2.3:            ; 592994496   ; Preds .B2.13



Оп-па! Вот тут уже интересней — вероятности уже другие! Причем разные. То есть:
а) компилятор знает какая функция вызывается чаще
б) что она чаще возвращает

и таки да, Spiral возвращает true чаще, чем Golova

количество вызовов функций Golova(), Spiral() и т.д., полученное из данных профилировки — можно посмотреть в optimization report (-Qopt-report и сопутствующие ключики) и убедится, что компилятор это знает.

Теперь про оптимизацию. Заметили, что в первом примере использовалась команда je, а во втором jne? вот это она и есть, оптимизация (до перестановки вызовов не дошло кстати). компилятор, сообразив что скорее всего получит false, решил поставить jne, в таком случае наиболее вероятно что переход не произойдёт (не будет сразу же выполнен return 4/3/2/1, а пойдет звать другие функции) и не будет сброса конвейера.

Всё это прямо противоречит твоему утверждению, которое я процитировал в начале этого сообщения.
Re[11]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 21:11
Оценка: 2 (1)
Здравствуйте, IID, Вы писали:

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


A>>было бы еще интересно на кваде проверить опенмпишный вариант


IID>Вечером заценю на домашнем Q6600. И опенмпшный, и сишарповский


Заценил.

SpeedTestCpp.exe
elapsed: 9.908 seconds. b=1813065000


Честно попытался запустить C# вариант с Parallel.For, но замучался. По дефолту 2008-ая этого не умеет. Скачал и установил ParallelExtensions_Jun08CTP.msi Всё равно неймспейс System.Threading.Concurrency, как и System.Concurrency неизвестен. А т.к. в шарпе я не большой спец — забил.

Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.
kalsarikännit
Re[12]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 20.05.09 21:17
Оценка:
Здравствуйте, IID, Вы писали:

IID>Честно попытался запустить C# вариант с Parallel.For, но замучался. По дефолту 2008-ая этого не умеет. Скачал и установил ParallelExtensions_Jun08CTP.msi Всё равно неймспейс System.Threading.Concurrency, как и System.Concurrency неизвестен. А т.к. в шарпе я не большой спец — забил.

IID>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.
Как-то нечестно, не находишь?
Re[12]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 21:19
Оценка:
Здравствуйте, IID, Вы писали:

IID>>Вечером заценю на домашнем Q6600. И опенмпшный, и сишарповский

IID>Заценил.
IID>

IID>SpeedTestCpp.exe
IID>elapsed: 9.908 seconds. b=1813065000


отлично, все как надо. абсолютно масштабируемая программа (итерации внешнего цикла-то независимые)
у меня было 18 с чем-то секунд на 2х ядрах по 2.4GHz, у тебя 9 на четырех таких же

IID>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.

видел бы это Шеридан
Re[13]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 21:23
Оценка:
Здравствуйте, MxKazan, Вы писали:

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


IID>>Честно попытался запустить C# вариант с Parallel.For, но замучался. По дефолту 2008-ая этого не умеет. Скачал и установил ParallelExtensions_Jun08CTP.msi Всё равно неймспейс System.Threading.Concurrency, как и System.Concurrency неизвестен. А т.к. в шарпе я не большой спец — забил.

IID>>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.
MK>Как-то нечестно, не находишь?

Расскажите как этот CTP включить — замеряю. Да и юзать CTP ещё более нечестно, вообще-то. В intel'e что openmp что GPO не являются tech preview фичами.
kalsarikännit
Re[14]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 20.05.09 21:34
Оценка:
Здравствуйте, IID, Вы писали:

IID>Расскажите как этот CTP включить — замеряю.

Reference на сборки то добавил? В любом случае раз не можешь замерить, так и не нужно делать выводы.
Re[15]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 21:39
Оценка:
Здравствуйте, MxKazan, Вы писали:

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


IID>>Расскажите как этот CTP включить — замеряю.

MK>Reference на сборки то добавил?
делаю Add Reference на проекте. На вкладке .NET громадный список сборок(?). Ничего похожего на ParallelExtensions/TPL/PLINQ там нет. ЧЯДНТ ? Желательно понятным языком расписать и по шагам.

MK>В любом случае раз не можешь замерить, так и не нужно делать выводы.

Это не штатная фича .NET платформы. Измерять её уже сомнительная затея. Но я готов идти навстречу.
kalsarikännit
Re[16]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 21:53
Оценка:
Здравствуйте, IID, Вы писали:

IID>>>Расскажите как этот CTP включить — замеряю.

MK>>Reference на сборки то добавил?
IID>делаю Add Reference на проекте. На вкладке .NET громадный список сборок(?). Ничего похожего на ParallelExtensions/TPL/PLINQ там нет. ЧЯДНТ ? Желательно понятным языком расписать и по шагам.

Сборка называется System.Threading

MK>>В любом случае раз не можешь замерить, так и не нужно делать выводы.

IID>Это не штатная фича .NET платформы. Измерять её уже сомнительная затея. Но я готов идти навстречу.

Это штатная фича дотнет начиная с 4.0. А пока можно скачать абсолютно рабочий CTP.
Re[14]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 21:55
Оценка: :)
Здравствуйте, IID, Вы писали:


IID>>>Честно попытался запустить C# вариант с Parallel.For, но замучался. По дефолту 2008-ая этого не умеет. Скачал и установил ParallelExtensions_Jun08CTP.msi Всё равно неймспейс System.Threading.Concurrency, как и System.Concurrency неизвестен. А т.к. в шарпе я не большой спец — забил.

IID>>>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.
MK>>Как-то нечестно, не находишь?

IID>Расскажите как этот CTP включить — замеряю. Да и юзать CTP ещё более нечестно, вообще-то. В intel'e что openmp что GPO не являются tech preview фичами.


Честно-нечестно... что за детский сад? У нас ParallelFx успешно применяется в одном из последних проектов.
Re[12]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 21:59
Оценка:
Здравствуйте, IID, Вы писали:

IID>Честно попытался запустить C# вариант с Parallel.For, но замучался. По дефолту 2008-ая этого не умеет. Скачал и установил ParallelExtensions_Jun08CTP.msi Всё равно неймспейс System.Threading.Concurrency, как и System.Concurrency неизвестен. А т.к. в шарпе я не большой спец — забил.


IID>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.


У Вас туго с арифметикой?
На двух ядрах дотнет вариант отрабатывает за 35 сек. Соответственно на 4х будет не больше 20 сек — то есть 100% от силы.
Re[16]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 20.05.09 21:59
Оценка: 1 (1)
Здравствуйте, IID, Вы писали:

IID>>>Расскажите как этот CTP включить — замеряю.

MK>>Reference на сборки то добавил?
IID>делаю Add Reference на проекте. На вкладке .NET громадный список сборок(?). Ничего похожего на ParallelExtensions/TPL/PLINQ там нет. ЧЯДНТ ? Желательно понятным языком расписать и по шагам.
Добавляешь Reference на System.Threading.dll
В коде юзаешь пространство имен System.Threading
parallel extensions to .net framework 3.5
Re[20]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 22:02
Оценка: +1
Здравствуйте, Antikrot, Вы писали:


A>Оп-па! Вот тут уже интересней — вероятности уже другие! Причем разные. То есть:

A>а) компилятор знает какая функция вызывается чаще
A>б) что она чаще возвращает

A>и таки да, Spiral возвращает true чаще, чем Golova


Принято. На счет этого был не прав.
Re[13]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 20.05.09 22:02
Оценка:
Здравствуйте, criosray, Вы писали:

C>У Вас туго с арифметикой?

C>На двух ядрах дотнет вариант отрабатывает за 35 сек. Соответственно на 4х будет не больше 20 сек — то есть 100% от силы.
Не, давай по нормальному сравнивать. В каком постинге написано про 35 сек и какой конфиг (железо) использовался?
Re[11]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 22:07
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Ок, замечательно. А как в предыдущем тесте у Вас получился корректный результат без private(a)? Потрудитесь объяснить.

A>>если нет возражений, вечером попробую объяснить (сейчас по уши в линуксе сижу)
C>Какие могут быть возражения...
ок, попробую на словах предположить почему у меня все правильно получилось при неправильном в принципе коде. это только мое предположение, никак не претендующее на истину в последней инстанции. не сверялось ни с репортами компилятора, ни с ассемблерным кодом (точнее, с кодом сверял, очень похоже на моё предположение, но конкретно показать не могу — кода немало).


#pragma omp parallel for reduction(+:x)
    for(int i = 0; i < 100; i++)
    {
        a.z = 0;
        for(a.y = -1.5; a.y < 1.5; a.y += 0.001)
        {
            for(a.x = -1; a.x < 2; a.x += 0.001)
            {
                x += a.GetColor();
            }
        }

    }


на самом деле, что у нас есть состояние объекта "а"? всего лишь три поля .x, .y и .z. причем .z всегда 0. остается два поля, GetColor внутри себя состояние объекта не меняет, стало быть загоняем перед внешним циклом a.x и a.y в регистры до конца цикла (то есть фактически они становятся локальными для потока; а потом вообще никуда не сохраняем), и совершенно пофигу, что там будут делать другие потоки — в наши регистры они не влезут (то есть один поток не поменяет объект "a" другому, и ничего делать private тут и не надо). но это всё очень зависит от оптимизатора, сделает лишние чтение/запись в память (например, регистров не хватило) — и всё, приплыли.


C>Что ж, неплохо. Выявили узкое место, собрали dll`ку, подцепили ее к менеджед проекту и все пучком.

+1, очень подходящая причина делать части проекта на разных языках, подкрепленная цифрами
Re[14]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 22:18
Оценка: 2 (1)
Здравствуйте, MxKazan, Вы писали:

C>>У Вас туго с арифметикой?

C>>На двух ядрах дотнет вариант отрабатывает за 35 сек. Соответственно на 4х будет не больше 20 сек — то есть 100% от силы.
MK>Не, давай по нормальному сравнивать. В каком постинге написано про 35 сек и какой конфиг (железо) использовался?
В одном из моих конечно:
http://rsdn.ru/forum/Default.aspx?mid=3397236&amp;flat=0
Автор: criosray
Дата: 20.05.09


Только не 35, а 32. Но важен порядок.

Процессор Core2Duo 3GHz

Цифру в 20 сек я вывел тупой в лоб линейной экстраполляцией, конечно. Реально наверно ближе к 16 будет.
Re[12]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 22:23
Оценка: :)
Здравствуйте, Antikrot, Вы писали:

A>
A>#pragma omp parallel for reduction(+:x)
...
A>


A>на самом деле, что у нас есть состояние объекта "а"? всего лишь три поля .x, .y и .z. причем .z всегда 0. остается два поля, GetColor внутри себя состояние объекта не меняет, стало быть загоняем перед внешним циклом a.x и a.y в регистры до конца цикла (то есть фактически они становятся локальными для потока; а потом вообще никуда не сохраняем), и совершенно пофигу, что там будут делать другие потоки — в наши регистры они не влезут (то есть один поток не поменяет объект "a" другому, и ничего делать private тут и не надо). но это всё очень зависит от оптимизатора, сделает лишние чтение/запись в память (например, регистров не хватило) — и всё, приплыли.


И что, Вы запускаете и каждый раз выдает корректный результат?

А можно экзешник где-нибудь выложить?
Re[17]: С# vs C++, голые цифры
От: IID Россия  
Дата: 20.05.09 22:27
Оценка: 2 (1) +1
Здравствуйте, MxKazan, Вы писали:

MK>Добавляешь Reference на System.Threading.dll

MK>В коде юзаешь пространство имен System.Threading

Спасибо, всё собралось. При исполнении все ядра загружены на 100%

Elapsed 00:00:35.7776257 sec.


Таким образом разрыв сокращается до 361%
kalsarikännit
Re[18]: С# vs C++, голые цифры
От: criosray  
Дата: 20.05.09 22:39
Оценка:
Здравствуйте, IID, Вы писали:

IID>Таким образом разрыв сокращается до 361%


Да, но дотнет вариант менее оптимальный алгоритмически в виду того, что в С++ создается по одному объекту Aux на поток благодаря private(a) директиве, а в дотнет я вписал хак с созданием нового объекта на каждом из 100 итераций цикла.

У Parallel.For есть возможность использовать специальный thread local дженерик объект, но я еще не разбирался с этим. Как появится время обязательно разберусь, и отпишусь.
Re[13]: С# vs C++, голые цифры
От: Antikrot  
Дата: 20.05.09 22:42
Оценка:
Здравствуйте, criosray, Вы писали:

A>>на самом деле, что у нас есть состояние объекта "а"? всего лишь три поля .x, .y и .z. причем .z всегда 0. остается два поля, GetColor внутри себя состояние объекта не меняет, стало быть загоняем перед внешним циклом a.x и a.y в регистры до конца цикла (то есть фактически они становятся локальными для потока; а потом вообще никуда не сохраняем), и совершенно пофигу, что там будут делать другие потоки — в наши регистры они не влезут (то есть один поток не поменяет объект "a" другому, и ничего делать private тут и не надо). но это всё очень зависит от оптимизатора, сделает лишние чтение/запись в память (например, регистров не хватило) — и всё, приплыли.

C>И что, Вы запускаете и каждый раз выдает корректный результат?

а что, код при пересборке генерится одинаковый, чтения/записи из памяти для полей "a" судя по всему нет, рандома нет. так что всё нормально повторяется, кстати проверил с пришпиливанием обоих потоков к одному ядру (через KMP_AFFINITY), тоже нормально.

C>А можно экзешник где-нибудь выложить?

вот здесь — http://files.rsdn.ru/31652/test.zip
это который без private(a)
собран как icl -fast -Qopenmp -Qopenmp-link:static -MT test.cpp чтобы работать без доп. библиотек
явно требует SSE3
Re[18]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 21.05.09 02:36
Оценка: :)))
Здравствуйте, IID, Вы писали:

IID>Таким образом разрыв сокращается до 361%

Прирожденный маркетолог! Порядок в процентах красивше А разница есть разность, следовательно НА 261% или в 3.6 раза.
Re: С# vs C++, голые цифры
От: minorlogic Украина  
Дата: 21.05.09 06:01
Оценка: +1 -1 :))) :)))
Ты не видишь очевидных вещей.

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

Черт , или я опять где то ошибся?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[19]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 21.05.09 06:26
Оценка:
Здравствуйте, criosray, Вы писали:

C>Да, но дотнет вариант менее оптимальный алгоритмически в виду того, что в С++ создается по одному объекту Aux на поток благодаря private(a) директиве, а в дотнет я вписал хак с созданием нового объекта на каждом из 100 итераций цикла.


C>У Parallel.For есть возможность использовать специальный thread local дженерик объект, но я еще не разбирался с этим. Как появится время обязательно разберусь, и отпишусь.


Тут ИМХО, намного важнее то, что на C++ с OpenMP запись получилась намного декларативнее.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[19]: С# vs C++, голые цифры
От: IID Россия  
Дата: 21.05.09 06:34
Оценка: +1 :))) :)))
Здравствуйте, criosray, Вы писали:

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


IID>>Таким образом разрыв сокращается до 361%


C>Да, но дотнет вариант менее оптимальный алгоритмически в виду того, что в С++ создается по одному объекту Aux на поток благодаря private(a) директиве, а в дотнет я вписал хак с созданием нового объекта на каждом из 100 итераций цикла.


Создание 100 объектов разве может как-то заметно повлиять на быстродействие ? Все мы слышали песни о том как быстро работает new в дотнете.
kalsarikännit
Re[20]: С# vs C++, голые цифры
От: criosray  
Дата: 21.05.09 07:00
Оценка: -1 :)
Здравствуйте, IID, Вы писали:

IID>>>Таким образом разрыв сокращается до 361%


C>>Да, но дотнет вариант менее оптимальный алгоритмически в виду того, что в С++ создается по одному объекту Aux на поток благодаря private(a) директиве, а в дотнет я вписал хак с созданием нового объекта на каждом из 100 итераций цикла.


IID>Создание 100 объектов разве может как-то заметно повлиять на быстродействие ? Все мы слышали песни о том как быстро работает new в дотнете.


А где я писал, что это может повлиять заметно на быстродействие? Я просто сказал, что алгоритмически не оптимальный вариант. Так что не ерничайте, уважаемый.
Re[2]: С# vs C++, голые цифры
От: criosray  
Дата: 21.05.09 07:04
Оценка: 4 (2) -3
Здравствуйте, minorlogic, Вы писали:

M>Ты не видишь очевидных вещей.


M>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок. Поэтому высвободившееся время можно использовать для оптимизации на более эффективных алгоритмов.

M>Именно поэтому когда доходит до реальных примеров, использования шарпа дает преимущество, а С++ прошлый век. И конечно твой бенчмарк выполнится быстрее в шарповом варианте или же просто бенчмарк неправильный.

M>Черт , или я опять где то ошибся?


Все верно. Заметьте, что только я — дотнетчик — успел оптимизировать код. С 86 секунд до 35 секунд. С++ вариант оптимизировался просто скопировав под копирку все действия по оптимизации дотнета кода.



PS: Лопата.
Re[20]: С# vs C++, голые цифры
От: criosray  
Дата: 21.05.09 07:08
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

C>>Да, но дотнет вариант менее оптимальный алгоритмически в виду того, что в С++ создается по одному объекту Aux на поток благодаря private(a) директиве, а в дотнет я вписал хак с созданием нового объекта на каждом из 100 итераций цикла.


C>>У Parallel.For есть возможность использовать специальный thread local дженерик объект, но я еще не разбирался с этим. Как появится время обязательно разберусь, и отпишусь.


DC>Тут ИМХО, намного важнее то, что на C++ с OpenMP запись получилась намного декларативнее.


Спорить не стану. OMP все-таки это постпроцессинг кода, а ParallelFx самая обычная библиотека.
Re[3]: С# vs C++, голые цифры
От: Antikrot  
Дата: 21.05.09 07:14
Оценка: +2
Здравствуйте, criosray, Вы писали:

M>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок. Поэтому высвободившееся время можно использовать для оптимизации на более эффективных алгоритмов.

M>>Именно поэтому когда доходит до реальных примеров, использования шарпа дает преимущество, а С++ прошлый век. И конечно твой бенчмарк выполнится быстрее в шарповом варианте или же просто бенчмарк неправильный.
M>>Черт , или я опять где то ошибся?

C>Все верно. Заметьте, что только я — дотнетчик — успел оптимизировать код. С 86 секунд до 35 секунд. С++ вариант оптимизировался просто скопировав под копирку все действия по оптимизации дотнета кода.


заметьте, что тебе для этого понадобилось сделать дополнительные изменения в коде , что как-то не вяжется с "намного быстрее и с меньшим к-вом ошибок"
и потом, а зачем например было оптимизировать код, если на проце с меньшей частотой я и так получаю быстрее 35 секунд?

а вообще, неплохое обсуждение получилось
Re[4]: С# vs C++, голые цифры
От: criosray  
Дата: 21.05.09 07:20
Оценка:
Здравствуйте, Antikrot, Вы писали:

M>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок. Поэтому высвободившееся время можно использовать для оптимизации на более эффективных алгоритмов.

M>>>Именно поэтому когда доходит до реальных примеров, использования шарпа дает преимущество, а С++ прошлый век. И конечно твой бенчмарк выполнится быстрее в шарповом варианте или же просто бенчмарк неправильный.
M>>>Черт , или я опять где то ошибся?

C>>Все верно. Заметьте, что только я — дотнетчик — успел оптимизировать код. С 86 секунд до 35 секунд. С++ вариант оптимизировался просто скопировав под копирку все действия по оптимизации дотнета кода.


A>заметьте, что тебе для этого понадобилось сделать дополнительные изменения в коде , что как-то не вяжется с "намного быстрее и с меньшим к-вом ошибок"


Все верно. Вспомните, что изначальный код на С++ вообще не работал.

A>и потом, а зачем например было оптимизировать код, если на проце с меньшей частотой я и так получаю быстрее 35 секунд?


Ну мы исходим из предположения, что это критичный к времени исполнения участок. Доведя время выполнения дотнет кода до 35 секунд, я бы проанализировал достаточной ли стала производительность. Если нет, то переписали бы на С++ конкретно этот участок кода...
Re[5]: С# vs C++, голые цифры
От: Antikrot  
Дата: 21.05.09 07:29
Оценка:
Здравствуйте, criosray, Вы писали:

A>>заметьте, что тебе для этого понадобилось сделать дополнительные изменения в коде , что как-то не вяжется с "намного быстрее и с меньшим к-вом ошибок"

C>Все верно. Вспомните, что изначальный код на С++ вообще не работал.
и то правда

A>>и потом, а зачем например было оптимизировать код, если на проце с меньшей частотой я и так получаю быстрее 35 секунд?

C>Ну мы исходим из предположения, что это критичный к времени исполнения участок. Доведя время выполнения дотнет кода до 35 секунд, я бы проанализировал достаточной ли стала производительность. Если нет, то переписали бы на С++ конкретно этот участок кода...
... после чего можно было бы поизвращатся еще и с плюсовым кодом на предмет векторизуемости
Re[17]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 21.05.09 08:51
Оценка: +1
Здравствуйте, MxKazan, Вы писали:

IID>>>>Расскажите как этот CTP включить — замеряю.

MK>>>Reference на сборки то добавил?
IID>>делаю Add Reference на проекте. На вкладке .NET громадный список сборок(?). Ничего похожего на ParallelExtensions/TPL/PLINQ там нет. ЧЯДНТ ? Желательно понятным языком расписать и по шагам.
MK>Добавляешь Reference на System.Threading.dll
MK>В коде юзаешь пространство имен System.Threading
MK>parallel extensions to .net framework 3.5

Господа, мне кажется хорошим тоном было бы простое выкладывание собранного бинаря в таких проблемных случаях.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: С# vs C++, голые цифры
От: serb Россия  
Дата: 21.05.09 09:06
Оценка: :)
а сколько бы выдала java на этом тесте?
http://files.rsdn.org/18969/writtenrussianprofessional.gif
Re[18]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 21.05.09 09:11
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

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

IID>>>>>Расскажите как этот CTP включить — замеряю.
MK>>>>Reference на сборки то добавил?
IID>>>делаю Add Reference на проекте. На вкладке .NET громадный список сборок(?). Ничего похожего на ParallelExtensions/TPL/PLINQ там нет. ЧЯДНТ ? Желательно понятным языком расписать и по шагам.
MK>>Добавляешь Reference на System.Threading.dll
MK>>В коде юзаешь пространство имен System.Threading
MK>>parallel extensions to .net framework 3.5
CC>Господа, мне кажется хорошим тоном было бы простое выкладывание собранного бинаря в таких проблемных случаях.
Ай, блин, не пали нас. Вдруг у нас дотНеты как-нить разъедутся

Если серьезно, то я уже запутался в исходниках.
Было бы неплохо увидеть финальные варианты на C++ и C#, со всеми using и include.
Re[19]: С# vs C++, голые цифры
От: quagmire  
Дата: 21.05.09 10:23
Оценка: 2 (1)
Здравствуйте, MxKazan, Вы писали:

MK>Было бы неплохо увидеть финальные варианты на C++ и C#, со всеми using и include.


Сделал выдержку из предыдущих постов C# варианта. Если что поправляйте.

using System;
using System.Diagnostics;
using System.Threading;

namespace Test
{
    class Program
    {
        private const int TestCount = 100;

        static void Main(string[] args)
        {
            Parallel1();
            Parallel2();
            Serial();
            Parallel1();
            Parallel2();
            Serial();
        }

        private static void Serial()
        {
            int total = 0;
            Aux a = new Aux();
            Stopwatch watch = new Stopwatch();
            watch.Start();
            for (int i = 0; i < TestCount; i++)
            {
                for (a.y = -1.5; a.y < 1.5; a.y += 0.001)
                {
                    for (a.x = -1; a.x < 2; a.x += 0.001)
                    {
                        total += a.GetColor();
                    }
                }
            }
            watch.Stop();
            Console.WriteLine("Elapsed: {0};   b = {1}", watch.Elapsed, total);
        }

        private static void Parallel1()
        {
            int total = 0;
            Stopwatch watch = new Stopwatch();
            watch.Start();
            Parallel.For(0, TestCount, i =>
            {
                Aux a = new Aux();
                int subTotal = 0;
                for (a.y = -1.5; a.y < 1.5; a.y += 0.001)
                {
                    for (a.x = -1; a.x < 2; a.x += 0.001)
                    {
                        subTotal += a.GetColor();
                    }
                }
                Interlocked.Add(ref total, subTotal);
            });
            watch.Stop();
            Console.WriteLine("Elapsed: {0};   b = {1}", watch.Elapsed, total);
        }

        private static void Parallel2()
        {
            int total = 0;
            Stopwatch watch = new Stopwatch();
            watch.Start();
            Parallel.For(0, TestCount, () => new Aux(), (i, local) =>
            {
                Aux a = local.ThreadLocalState;
                int subTotal = 0;
                for (a.y = -1.5; a.y < 1.5; a.y += 0.001)
                {
                    for (a.x = -1; a.x < 2; a.x += 0.001)
                    {
                         subTotal += a.GetColor();
                    }
                }
                Interlocked.Add(ref total, subTotal);
            });
            watch.Stop();
            Console.WriteLine("Elapsed: {0};   b = {1}", watch.Elapsed, total);
        }

        class Aux
        {
            public double x, y, z;

            double ZZZFunc()
            {
                double xmy = x - y;
                return xmy - Math.Floor(xmy + 0.5);
            }
            double Spiral_()
            {
                double xk = x * 20;
                double a = 0.2;
                double b = 1.5;
                double y1 = y * b - a * Math.Sin(xk);
                double z1 = z * b - a * Math.Cos(xk);
                return y1 * y1 + z1 * z1;
            }
            bool Golova()
            {
                return x < 0.0 && (x * x + y * y + z * z) < 1.0 && !Shliz();
            }
            bool Spiral()
            {
                return x > 0.0 && x < 1.75 && Math.Abs(Spiral_()) < 0.5;
            }
            bool Shliz()
            {
                return x < -0.4 && y < 0.1 && y > -0.1;
            }
            bool Strokes()
            {
                return (Math.Abs(0.5 - x) < 0.02 || (x > 0.5 && Math.Abs(ZZZFunc()) < 0.005));
            }
            bool Wall()
            {
                return x > 0.5;
            }
            public int GetColor()
            {
                if (Golova()) return 1;
                if (Spiral()) return 2;
                if (Strokes()) return 3;
                if (Wall()) return 4;
                return 0;
            }
        }
    }
}
Re[2]: С# vs C++, голые цифры
От: criosray  
Дата: 21.05.09 11:18
Оценка:
Здравствуйте, serb, Вы писали:

S>а сколько бы выдала java на этом тесте?


Понеслось...
Re[3]: С# vs C++, голые цифры
От: criosray  
Дата: 21.05.09 11:20
Оценка:
Здравствуйте, criosray, Вы писали:


M>>Ты не видишь очевидных вещей.


M>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок. Поэтому высвободившееся время можно использовать для оптимизации на более эффективных алгоритмов.

M>>Именно поэтому когда доходит до реальных примеров, использования шарпа дает преимущество, а С++ прошлый век. И конечно твой бенчмарк выполнится быстрее в шарповом варианте или же просто бенчмарк неправильный.

M>>Черт , или я опять где то ошибся?


C>Все верно. Заметьте, что только я — дотнетчик — успел оптимизировать код. С 86 секунд до 35 секунд. С++ вариант оптимизировался просто скопировав под копирку все действия по оптимизации дотнета кода.


C>


C>PS: Лопата.


Поставившим минусы внимательно перечитать выделенное. Специально для особо "понятливых" написал ведь...
Re[3]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 21.05.09 11:32
Оценка:
Здравствуйте, criosray, Вы писали:

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

S>>а сколько бы выдала java на этом тесте?
C>Понеслось...
А че, и правда интересно.
Re[4]: С# vs C++, голые цифры
От: Antikrot  
Дата: 21.05.09 11:48
Оценка:
Здравствуйте, MxKazan, Вы писали:

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

S>>>а сколько бы выдала java на этом тесте?
C>>Понеслось...
MK>А че, и правда интересно.
и особенно как распараллеливать будут, сравнить подход хочется
Re[4]: С# vs C++, голые цифры
От: vdimas Россия  
Дата: 21.05.09 18:10
Оценка:
Здравствуйте, Sorantis, Вы писали:

S>Запустил С++ вариант под МС компиллер.

S>Время показало 3 секунды. ЧЯДНТ?

Аргументы компилятора какие?

S>Время шарпов такое же как у тебя.


Ну охренеть, что еще добавить.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[4]: С# vs C++, голые цифры
От: Erop Россия  
Дата: 21.05.09 21:23
Оценка:
Здравствуйте, Sorantis, Вы писали:

S>Время показало 3 секунды. ЧЯДНТ?

Что за машина/система/опции компилятора?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: С# vs C++, голые цифры
От: Erop Россия  
Дата: 21.05.09 21:32
Оценка: +1 :)
Здравствуйте, criosray, Вы писали:

IID>>Читайте доки, они рулез. (тыкаю пальцем: Profile-Guided Optimization)


C>Доки эти я читал за долго до того, как Вы программированием занялись.


Видимо ещё и до того, как это документ был опубликован и даже написан?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 21.05.09 22:43
Оценка: 1 (1) +1 -1
Здравствуйте, IID, Вы писали:

IID>В соселней ветке "Работа — с чего начать: С++ или С#?" было озвучено мнение
Автор: samius
Дата: 19.05.09
, что C# немного медленее С++. И даже предложен код на C#
Автор: IID
Дата: 19.05.09
.

Что-то я и не отметился здесь... Только сегодня обнаружил тему, прочитал всю.

Вопервых, на счет моего тезиса, ссылка на который приведена: там я говорил о примере немного другой программы. Программа, о которой я говорил, могла бы числорубить сцены прочитанные из файла и/или отредактированные в рантайме. Ты же выдернул из программы кусок и начал сравнивать производительности компиляторов в чистом числорублении.
В контексте моего тезиса (о том что я привел пример программы, где C# рвет C++) я признаю победу С++ только если ты (или кто-нибудь) прикрутит (легально) к программе на С++ компилятор Intel C++ или какой-нибудь другой, или пусть это будет интерпретатор, в общем, что угодно, что могло бы прочитать из текстового файла скрипт со сценой и отчислорубить его быстрее чем программа на C# при прочих равных условиях (возможность использовать все доступные ядра, SSE, одинаковый порядок просмотра тел, одинаковые цифры в определениях тел и т.п.)

Потому все это небезынтересное состязание я воспринимаю только в контексте того, что где-то ляпнул будто C# числорубка будет лишь немного медленнее C++ числорубки.

IID>Я привёл код в компилябельное состояние. Вот C# вариант, а вот C++ вариант. Для компиляции использовалась MSVS2008 со всеми обновлениями.


Угу, пойдет. Немного разная функциональность у Math.Round(xmy, 1) и у Math.Floor(xmy). На картинке это очень сильно заметно. Ну да пофигу, перевеса за счет этого не получится, да и вроде поправили уже шарповскую версию.

IID>- компилятор C# версии 3.5 Настроки релизной сборки — дефолтные. (Там-то и настраивать особо нечего).

IID>- компилятор Intel С++ 11.0.072. Релизная сборка кастомизирована. Впрочем, разница между дефолтной релизной сборкой и кастомизированной невелика, порядка 10-15%. Ключи компиляции:

IID>

IID>/c /O2 /Og /Oi /Ot /Oy /Qipo /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /EHsc /MD /GS- /Gy /fp:fast /Yu"StdAfx.h" /Fp"Release/SpeedTestCpp.pch" /Fo"Release/" /W3 /nologo /Zi /QxSSSE3 /Qparallel /Qprof_use /Qprof_dir "Release"

Ой, интеловский компилятор, интересные ключики... Может кто-нибудь заточит C# версию под Мono.SIMD ?

IID>Тестовая машина: Intel Core2 Q6600, 800mhz RAM 8Gb. ОС — Windows 7 RC1 x64. Программы собирались для x86.

IID>Условия прогона: в диапазонах, указанных автором оригинального C# кода. Шаг по X/Y составляет 0.001 (всего за прогон обсчитывается 9млн пикселей). Делается 100(сто) прогонов подряд. Вычисляется суммарное время.
IID>Побочные эффекты: практически исключены. Сторонней нагрузки не было, taskmgr показывал загрузку только одного ядра во время прогонов. Т.е. гипотеза о том что интел компилер сумел заюзать несколько ядер отпадает.

IID>Результаты:

IID> С#: 2m 14s (134 секунды)
IID>С++: 27 секунд

Это окончательные результаты? А то там что-то вроде не работало?

IID>С++ показал практически пятикратное преимущество (496%), обеспечив обсчёт ~33.33млн пикселей в секунду. C# осилил только ~6.71млн пикселей в секунду. (что довольно близко к результату автора в 5.9млн пикселей)

Версия автора еще кое-что делала. В частности обращалась она не с int-ами, а с System.Drawing.Color. Эта структура сильно потяжелее int-а будет. Ну и в буфер ведь все складывал. Так что простим автору, что его результат чуть меньше чем твой на C#.

IID>Итог: подавляющее превосходство С++. Не "немного быстрее", как утверждал автор, а в разы. Причём задача сводилась, фактически, только к грамотному распихиванию FPU команд. Интересно было бы посмотреть на работу с битами. Думаю, тут интел смог бы обеспечить ещё больший отрыв.


Еще одна путаница произошла. В начале поста ты даешь ссылку где я утверждаю что мой пример рвет в разы, тут ссылаешься на другую мою фразу из другого контекста. О чем собственно бенчмарк-то?
Если о той фразе, на которую ссылка в начале поста, то ждем динамической компиляции от программы на C++.
Если о том, что я ляпнул про "лишь немного быстрее", то
а) ждем резултатов Mono.SIMD
б) сравниваем голый C# с голым MS C++ (где возможно получим не такую большую разницу).

Когда я говорил "немного", я подразумевал MS компилятор, что впрочем меня не извиняет.

З.Ы. Видел тут поклонники C# химичили с заданием тел. Не дело. Исходная задача — рендеринг картинки, инвариантной к порядку просмотра тел. Потому для каждого тела важны все его части. Если из стены выкушен цилиндр, то это значит, что точки, находящиеся в пересечении стены и цилиндра к полученному телу не относятся. Т.е. операции над телами строились из соображений подобия строгим теоретико-множественным операциям над точками пространства.
Ну и потом, это просто не спортивно. Если уж бенчмаркать, то бенчмаркать в равных условиях.

З.Ы2. По поводу распараллеливания: ради бенчмарка компиляторов смысла параллелить нет, т.к. задача масштабируется по ядрам идеально. Если уж параллелить, то параллелить оба варианта. И нет смысла сравнивать параллельный C# с непараллельным C++.
Re[2]: С# vs C++, голые цифры
От: IID Россия  
Дата: 22.05.09 06:43
Оценка:
Здравствуйте, samius, Вы писали:

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


IID>>Итог: подавляющее превосходство С++. Не "немного быстрее", как утверждал автор, а в разы. Причём задача сводилась, фактически, только к грамотному распихиванию FPU команд. Интересно было бы посмотреть на работу с битами. Думаю, тут интел смог бы обеспечить ещё больший отрыв.


S>Еще одна путаница произошла. В начале поста ты даешь ссылку где я утверждаю что мой пример рвет в разы, тут ссылаешься на другую мою фразу из другого контекста. О чем собственно бенчмарк-то?

S>Если о той фразе, на которую ссылка в начале поста, то ждем динамической компиляции от программы на C++.
S>Если о том, что я ляпнул про "лишь немного быстрее", то
S>а) ждем резултатов Mono.SIMD

Как его установить-заюзать ? Можно в привате на эту тему пообщаться, чтобы не оффтопить тут.

S>б) сравниваем голый C# с голым MS C++ (где возможно получим не такую большую разницу).

S>Когда я говорил "немного", я подразумевал MS компилятор, что впрочем меня не извиняет.

с MS C++ разница действительно не такая большая. Порядка 2-х раз. Это, конечно, уже не "немного", но и не так хорошо как с Интелом. С другой стороны, я не тратил усилий на тюнинг параметров MSVC++ проекта. Скорее всего можно было бы выжать ещё.


S>З.Ы. Видел тут поклонники C# химичили с заданием тел. Не дело. Исходная задача — рендеринг картинки, инвариантной к порядку просмотра тел. Потому для каждого тела важны все его части. Если из стены выкушен цилиндр, то это значит, что точки, находящиеся в пересечении стены и цилиндра к полученному телу не относятся. Т.е. операции над телами строились из соображений подобия строгим теоретико-множественным операциям над точками пространства.

S>Ну и потом, это просто не спортивно. Если уж бенчмаркать, то бенчмаркать в равных условиях.



S>З.Ы2. По поводу распараллеливания: ради бенчмарка компиляторов смысла параллелить нет, т.к. задача масштабируется по ядрам идеально. Если уж параллелить, то параллелить оба варианта. И нет смысла сравнивать параллельный C# с непараллельным C++.


Сравнивали и оба параллельных. 3.6 раз получилась разница. Хотя у С++ варианта время исполнения в параллельном случае снизилось до 9сек, там уже могли иметь место накладные расходы по инициализации самого процесса + инициализация OpenMP (тут уже даже секунда оказывает значительное влияние на итоговую оценку). Возможно, имеет смысл повторить, увеличив на порядок количество итераций.
kalsarikännit
Re[2]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 22.05.09 06:56
Оценка:
Здравствуйте, samius, Вы писали:

S>Ой, интеловский компилятор, интересные ключики... Может кто-нибудь заточит C# версию под Мono.SIMD ?

Было бы отлично

S>З.Ы2. По поводу распараллеливания: ради бенчмарка компиляторов смысла параллелить нет, т.к. задача масштабируется по ядрам идеально. Если уж параллелить, то параллелить оба варианта. И нет смысла сравнивать параллельный C# с непараллельным C++.

Ну ради интереса, смысл вполне себе был
Re[3]: С# vs C++, голые цифры
От: MxKazan Россия  
Дата: 22.05.09 06:57
Оценка: +2
Здравствуйте, IID, Вы писали:

IID>Как его установить-заюзать ? Можно в привате на эту тему пообщаться, чтобы не оффтопить тут.

Лучше по "оффтопьте" здесь, думаю всем будет полезно и интересно
Re[3]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 22.05.09 07:30
Оценка: +1
Здравствуйте, MxKazan, Вы писали:

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


S>>Ой, интеловский компилятор, интересные ключики... Может кто-нибудь заточит C# версию под Мono.SIMD ?

MK>Было бы отлично
Вряд ли, Мono.SIMD операции с векторами оптимизирует, а в этих вычислениях веторов нет.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[3]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 22.05.09 08:22
Оценка:
Здравствуйте, IID, Вы писали:

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


S>>а) ждем резултатов Mono.SIMD


IID>Как его установить-заюзать ? Можно в привате на эту тему пообщаться, чтобы не оффтопить тут.


Без малейшего понятия. Все что я о нем знаю — это как поискать его в гугле.
Если честно, то я даже почти уверен в том, что SIMD этому конкретному бенчмарку мало чем поможет. Векторных операций как-таковых нет.

S>>б) сравниваем голый C# с голым MS C++ (где возможно получим не такую большую разницу).

S>>Когда я говорил "немного", я подразумевал MS компилятор, что впрочем меня не извиняет.

IID>с MS C++ разница действительно не такая большая. Порядка 2-х раз. Это, конечно, уже не "немного", но и не так хорошо как с Интелом. С другой стороны, я не тратил усилий на тюнинг параметров MSVC++ проекта. Скорее всего можно было бы выжать ещё.

Да уж, не немного...
Поливаю кепку майонезом

S>>З.Ы2. По поводу распараллеливания: ради бенчмарка компиляторов смысла параллелить нет, т.к. задача масштабируется по ядрам идеально. Если уж параллелить, то параллелить оба варианта. И нет смысла сравнивать параллельный C# с непараллельным C++.


IID>Сравнивали и оба параллельных. 3.6 раз получилась разница. Хотя у С++ варианта время исполнения в параллельном случае снизилось до 9сек, там уже могли иметь место накладные расходы по инициализации самого процесса + инициализация OpenMP (тут уже даже секунда оказывает значительное влияние на итоговую оценку). Возможно, имеет смысл повторить, увеличив на порядок количество итераций.


Динамического варианта на C++ ждать?
Re[13]: С# vs C++, голые цифры
От: Ночной Смотрящий Россия  
Дата: 22.05.09 09:45
Оценка: +1 -1
Здравствуйте, MxKazan, Вы писали:

MK>Как-то нечестно, не находишь?


Это характерная черта всех подобных флеймов. Те кто чмырять C#, его знают на уроыне чайника, и наоборот.
Re[17]: С# vs C++, голые цифры
От: Ночной Смотрящий Россия  
Дата: 22.05.09 09:45
Оценка: 1 (1) :)
Здравствуйте, criosray, Вы писали:

C>Это штатная фича дотнет начиная с 4.0. А пока можно скачать абсолютно рабочий CTP.


Рабочий то он рабочий, но у него серьезные проблемы как раз с производительностью. Надо было хотя бы beta 1 4-го фреймворка пользовать.
Re[4]: С# vs C++, голые цифры
От: criosray  
Дата: 22.05.09 09:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>>Ой, интеловский компилятор, интересные ключики... Может кто-нибудь заточит C# версию под Мono.SIMD ?

MK>>Было бы отлично
G>Вряд ли, Мono.SIMD операции с векторами оптимизирует, а в этих вычислениях веторов нет.

А разве SIMD это не MMX / SSE x и т.п. расширения? Дело в том, что включение SSE3 оптимизации ускорило С++ вариант почти в два раза.
Re[5]: С# vs C++, голые цифры
От: Antikrot  
Дата: 22.05.09 10:10
Оценка:
Здравствуйте, criosray, Вы писали:

S>>>>Ой, интеловский компилятор, интересные ключики... Может кто-нибудь заточит C# версию под Мono.SIMD ?

MK>>>Было бы отлично
G>>Вряд ли, Мono.SIMD операции с векторами оптимизирует, а в этих вычислениях веторов нет.
C>А разве SIMD это не MMX / SSE x и т.п. расширения? Дело в том, что включение SSE3 оптимизации ускорило С++ вариант почти в два раза.
интересный вопрос, что там на самом деле ускорило. но векторных операций не было, то есть обработка шла по одному элементу, хотя и sse-шными функциями. я почти уверен, что агрессивный инлайн в данном примере дает больше, чем sse...

ps. попробую что-нибудь векторизовать в тесте, если будет немного времени в выходные
Re[4]: С# vs C++, голые цифры
От: Erop Россия  
Дата: 22.05.09 11:00
Оценка:
Здравствуйте, samius, Вы писали:


S>Динамического варианта на C++ ждать?

dll?
Такой тест будет очень уж сентетическим. Могу для сравнения сказать, что у меня есть мотор, который умеет интерпретировать некий байт-код или умеет компилять его в срр. Компиляция даёт ускорение где-то процентов на 20%...
Но это уже очень сильно от задачи зависит...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: С# vs C++, голые цифры
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 23.05.09 01:52
Оценка: +1 :))) :)))
Здравствуйте, IID, Вы писали:

IID><skipped>

Всё гораздо проще:
Console.WriteLine("23 см.");

cout << L"25 см." << endl;


[КУ] оккупировала армия.
Re[2]: С# vs C++, голые цифры
От: criosray  
Дата: 23.05.09 07:40
Оценка:
Здравствуйте, koandrew, Вы писали:

IID>><skipped>

K>Всё гораздо проще:
K>
K>Console.WriteLine("23x5 см.");
K>

K>
K>cout << L"25x2 см." << endl;
K>


K>


Re[3]: С# vs C++, голые цифры
От: IID Россия  
Дата: 23.05.09 08:43
Оценка:
Здравствуйте, criosray, Вы писали:

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


IID>>><skipped>

K>>Всё гораздо проще:
K>>
K>>Console.WriteLine("23x5 см.");
K>>

C>

пятих#й ? подозревал, что С# мутант, но чтобы настолько...
kalsarikännit
Re[4]: С# vs C++, голые цифры
От: criosray  
Дата: 23.05.09 10:40
Оценка:
Здравствуйте, IID, Вы писали:


IID>>>><skipped>

K>>>Всё гораздо проще:
K>>>
K>>>Console.WriteLine("23x5 см.");
K>>>

C>>

IID>пятих#й ? подозревал, что С# мутант, но чтобы настолько...


Для непонятливых вторая цифра означает диаметр.
Re[5]: С# vs C++, голые цифры
От: VoidEx  
Дата: 23.05.09 12:29
Оценка:
Здравствуйте, criosray, Вы писали:

C>Для непонятливых вторая цифра означает диаметр.


И с каких пор длина * диаметр измеряется в линейных сантиметрах?
Re[6]: С# vs C++, голые цифры
От: criosray  
Дата: 23.05.09 15:39
Оценка:
Здравствуйте, VoidEx, Вы писали:

C>>Для непонятливых вторая цифра означает диаметр.


VE>И с каких пор длина * диаметр измеряется в линейных сантиметрах?


Где Вы там увидели знак умножения?
Re[7]: С# vs C++, голые цифры
От: Sorantis Швеция sorantis.blogspot.com
Дата: 23.05.09 17:25
Оценка: :)
Здравствуйте, criosray, Вы писали:

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


C>>>Для непонятливых вторая цифра означает диаметр.


VE>>И с каких пор длина * диаметр измеряется в линейных сантиметрах?


C>Где Вы там увидели знак умножения?

ну тогда

Console.WriteLine("23 x 5 см х см.");
As long as there is life, there is hope
Re[2]: С# vs C++, голые цифры
От: mrTwister Россия  
Дата: 24.05.09 06:36
Оценка: :)
Здравствуйте, serb, Вы писали:

S>а сколько бы выдала java на этом тесте?


<Summon target="Cyberax">
Java бы жутко тормозила, как обычно.
</Summon>

P.S.: действительно интересно
лэт ми спик фром май харт
Re[3]: С# vs C++, голые цифры
От: criosray  
Дата: 25.05.09 07:28
Оценка:
Здравствуйте, mrTwister, Вы писали:

S>>а сколько бы выдала java на этом тесте?


T><Summon target="Cyberax">

T>Java бы жутко тормозила, как обычно.
T></Summon>

T>P.S.: действительно интересно


Немного погуглил — нашел несколько вариаций ParallelFor для Java. Но дальше разбираться не стал, т.к. не знаю какая из них реально применяется в продакшине.
Re[4]: С# vs C++, голые цифры
От: Sinix  
Дата: 25.05.09 07:52
Оценка:
Здравствуйте, criosray

C>Немного погуглил — нашел несколько вариаций ParallelFor для Java. Но дальше разбираться не стал, т.к. не знаю какая из них реально применяется в продакшине.


А без ParallelFor?
Re[5]: С# vs C++, голые цифры
От: criosray  
Дата: 25.05.09 10:43
Оценка: 2 (2)
Здравствуйте, Sinix, Вы писали:

C>>Немного погуглил — нашел несколько вариаций ParallelFor для Java. Но дальше разбираться не стал, т.к. не знаю какая из них реально применяется в продакшине.


S>А без ParallelFor?

jre 6 13

passed 106 sec
total=1813065000

.net

passed 62 sec
total=1813065000

Даже и не знаю почему Java на столько медленнее. Возможно я при сборке каких-то ключиков не задал...
Re[6]: С# vs C++, голые цифры
От: Sinix  
Дата: 25.05.09 23:45
Оценка: :)
Здравствуйте, criosray

C>Даже и не знаю почему Java на столько медленнее. Возможно я при сборке каких-то ключиков не задал...

Ага. Уж я на что ламер в этом плане — и то помню что в любом мегахоливаре надо яву запускать с server gc и потюненным hot spot'om.
Re[7]: С# vs C++, голые цифры
От: criosray  
Дата: 26.05.09 07:05
Оценка:
Здравствуйте, Sinix, Вы писали:

C>>Даже и не знаю почему Java на столько медленнее. Возможно я при сборке каких-то ключиков не задал...

S>Ага. Уж я на что ламер в этом плане — и то помню что в любом мегахоливаре надо яву запускать с server gc и потюненным hot spot'om.
А чем server gc поможет число дробилке?

Какие ключи надо задать для тюнинга jvm?

Нашел только -server. Результат заметно улучшился:

passed — 89 sec
total=1813065000

Но все-равно пока сильно отстает и от С++ и от дотнет вариантов...
Re[8]: С# vs C++, голые цифры
От: Sinix  
Дата: 26.05.09 08:18
Оценка:
Здравствуйте, criosray, Вы писали:

C>Какие ключи надо задать для тюнинга jvm?


Я ж говорю — полный ламер в практическом плане. За теорией плотно сидел чтоб узнать "а как оно ещё бывает", а вот на практике применять не довелось.
Re: С# vs C++, голые цифры
От: minorlogic Украина  
Дата: 01.06.09 19:12
Оценка:
Обидно, как всегда ...

Как только дошли до бенчмарков , сразу сторонники языка X рассосались а было весело.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: С# vs C++, голые цифры
От: criosray  
Дата: 01.06.09 19:28
Оценка: :)
Здравствуйте, minorlogic, Вы писали:

M>Обидно, как всегда ...


M>Как только дошли до бенчмарков , сразу сторонники языка X рассосались а было весело.


А что интересного в меряние попугайчиков, сиречь в синтетических тестах?

Ведь реальная задача заключалась в том, что код числодробилки задается в рантайм пользователем.
Но т.к. С++ники не могут этого реализовать, то и сравнивать нам особо нечего.
Re[2]: С# vs C++, голые цифры
От: Antikrot  
Дата: 01.06.09 20:10
Оценка: :)
Здравствуйте, minorlogic, Вы писали:

M>Как только дошли до бенчмарков , сразу сторонники языка X рассосались а было весело.

не знаю, какой язык ты обозвал "Х", но можешь предлагать еще какую-нибудь задачку, авось найдутся желающие достать линейки
Re[3]: С# vs C++, голые цифры
От: Antikrot  
Дата: 01.06.09 20:14
Оценка:
Здравствуйте, criosray, Вы писали:

C>А что интересного в меряние попугайчиков, сиречь в синтетических тестах?

C>Ведь реальная задача
а ткнуть в реальную задачу можно? поиск что-то глючит

C>заключалась в том, что код числодробилки задается в рантайм пользователем.

C>Но т.к. С++ники не могут этого реализовать, то и сравнивать нам особо нечего.
как-то непонятно — код числодробилки задаётся каким образом? на каком-то собственном языке или на том же, что и программа? но все равно — в первом случае независимо от языка реализации будет своё для обработки, во втором — будет вызов компилятора в чем проблема-то?
Re[4]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 01.06.09 20:47
Оценка:
Здравствуйте, Antikrot, Вы писали:

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


C>>А что интересного в меряние попугайчиков, сиречь в синтетических тестах?

C>>Ведь реальная задача
A>а ткнуть в реальную задачу можно? поиск что-то глючит
http://www.rsdn.ru/forum/flame.comp/3395396.1.aspx
Автор: samius
Дата: 19.05.09

http://www.rsdn.ru/forum/flame.comp/3395494.1.aspx
Автор: samius
Дата: 19.05.09


C>>заключалась в том, что код числодробилки задается в рантайм пользователем.

C>>Но т.к. С++ники не могут этого реализовать, то и сравнивать нам особо нечего.
A>как-то непонятно — код числодробилки задаётся каким образом? на каком-то собственном языке или на том же, что и программа?
Каким образом — не суть важно. Важна была интерактивность программы (мгновенная отрисовка введенного пользователем описания геометрии сцены).

A>но все равно — в первом случае независимо от языка реализации будет своё для обработки, во втором — будет вызов компилятора в чем проблема-то?

Проблема в том, что пример на C++ с вызовом компилятора в рантайме пока не предоставлен (особенно с интеловским, с которым мерили). Рабочего примера на C# тоже не было, но с этим как-раз таки проблемы нет.
Re[5]: С# vs C++, голые цифры
От: criosray  
Дата: 01.06.09 21:03
Оценка:
Здравствуйте, samius, Вы писали:

A>>но все равно — в первом случае независимо от языка реализации будет своё для обработки, во втором — будет вызов компилятора в чем проблема-то?

S>Проблема в том, что пример на C++ с вызовом компилятора в рантайме пока не предоставлен (особенно с интеловским, с которым мерили). Рабочего примера на C# тоже не было, но с этим как-раз таки проблемы нет.

http://www.codeproject.com/KB/msil/MsilParser.aspx вполне себе пример. Пусть хотя бы такое простенькое на С++ сделают.
Re[5]: С# vs C++, голые цифры
От: Antikrot  
Дата: 01.06.09 21:08
Оценка: +1
Здравствуйте, samius, Вы писали:

C>>>заключалась в том, что код числодробилки задается в рантайм пользователем.

C>>>Но т.к. С++ники не могут этого реализовать, то и сравнивать нам особо нечего.
A>>как-то непонятно — код числодробилки задаётся каким образом? на каком-то собственном языке или на том же, что и программа?
S>Каким образом — не суть важно. Важна была интерактивность программы (мгновенная отрисовка введенного пользователем описания геометрии сцены).
ну это... если изменяемая часть — это математическое задание поверхностей, то (вот сейчас меня заплюют) я бы написал на плюсах простенький компилятор (прямо с кодогенерацией) матем.выражений на fpu и/или sse (собственно, я так делал для решения задач многокритериальной оптимизации при задании задачи интерактивно). таки да, платформозависимо, но так ведь и C# у нас не жуть какой кроссплатформенный.
Re[6]: С# vs C++, голые цифры
От: criosray  
Дата: 01.06.09 21:11
Оценка:
Здравствуйте, Antikrot, Вы писали:

C>>>>заключалась в том, что код числодробилки задается в рантайм пользователем.

C>>>>Но т.к. С++ники не могут этого реализовать, то и сравнивать нам особо нечего.
A>>>как-то непонятно — код числодробилки задаётся каким образом? на каком-то собственном языке или на том же, что и программа?
S>>Каким образом — не суть важно. Важна была интерактивность программы (мгновенная отрисовка введенного пользователем описания геометрии сцены).
A>ну это... если изменяемая часть — это математическое задание поверхностей, то (вот сейчас меня заплюют) я бы написал на плюсах простенький компилятор (прямо с кодогенерацией) матем.выражений на fpu и/или sse (собственно, я так делал для решения задач многокритериальной оптимизации при задании задачи интерактивно).
Можно увидеть простой пример?

A>таки да, платформозависимо, но так ведь и C# у нас не жуть какой кроссплатформенный.

С# вариант будет работать и на древнем PII и на новейшем I7.
Re[6]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 01.06.09 21:19
Оценка:
Здравствуйте, Antikrot, Вы писали:

A>ну это... если изменяемая часть — это математическое задание поверхностей, то (вот сейчас меня заплюют) я бы написал на плюсах простенький компилятор (прямо с кодогенерацией) матем.выражений на fpu и/или sse (собственно, я так делал для решения задач многокритериальной оптимизации при задании задачи интерактивно). таки да, платформозависимо, но так ведь и C# у нас не жуть какой кроссплатформенный.


Компилятор можно и на Руби написать.
* Будет ли это только сравнение C++ и Руби?
* Сколько займет ресурсов написание простенького компилятора, который бы опередил JIT (хотя бы в рамках задачи)?
Re[7]: С# vs C++, голые цифры
От: Antikrot  
Дата: 01.06.09 21:34
Оценка:
Здравствуйте, criosray, Вы писали:

S>>>Каким образом — не суть важно. Важна была интерактивность программы (мгновенная отрисовка введенного пользователем описания геометрии сцены).

A>>ну это... если изменяемая часть — это математическое задание поверхностей, то (вот сейчас меня заплюют) я бы написал на плюсах простенький компилятор (прямо с кодогенерацией) матем.выражений на fpu и/или sse (собственно, я так делал для решения задач многокритериальной оптимизации при задании задачи интерактивно).
C>Можно увидеть простой пример?
нельзя там кода дофига, и у меня его с собой нет но идея ровно та же, что и по твоей ссылке http://www.codeproject.com/KB/msil/MsilParser.aspx, разве только что я всю эту фигню в классы запихал, и вместо набора функций вроде matchAdd у меня тупо был класс binary_operation с методами interpret, compileFPU и compileSSE. Последние две делали то же, что и ILGenerator.Emit.
поддерживалось до восьми переменных (Х1-...-Х8), читались-писались они просто в предопределенную область памяти, о которой знал мой кодогенератор
блин, да я бы эту свою фигню заопенсорсил, кабы нашел

ps. трудозатраты на это можешь сам представить... уж и правда проще сделать system(cl.exe)

A>>таки да, платформозависимо, но так ведь и C# у нас не жуть какой кроссплатформенный.

C>С# вариант будет работать и на древнем PII и на новейшем I7.
ну так вариант с FPU тоже везде будет работать
Re[7]: С# vs C++, голые цифры
От: Antikrot  
Дата: 01.06.09 21:35
Оценка:
Здравствуйте, samius, Вы писали:

S>Компилятор можно и на Руби написать.

S>* Будет ли это только сравнение C++ и Руби?
S>* Сколько займет ресурсов написание простенького компилятора, который бы опередил JIT (хотя бы в рамках задачи)?
неделю, не меньше
Re[6]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 01.06.09 21:35
Оценка:
Здравствуйте, criosray, Вы писали:

C>http://www.codeproject.com/KB/msil/MsilParser.aspx вполне себе пример. Пусть хотя бы такое простенькое на С++ сделают.

На счет этого, я как раз не переживаю. Умельцы такое и на Delphi слабают и даже на том же C# без MSIL-а.
Re[7]: С# vs C++, голые цифры
От: criosray  
Дата: 01.06.09 21:37
Оценка:
Здравствуйте, samius, Вы писали:

C>>http://www.codeproject.com/KB/msil/MsilParser.aspx вполне себе пример. Пусть хотя бы такое простенькое на С++ сделают.

S>На счет этого, я как раз не переживаю. Умельцы такое и на Delphi слабают и даже на том же C# без MSIL-а.
Слабать-то слабают — вопрос в производительности решения.
Re[8]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.06.09 21:39
Оценка: +1 :)
Здравствуйте, Antikrot, Вы писали:

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


S>>Компилятор можно и на Руби написать.

S>>* Будет ли это только сравнение C++ и Руби?
S>>* Сколько займет ресурсов написание простенького компилятора, который бы опередил JIT (хотя бы в рамках задачи)?
A>неделю, не меньше
Добаляю этот пост в избранное, через неделю ждем первых результатов.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[8]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 01.06.09 21:48
Оценка:
Здравствуйте, Antikrot, Вы писали:

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


S>>Компилятор можно и на Руби написать.

S>>* Будет ли это только сравнение C++ и Руби?
S>>* Сколько займет ресурсов написание простенького компилятора, который бы опередил JIT (хотя бы в рамках задачи)?
A>неделю, не меньше
не меньше — однозначно.

А вообще, идея с собственным компилятором не так и плоха в контексте данной задачи. Например, имея собственный компилятор можно сделать решение на чистом SSE и прогонять через него сразу пачки векторов при отсутствии логики ветвления в описании геометрии. А то даже и GPU прикрутить.
Однако, ресурсы!!!
Re[9]: С# vs C++, голые цифры
От: Antikrot  
Дата: 01.06.09 21:54
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>>* Сколько займет ресурсов написание простенького компилятора, который бы опередил JIT (хотя бы в рамках задачи)?

A>>неделю, не меньше
G>Добаляю этот пост в избранное, через неделю ждем первых результатов.
у нас очевидно сильно разные понятия о "простеньком". я говорю о компиляции математического задания поверхностей, это так, для уточнения.

ps. и еще я сразу сказал, что примеры посмотреть нельзя так что не ждите
Re[9]: С# vs C++, голые цифры
От: Antikrot  
Дата: 01.06.09 21:58
Оценка:
Здравствуйте, samius, Вы писали:

A>>неделю, не меньше

S>не меньше — однозначно.
а то

S>А вообще, идея с собственным компилятором не так и плоха в контексте данной задачи. Например, имея собственный компилятор можно сделать решение на чистом SSE и прогонять через него сразу пачки векторов при отсутствии логики ветвления в описании геометрии. А то даже и GPU прикрутить.

S>Однако, ресурсы!!!
а вот это уже зависит от того, насколько критична производительность. полагаю, векторный обсчет на gpu может сильно перекрыть трудозатраты на разработку.
Re[10]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 01.06.09 22:14
Оценка:
Здравствуйте, Antikrot, Вы писали:

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


S>>А вообще, идея с собственным компилятором не так и плоха в контексте данной задачи. Например, имея собственный компилятор можно сделать решение на чистом SSE и прогонять через него сразу пачки векторов при отсутствии логики ветвления в описании геометрии. А то даже и GPU прикрутить.

S>>Однако, ресурсы!!!
A>а вот это уже зависит от того, насколько критична производительность. полагаю, векторный обсчет на gpu может сильно перекрыть трудозатраты на разработку.

Не критична. Это я теоретизирую. В НИИ, где я работал несколько лет назад (откуда собственно задача), такому решению бы безусловно обрадовались, но их вполне устраивает интерпретатор, написанный на фортране кучу лет назад. Может и не устраивает, но что-то предпринимать по этому поводу они вряд ли будут.
Re[13]: С# vs C++, голые цифры
От: and1  
Дата: 03.06.09 08:23
Оценка: +1
Здравствуйте, Antikrot, Вы писали:

A>отлично, все как надо. абсолютно масштабируемая программа (итерации внешнего цикла-то независимые)

A>у меня было 18 с чем-то секунд на 2х ядрах по 2.4GHz, у тебя 9 на четырех таких же

IID>>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.

A>видел бы это Шеридан

[offtop]
Чтоб дойти до этой ветки Шеридану надо знать, что в результате полемики C# vs C++ в конкретной задаче получится нужный для его дальнейших войн вывод. А так, как для этого надо еще все ветки прочитать и даже заинтересоваться реализацией алгоритмов... ИМХО этого он не выдержит...
[/offtop]
Re[14]: С# vs C++, голые цифры
От: Sheridan Россия  
Дата: 03.06.09 17:36
Оценка: +1
and1 wrote:
> IID>>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.
> A>видел бы это Шеридан

> [offtop]

> Чтоб дойти до этой ветки Шеридану надо знать, что в результате полемики C# vs C++ в конкретной
>
задаче получится нужный для его дальнейших войн вывод. А так, как для этого надо еще все
> ветки прочитать и даже заинтересоваться реализацией алгоритмов... ИМХО этого он не выдержит...
> [/offtop]
Я КСВ если и не читаю полностью, то хотябы пробегаю взглядом практически каждое сообщение.

По сабжу: я и так __вижу__, что дотнет приложения заметно тормозят на __любой__ технике. Лично мне кажется что надо быть самому
тормозом, чтобы этого не видеть. Либо надо быть программистом и писать при помощи дотнета. В последнем случае лишь самолюбие не
дает согласиться что таки да, софт тормозной выходит.
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re[15]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.06.09 18:03
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

S>and1 wrote:

>> IID>>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.
>> A>видел бы это Шеридан

>> [offtop]

>> Чтоб дойти до этой ветки Шеридану надо знать, что в результате полемики C# vs C++ в конкретной
>>
задаче получится нужный для его дальнейших войн вывод. А так, как для этого надо еще все
>> ветки прочитать и даже заинтересоваться реализацией алгоритмов... ИМХО этого он не выдержит...
>> [/offtop]
S>Я КСВ если и не читаю полностью, то хотябы пробегаю взглядом практически каждое сообщение.

S>По сабжу: я и так __вижу__, что дотнет приложения заметно тормозят на __любой__ технике. Лично мне кажется что надо быть самому

S>тормозом, чтобы этого не видеть. Либо надо быть программистом и писать при помощи дотнета. В последнем случае лишь самолюбие не
S>дает согласиться что таки да, софт тормозной выходит.
Не будь голословным. Сразу приводи название софта, который "заметно тормозит".
И сразу придумай определение заметности тормозов.
И желательно показазывай нетормозящие аналоги, а то пока сравнить не с чем тормоза условны.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[2]: С# vs C++, голые цифры
От: shrecher  
Дата: 03.06.09 18:03
Оценка: +2
Здравствуйте, minorlogic, Вы писали:

M>Ты не видишь очевидных вещей.


M>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок.


Очень спорное утверждение. Возможно средне-типовые задачи, типа сделать выборку и БД или простенькую формочку соединить со стандартным контролом делается пару кликов мыши, почти без кода.

Когда же наступает пора сделать что-то не поддерживаемое фреймворком, к примеру интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной маршалинг.

M>Поэтому высвободившееся время можно использовать для оптимизации на более эффективных алгоритмов.


Да?! Или на чашку кофе.

M>Именно поэтому когда доходит до реальных примеров, использования шарпа дает преимущество, а С++ прошлый век.


Большинство софта С++ и пока что переход на C# не намечается.
Re[16]: С# vs C++, голые цифры
От: Sheridan Россия  
Дата: 03.06.09 18:10
Оценка:
gandjustas wrote:

> Сразу приводи название софта, который "заметно тормозит".

rsdn@home vs. knode например

> И сразу придумай определение заметности тормозов.

Да тупо отрисовка и реакция на пользователя.
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re[3]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.06.09 18:11
Оценка: :)
Здравствуйте, shrecher, Вы писали:

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


M>>Ты не видишь очевидных вещей.


M>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок.

S>Очень спорное утверждение.
Не придуривайся, это уже давно факт.

S>Возможно средне-типовые задачи, типа сделать выборку и БД или простенькую формочку соединить со стандартным контролом делается пару кликов мыши, почти без кода.

Ты только таким занимаешься?
Под быстрым написанием кода имеется ввиду именно написание кода.


S>Когда же наступает пора сделать что-то не поддерживаемое фреймворком, к примеру интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной маршалинг.


И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?
Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?


M>>Именно поэтому когда доходит до реальных примеров, использования шарпа дает преимущество, а С++ прошлый век.

S>Большинство софта С++ и пока что переход на C# не намечается.
Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается?
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[17]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.06.09 18:15
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>gandjustas wrote:


>> Сразу приводи название софта, который "заметно тормозит".

S>rsdn@home vs. knode например
Там тормозит нативная БД вроде как.

>> И сразу придумай определение заметности тормозов.

S>Да тупо отрисовка и реакция на пользователя.
Тупо отрисовка — это сплошной нэтив. Считй что ты сравниваешь один нэтив фреймворк с другим.

Кстати, покажи в каком WPF приложении тормозит "тупо отрисовка".
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[4]: С# vs C++, голые цифры
От: shrecher  
Дата: 03.06.09 18:19
Оценка:
Здравствуйте, gandjustas, Вы писали:

M>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок.

S>>Очень спорное утверждение.
G>Не придуривайся, это уже давно факт.

Факт — в парочке компаний, а везде С++

S>>Когда же наступает пора сделать что-то не поддерживаемое фреймворком, к примеру интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной маршалинг.


G>И какой процет таких задач?


Очень большой, т.к количество производимого софта на C++ очень большое. Поэтому если надо что-то итегирирвать, то C++ в большинстве случаев предпочтительней.

G>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?


Интерефейсы нужно делать на C, а внутри C++, тогда потрабельней.

S>>Большинство софта С++ и пока что переход на C# не намечается.

G>Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается?

Практически весь софт, включая MS Office, Adobe, Skype, и пр. пишется на C++. Перехода на C# даже на горизонте нет
Re[5]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.06.09 18:24
Оценка: :)
Здравствуйте, shrecher, Вы писали:

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


M>>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок.

S>>>Очень спорное утверждение.
G>>Не придуривайся, это уже давно факт.
S>Факт — в парочке компаний, а везде С++
Это вообще во всех компаниях. Отсуствие ручного управления памятью в разы увеличивает скорость разработки.

S>>>Когда же наступает пора сделать что-то не поддерживаемое фреймворком, к примеру интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной маршалинг.


G>>И какой процет таких задач?

S>Очень большой, т.к количество производимого софта на C++ очень большое. Поэтому если надо что-то итегирирвать, то C++ в большинстве случаев предпочтительней.
Ну я несколько лет пишу на .NET, всего пару раз пришлось столкнутся с интеропом, проблем вообще никаких.
Сам то ты на .NET пишешь и интероп делаешь?

G>>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?

S>Интерефейсы нужно делать на C, а внутри C++, тогда потрабельней.

Когда же наступает пора C++ интегрировать Win32 DLL и кучей callback, то тогда идут мучения и сплошной C.



S>>>Большинство софта С++ и пока что переход на C# не намечается.

G>>Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается?
S>Практически весь софт, включая MS Office, Adobe, Skype, и пр. пишется на C++. Перехода на C# даже на горизонте нет
Значит не усвоил.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[6]: С# vs C++, голые цифры
От: shrecher  
Дата: 03.06.09 18:34
Оценка: +1 -1 :)
Здравствуйте, gandjustas, Вы писали:



S>>>>Большинство софта С++ и пока что переход на C# не намечается.

G>>>Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается?
S>>Практически весь софт, включая MS Office, Adobe, Skype, и пр. пишется на C++. Перехода на C# даже на горизонте нет
G>Значит не усвоил.

Я понимаю ваше волнение и пережвание из-за неверно выбранной специализации. Тут вомногом виноват MS со своей промывкой мозгов.

Ну ничего, можно еще бросить этот убогий C#. Переходите хоть на Питон.
Re[18]: С# vs C++, голые цифры
От: Sheridan Россия  
Дата: 03.06.09 18:38
Оценка:
gandjustas wrote:

>>> Сразу приводи название софта, который "заметно тормозит".

> S>rsdn@home vs. knode например
> Там тормозит нативная БД вроде как.
И изза этого окно при перетаскивании не отрисовывалось?


> Тупо отрисовка — это сплошной нэтив. Считй что ты сравниваешь один нэтив фреймворк с другим.

И что? Это както лишает приложение тормозов?

> Кстати, покажи в каком WPF приложении тормозит "тупо отрисовка".

В любом. ___Любое___ дотнет приложение, которое я когда-либо видел — так или иначе тормозило.
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re[19]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.06.09 19:11
Оценка: -1 :))
Здравствуйте, Sheridan, Вы писали:

S>gandjustas wrote:


>>>> Сразу приводи название софта, который "заметно тормозит".

>> S>rsdn@home vs. knode например
>> Там тормозит нативная БД вроде как.
S>И изза этого окно при перетаскивании не отрисовывалось?
???
Это надо как-то особенно писать, .NET по-умолчанию так не умеет.


>> Тупо отрисовка — это сплошной нэтив. Считй что ты сравниваешь один нэтив фреймворк с другим.

S>И что? Это както лишает приложение тормозов?
Это как-то связано с .NET?


>> Кстати, покажи в каком WPF приложении тормозит "тупо отрисовка".

S>В любом. ___Любое___ дотнет приложение, которое я когда-либо видел — так или иначе тормозило.
Это вообще философский вопрос. Любое приложение так или иначе тормозит, потому что его скорость работы конечна.
Более того, все компьютеры тормозят и тормозить будут всегда, потому что конечна скорость света.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[7]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.06.09 19:12
Оценка:
Здравствуйте, shrecher, Вы писали:

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




S>>>>>Большинство софта С++ и пока что переход на C# не намечается.

G>>>>Какого софта? Ты еще не усвоил по каким причинам некоторый софт пока на неуправляемых языках делается?
S>>>Практически весь софт, включая MS Office, Adobe, Skype, и пр. пишется на C++. Перехода на C# даже на горизонте нет
G>>Значит не усвоил.

S>Я понимаю ваше волнение и пережвание из-за неверно выбранной специализации. Тут вомногом виноват MS со своей промывкой мозгов.

Не завидуй.

S>Ну ничего, можно еще бросить этот убогий C#. Переходите хоть на Питон.

Да я и так питон пользую.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[4]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 04.06.09 07:48
Оценка:
Здравствуйте, gandjustas, Вы писали:

M>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок.

S>>Очень спорное утверждение.
G>Не придуривайся, это уже давно факт.
Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.

G>И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?

G>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
Пример с CreateThread в который передается метод в качестве функции потока тебя устроит?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 04.06.09 07:48
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это вообще во всех компаниях. Отсуствие ручного управления памятью в разы увеличивает скорость разработки.

Использование например STL контейнеров это ручное управление памятью?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 04.06.09 11:43
Оценка: 1 (1) +2
Здравствуйте, gandjustas, Вы писали:

G>Это вообще во всех компаниях. Отсуствие ручного управления памятью в разы увеличивает скорость разработки.

На С++ можно вполне избежать ручного управления памятью. Вот то, что в C# нельзя управлять вручную, это вполне может оказаться серьёзным недостатком .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[5]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 18:22
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


M>>>>Код на шарпе пишется намного быстрее и с меньшим к-вом ошибок.

S>>>Очень спорное утверждение.
G>>Не придуривайся, это уже давно факт.
CC>Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.
Теже индусы на C++ создавали бы код с гораздо большим количеством ошибок.

G>>И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?

G>>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
CC>Пример с CreateThread в который передается метод в качестве функции потока тебя устроит?
Не устроит, нужен именно способ, а не пример функции, на которой это как-то работает.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[7]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 18:27
Оценка: -1
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Это вообще во всех компаниях. Отсуствие ручного управления памятью в разы увеличивает скорость разработки.

DC>На С++ можно вполне избежать ручного управления памятью.
Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

DC>Вот то, что в C# нельзя управлять вручную, это вполне может оказаться серьёзным недостатком .

Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[8]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 04.06.09 18:35
Оценка:
Здравствуйте, gandjustas, Вы писали:

DC>>Вот то, что в C# нельзя управлять вручную, это вполне может оказаться серьёзным недостатком .

G>Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.
Я могу. Поднапрячь LOH слегка. Есть такие реальные сценарии, где LOH капитально подводит. Очень не хватает ручного управления.
Re[9]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 18:48
Оценка:
Здравствуйте, samius, Вы писали:

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


DC>>>Вот то, что в C# нельзя управлять вручную, это вполне может оказаться серьёзным недостатком .

G>>Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.
S>Я могу. Поднапрячь LOH слегка. Есть такие реальные сценарии, где LOH капитально подводит. Очень не хватает ручного управления.
И прямо совсем нельзя оптимизировать?
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[10]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 04.06.09 19:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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


G>>>Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.

S>>Я могу. Поднапрячь LOH слегка. Есть такие реальные сценарии, где LOH капитально подводит. Очень не хватает ручного управления.
G>И прямо совсем нельзя оптимизировать?
Речь идет об численной обработке больших снимков (автоматизированная медицинская диагностика). Один снимок порядка полусотни мегабайт. С ним надо сделать N-ое количество манипуляций. Память фрагментируется — шуба заворачивается. Начали с того, что приложение за пол часа работы уходит в жесткий и глубокий свап при реальных потребностях всего в 400Мб памяти в пике.
Оптимизировать? Можно, но это слишком трудозатратно. Предложения выделять память под снимки строками или переводить математику на unsafe всерьез не рассматриваются. Можно обрабатывать снимки кусками, но там и так довольно много нетривиальных вычислений, усугублять их не хотелось бы.
Выкручиваемся с помощью пулинга. Жизнь приложения продлили. Но стопудовых гарантий что не упадет нет.

З.Ы. Неконтроллируемых висячих ссылок нет.
Re[11]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 19:20
Оценка:
Здравствуйте, samius, Вы писали:

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


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


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


G>>>>Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.

S>>>Я могу. Поднапрячь LOH слегка. Есть такие реальные сценарии, где LOH капитально подводит. Очень не хватает ручного управления.
G>>И прямо совсем нельзя оптимизировать?
S>Речь идет об численной обработке больших снимков (автоматизированная медицинская диагностика). Один снимок порядка полусотни мегабайт. С ним надо сделать N-ое количество манипуляций. Память фрагментируется — шуба заворачивается. Начали с того, что приложение за пол часа работы уходит в жесткий и глубокий свап при реальных потребностях всего в 400Мб памяти в пике.
Откуда фрагментация памяти? как раз тот случай когда выделять память и не надо, максимум создать пул буферов под картинки и работать с ними.

S>Оптимизировать? Можно, но это слишком трудозатратно. Предложения выделять память под снимки строками или переводить математику на unsafe всерьез не рассматриваются. Можно обрабатывать снимки кусками, но там и так довольно много нетривиальных вычислений, усугублять их не хотелось бы.

Выделить один раз столько сколько нужно и все.
LOH устати также работат как среднестатистическая куча в C++, и надо соотвествующие методы применять.

S>Выкручиваемся с помощью пулинга. Жизнь приложения продлили. Но стопудовых гарантий что не упадет нет.

Ну это собственно единственный способ работы с такими объемами, причем независимо от языка и платформы.
Еще вариант — выделять буферы как можно раньше.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[12]: С# vs C++, голые цифры
От: samius Россия http://sams-tricks.blogspot.com
Дата: 04.06.09 19:53
Оценка: 3 (1)
Здравствуйте, gandjustas, Вы писали:

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


S>>Речь идет об численной обработке больших снимков (автоматизированная медицинская диагностика). Один снимок порядка полусотни мегабайт. С ним надо сделать N-ое количество манипуляций. Память фрагментируется — шуба заворачивается. Начали с того, что приложение за пол часа работы уходит в жесткий и глубокий свап при реальных потребностях всего в 400Мб памяти в пике.

G>Откуда фрагментация памяти? как раз тот случай когда выделять память и не надо, максимум создать пул буферов под картинки и работать с ними.
Все не так просто. Там большой конвейер, на каждом этапе используются массивы разных типов. Зарезервировать память под все не получится — тупо не хватит. Что-то пулить можно, что-то нельзя. Закладываться на максимальный размер снимков тоже не можем, да и числорубок может быть несколько (по числу процессоров).

S>>Оптимизировать? Можно, но это слишком трудозатратно. Предложения выделять память под снимки строками или переводить математику на unsafe всерьез не рассматриваются. Можно обрабатывать снимки кусками, но там и так довольно много нетривиальных вычислений, усугублять их не хотелось бы.

G>Выделить один раз столько сколько нужно и все.
Ответил выше.
G>LOH устати также работат как среднестатистическая куча в C++, и надо соотвествующие методы применять.
Среднего пошиба куча из C++ нас бы устроила больше, т.к. она как раз поддается ручному контролю распределения памяти. В дотнете тоже можно, но нельзя работать с выделенной памятью как с массивом аки byte[]. А если сделал new byte[], то через минуту нельзя его использовать как массив ushort[].

S>>Выкручиваемся с помощью пулинга. Жизнь приложения продлили. Но стопудовых гарантий что не упадет нет.

G>Ну это собственно единственный способ работы с такими объемами, причем независимо от языка и платформы.
Согласен, но в управляемых платформах нет возможности строить планы по распределению памяти, ориентированные на задачу.
G>Еще вариант — выделять буферы как можно раньше.
Хороший вариант, но не совсем наш. Используем такие трюки как принудительная дефрагментация со сбросом актуальных данных на диск (с приостановкой счета), собственноручное прогнозирование выделения памяти, немного другое чем MemoryFailPoint и т.п.
Впрочем, пока бороться получается, перетаскивать кухню на C++ желающих нет, да и необходимости такой нет.
Re[6]: С# vs C++, голые цифры
От: shrecher  
Дата: 04.06.09 21:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

CC>>Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.

G>Теже индусы на C++ создавали бы код с гораздо большим количеством ошибок.

Если индивидум не умеет программировать, то тут уже ничего не поделать. Главное это не зависит от национальности и языка программирования.
Re[6]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 05.06.09 07:18
Оценка:
Здравствуйте, gandjustas, Вы писали:

CC>>Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.

G>Теже индусы на C++ создавали бы код с гораздо большим количеством ошибок.
Их продукт на С++ бы вообще не вышел, чем сильно облегчил бы нам жизнь.

G>>>И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?

G>>>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
CC>>Пример с CreateThread в который передается метод в качестве функции потока тебя устроит?
G>Не устроит, нужен именно способ, а не пример функции, на которой это как-то работает.
Способ простой:

template <class CLASS, DWORD(CLASS::*__thunkPtr)()> 
DWORD WINAPI CallbackThunk (void* __ptr)
{
    return (((CLASS*)__ptr)->*__thunkPtr)();
}

class MyClass
{
...
  DWORD MyFunc ();
...
};

MyClass classInstance;
CreateThread(0, 0, CallbackThunk<MyClass, &MyClass::myFunc>, &classInstance, 0, 0);
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 08:23
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


CC>>>Расскажи это индусам. А то они не знают и говнокодят на шарпе так, что только брызги летят.

G>>Теже индусы на C++ создавали бы код с гораздо большим количеством ошибок.
CC>Их продукт на С++ бы вообще не вышел, чем сильно облегчил бы нам жизнь.
Эт о зависит от маркетологов. Вот corel draw написан индусами на С++ и ниче.
Хотя глючный аж жуть.


G>>>>И какой процет таких задач? В какого типа приложениях возникает? Какие мучения имеются ввиду?

G>>>>Кстати, в С++ есть способ передать метод объекта коллбэком в функцию winapi?
CC>>>Пример с CreateThread в который передается метод в качестве функции потока тебя устроит?
G>>Не устроит, нужен именно способ, а не пример функции, на которой это как-то работает.
CC>Способ простой:

CC>
CC>template <class CLASS, DWORD(CLASS::*__thunkPtr)()> 
CC>DWORD WINAPI CallbackThunk (void* __ptr)
CC>{
CC>    return (((CLASS*)__ptr)->*__thunkPtr)();
CC>}

CC>class MyClass
CC>{
CC>...
CC>  DWORD MyFunc ();
CC>...
CC>};

CC>MyClass classInstance;
CC>CreateThread(0, 0, CallbackThunk<MyClass, &MyClass::myFunc>, &classInstance, 0, 0);
CC>


А теперь для SetWindowsHookEx.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[8]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 05.06.09 08:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А теперь для SetWindowsHookEx.

Ну а сюда уже тока статические методы by design самого механизма хуков.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: С# vs C++, голые цифры
От: Antikrot  
Дата: 05.06.09 08:50
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>А теперь для SetWindowsHookEx.

а что, на C# можно? (я просто не в курсе)
Re[9]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 09:06
Оценка: -1 :)
Здравствуйте, Antikrot, Вы писали:

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


G>>А теперь для SetWindowsHookEx.

A>а что, на C# можно? (я просто не в курсе)
Конкретно хук — вряд ли, грузить рантайм в чужой процесс наверное не получится.
А внутри одного процесса передать метод объекта коллбеком — вполне.

Пример:
using System.Runtime.InteropServices;

public delegate bool CallBackPtr(int hwnd, int lParam);

public class EnumReport
{
    int token;

    public EnumReport()
    {
        token = (new Random()).Next();
    }

    [DllImport("user32.dll")]
    public static extern int EnumWindows(CallBackPtr callPtr, int lPar);

    public bool Report(int hwnd, int lParam)
    {
        Console.WriteLine("{0}:Window handle is {1}", token, hwnd);
        return true;
    }
}

class Program
{

    static void Main()
    {
        EnumReport.EnumWindows((new EnumReport()).Report, 0);
        Console.ReadLine();
        EnumReport.EnumWindows((new EnumReport()).Report, 0);
        Console.ReadLine();
    }
}


Интероп с нэйтив кодом в C# дается весьма просто. Вот наоборот — возникают проблемы.
Хотя если использовать out-proc COM сервер, то и проблем нету.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[9]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 09:15
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


G>>А теперь для SetWindowsHookEx.

CC>Ну а сюда уже тока статические методы by design самого механизма хуков.
Ну а попроще, типа EnumWindows
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[10]: С# vs C++, голые цифры
От: IID Россия  
Дата: 05.06.09 09:27
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну а попроще, типа EnumWindows


Ну дык там lParam есть, в котором передаём this, и уже по нему вызываем обработчик класса. Если надо в свой обработчик ещё и свой контекст передавать — тоже элементарно. В оригинальый EnumWindows в lParam передаеём указатель на прокси с двумя полями: this и контекст.
kalsarikännit
Re[11]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 09:42
Оценка:
Здравствуйте, IID, Вы писали:

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


G>>Ну а попроще, типа EnumWindows


IID>Ну дык там lParam есть, в котором передаём this, и уже по нему вызываем обработчик класса. Если надо в свой обработчик ещё и свой контекст передавать — тоже элементарно. В оригинальый EnumWindows в lParam передаеём указатель на прокси с двумя полями: this и контекст.

Еще раз: хаки не нтересуют, интересует общий способ, как в моем примере на шарпе.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[8]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 05.06.09 11:39
Оценка: 1 (1) +1
Здравствуйте, gandjustas, Вы писали:

G>Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

Ну почему же сразу счётчики ссылок? Можно организовать такую схему что мы ничего удалять руками не будем, т.е. в коде будем только выделять память или вообще всё будет крутиться в статических буферах. Если мы перекладываем управление на железку вполне логично что это требует ресурсов, оверхед от счётчиков небольшой, время освобождения ресурса детерминировано.

G>Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.

Да я и искать то не буду, GC дотнетовский хорош, но он заточен на вполне определённый круг сценариев работы (ну нельзя впихнуть невпихуемое), как только мы натыкаемся на такой сценарий, начинается борьба с GC, её можно облегчить сделав GC расширяемым, но про такое я ещё не слышал. А в плюсах всё просто — не нравится автобус, взял написал горный велосипед и поехал по горным тропам .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[12]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 05.06.09 11:42
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Еще раз: хаки не нтересуют, интересует общий способ, как в моем примере на шарпе.

Да, тебя, кажется, вообще C++ не интересует, как и то что его помощью сделать можно.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[9]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 15:05
Оценка: +1
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

DC>Ну почему же сразу счётчики ссылок? Можно организовать такую схему что мы ничего удалять руками не будем, т.е. в коде будем только выделять память или вообще всё будет крутиться в статических буферах.
Не надо выдумывать небылицы. Хоть один серьезный продукт так написан?

DC>Если мы перекладываем управление на железку вполне логично что это требует ресурсов, оверхед от счётчиков небольшой, время освобождения ресурса детерминировано.

Счетчики ссылок требуют синхронизации, что сказывается на производительности в многопоточных системах. Кроме того они слабо умеют разаруливать циклические ссылки.

G>>Может, но не оказывается. Ты вряд ли придумаешь сценарий работы с памятью, где GC будет сливать ручному управлению в быстродействию.

DC>Да я и искать то не буду, GC дотнетовский хорош, но он заточен на вполне определённый круг сценариев работы (ну нельзя впихнуть невпихуемое), как только мы натыкаемся на такой сценарий, начинается борьба с GC, её можно облегчить сделав GC расширяемым, но про такое я ещё не слышал.
В том то и дело что GC, по крайней мере в .NET, рассчитан на огромное число сценариев работы. Главное ему не мешать, и уж тем более не пытться помогать.

DC>А в плюсах всё просто — не нравится автобус, взял написал горный велосипед и поехал по горным тропам .

На словах просто, а на деле большое количество велосипедов делаю очень тяжелой поддержку. При этом далеко не факт что кучи велосипедов будут работать быстрее GC.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[13]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.06.09 15:08
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Еще раз: хаки не нтересуют, интересует общий способ, как в моем примере на шарпе.

DC>Да, тебя, кажется, вообще C++ не интересует, как и то что его помощью сделать можно.
Ну если бы не интересовал, то я бы сюда не писал.
А если че — я в течение 5 лет писал на С++.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[10]: С# vs C++, голые цифры
От: jazzer Россия Skype: enerjazzer
Дата: 12.06.09 18:45
Оценка: +3
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, dr.Chaos, Вы писали:


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


G>>>Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

DC>>Ну почему же сразу счётчики ссылок? Можно организовать такую схему что мы ничего удалять руками не будем, т.е. в коде будем только выделять память или вообще всё будет крутиться в статических буферах.
G>Не надо выдумывать небылицы. Хоть один серьезный продукт так написан?

дофига.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: С# vs C++, голые цифры
От: criosray  
Дата: 12.06.09 23:04
Оценка:
Здравствуйте, jazzer, Вы писали:


G>>>>Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

DC>>>Ну почему же сразу счётчики ссылок? Можно организовать такую схему что мы ничего удалять руками не будем, т.е. в коде будем только выделять память или вообще всё будет крутиться в статических буферах.
G>>Не надо выдумывать небылицы. Хоть один серьезный продукт так написан?

J>дофига.


Перефразирю: серьезный не заваленный по срокам и не глючный продукт.
Re[12]: С# vs C++, голые цифры
От: VoidEx  
Дата: 12.06.09 23:09
Оценка: -1
Здравствуйте, criosray, Вы писали:

J>>дофига.


C>Перефразирю: серьезный не заваленный по срокам и не глючный продукт.


Ответ тебе тоже перефразировать или он и так понятен?
Re[12]: С# vs C++, голые цифры
От: jazzer Россия Skype: enerjazzer
Дата: 13.06.09 03:11
Оценка: +3 -1 :)
Здравствуйте, criosray, Вы писали:

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



G>>>>>Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

DC>>>>Ну почему же сразу счётчики ссылок? Можно организовать такую схему что мы ничего удалять руками не будем, т.е. в коде будем только выделять память или вообще всё будет крутиться в статических буферах.
G>>>Не надо выдумывать небылицы. Хоть один серьезный продукт так написан?

J>>дофига.


C>Перефразирю: серьезный не заваленный по срокам и не глючный продукт.


дофига.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: С# vs C++, голые цифры
От: FR  
Дата: 13.06.09 03:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

DC>>Ну почему же сразу счётчики ссылок? Можно организовать такую схему что мы ничего удалять руками не будем, т.е. в коде будем только выделять память или вообще всё будет крутиться в статических буферах.
G>Не надо выдумывать небылицы. Хоть один серьезный продукт так написан?

Нормальная практика у игроделов, используется несколько пулов памяти (глобальный, на уровень, временный) динамическое выделение вне пулов не происходит совсем, освобождение практически тоже при завершеннии программы. Подробнее тут http://www.dtf.ru/articles/print.php?id=4071
У эмдебщиков все еще жестче.
Re[13]: С# vs C++, голые цифры
От: criosray  
Дата: 13.06.09 07:09
Оценка:
Здравствуйте, VoidEx, Вы писали:

J>>>дофига.


C>>Перефразирю: серьезный не заваленный по срокам и не глючный продукт.


VE>Ответ тебе тоже перефразировать или он и так понятен?


Нет. Не понятен. Названия / ссылки в студию, как говорится.
Re[14]: С# vs C++, голые цифры
От: FR  
Дата: 13.06.09 07:20
Оценка:
Здравствуйте, criosray, Вы писали:

VE>>Ответ тебе тоже перефразировать или он и так понятен?


C>Нет. Не понятен. Названия / ссылки в студию, как говорится.


Ссылка практически на любую крупную игру которая идет на игровых консолях.
Re[15]: С# vs C++, голые цифры
От: criosray  
Дата: 13.06.09 07:24
Оценка:
Здравствуйте, FR, Вы писали:

VE>>>Ответ тебе тоже перефразировать или он и так понятен?


C>>Нет. Не понятен. Названия / ссылки в студию, как говорится.


FR>Ссылка практически на любую крупную игру которая идет на игровых консолях.


Кроме игр на консолях?
Re[16]: С# vs C++, голые цифры
От: FR  
Дата: 13.06.09 07:32
Оценка:
Здравствуйте, criosray, Вы писали:


FR>>Ссылка практически на любую крупную игру которая идет на игровых консолях.


C>Кроме игр на консолях?


Приложения для недокомпьютеров работающих под операционками подобными PowerTV,
без виртуальной памяти ссылок нет, например мы писали под подобное устройство
программы работы с графикой и портировали казуальные игры.
Re[17]: С# vs C++, голые цифры
От: criosray  
Дата: 13.06.09 07:48
Оценка:
Здравствуйте, FR, Вы писали:

FR>>>Ссылка практически на любую крупную игру которая идет на игровых консолях.


C>>Кроме игр на консолях?


FR>Приложения для недокомпьютеров работающих под операционками подобными PowerTV,

FR>без виртуальной памяти ссылок нет, например мы писали под подобное устройство
FR>программы работы с графикой и портировали казуальные игры.

Ок. Что на счет полноценных компьютеров — PC?
Re[11]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.06.09 09:56
Оценка: :)
Здравствуйте, FR, Вы писали:

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


G>>>>Да проходили это сотню раз, можно использовать shared_ptr или аналоги, но они замедляют программу, и какой тогда смысл писать на С++?

DC>>>Ну почему же сразу счётчики ссылок? Можно организовать такую схему что мы ничего удалять руками не будем, т.е. в коде будем только выделять память или вообще всё будет крутиться в статических буферах.
G>>Не надо выдумывать небылицы. Хоть один серьезный продукт так написан?

FR>Нормальная практика у игроделов, используется несколько пулов памяти (глобальный, на уровень, временный) динамическое выделение вне пулов не происходит совсем, освобождение практически тоже при завершеннии программы. Подробнее тут http://www.dtf.ru/articles/print.php?id=4071

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


FR>У эмдебщиков все еще жестче.

Там где идут жесткие ограничения начинается совсем другая работа.
Сам разрабатывал для dsp-процессоров, большую часть времени убил на то как впихнуть восьмикилобайтный буфер в два килобайта.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[18]: С# vs C++, голые цифры
От: VoidEx  
Дата: 13.06.09 18:51
Оценка:
Здравствуйте, criosray, Вы писали:

C>Ок. Что на счет полноценных компьютеров — PC?


Можно сразу список всех условий?
Re[19]: С# vs C++, голые цифры
От: criosray  
Дата: 13.06.09 18:56
Оценка:
Здравствуйте, VoidEx, Вы писали:

C>>Ок. Что на счет полноценных компьютеров — PC?


VE>Можно сразу список всех условий?


Условие одно: нормальные условия, а не какая-то экзотика. А то давайте еще особенности программирования микроконтролеров обсудим.
Re[20]: С# vs C++, голые цифры
От: jazzer Россия Skype: enerjazzer
Дата: 16.06.09 03:57
Оценка: +1 -2
Здравствуйте, criosray, Вы писали:

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


C>>>Ок. Что на счет полноценных компьютеров — PC?


VE>>Можно сразу список всех условий?


C>Условие одно: нормальные условия, а не какая-то экзотика. А то давайте еще особенности программирования микроконтролеров обсудим.


А тебе этого недостаточно?
Вопрос, напоминаю, звучал так: "Не надо выдумывать небылицы. Хоть один серьезный продукт так написан?"
Ответ дан, с примерами: тысячи серьезных продуктов.
На каких они платформах — дело десятое.
Так что если опровержения по сути (а не "мне твой пример не нравится, придумай другой") не предвидится, то вопрос закрыт.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[20]: С# vs C++, голые цифры
От: Eugeny__ Украина  
Дата: 16.06.09 07:04
Оценка: +1
Здравствуйте, criosray, Вы писали:

C>>>Ок. Что на счет полноценных компьютеров — PC?


VE>>Можно сразу список всех условий?


C>Условие одно: нормальные условия, а не какая-то экзотика. А то давайте еще особенности программирования микроконтролеров обсудим.


Безотносительно к спору, то есть оффтоп(хотя, в этом форуме можно и не предупреждать).

Вот у меня дома сейчас ноут с линухом, обычный комп с виндой, телефон с симбианом, 3 разных портативных плеера с хз чем, DVD-проигрыватель, телик(пусть и не юзается, но есть), POS-терминал(тестовый, с работы). У обычного компа есть еще монитор с собственной независимой настройкой(т.е. там есть определенное ПО). А, еще где-то в закромах Sega валяется, иногда ностальгируем.

Все эти устройства содержат ПО. К "нормальным" по твоему критерию можно отнести комп с виндой, ну, может, еще ноут. Что в общем зачете не так уж и много.

А теперь вопрос, почему мы обязательно должны опускать программинг под все эти девайсы? В реальной жизни такое ПО используется очень активно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[21]: С# vs C++, голые цифры
От: jazzer Россия Skype: enerjazzer
Дата: 16.06.09 09:39
Оценка: -1
2 gandjustas:
C чем не согласен-то?
Или мой ответ тоже просто не нравится, без аргументов?

Тебе сказали: "Есть техника А".
Ты сказал, что этой техникой всерьез не пользуется, и попросил привести примеры обратного.
Тебе их привели.
После этого, в принципе, действительно есть только два пути: либо согласиться, что тебе на вопрос ответили и ты был неправ, либо молча раздавать минусы.
Жаль, что ты выбрал второе.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 16.06.09 11:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Не надо выдумывать небылицы. Хоть один серьезный продукт так написан?

Ну ту мне добавить к ответам других особо нечего .

DC>>Если мы перекладываем управление на железку вполне логично что это требует ресурсов, оверхед от счётчиков небольшой, время освобождения ресурса детерминировано.

G>Счетчики ссылок требуют синхронизации, что сказывается на производительности в многопоточных системах. Кроме того они слабо умеют разаруливать циклические ссылки.
Ну многопоточный GC тоже требует накладных расходов на синхронизацию, кроме того если у меня будет затык именно в синхронизации счётчиков, то я вполне могу убрать его нафиг и управлять вручную. Да и, честно говоря, разделять объект между двумя нитями не самая хорошая идея, я бы даже при наличии GC так делать по-возможности не стал.

G>В том то и дело что GC, по крайней мере в .NET, рассчитан на огромное число сценариев работы. Главное ему не мешать, и уж тем более не пытться помогать.

Ну точно помню, что Cyberaxe говорил что он со свапом не дружит. Вот тут про картинки речь шла. Вобщем, я не настолько хорошо знаю его особенности чтоб предметно обсуждать его узкие места, но ручное управление памятью он не обойдёт, правда управлять памятью вручную дороже.

G>На словах просто, а на деле большое количество велосипедов делаю очень тяжелой поддержку. При этом далеко не факт что кучи велосипедов будут работать быстрее GC.

Велосипед может не претендовать на универсальность, и за счёт этого быть простым и быстрым или распадаться на несколько простых вариантов, которые могут быть довольно просты в поддержке. Только использование всего этого зоопарка, вероятнее, будет требовать большей аккуратности, чем просто дать всё на откуп GC, правда в умелых руках и GC может просесть.

Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[11]: С# vs C++, голые цифры
От: kuj  
Дата: 16.06.09 19:59
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.


Эт точно. :>
Re[11]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 16.06.09 20:29
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>>>Если мы перекладываем управление на железку вполне логично что это требует ресурсов, оверхед от счётчиков небольшой, время освобождения ресурса детерминировано.

G>>Счетчики ссылок требуют синхронизации, что сказывается на производительности в многопоточных системах. Кроме того они слабо умеют разаруливать циклические ссылки.
DC>Ну многопоточный GC тоже требует накладных расходов на синхронизацию, кроме того если у меня будет затык именно в синхронизации счётчиков, то я вполне могу убрать его нафиг и управлять вручную.
Не требует.

DC>Да и, честно говоря, разделять объект между двумя нитями не самая хорошая идея, я бы даже при наличии GC так делать по-возможности не стал.

Тут речь идет не об объектах, а о выделении памяти.

G>>В том то и дело что GC, по крайней мере в .NET, рассчитан на огромное число сценариев работы. Главное ему не мешать, и уж тем более не пытться помогать.

DC>Ну точно помню, что Cyberaxe говорил что он со свапом не дружит. Вот тут про картинки речь шла. Вобщем, я не настолько хорошо знаю его особенности чтоб предметно обсуждать его узкие места, но ручное управление памятью он не обойдёт, правда управлять памятью вручную дороже.
Ну если брать сферического программиста в вакууме, который никогда не ошибается, то да.
В реальности программы пишут живые люди средней квалификации, большинство из котороых и не особо знает как можно ускорить работу с памятью в C++.

G>>На словах просто, а на деле большое количество велосипедов делаю очень тяжелой поддержку. При этом далеко не факт что кучи велосипедов будут работать быстрее GC.

DC>Велосипед может не претендовать на универсальность, и за счёт этого быть простым и быстрым или распадаться на несколько простых вариантов, которые могут быть довольно просты в поддержке. Только использование всего этого зоопарка, вероятнее, будет требовать большей аккуратности, чем просто дать всё на откуп GC, правда в умелых руках и GC может просесть.
Аналогично предыдущему.

DC>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.

Решение проблем С++ требует наличия GC.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[12]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 07:40
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Не требует.


Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?

G>Тут речь идет не об объектах, а о выделении памяти.

Погоди, каким боком синхронизация счётчиков и выделение памяти? Если у нас объект между нитями не разделяется то и синхронизировать ничего не надо.

G>Ну если брать сферического программиста в вакууме, который никогда не ошибается, то да.

Ну так я и сказал — дороже.

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

Ну взяли они shared_ptr и довольны как слоны .

DC>>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.

G>Решение проблем С++ требует наличия GC.

Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.

Вообще, ИМХО, эта проблема сильно преувеличена. Сделали из GC священную корову. Мне, например, в C++ намного бы полезнее были гигиенические макросы или другой простой способ построения eDSL-ей, удобный в использовании или отладке.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[13]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 07:47
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

G>>Не требует.


DC> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?


Да, работает в несколько потоков — поток на ядро, если в server mode`е.
В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.
Re[13]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 07:52
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.


DC>Вообще, ИМХО, эта проблема сильно преувеличена. Сделали из GC священную корову. Мне, например, в C++ намного бы полезнее были гигиенические макросы или другой простой способ построения eDSL-ей, удобный в использовании или отладке.


Ну конечно строить DSL`и без GC это вверх гениальности ;]
Re[14]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 08:01
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Ну конечно строить DSL`и без GC это вверх гениальности ;]

А какие проблемы?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[14]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 08:03
Оценка:
Здравствуйте, kuj, Вы писали:

DC>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?


kuj>Да, работает в несколько потоков — поток на ядро, если в server mode`е.

kuj>В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.

Меня не удивляет, то что он может работать в нескольких нитях. У меня вызывает сомнения выделенное.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[13]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 08:15
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Не требует.

DC> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?
Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков.

G>>Тут речь идет не об объектах, а о выделении памяти.

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

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

DC>Ну взяли они shared_ptr и довольны как слоны .
Который работает еще медленее.
Тогда бы уже сразу взяли .NET

DC>>>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.

G>>Решение проблем С++ требует наличия GC.
DC>Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.
А другой способ — считать ссылки, только он полон недостатков.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[15]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 08:23
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


kuj>>Ну конечно строить DSL`и без GC это вверх гениальности ;]

DC>А какие проблемы?
Перечислить по пунктам?
Re[14]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 08:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

DC>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?

G>Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков.
Ну а синхронизация счётчиков ссылок тут при чём? Да и если не устраивает стандартный аллокатор, берёшь и делаешь свой .

G>Кстати, как у вас многопоточные программы работают когда нету разделяемых данных?

Отлично и с линейной масштабируемостью

DC>>Ну взяли они shared_ptr и довольны как слоны .

G>Который работает еще медленее.
G>Тогда бы уже сразу взяли .NET
Докажи.

G>А другой способ — считать ссылки, только он полон недостатков.

А GC недостатков не имееет?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[15]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 08:38
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?


kuj>>Да, работает в несколько потоков — поток на ядро, если в server mode`е.

kuj>>В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.

DC>Меня не удивляет, то что он может работать в нескольких нитях. У меня вызывает сомнения выделенное.


В server-mode создается несколько GC`ов — по одному на ядро. У каждого GC своя собственная managed куча. Каждый пользовательский поток получает место в одной из куч то ли рандомно то ли по очередно — точно не знаю — надо гуглить этот момент. Ну и еще там мутки с достижением gen0 лимита (примерно: если достигли лимита нулевой генерации в одной из куч, то последующие allocations будут производиться на второй/третьей/т.д. пока не будет выбран лимит и там или пока GC не наведет шмон в первой).
Re[15]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 08:40
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

G>>А другой способ — считать ссылки, только он полон недостатков.

DC>А GC недостатков не имееет?
В контексте многих (не побоюсь этого слова — большинства) задач достоинства GC с лихвой перевешивают все недостатки.
Re[15]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 08:53
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


DC>>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?

G>>Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков.
DC>Ну а синхронизация счётчиков ссылок тут при чём? Да и если не устраивает стандартный аллокатор, берёшь и делаешь свой .
Ну да, всего-то


DC>>>Ну взяли они shared_ptr и довольны как слоны .

G>>Который работает еще медленее.
G>>Тогда бы уже сразу взяли .NET
DC>Докажи.
Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный.

G>>А другой способ — считать ссылки, только он полон недостатков.

DC>А GC недостатков не имееет?
Зависит от реализации GC.
В .NETовской реализации недостатков немного, по сравнению с подсчетом ссылок.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[16]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 08:59
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>В server-mode создается несколько GC`ов — по одному на ядро. У каждого GC своя собственная managed куча. Каждый пользовательский поток получает место в одной из куч то ли рандомно то ли по очередно — точно не знаю — надо гуглить этот момент. Ну и еще там мутки с достижением gen0 лимита (примерно: если достигли лимита нулевой генерации в одной из куч, то последующие allocations будут производиться на второй/третьей/т.д. пока не будет выбран лимит и там или пока GC не наведет шмон в первой).


А если один поток передал объект другому чего происходит? Вобщем приведённое тобой не доказывает отсутствия издержек у GC.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[16]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 09:06
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Перечислить по пунктам?


Да. Причём лучше всего и для варианта реализации гигиенических макросов и для eDSL на монадах и комбинаторах a la Хаскель
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[16]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 09:07
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну да, всего-то


Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор. Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно.
Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.

DC>>Докажи.

G>Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный.
А проход GC когда бесплатным стал?

G>Зависит от реализации GC.

G>В .NETовской реализации недостатков немного, по сравнению с подсчетом ссылок.
Я тебе тоже могу сказать — зависит от реализации.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[17]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 09:23
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Ну да, всего-то


DC>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор.

Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.
Дай бог каждый сотый.

DC>Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно.

Все тоже самое что и в C++ — пулинг объектов, предварительное выделение буферов.
Тем более ты сам говришь что это маловероятно.

DC>Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.

Ну если хочется использовать подсчет ссылок в многопоточно среде, то это несет дополнительный оверхед, так как требуется синхронизация.


DC>>>Докажи.

G>>Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный.
DC>А проход GC когда бесплатным стал?
Нет, но работает он быстрее стандартного аллокатора.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[18]: С# vs C++, голые цифры
От: FR  
Дата: 17.06.09 09:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

DC>>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор.

G>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.
G>Дай бог каждый сотый.

Угу и они их давно написали и выложили, так что остальным 99% остается только скачать.
Re[18]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 10:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.

G>Дай бог каждый сотый.

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

DC>>Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно.

G>Все тоже самое что и в C++ — пулинг объектов, предварительное выделение буферов.
G>Тем более ты сам говришь что это маловероятно.

DC>>Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.

G>Ну если хочется использовать подсчет ссылок в многопоточно среде, то это несет дополнительный оверхед, так как требуется синхронизация.
А если передавать объект которым управляет GC между потоками, синхронизации не надо? Да и синхронизации будет требовать не только посчёт ссылок.

G>Нет, но работает он быстрее стандартного аллокатора.


Ну я могу сказать что ручное управление памятью в любом случае быстрее и дешевле . Вобщем ты разберись чего GC у нас быстрее shared_ptr-а или стандартного аллокатора (кстати какой имеется ввиду? Windows, Linux, у STLPort вроде что-то своё было) и можешь дать ссылки на сравнения ну или сам тест сбацать.

Короче, дискуссия скатилась к тому что быстрее .Net GC или стандартный аллокатор, мне этот диспут не очень интересен, да и влез я сюда чтоб сказать, что ручное управление памятью это скорее достоинство С++, а автоматическое управление памятью в том или ином виде есть, причём как всегда в С++, можно заточиться под свои нужды и отсутствие GC это не самый страшный недостаток плюсов. Думаю, повторять это в 4-й раз смысла не имеет.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[19]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 11:06
Оценка:
Здравствуйте, FR, Вы писали:

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


DC>>>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор.

G>>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.
G>>Дай бог каждый сотый.

FR>Угу и они их давно написали и выложили, так что остальным 99% остается только скачать.


Ссылки дашь?
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[19]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 11:14
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.

G>>Дай бог каждый сотый.

DC>Ну я думаю далеко не каждый программист на С++ натыкается на тормоза аллокации в многопоточной среде. Вообще есть мысль что стандартные аллокаторы заточены под вариант с многопоточностью, да и FR совершенно правильно заметил.

Блокировки небесплатные, даже когда работает один поток. Но эти тормоза не настолько большие, чтобы на наих обращать внимание.
Вот также и с GC, пока не происходить сборка мусора во втором поколении каждую секунду, то работа сборщика мусора не оказывает влияния на общее быстродействие.

DC>>>Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.

G>>Ну если хочется использовать подсчет ссылок в многопоточно среде, то это несет дополнительный оверхед, так как требуется синхронизация.
DC>А если передавать объект которым управляет GC между потоками, синхронизации не надо?
Не надо.

DC>Да и синхронизации будет требовать не только посчёт ссылок.

А что еще?

G>>Нет, но работает он быстрее стандартного аллокатора.


DC>Ну я могу сказать что ручное управление памятью в любом случае быстрее и дешевле .

Теоретически быстрее может быть. А практически добиться таких результатов в сложных случаях выйдет настолько дорого, что реально этим никто заниматься не будет.

DC>Вобщем ты разберись чего GC у нас быстрее shared_ptr-а или стандартного аллокатора (кстати какой имеется ввиду? Windows, Linux, у STLPort вроде что-то своё было) и можешь дать ссылки на сравнения ну или сам тест сбацать.

Тест уже был, читайте холивары.

DC>Короче, дискуссия скатилась к тому что быстрее .Net GC или стандартный аллокатор, мне этот диспут не очень интересен, да и влез я сюда чтоб сказать, что ручное управление памятью это скорее достоинство С++, а автоматическое управление памятью в том или ином виде есть, причём как всегда в С++, можно заточиться под свои нужды и отсутствие GC это не самый страшный недостаток плюсов. Думаю, повторять это в 4-й раз смысла не имеет.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[20]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 17.06.09 11:34
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ссылки дашь?

Например Hoard, аллокатор в Intel TBB
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: С# vs C++, голые цифры
От: FR  
Дата: 17.06.09 11:47
Оценка:
Здравствуйте, gandjustas, Вы писали:

FR>>Угу и они их давно написали и выложили, так что остальным 99% остается только скачать.


G>Ссылки дашь?


http://www.garret.ru/threadalloc/readme.html
http://www.dent.med.uni-muenchen.de/~wmglo/malloc-slides.html#tth_sEc14
http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html
http://www.hoard.org/
Re[20]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 11:49
Оценка:
Здравствуйте, gandjustas, Вы писали:

DC>>А если передавать объект которым управляет GC между потоками, синхронизации не надо?

G>Не надо.

Объясни почему или дай ссылку на источник. Интересно, как происходит сериализация доступа если у нас два потока лежат на разных GC?

DC>>Да и синхронизации будет требовать не только посчёт ссылок.

G>А что еще?

Ну собственно работа с самим объектом, например.

G>Тест уже был, читайте холивары.

Ну и тебя туда же .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[21]: С# vs C++, голые цифры
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.06.09 22:39
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>>>А если передавать объект которым управляет GC между потоками, синхронизации не надо?

G>>Не надо.
DC>Объясни почему или дай ссылку на источник. Интересно, как происходит сериализация доступа если у нас два потока лежат на разных GC?

Сейчас на вскидку не скажу, но есть lock-free алгоритмы, позволяющие обойтись без прямой синхронизации в этом случае. Пробегало где-то у Sun. Если найду, скину ссылку.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: С# vs C++, голые цифры
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.06.09 22:47
Оценка:
Здравствуйте, gandjustas, Вы писали:

DC>>Ну я могу сказать что ручное управление памятью в любом случае быстрее и дешевле .

G>Теоретически быстрее может быть. А практически добиться таких результатов в сложных случаях выйдет настолько дорого, что реально этим никто заниматься не будет.

С чего ты это взял? Простой Thread-local pool с соответствующими указателями вполне дёшев и в реализации, и в использовании. И скорость даёт очень приличную.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 26.06.09 07:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Сейчас на вскидку не скажу, но есть lock-free алгоритмы, позволяющие обойтись без прямой синхронизации в этом случае. Пробегало где-то у Sun. Если найду, скину ссылку.


Не, ну с подсказками нечестно .

ЗЫ Обязательно кинь.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[21]: С# vs C++, голые цифры
От: CreatorCray  
Дата: 26.06.09 08:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

DC>>>Ну я могу сказать что ручное управление памятью в любом случае быстрее и дешевле .

G>>Теоретически быстрее может быть. А практически добиться таких результатов в сложных случаях выйдет настолько дорого, что реально этим никто заниматься не будет.

ГВ>С чего ты это взял? Простой Thread-local pool с соответствующими указателями вполне дёшев и в реализации, и в использовании. И скорость даёт очень приличную.

плюсадин!
Тем более что как раз такой "Простой Thread-local pool" уже как то порвал его (ганжустаса) тест на скорость аллокации.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: С# vs C++, голые цифры
От: fuyant  
Дата: 26.06.09 14:54
Оценка:
Здравствуйте, IID, Вы писали:

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


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


A>>>было бы еще интересно на кваде проверить опенмпишный вариант


IID>>Вечером заценю на домашнем Q6600. И опенмпшный, и сишарповский


IID>Заценил.


не могли бы вы выложить оба бинарники?
хотелось бы и сюда статистики добавить, и посмотреть, настолько ли мой проц такой тупой на вычисления, как говорят... да и вообще посмотреть на его возможности: core i7 920 (не гнался), который о четырех ядрах, но типа как их там восемь, и с трехканальной памятью
И что таки нужно установить для .нетовского примера? четвертый фреймворк? потому что в шарпах я уже практически ничего не смыслю

IID>

IID>SpeedTestCpp.exe
IID>elapsed: 9.908 seconds. b=1813065000


IID>Честно попытался запустить C# вариант с Parallel.For, но замучался. По дефолту 2008-ая этого не умеет. Скачал и установил ParallelExtensions_Jun08CTP.msi Всё равно неймспейс System.Threading.Concurrency, как и System.Concurrency неизвестен. А т.к. в шарпе я не большой спец — забил.


IID>Так что время исполнения C# кода пока остаётся тем же, и мы уже имеем 1353% преимущества.
Re[19]: С# vs C++, голые цифры
От: fuyant  
Дата: 26.06.09 14:57
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>gandjustas wrote:


>>>> Сразу приводи название софта, который "заметно тормозит".

>> S>rsdn@home vs. knode например
>> Там тормозит нативная БД вроде как.
S>И изза этого окно при перетаскивании не отрисовывалось?


>> Тупо отрисовка — это сплошной нэтив. Считй что ты сравниваешь один нэтив фреймворк с другим.

S>И что? Это както лишает приложение тормозов?

>> Кстати, покажи в каком WPF приложении тормозит "тупо отрисовка".

S>В любом. ___Любое___ дотнет приложение, которое я когда-либо видел — так или иначе тормозило.

ну, я видел очень много приложений на плюсах, которые невероятно тормозили. И видел дельфийские и ява программы, которые субъективно обгоняли приложения на плюсах и .нете
имхо, некорректно сравнивать языки (фреймворки, платформы, библиотеки — подчеркните нужное), меряя написанные на них приложения
Re[23]: С# vs C++, голые цифры
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.06.09 12:23
Оценка: 3 (2)
Здравствуйте, dr.Chaos, Вы писали:

ГВ>>Сейчас на вскидку не скажу, но есть lock-free алгоритмы, позволяющие обойтись без прямой синхронизации в этом случае. Пробегало где-то у Sun. Если найду, скину ссылку.

DC>Не, ну с подсказками нечестно .

Да ладно.

DC>ЗЫ Обязательно кинь.


Покопайся вот тут. Именно ту бумажку, о которой я упоминал, я пока не нашёл, нашлась довольно интересная другая: Lock-free reference counting. Вообще, кстати, достаточно просто погуглить по "lock free", в сети много любопытного по этому поводу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: С# vs C++, голые цифры
От: _d_m_  
Дата: 29.06.09 01:05
Оценка:
Здравствуйте, fuyant, Вы писали:

F>хотелось бы и сюда статистики добавить, и посмотреть, настолько ли мой проц такой тупой на вычисления, как говорят... да и вообще посмотреть на его возможности: core i7 920 (не гнался), который о четырех ядрах, но типа как их там восемь, и с трехканальной памятью


Их там 4. Но Intel опять вернулись к идее HyperThreding-а — вобщем по два конвеера на ядро.
Re[24]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 29.06.09 18:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Покопайся вот тут. Именно ту бумажку, о которой я упоминал, я пока не нашёл, нашлась довольно интересная другая: Lock-free reference counting. Вообще, кстати, достаточно просто погуглить по "lock free", в сети много любопытного по этому поводу.


Так, из занудства замечу, что lock-free это лишь гарантия отсутствия дедлоков, а вовсе не скорости выполнения .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[25]: С# vs C++, голые цифры
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.06.09 21:53
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Так, из занудства замечу, что lock-free это лишь гарантия отсутствия дедлоков, а вовсе не скорости выполнения .


Правильно заметишь. Правда, это ещё и гарантия того, что параллельные процессы не буду сталкиваться, кроме как на атомарных операциях.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.