Написал простенькую программу (построчное чтение больших текстовых файлов, разбиение строки на составные части, преобразование текстовых значений в нужные форматы и их складирование в массив с последующим очищением массива).

В ОС Debian сборка выполнялась в Qt Creator, а в ОС Windows- в Visual Studio 2017 (для третьего варианта также был выполнен замер времени выполнения программы собранной в Qt Creator- результаты практически те же). В ОС Windows предварительно полностью выключался антивирус.

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

Чтение строк из файлов / полное время выполнения программы (приведены средние значения):

Вывод команды time (у меня 4-ех ядерный процессор i5-4690, поэтому запускались 4 потока):

Почему под разными платформами для компилятора Intel C/C++ мы получаем настолько разные значения? Ведь если из полного времени выполнения вычесть время чтения данных (таким образом получив чистое время работы процессора), то получим отличие в 1,5 раза(!!!). По логике программный код должен исполняться напрямую без участия ОС (кроме кода ядра, разумеется), тогда не понятно почему один и тот же код, скомпилированный одним и тем же компилятором выполняется в 1,5 раза дольше.

Забыл написать, что в обоих случаях использовались Release- сборки. В Qt Creator использовались настройки оптимизации по- умолчанию для Release- сборки, а в Visual Studio- O2 максимальная скорость кода.

kealon(Ruslan)AlekseySQL,

выбирай:
так проц распределился между процессами

так выпали звёзды

в Dos пробовал?


Не думаю, что превосходство Debian сразу по двум компиляторам является следствием расположения звезд. Меня подмывает поставить Visual Studio 2015, чтобы проверить для компилятора Clang.

У меня интерфейс построен на Qt, поэтому не думаю, что Dos позволит выполнить замеры.

Вопрос к знатокам Linux: если я соберу ядро на своей машине приведет ли это к ускорению работы моей программы? Ведь возможно при сборке из исходников система как- либо анализирует аппаратную часть и использует те или иные куски кода для повышения производительности или такого нет и я все выдумал?

Кстати, я правильно понимаю, что оптимизации ядра повлияют только на значение sys команды time (что в моем случае составляет очень маленькую долю выполнения программы)?

Dima TЕсть еще ключи для использования различных наборов команд проца.
Например MSVC по умолчанию использует только MMX2 от PentiumIII, а более современные не использует.
Например в твоем i5-4690 есть поддержка SSE4.1, SSE4.2, AVX2. Попробуй разрешить компилятору их использовать.

Гугл сообщает , что подобные оптимизации интересовали пользователей только до 2013 версии. В настройках компилятора в Visual Studio я подобных настроек не нашел (в том числе перечитывая список "Все параметры"). Скорее всего эти наборы команд включены по умолчанию и никаких дополнительных действий программистам совершать не нужно.

Dima TЕсть еще ключи для использования различных наборов команд проца.
Например MSVC по умолчанию использует только MMX2 от PentiumIII, а более современные не использует.
Например в твоем i5-4690 есть поддержка SSE4.1, SSE4.2, AVX2. Попробуй разрешить компилятору их использовать.

Нашел где в настройках указывается использование расширенных наборов инструкций. Но, к сожалению, замеры показали, что никакого преимущества над дефолтными настройками нет (а кое- где даже небольшие просадки). Microsoft реализовал поддержку только sse2, а у компилятора intel также есть возможность выбора инструкций sse3. Дополнительно я пробовал выбрать набор команд AVX2- нет прироста производительности.

Leonid KudryavtsevТо, что существуют специальные программы для профилирования кода (например Intel VTune) автору похоже даже не догадывается. Всем участникам форума предлагается погадать на кофейной гущи и написать, что же они там увидели. А у меня даже кофе нет (((, только чай.

Спасибо, сейчас буду профилировщиком пользоваться.

Но мне не понятно в принципе: почему один и тот же код, скомпилированный одним и тем же компилятором выполняется сильно разное время (причем системное время очень мало)? Ведь у нас С++, который должен работать напрямую на железе, а не С# или Java с их дополнительными программными прокладками. Может я чего-то недопонимаю?

azsxавторесли я соберу ядро на своей машине приведет ли это к ускорению работы моей программы?
Тут вопроса 2.
1. Вы выкините всё лишнее из ядра и оставите только нужное вам в консоли. Сборка на основе, например, debian.
2. Вы мало того, что всё выкините, но ещё и перекомпиируете под свой проц "native". Вывод -- ваш выбор gentoo.
---
У меня была иная задача, просмотр fhd на слабом пк. Даже установка calculate linux вместо: debian, ubuntu, win 7 64, значительно оживило ПК. Скомпилированный vlc под мой процессор (то есть с опциями для gcc компилятора) стал показывать fhd. Наверное, ядро перекомпилировал бы -- ваще взлетел бы. Но зато пол светового дня -- я компилирую обновления для системы :)
зы
я не знаток.

Какой ресурс вы порекомендуете для изучения подобных оптимизаций?

Сделал замеры производительности для компилятора Clang на обоих платформах (приведено среднее время выполнения всей программы):
1. Debian 9.2.3, Qt Creator, Clang, ext4: 65,3 сек
2. Win 10 Pro 1709, Visual Studio 2015, Clang, ntfs: 97 сек

Как видим ситуация аналогичная компилятору от Intel: сильная просадка производительности на платформе Windows. Так что это не "особенность" компилятора от Intel, а общая закономерность.

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

Профайлер Intel Vtune Amplifier показал (Elapsed Time / CPU Time):
1. Debian 9.2.3, Qt Creator, Clang, ext4: 66,2 / 250,6
2. Win 10 Pro 1709, Visual Studio 2015, Clang, ntfs: 113,6 / 397
3. Debian 9.2.3, Qt Creator, Intel C/C++, ext4: 66,5 / 250,9
4. Win 10 Pro 1709, Visual Studio 2015, Intel C/C++, ntfs: 94 / 302

У меня 4-ех ядерный процессор, поэтому я запускаю 4 потока. Видно, что под Debian происходит асинхронное чтение данных с диска, поскольку
Elapsed Time ~ CPU Time / 4

, а платформа Windows этим похвастаться не может. Хотя, просадка производительности больше, чем эта разница, так что скорее всего библиотеки у Windows- решения также проигрывают в производительности. Компилятор от корпорации зла оказался самым неудачным решением из 4 рассмотренных во время тестирования.

Самое смешное, что я много раз слышал обратные утверждения: "gcc глючный, а Microsoft далеко впереди"... Думаю это был еще один пример недобросовестной рекламы от тех, кто очень боится наступления Linux- систем.

Отпишусь, по изменению производительности когда задам опции для gcc. Может получится еще немного ускориться.

rdb_devAlekseySQL, так ты же опять на винде по ntfs елозишь!
Сделай уже нормальный тест - создай на СХД раздел с FAT32 и цепляй его по iSCSI для обоих тестов.

Я уже давно не видел использование fat32. Я проделал эксперимент для типовых конфигураций, используемых на каждой платформе. Поэтому мой эксперимент отражает реальность, а не синтетические циферки.

К тому же я в свое дело ставил эксперимент (и тут приводил его результаты):
Как же приятно себя цитировать!Оказалось, что ничего этого не нужно: система работает через буферы, которые и берут на себя задачу непрерывной подачи данных.

Я сделал замеры когда на моем SSD были ФС ext4 и ntfs. В последнем случае сильно упала скорость чтения файла, но общая скорость работы программы практически сохранилась (привожу средние значения):
Чтение ext4: 22,5 сек
Чтение ntfs: 38 сек
Чтение + Выполнение ext4: 65 сек
Чтение + Выполнение ntfs: 66,5 сек

По результатам видно, что падение скорости выполнения всей программы значительно меньше, чем падение скорости чисто файлового чтения. Так что отбой: умные дяденьки этот вопрос уже обдумали и дали нам готовое решение.
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1283738&msg=21162931

Будет fat32, ext4 или ntfs- результаты будут практически такие же (разумеется под Линаксом, который умеет асинхронно подтягивать данные с дисков).

Dima TAlekseySQL, есть разница померить что-то в разных условиях и сделать вывод:
1. "Получилось вот что, объясните почему."
2. "Я думаю что так получилось потому что ...."

Ты идешь по п.1.

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

Для себя я уже сделал вывод. Всем спасибо.