Быстрый linux vs медленный windows

агрессивное кеширование файловой системы?

У меня, если что, таже тема, только с явой. Под вендой создание директорий/файлов, да и вообще любая работа с фс заметно тормозит. Видимо, особенность вендовозки.

Где-то в соседнем топике в отношении производительности веб-серверов под вендой это обсуждалось, лет 5 назад. Я не найду. Типа, это by design.

если линукс такой быстрый, то почему я тогда жду старта хрома порядка 10-15 сек на сильной машине? Примерно столько же, сколько на слабой вендовой? Загадка века.

И кстати, трейдерских платформ под линукс раз два и обчелся. Если бы там действительно был бы большой выигрыш, соотношение было бы другим, учитывая то, что половина трейдеров сами программисты, и им насрать на какой системе работать и на дружественность UI

производительность веб-серверов вообще от скорости обработки данных не зависит, максимальная производительность достигается асинхронностью и масштабированием.

Может те кто делал виндовс версию буста сделал её плохо ? Недостаточно разбирается в апи виндовс ?

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

с чем это связано?

Наиболее вероятным вариантом мне видится тормознутость NTFS, которой уже лет 16

Я грешу на хреновую оптимизацию msvc

Зря. MSVC обычно всегда предпочтительнее MinGW-w64, под MS Windows он быстрее.

А вот с сетью/сокетами/файловыми IO у винды какие-то вечные затупы.

Судя по Boost и Qt — там кросс-платформенное приложение.

Зато под виндой mmap быстрый :) Юзай его, не помню как он там называется, но в том же бусте должна быть абстракция.

Если бы только ФС - но ведь работа с графиками/таблицами также быстрее на порядок. А это чистой воды оперативная память + проц. Это как объяснить? Только компилятор, по идее

Зря. MSVC обычно всегда предпочтительнее MinGW-w64, под MS Windows он быстрее.

Хмм, а каким образом? От того, на винде или линуксе выполняется программа, набор инструкций процессора не меняется. Или по-вашему MSVC генерирует лучший машинный код?

vtune натрави или что-то похожее

Просто сначала все показывается у АНБ, а потом уже у тебя на экране, чтобы они успели проверить, нет ли там терроризма.

набор инструкций процессора не меняется

Набор этих инструкций генерирует компилятор, не так ли? И наборы инструкций, которые генерируют MSVC/ICC/GCC (MinGW)/Clang->LLVM различаются, ибо оптимизируют они по-разному.

Или по-вашему MSVC генерирует лучший машинный код?

Лучший/худший, у меня нет общего суждения на этот счёт. Я предпочитаю использовать на Windows именно MinGW, хотя бы потому, что бинари собранные им будут тупо работать на всех MS Windows, начиная с 98.

Но когда-то видел бенчмарки, которые показывали, что бинари под MS Windows лучше всего собирать именно студийным компилятором.

Так поступают те же открытые кросс-платформенные проекты: Qt Creator (под винду распространяется только MSVC-версия), qBittorent, FileZilla и иже с ними.

но ведь работа с графиками/таблицами также быстрее на порядок.

Лично я у себя не вижу особых различий в работе GUI-программ с графиками, как на GNU/Linux, так и на MS Windows.

Только компилятор, по идее

Да что ты. А про всякие там прослойки в виде Xorg и GDM (в винде) ты забыл? Может быть эти графики рисуются с помощью OpenGL, поддержка которого в винде всегда была хреновенькой?

Ты можешь приложение это показать?

Ну и да, если ты думаешь что это компилятор — собери приложение в винде тем же MinGW'ом. Не думаю, что оно станет отзывчивее, скорее наоборот.

Зря. MSVC обычно всегда предпочтительнее MinGW-w64, под MS Windows он быстрее.

Я лично msvc не пользуюсь, но им пользуются некоторые мои коллеги и они иногда делают сравнительные тесты для чего-либо на разных компиляторах (последние версии gcc, clang и msvc). Так msvc обычно показывает худшие результаты для офтопика, иногда с ним происходят вообще невообразимые странности. Ещё стоит учесть лаг в реализации новых стандартов, т.е. clang и gcc быстрее их осиливают.

будут тупо работать на всех

ну это уж как соберёшь, как соберёшь

только MSVC-версия

ну это спорный вопрос, можно хоть с cygwin взять бинари

Первое, о чём подумал: на типичной винде присутствует антивирус. Отсюда логично ожидать тормозов с ФС, а хитрые, может, и память постоянно мучают.

на конкретной машине она может быть просто фрагментированной

внутри boost и Qt вызов апи платформы

10-15 сек на сильной машине

у меня стартует примерно за секунду

если линукс такой быстрый, то почему я тогда жду старта хрома порядка 10-15 сек на сильной машине? Примерно столько же, сколько на слабой вендовой? Загадка века.

Видимо у всех та же фигня. Вероятно пытается отослать твои координаты и ищет gps которого может и нет.

Набор этих инструкций генерирует компилятор, не так ли? И наборы инструкций, которые генерируют MSVC/ICC/GCC (MinGW)/Clang->LLVM различаются, ибо оптимизируют они по-разному.

Оптимизируют-то по разному, не спорю. Меня тут смутила фраза «под MS Windows он быстрее». Будто бы вы намекаете что использование GCC в среде Windows может каким-то образом дать код более медленный, чем при использовании того же GCC в среде Linux (это кстати действительно может быть так, например это может быть связано с плюсовым рантаймом, например mingw-gcc попросту не поддерживает механизм обработки исключений SEH (см. https://gcc.gnu.org/wiki/WindowsGCCImprovements ).

Если же имеется ввиду что сам MSVC генерирует лучший машинный код, чем это делает GCC(безотносительно целевой ОС), то тут я категорически не соглашусь с этим бездоказательным утверждением. Я например делал небольшие сравнения сгенерированного машинного кода (для Си, не для плюсов) и каких-либо существенных преимуществ у студии в плане оптимизаций я не нашел.

А вот с сетью/сокетами/файловыми IO у винды какие-то вечные затупы.

Потому-что эта область закакана левыми велосипедами и костылями чуть более чем полностью

антивирус мешает?

Компилируй кросс-компиляцией с помощью mingw.

лучше всего под вантузом работает icc. он даёт иногда раза в полтора прибавку по скорости работы. причём даже на AMD.
что касается GCC, то давно, когда я имела дела с вантузом, GCC иногда давал лучшую производительность, если дело не касалось дёрганья вендозных API. и msvc сильно отставал в поддержке стандартов и имел суровые баги в стандартной библиотеке.

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

А хороший ведь совет - профайлинг на всё ответит!

Наверняка в винде есть нечто вроде perf, а в Linux-е оно показывает внутрянки ядра где что выполнялось...

Я помню как некоторые виндузятники кичились что виндоядро гибридное, типа ФС там вне режима ядра - может это и есть причина тормозявости? Типа FUSE, может я не так понял их.

Приложение показать не могу, проприетарщина.

С mingw тоже протестировать не могу, т.к. завязано на внутренние либы, которые мне доступны только уже собранные с msvc. Тормоза точно не в них, т.к. они нужны для первичной обработки данных, а отрисовка уже идет со своими структурами данных.

Чтение файлов под linux через boost::serialization происходит в 10 раз быстрее, чем под виндой.

ну не в 10 положим. у меня процентов 10-15 разница была.

Во-первых если пользуешь буст, то пользуй последний. недавно сильно оптимизировали как раз венду (были там какие-то старые грабли)

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

В-третьих Qt после нокии вообще отвратно работает.

Я тоже думаю, что проблема с ntfs. Попробую прогнать профайлер рали интереса, когда в слудующий раз буду работать под виндой.

Что за маппинг? Хотя код уже написан и вряд ли будем переписывать ради винды.

Десериализация под линуксом работает около 0.5 секунды, глаз даже не успевает увидеть задержку. Под виндой - 17 секунд (sic)

Кстати может и антивирус, точно... Попробую без него

*станиславский.жпг*

давай минимальный пример. у меня crc считалось и на той и на другой системе (файлы от пустых до DVD образов). разница - 15% максимум. И это не «на глаз».

Еще может быть файловая система сильно фрагментирована. Тогда на дисковых операциях будут большие тормоза. Насколько знаю, NTFS тоже фрагментируется как и FAT. Обе нужно в ручную дефрагментировать с помощью специальных утилит.

у нее менее точный таймер, если где-то ты его пользуешь.

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

1. Как ни странно, но действительно, огромное количество Open Source библиотек, программ, и просто кода - банально не умеют работать с Windows, и в частности с Windows API, из-за чего грешат костылями, граблями и тормозами.
2. Антивирус. В 10й винде(по крайней мере, в версиях для дома и офиса), да и по-моему уже в 8й, он встроенный, и неотключаемый(можно только на время выключать). В серверной версии этот пункт снимается.
3. NTFS медленнее ext*(потому как более фичастая, на самом деле). Но тут, опять же, смотри пункт 1. Т.е. вместо того чтобы принять факт, и использовать ФС только для сторажда того чего надо, и желательно в одном месте, т.н. «кроссплатформенные» программы плодят файлы направо и налево.
4. «Юникс-вей» в виде форка процессов направо и налево на Windows работает плохо, т.к. там процесс это совершенно другая вещь, достаточно тяжеловесная. Это опять к пункту 1.

Само же исполнения кода скомпилированного MSVC++ местами даже лучше G++, особенно в области исключений и RAII(потому как SEH, VEH итд.).

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

Но даже с самыми кривыми программами, разницы в 30 раз нет нигде.

Что за маппинг?

обычный маппинг файла в память. чтобы не тащить целиком большой файл. конечно, если ты знаешь специфику работы со своими файлами.
а тормозить ещё могут стандартные контейнеры. в последней студии запилили по умолчанию проверки валидности обращений (https://msdn.microsoft.com/en-us/library/aa985965.aspx) и их лучше явно отключать. и ещё поставить NDEBUG, чтобы точно убить всякую лишнюю хрень. конечно, если вы этой хренью сами не пользуетесь.

Какая винда? Попробуйте 8 или 10: ходят слухи, что сеть, таймеры и IO там поддопилили. У меня такая же проблема с моим поделием на GLib/GTK: на xp и семерке тормозит. Проверить на восьмерке/десятке никак руки не дойдут.

тупой вопрос: в MSVC Realease выбран? или Debug? у них разница в скорости порядки.

А ещё на конкретной машине может быть изношенный винт с битыми секторами. А ещё может быть много чего.

для Си, не для плюсов

Так MS же забила на C в студии. Видимо поэтому и криво.

Меня больше вымораживают сообщения об ошибках в MSVS. Другое дело clang.

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

А что там с работой десктопных программ для линукса в встроенной в виндовс убунте? Там они вроде линуксовые системные вызовы реализовали, так что должно все четко работать

Так MS же забила на C в студии. Видимо поэтому и криво.

Всмысле забила? Не думаю что у них там какие-то оптимизации есть для C, которые для C++ не используются. Да в любом случае можно сишный код плюсами компилить после некоторых косметических исправлений

Ссылку сходу не найду, но MSVS 2015 все еще не поддерживает C99 и не собирается.

Да пусть забила, я к тому веду, что можно компилировать (почти) сишный код плюсовым компилятором, используя общее подмножество плюсов и Си. Не использовать С++ классы, шаблоны, всякие там constexpr, auto, new и прочее