Сравнение языков на массивах. Конец

[Vapaamies]

Сообщение от DeepFlake

Там в прикреплении полный исходный текст тестов.

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

В начале должна быть некая преамбула, вроде: «мне показалось, что реализация массивов стандартными библиотеками современных языков программирования в отдельных/большинстве/всех случаях уже не соответствует машинному представлению массивов в памяти, как было раньше, а добавляет новые слои абстракции; захотелось выяснить их цену; чтобы избежать наведенных эффектов, я использовал такие/сякие методики...». Так всем заинтересованным в вопросе сразу станет понятно, что вы делали, и СТОИТ ЛИ смотреть в код и тратить на него свое время, или даже вдруг компилировать и запускать У СЕБЯ, если внезапно стало до усрачки интересно. Сейчас же вы предлагаете нам восстановить ваши мотивы, вникая в код. Это так не работает.

[pu4koff]

Сообщение от DeepFlake

измеряется только время работы с циклами между вызовами chrono::system_clock::now() :

В процессе замеров ОС банально выполнила синхронизацию времени по NTP и привет погрешность в секунду-другую? По-моему эта функция вообще не рекомендуется для замеров в бенчмарках. Хотя бы уж steady_clock, а не system_clock.
Даже для C++ уж должны быть специализированные библиотеки для создания бенчмарков, к чему это хождение по граблям с замерами времени вручную?

[Алексей1153]

и ещё вопросы:
1) почему при поиске элемента в C++ использован "ручной" цикл, а не std::find_if со включенной векторизацией
2) была ли включена оптимизация

[DeepFlake]

to pu4koff:
с интернетом не было связи когда запускались тесты.

[DeepFlake]

to Алексей1153:

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

я исследовал скорость доступа к элементам массива, поэтому через индексатор.
Для сравнения также применял
found = std::any_of( set1.begin(), set1.end(),
[ &el1 ] ( const long int& el ) { return el1 == el; } );

Этот вариант как раз оказался на 2-м месте.( после Java).

Оптимизация опциями -O и -O3 в С++. Во всех языках применял опции оптимизации.

Java оказалась быстрее не из-за опций, а ... вот смотрите, если провести проверку на скрость для разных языков в Windows, то оказывается, что самый быстрый - C++/CLR. Ну то есть это MS C++ с опцией чтобы генерировал код для .Net. Он на 15% быстрее Delphi. Чуете в чём дело? Если не совсем, тогда вопрос-подсказка: Что общего между .Net и Java?

[DeepFlake]

to Vapaamies:
>Нужен не код, а объяснение побудительных мотивов

часто человек сам сказать не может чего он хочет и зачем что-то делает. И кошки тоже также непонятно зачем куда-то бегут

[DeepFlake]

to pu4koff:
спасибо за подсказку про steady_clock

[Алексей1153]

Сообщение от DeepFlake

Для сравнения также применял
found = std::any_of

так а с векторизацией то ? https://en.cppreference.com/w/cpp/al...ll_any_none_of
см. ExecutionPolicy

[DeepFlake]

to Алексей1153:

Понимаю, что я не звезда чтобы все читали каждое моё сообщение, просто об этом я писал раньше в сообщении "Часть 1".
https://programmersforum.ru/showthread.php?t=347255

вот текст оттуда:

Если массив размещять в типе-контейнере std::vector, то работать с ним надо при помощи функций из <algorithm>, а иначе нет смысла использовать вектор.

Код:

std::vector< long int >     set1;
std::vector< long int >     set2;

isSubSet = true;
if ( set1_len >= set2_len )
{ // первый массив больше
    for ( long int el1 : set2 )
    {
        found = std::any_of( set1.begin(), set1.end(),
                    [ &el1 ] ( const long int& el ) { return el1 == el; } );

        if ( not found )
        {  // не все элементы set2 принадлежат set1
            isSubSet = false;
            break;
        }
    }
}
else 
{  // второй массив больше
    for ( long int el1 : set1 )
    {  // проход по первому массиву
        found = std::any_of( set2.begin(), set2.end(),
                    [ &el1 ] ( const long int& el ) { return el1 == el; } );
    
        if ( not found )
        {   // не все элементы set1 принадлежат set2
            isSubSet = false;
                //  не является подмножеством
            break;
        }
    }
}

Можно разрешить компилятору распараллелить обработку массива если использовать параметр std::executionar
Код:

found = std::any_of( std::execution::par, set2.begin(), set2.end(),
            [ &el1 ] ( const long int& el ) { return el1 == el; } );

std::executionar_unseq - разрешает распараллелить и использовать SIMD.
std::execution::unseq - разрешает в однопоточном коде использовать SIMD.
Проверим скорость работы программы со всеми этими параметрами в ALT (в Debian компиляторы это не поддерживают). В секундах:

GNU C++ - 10.44525
GNU C++ (alt) - 11.32513
GNU C++ (alt) паралел. - 11.10373
GNU C++ (alt) паралел.+SIMD - 28
GNU C++ (alt) SIMD - 20
Clang C++ - 10.27182
Clang C++ (alt) паралел. - 11.2052
Clang C++ (alt) паралел.+SIMD - 18

Видно, что параллельный код не генерируется, только однопоточный. SIMD значительно ухудшает производительность.

[DeepFlake]

Если кому-то интересно сравнить, хотя бы для C++ и Java, вот текст, можно в Windows запускать, платформоспецифичного нет: