Почему рубин настолько медленнее на окнах?

Question

Каковы конкретные технические причины, по которым Ruby в Windows настолько медленнее? Люди сообщают о снижении скорости на 3X от Linux/OSX, и есть некоторые неопределенные дискуссии о Ruby с использованием компилятора для версий Windows, которые производят медленный код, но я не могу найти никаких конкретных деталей.

Кто-нибудь знает особенности? Меня не интересует hurf durf Windoze сосет yuk yuks.

Answer 1

Я думаю, есть несколько возможных вариантов, и они, вероятно, все сложить:

1. рубин разрабатывается в основном на Linux, он заканчивает механически оптимизированы для него. Код регулярно протестирован для Windows, и все работает, но в результате разработчик будет тратить больше времени на Linux, чем Windows.
2. К моему опыту, последние версии gcc (4.3 и выше) дают код более эффективный, чем последние версии Visual Studio (по крайней мере, 2005). Мои тесты включали в оба случая расходы примерно на день, найдя лучшие варианты оптимизации кода.
3. Связано с пунктом 1, если вы скомпилируете один и тот же проект с использованием gcc для Windows или Linux, я обычно наблюдаю снижение производительности около 20% в Windows по сравнению с Linux. И здесь, я полагаю, это связано с тем, что Linux (или Unices в целом) является основной целью для gcc, windows - это порт. Оптимизация для Windows меньше, чем Linux.

В конце концов, если вы хотите оптимизировать Ruby для Windows, значительное время (и деньги, насколько мне известно, профилировщики на Windows не предоставляются бесплатно) придется потратить используя профилировщик и оптимизируя узкие места. И все нужно будет протестировать на Linux, чтобы убедиться, что нет потери производительности.

Конечно, все испытания должны быть проверены повторно с их новым переводчиком YARV.

Answer 2

Сначала вам необходимо провести различие между старшими MRI interpreter (версии до 1,8) и новее YARV, который является официальным интерпретатором Ruby 1.9. В Ruby 1.9 есть большие улучшения производительности и другой дизайн, поэтому вам нужно знать, в какой версии вы говорите. Я предполагаю, что то, что вы прочитали, относится к версии 1.8.x, которая является единственной, у которой есть установщик с одним щелчком мыши.

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

Что касается компилятора, Ruby может быть построен с использованием любой новой версии Visual Studio, что более чем нормально. Я предполагаю, что если такая разница в производительности существует, нужно посмотреть на реализацию интерпретатора и посмотреть, есть ли что-то, что могло бы сделать разницу между POSIX и системой Windows.

Answer 3

Удар производительности не составляет 300%, в общем случае он ближе к 50% -100%. Повседневное объяснение Джима является одной из причин, почему сценарии обработки данных медленнее в Windows по сравнению с Unix-вариантами и Linux.

В более общем случае единственное, о чем я могу думать, это то, что разработка Ruby ориентирована на Linux, что привело к созданию многих Unix -измов в способе создания Ruby.Кроме того, поскольку большинство активных разработчиков не являются пользователями Windows, в команде присутствует очень мало опыта оптимизации Windows, и большинство решений по оптимизации производительности направлены на ускорение работы в Unix-системах.

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

Я не могу понять, хотя, что Casual Jim сделал, чтобы заслужить -8 голосов.

Answer 4

Не совсем на ваш вопрос, но было замечательное обсуждение на Deep Fried Bytes podcast, в котором обсуждался тот же вопрос в контексте IronPython. Я понимаю, что ваш вопрос относится к Ruby, но могут быть связанные проблемы, которые также влияют на Ruby.

Кроме того, обсуждение действительно выглядит немного глубже, чем «Windows отстой», поэтому стоит проверить его.

Answer 5

Я не очень много работал с исходным кодом интерпретатора YARV, поэтому следующие комментарии относятся только к интерпретатору 1.8.6 MIR.

При попытке написать расширение C для Ruby в Visual Studio, я с ужасом обнаружил, что загружаемые двоичные файлы Windows Ruby 1.8.6 скомпилированы с использованием Visual C++ 6.0, который был выпущен вскоре после окончания вторая мировая война. С тех пор компиляторы (и процессоры, на которые они нацелены) значительно продвинулись. В то время как сборка Linux получает новейшую gcc-доброту, Windows build хромает вместе с технологией компилятора прошлого века. Это одна из причин. (Отказ от ответственности: предположительно 1.9 должен быть построен с помощью mingw, из которых я не являюсь поклонником, но который также должен быть лучше, чем VC6)

Не зная, какие операционные системы, в частности, вы обнаружите медленнее в Windows, сложно комментировать дальше, но я хотел бы отметить, что я обнаружил, что реализация ввода-вывода на Ruby значительно менее эффективна как с сетевым, так и с локальным файловым вводом-выводом. Я никогда не углублялся в реализацию примитивов ввода-вывода, чтобы понять, почему, но я предполагаю, что реализации предполагают, что быстрые построения IO в Linux - это быстрые конструкции ввода-вывода в Windows, что почти всегда не так.

Answer 6

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

Выполните следующую команду, чтобы распаковать целое ntfs диск от его корня (т. е. «C: \») и посмотреть, есть ли какие-либо различия, для меня это сильно изменило и получило рубин/рельсы обратно к тому, к чему я привык раньше!

команда:

compact /u /s /i