Feature #19325: YJIT: Windows support lacking.

• Status: Assigned
• Assignee: yjit
• Target version: -

[dsisnero (Dominic Sisneros)]

Ruby's support on windows has always been second class. With some of the recent decisions, windows support is falling even more behind. Recent developments in mjit and yjit that exclude windows are two glaring issues that should be corrected. Googling 'percent of windows vs other operating systems' and it shows windows has a share of 76%. Ceding that users to python and other programming languages has to be one of the reasons python continues get more market share from ruby. With rust having first class windows support and threading support, is there a reason why yjit is not able to work on windows? Also, windows compiler support has matured enough and vcpkg support has evolved enough that it seems it should be possible to finally get a ruby version without having to use msys2. Even Crystal language has a version that runs on windows without needing msys2.

[nobu (Nobuyoshi Nakada)]

• Assignee set to k0kubun (Takashi Kokubun)
• Backport changed from 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN to 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: UNKNOWN

With rust having first class windows support and threading support, is there a reason why yjit is not able to work on windows?

Whether the tool (rustc) used to write a (YJIT) compiler supports a platform and whether the compiler supports the platform are completely unrelated.
YJIT needs to emit code with obeying the convention for each platform, rust doesn't do it automatically.
In contrary, even if the former is not true, the latter can be possible; that is called a cross-compiler.

[naruse (Yui NARUSE)]

• Assignee changed from k0kubun (Takashi Kokubun) to yjit

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Assigned

[matz (Yukihiro Matsumoto)]

The reason Windows being second class is not lack of interest but lack of contributors with extensive experience with (non WSL) Windows platform. Any contributors?
I understand your frustration, but complaining does not improve the situation, unfortunately. We need contribution.

Matz.

[naruse (Yui NARUSE)]

• Tracker changed from Bug to Feature
• Backport deleted (2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: UNKNOWN)

[mame (Yusuke Endoh)]

• Tracker changed from Feature to Bug
• Backport set to 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN

dsisnero (Dominic Sisneros) wrote:

Also, windows compiler support has matured enough and vcpkg support has evolved enough that it seems it should be possible to finally get a ruby version without having to use msys2.

Well, you can build Ruby using VC++, nmake, etc, without msys2. Here is an instruction.

https://github.com/ruby/ruby/blob/master/win32/README.win32

There is an unofficial but more detailed document in Japanese, which uses vcpkg, etc.

https://gist.github.com/unak/54d68e1b7b96864457c116123a75eace

Actually, as far as I know, it is a more recommended way to use Ruby in Windows than msys2.

However, RubyInstaller uses the msys2 version. This is my guess, but since many gems do not support Windows, an emulation layer like msys2 will eventually be needed for practical use. This is not going to solve this situation by making a request to Ruby itself.

[k0kubun (Takashi Kokubun)]

• Is duplicate of Feature #18439: YJIT: Support Microsoft x86 calling convention added

[k0kubun (Takashi Kokubun)]

• Subject changed from Windows support lacking. to YJIT: Windows support lacking.

[mame (Yusuke Endoh)]

• Tracker changed from Bug to Feature
• Backport deleted (2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN)

Sorry, not intended to change the tracker

[dsisnero (Dominic Sisneros)]

Sorry my tone seemed to be complaining - I appreciate all the hard work being done and seeing that #18439 is being looked at eases my mind. I will try to contribute with some tooling to help ease the pain since I do use windows at work (unfortunately).

[aidog (Andi Idogawa)]

Hello everyone!
First, let me thank you for all your work! Ruby on Windows has helped me a lot over the years. Gems with C extensions used sometimes fail to install, but nowadays it works. Ruby Installer with MSYS2 actually works quite well. Of course, it would be nice, if MSYS2 wasn't necessary, but I believe most users care the most that for example gem install sqlite3 just works.

I'm a ruby programmer without much C experience, but as a challenge, I tried to figure out how to debug the ruby source code on windows. I think the easiest way to build is to use ruby-loco[1].
I managed to debug and step through the code, but it took me a few days. While I cannot help with development, wouldn't it be good to make it easier for others to build and debug ruby on windows, so a lot more people could easily help?

By the way, I started this project, because require takes longer on windows[2]. I found a lot of good work over the years to make FileIO on windows faster, but if you look at the linked CSV file [3] you will see a lot of syscalls (0.5 seconds long for require 'tzinfo'). I couldn't figure out if it's in the c code (winnt_stat should be cached?) or if it is actually rubygems that does unnecessary things.
If I remove all the duplicate syscalls with the (seemingly) same result from the file, it would only take 0.06 seconds... wow!

If we improve this, maybe more people will use ruby to make windows GUI applications, because they will start faster. Users don't need to install ruby, because there is ocra [4]. Of course, if we also get YJIT that would be even better.

Thanks again everyone!

[1] https://github.com/MSP-Greg/ruby-loco/
[2] https://github.com/oneclick/rubyinstaller2/issues/328
[3] https://github.com/oneclick/rubyinstaller2/files/10370934/Logfile.CSV
[4] https://github.com/larsch/ocra

[rubyFeedback (robert heiler)]

Although I have no data to showcase, my impression has been
that ruby is very slow on windows. Java on the other hand
is fairly fast on both windows and linux. With "require"
on windows, it seems to take significantly longer than
the equivalent (same .rb files code base) on Linux, and
the more gems I require, the longer it takes. Any improvement
there may be really nice to have, even if my above comment
is more anecdotal than "can be verified", as-is.

On windows I work around this a bit by wrapping kojix2'
libui wrapper, and running a custom shell, and then using that
GUI to input commands I would normally type via cmd.exe
or some other windows terminal. Once I have such a GUI
running, it gets significantly easier to use ruby on windows
(my custom shell is quite similar to e. g. bash, but runs
via ruby), but plain cmd.exe or even just commandline stuff
on windows can be quite frustrating.

Any improvement would be great. At this point I am using ruby
on linux mostly (where it is absolutely awesome), but for
windows I kind of transitioned to java (and have jruby/graalvm
available). The extra time investment when using java here
is somewhat worth it, considering how frustrating it can be
to use ruby on windows (which is not solely ruby's fault,
of course; linux is so much more convenient and productive
than windows really).

[tamaron (Raiki Tamura)]

Hello, any progress here?
I am very new to the Ruby community but interested in working on this.

[maximecb (Maxime Chevalier-Boisvert)]

Hello @tamaron (Raiki Tamura). There is no update as of yet. One of the challenges is that it's not easy for us to have access to windows machines, it would be kind of a pain for us to debug things in a VM. This would also add complexity to our CI test workflow. At the moment we're focused on servers and Apple hardware.