Вопрос про перенос с Windows на Linux

Другая модель потоков, другой компилятор, стандартная библиотека, оптимизации etc

У меня вот наоборот, после переноса тормознее стало (я правда на LuaJIT грешу) но тем не менее, факт.

Полагаю, именно в потоках дело.

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

Во первых, почему только этот фактор? Это ты сможешь утверждать, только погоняв однопоточную версию.

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

А ещё можешь собрать другой версией компилятора и скорей всего тоже будет разница в быстродействии.

Вангую, что ты исправил какую-то ошибку, пока переносил.

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

Попробуй на фряхе потестить, для сравнения.

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

Не, я только поменял работу с консолью, кардинально ничего при этом не трогая.

Утечек вроде нет, постарался сделать всё чисто, но кто же это подтвердит?) Вполне может быть.

А что такое фряха?

А что такое фряха?

FreeBSD — https://freebsd.org

Не, я только поменял работу с консолью,

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

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

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

Настройки планировщика. В винде тоже можно крайне неплохо (в 6 раз точно разницы не будет). Но в лялихе годнее дефолт видимо.

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

Я тоже иногда наблюдаю, как некоторое ПО под wine работает как минимум отзывчивей, чем под виндой.

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

Не, я только поменял работу с консолью, кардинально ничего при этом не трогая.

this. Консоль вообще тормоз, а в винде так ещё и с гирями :-)

хочешь сравнить скорость - отключай консоль и весь непосредственно ненужный I/O

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

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

Либо, хотя-бы просто сообщить конфигурацию компилятора в линуксе и/или в маздайке.

Тоже плюсую дефолтные настройки планировщика.

Файлов всего 5 включая main.cpp

Но телепаты по-прежнему в отпуске.

верхним потолком для программы было 300 объектов,

При добавлении 301-ого венда превращалась в линукс?

Использовалась лишь одна несистемная библиотека (SFML) + Windows.h, всё остальное итак есть в Линуксе.
После переноса и подмены некоторых функций и библиотек столкнулся с такими вот ошибками:

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

Попробуй на фряхе потестить, для сравнения.

Вангую, что ТС делает что-то эффективное на pthreads и неэффективное в виндовой модели потоков, так что на фре будет примерно то же самое, что и на линуксе

Во-первых, в маздайке убогий компилятор

Да ну брось

особенно в сравнении с актуальным гцц

лол

Да ну брось

Споришь с объективной реальностью?

лол

Можешь показать компилятор лучше? Ну попытайся.

Ты его что ли сравниваешь с gcc на линуксе? так это теплое с мягким. И от компилятора шестикратного ускорения быть ну никак не может

Ты его что ли сравниваешь с gcc на линуксе?

Это неважно. Говно оно везде говно.

так это теплое с мягким.

Так это оправдания.

И от компилятора шестикратного ускорения быть ну никак не может

Может. К тому же, это не обязательно ТОЛЬКО компилятор. Зная каким дерьмом является маздайкай - там может быть всё, что угодно.

В предыдущей теме подобной(по крайней мере для меня) - у пациента была подобная проблема, и как оказалось там было дело в том, что маздайка вообще не юзает hugepages.

Поцчему никто до сих пор не предложил сравнить с выполнением в WSL?

Ну потому что WSL всяко тормознее будет.

Нет, порог в 300 объектов означает, что далее начинаются непростительные торомза, такой эффект на линуксе достигается лишь по добавлении 2000 объектов

Опять же, возможно, но я постарался не допустить этого + утечек памяти не было

если не хочешь домыслов - выкладывай исходники (можно не все), но показывающие ускорение в 6 раз

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

Помню ещё в самом начале нулевых мы в институте пилили парсер видеоряда с видеорегистратора (детект дефектов асфальта для последующего планирования заделывания дыр в нём).

У команды, тестирующей это всё с линуксом, оно на целероне отрабатывало без заеданий на скорости 60 км/ч.
А у вантузной команды оно на новом пентиум 4 быстрее 15 км/ч так и не заработало.

У тса всего 4 потока. Скорее всего, создаются на старте. По крайней мере про динамическое создание ни слова. ТС проясни.

В этом случае, потоки ощутимой разницы не дадут. Разве что он реально накосячил, и под виндой работает в один поток.

В общем без кода не понятно.

Не факт. Win32 очень толстое, а wsl вроде на ядрёном api реализован. Так что - анон прав, было бы интересно сравнить тем более это дёшево.

Там в WSL вроде I/O весьма плох.

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

gcc с шлангом не осилил Parallelism TS в отличие от. А это между прочим prequisite к стандартной библиотеке C++17.

разительный скачок в производительности

правильно приготовленый линукс будет летать даже на самом слабом и старом железе - видимо ты правильно приготовил линукс!

Надо будет кстати проверить, у меня даже есть на чём, только нет денег на соответсвующую виртуалку.

говнокодер детектед, профайлеры для дураков, давайте демагогией выяснять суть производительности

Нет, порог в 300 объектов означает, что далее начинаются непростительные торомза, такой эффект на линуксе достигается лишь по добавлении 2000 объектов

а что со свопом на винде и гнулинуксе? Сколько программа жрёт памяти в процессе выполнения? На эти 300 объектов?

С чем может быть связан такой разительный скачок в производительности, как это объясняется?

Предлагаешь на кофейной гуще годать? Профайлер в руки, если тебе это так интересно. Может быть всё что угодно от говённости винды и мсявого компилятора до UB в твоём коде, который позволяет компилятору выбросить половину вычислений, разумеется получив не тот результат что ты ожидал.

Не факт, если программа на каждый чих не открывает/закрывает файл. Открытие файла в WSL тормознее, да.

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

Правильно «шлангом, да и даже gcc». Шланг сейчас всех рвёт, подробности - у Яндекса которые используют именно его. Но микрософтовский обрубок да, далеко позади обоих.

софта на чём писана? так случаем какие-нить объекты/маллоки по ходу вычислений не создаются?

В маня-фантазиях твоих он что-то там рвёт.

gcc с шлангом не осилил Parallelism TS в отличие от.

Убожество для птушников.

А это между прочим prequisite к стандартной библиотеке C++17.

Зачем мне нужно это дерьмо? Мне нужен компилятор, а не убогие либы для птушников. К тому же, там нечего осиливать.

1. В линуксе лучше работают планировщики и многопоточность.

2. В линуксе подсистема ввода-вывода намного быстрее.

3. Компилятор GCC - один из лучших в мире, если не единственный лучший.

4. Ресурсы не отъедаются лишними процессами.

5. Оптимизация под используемую тобой архитектуру.

Благодарю, это действительно то, что я хотел увидеть.

Как это оптимизация под архитектуру?

Как это оптимизация под архитектуру?

Множество вариантов, допусти:

-march=native(либо что-то конкретное) - компилятор.

glibc(как пример) имеет множество реализаций одних и тех же функций оптимизированных под каждую из платформу(может и не под каждую, но в к этому стремятся), а далее в рантайме выбирает(в зависимости от того процессора на котором запускается) подходящую, наиболее оптимальную под данную «архитектуру».

Ядро - оно работает аналогичным(как glibc) образом. Множество платформа-специфичных фишек работают прозрачно(я уже приводил пример с hugepages).

Благодарю, это действительно то, что я хотел увидеть.

Ты ничего не увидел и не увидишь, т.к. не дал никакой конкретики.