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

В ОС 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 то подскажут кучу направлений в которых покопать.

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

azsxавторКакой ресурс вы порекомендуете для изучения подобных оптимизаций?
Хотя вопрос явно не ко мне, отмечу. Я компилирую "linux" не потому, что мне жизненно необходима оптимизация под процессор, а потому, что комп домашний, время было -- настроил. Для дома самое то и видео теперь есть.
Производительность очень интересная вещь. Если бы мне поручили вояджер куда то отправить или на форексе робота воткнуть -- я бы о полной компиляции ядра подумал. Но в обычных случаях лучше юзать уже кем то скомпилированными, а то вы так и linux from scratch читать начнёте, благо, что на русском есть :)
В вашем случае я согласен с предыдущими ответами, начните с изучения опций компилятора, затем всякие няшки, например, профилирование. Например, вы толком опций не нашли, а ведь intel тем и плох (хорош), что у него немеряно всяких технологий внутри камня. Я то оптимизации по воспроизведению видео добился именно тем, что скомпилировал vlc именно под свой проц, а не под "общий" скачал бинарник.
Затем, если понравится почитать Столярова про ассемблер и искать мануалы на нерусском.
зы
ну да, производительность считать в десятых долях секунд (и ваще в секундах) -- это что то из области java.


Спасибо, наконец вернулся в свой родной Linux и дошли руки до оптимизации gcc. В pro- файл добавил:
QMAKE_CXXFLAGS += -march=native -mtune=native

, что ограничивает набор инструкций возможностями текущего процессора и делает оптимизационную настройку кода на текущий процессор. Также пробовал оба варианта, добавляя только один из двух ключей.
https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/x86-Options.html#x86-Options

В консоли сборки видно, что эти флаги действительно передаются компилятору. Но прироста производительности не замечено.
Думаю, что остальные опции не принесут серьезных изменений производительности, поэтому тестировать их не стал.

Может, конечно, у меня программа не особо сложная, но так или иначе результата не обнаружено.

Dima TAlekseySQLДля себя я уже сделал вывод. Всем спасибо.
Звучит как "Спасибо что бесплатно на меня поработали". Выводом делись или сделаем выводы.

Вот он: http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1284501&msg=21174163

Если хочется подробнее почему я не вижу смысла в использовании fat32:
1. В топике приведено время чтения данных ~20 секунд. fat32 быстрее ntfs максимум на 5%, так что в лучшем случае выигрыш составит примерно 1 секунду. А вопрос идет в падении производительности на ~50 секунд. Другими словами это фактор второго порядка малости. Это если не учитывать частичной асинхронность чтения, а если учитывать, то все еще будет незначительнее...

2. Почему мы должны сравнивать работу на ФС, которая нативна для Виндовс и ненативна для Линакс? Не лучше ли сравнить работу на типовых ФС для каждой платформы?

3. Почему я должен заниматься анализом причин низкой производительности Виндовс? Думаю эти товарищи могут нанять специалистов, которые выполнят им подобные работы.

azsxВряд ли это понадобится ТС, поэтому очень образно.
Вывожу флаги своего процессора:
авторcat /proc/cpuinfo | grep flags
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave lahf_lm epb pti retpoline tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm arat pln pts
Каждый флаг -- это чаще всего какая то технология внутри камня. Она может работает на другой частоте, может имеет какие то особенности. Например, fpu -- по сути математический сопроцессор. Если Ваша программа активно работает с вещественными числами -- то выключения данного флага при компиляции может увеличить число тактов выполнения программы (будет дольше выполняться).
Есть некоторый "стандартные настройки" и некоторые флаги включены всегда для стандартно выкладываемых бинарников. Есть некоторые не включаемые. Как бы основа -- чтобы бинарник запустился везде.
Например, при компиляции vlc под свой процессор я включил какие то флаги, важные для производительности. А в Вашем коде оптимизации на уровне флагов видимо нет.
Рискну погадать, что к флагам надо относиться как к черному ящику или читать Столярова для начала.

Насколько я понял опция

включает все возможные для текущего камня инструкции. Цитата из приведенной ранее ссылки (с переводом от Google):
marchGenerate instructions for the machine type cpu-type. In contrast to -mtune=cpu-type, which merely tunes the generated code for the specified cpu-type, -march=cpu-type allows GCC to generate code that may not run at all on processors other than the one indicated. Specifying -march=cpu-type implies -mtune=cpu-type.
nativeThis selects the CPU to generate code for at compilation time by determining the processor type of the compiling machine. Using -march=native enables all instruction subsets supported by the local machine (hence the result might not run on different machines). Using -mtune=native produces code optimized for the local machine under the constraints of the selected instruction set.

https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/x86-Options.html#x86-Options

Если в приведенной мне ссылке спуститься ниже, то для моего типа процессора в опции -march написано:
haswellIntel Haswell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2 and F16C instruction set support.

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

Если я не прав и запутался в выборе ключей, то буду рад подсказке.

azsxавторЕсли в приведенной мне ссылке спуститься ниже, то для моего типа процессора в опции -march написано:
Может более правильно "Если в приведенной мне ссылке спуститься ниже, то для моей архитектуры (haswell) процессора в опции -march написано:"
---
По сути Вы разобрались :)
Теперь вы понимаете почему натив при компиляции Вам ничего не дал?

Я не очень понимаю эти загадки. Если вам есть что сказать по теме, то буду рад услышать.

Leonid Kudryavtsevazsx,

У Вас какое-то странное мнение. Сначала обычно определяют задачу, которую хотят решить, потом разбираются со средствами.

Автору бы определится какой конкретно участок ЕГО кода тормозит, а потом уже ставить диагноз и искать решения. Но диагноз поставлен уже заранее: windows suxx, linux rules.

IMHO

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

Диагноз заранее поставлен не был: после падения производительности компилятора Intel на Windows- платформе я потратил еще целые сутки, чтобы проверить поведения компилятора Clang. Если у вас есть возможность провести подобные эксперименты для какой- либо своей программы, то я буду очень рад, если вы это выполните и в этой теме поделитесь полученными результатами.