Почему Ruby намного медленнее в Windows?

Question

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

Кто-нибудь знает специфику? Я не заинтересован в Hurf Durf Windoze сосет юк юкс.

Answer 1

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

1. Ruby в основном разрабатывается для 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

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

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

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

Answer 3

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

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

Answer 4

Сначала нужно провести различие между старшим MRI-интерпретатором (версии до 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 5

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

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

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

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

Answer 6

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

Запустите следующую команду, чтобы распаковать весь диск NTFS от его корня (то есть "C: \") и посмотреть, есть ли какие-либо различия, для меня это имело огромное значение и вернуло скорость ruby ​​/ rails к тому, что я был раньше раньше!

команда:

compact /u /s /i