Russian Qt Forum

Около 75000 строк исходников, из них около 10000 на Си (только стандартные библиотеки), остальные на C++/Qt4.

1. Виртуальная машина Oracle VirtualBox, в ней Kubuntu 14.04 i386, RAM 1 ГБ, 1 виртуальный процессор. Хост реальный Athlon X2 64 2.0 ГГц DDR2 667 2 ГБ одной линейкой, Kubuntu 14.04 x86_64, стандартный 5" жесткий диск IDE 5400 RPM. Компилятор штатный GCC 32 бит (build-essential из репозитория).

2. Реальная машина AMD A8-6500 3.5 ГГц, DDR3 1866 4ГБ двумя линейками, ноутбучный быстрый жесткий диск SATA3 10000 RPM. Windows XP i386 SP3. Компилятор MinGW32 4.какой-то. Свопинг в ОС отключен.

Полная сборка с 0 в обоих случаях вариант release 32 бит в 1-м случае заняла 15 минут, во втором 21 минуту...

Виртуальная машина, Карл! 1 (ОДИН, КАРЛ!) виртуальный процессор против 4-х реальных ядер, каждое в 1.75 раза быстрее (хотя бы 2 компилятор же может использовать)! Минимум вдвое медленнее винчестер (на самом деле, больше из-за большего кэша ноутбучного винта)! Значительно более медленная память! И выигрыш в 1.4 раза!

Веники-ХРеники виноваты?... Больше не могу даже предположить, что именно - ну не MinGW же, компилятор ведь практически тот же GCC.  Да, я знаю про аппаратную поддержку виртуализации процессором AMD, но это только на уровне кода, а не системных вызовов - они же всё равно через ДВЕ операционные системы проходят. И процессор медленнее.

Может дело в системе сборки и на виртуалке она параллелит билд? Qmake или jom например.

Ну и в случае виртуалки скорей всего к физическому диску обращений меньше.

А давайте немного переформулируем.

Берём порт компилятора Linux на Windows, и начинаем замерять его быстродействие в Windows. 21 минута на 4 ядрах.

Берём компилятор Linux на Linux(оригинал) и замеряем его быстродействие в Linux. Ух ты 15 минут.

Уже давно обсасывалась эта тема. MinGw это компилятор Linux, MSVC компилятор Windows.
На своих родных системах они оптимизированы и работают с максимальным быстродействием.
Портирование компиляторов на другие системы замедляет работу.


Ну и немного конкретики - mingw работает с множеством файлов по несколько раз. Для linux это не проблема. Но у Windows время доступа к файлу выше, отсюда и разница.

PS так что ваши претензии нужно предъявлять порту mingw :)

Однако ж выиграла машина, которая минимум вдвое менее производительная. И по железу, и еще и из-за виртуализации.

Так что именно тормозит компилятор MinGW? Его переработка для Windows, или таки его среда выполнения, то есть Windows? Вообще когда речь окомпиляторе и его взаимодействии с ОС, то там на 99% stdout.h и stdlib.h используется. А эти функции компилятор сам по идее не реализует - он за ними к ОС обращается.


32-х разрядная виртуальная машина работает в реальной 64-х разрядной хостовой машине - что она может параллелить? с чего вдруг обращений к диску меньше?

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

написано же всё, что собиралось - в соответствии с ОС, в которой работало

что значит "собиралось в один поток"?

Вы ещё попробуйте собрать простой пример - приложение с 50-60 потоками с приоритетом реального времени.
В Linux оно будет работать, в Windows зависнет нахрен вместе с системой.
Потому что ОС разные :D

make -j 5
5 = 4 ядра + 1 (например)

Возможно. Но такое мне пока не надо. Запускал своё приложение с 6-7 потоками, с обычным приоритетом - работает везде одинаково.

А... ну я на обеих машинах собираю тем, что по-умолчанию qmake нагенерил. По-русски это будет "собиралось в последовательных заданиях". Но основное время сборки всё-таки тратится на компиляцию, это даже в консоли заметно. А компилятор сам процессоры использует.

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

Ага, и имя этим отличиям - тормозной до безобразия ntfs  ;D

Я понимаю, что есть много отличий. И что Linux во многих случаях обыгрывает Windows я тоже в курсе. Но чтобы усредненная производительность при сборке приложений отличалась В РАЗЫ... Я даже не подозревал. Ведь компиляция и сборка - это один из самых ресурсоёмких процессов, в большой степени нагружающий все части компьютера. Его можно считать как бы естественным натуральным тестом производительности.

Есть и обратная ситуация. К примеру компиляция в MSVC в отдельных случаях даёт такую же разницу производительности. Только тормозит в этом случае Linux :)

Так вроде ж MingGW - очень медленный компилятор? Если студией компилировать, то быстрее будет.

Думаю что на винде использовался старый mingw, как следствие неспешная компиляция в один поток, плюс накладки NTFS, как уже сказали. Возьми какой-нибудь mingw версии 4.8.2 и используй make -j5, думаю будет намного быстрее.

MinGW как раз именно 4.8. С -j5 в сумме будет быстрее - просто будет одновременно компилять несколько файлов при сборке библиотек. Но ведь на виртуальной машине в Linux тоже в последовательных процессах компиляция шла...