Project

General

Profile

Actions

Feature #19325

open

YJIT: Windows support lacking.

Added by dsisnero (Dominic Sisneros) 30 days ago. Updated 22 days ago.

Status:
Assigned
Priority:
Normal
Assignee:
Target version:
-
[ruby-core:111740]

Description

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.


Related issues 1 (1 open0 closed)

Is duplicate of Ruby master - Feature #18439: YJIT: Support Microsoft x86 calling conventionAssignedyjitActions

Updated by nobu (Nobuyoshi Nakada) 28 days ago

  • 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.

Updated by naruse (Yui NARUSE) 28 days ago

  • Assignee changed from k0kubun (Takashi Kokubun) to yjit
Actions #3

Updated by nobu (Nobuyoshi Nakada) 28 days ago

  • Status changed from Open to Assigned

Updated by matz (Yukihiro Matsumoto) 28 days ago

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.

Actions #5

Updated by naruse (Yui NARUSE) 28 days ago

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

Updated by mame (Yusuke Endoh) 28 days ago

  • 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.

Actions #7

Updated by k0kubun (Takashi Kokubun) 28 days ago

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

Updated by k0kubun (Takashi Kokubun) 28 days ago

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

Updated by mame (Yusuke Endoh) 28 days ago

  • 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

Updated by dsisnero (Dominic Sisneros) 28 days ago

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).

Updated by aidog (Andi Idogawa) 22 days ago

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

Actions

Also available in: Atom PDF

Like1
Like0Like0Like0Like0Like0Like0Like1Like0Like1Like0Like0