[Rubyinstaller-devel] Migrate to GCC as soon as possible?

Luis Lavena luislavena at gmail.com
Wed Nov 26 16:34:01 EST 2008

On Wed, Nov 26, 2008 at 5:39 AM, Joao Pedrosa <joaopedrosa at gmail.com> wrote:
> Hi guys,
> First of all, thanks for working on this installer which is much
> appreciated. :-)
> It was how I first installed Ruby for instance. :-)

Thanks to you and welcome! :-)

> But for a long-time I have also been running Ruby on Linux and left Windows
> by itself since then. Every now and then I could be seen testing Ruby
> on Windows though, and this is such an occasion.

Sometimes I go back and forth these environments too, so I know how
you must feel.

> Today I was testing these versions of Ruby:
> ruby -v
> ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
> C:\t_\downloads\rubyinstaller\sandbox\ruby_mingw\bin\ruby -v
> ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]
> jruby -v
> jruby 1.1.5 (ruby 1.8.6 patchlevel 114) (2008-11-26 rev ) [x86-java]
> When building the MinGW Ruby I used git to download the rubyinstaller
> scripts and ran it with rake. When it got to the Rubygems part it returned
> an error during the "ruby setup.rb [...] c:/path/c:/doubling_path" or something.
> I was able to install the Rubygems by running the setup manually for it, though
> I am not sure what else I missed from the remaining of the installation scripts.

Yes, rubyinstaller bugs should be fixed soon. Been focusing energy in
the new scripts and some helpers to solve the issues of several

Manually installing latest version of rubygems (1.3.1) works, so
fixing the scripts will be easy.

> To test the different Ruby versions, I ran some JRuby benchmark files with each
> interpreter to make a rough comparison. JRuby came faster by a good margin,
> though JRuby has different setups itself (--client, --server, -X-C)
> which influence
> the results. In general though, JRuby has closed the gap and generally surpassed
> MRI's performance. Second faster came the MinGW Ruby I just built. Only in
> third and last came the original OneClick installed Ruby which uses VC6 right?

Yes, current One-Click Installer is based on VC6.

Is good to know VC6 build was beaten by both Jruby and MinGW build!

Every time I test jruby I don't enable any of these flags since
"average joe ruby" will need to dig into the documentation or some
sites to get info from them.

In any case, these should be enabled by default, right? These are safe
to be used by average joe?

For example, MinGW version is built with zero flag optimization, and
it's even including debug information (-g) to ease the debug process
while developing the package.

> You can run the benchmarks I ran and see for yourself:
> http://svn.codehaus.org/jruby/trunk/jruby/bench/language/bench_colon.rb
> http://svn.codehaus.org/jruby/trunk/jruby/bench/bench_regex.rb
> They have a bunch of other benchmarks though:
> http://svn.codehaus.org/jruby/trunk/jruby/bench/

Cool, I'll check them out later if time allows.

> JRuby could "just work" on unfriendly environments such as Windows while
> it has been a pain in the neck all these years to fully support Ruby on
> Windows. To top it all, JRuby could run considerably faster than Ruby on
> Windows in special.

The thing is that JRuby requires several things:

JRE for running it.
JDK for extending it from Java.

Also with it's drawbacks:

Has no native support for extensions, so Hpricot, nokogiri,
RubyInline, ParseTree and many others end with problems.

Pretty much current Ruby for Windows situation, anyway :-D

The dependency in a 12 years old compiler (VC6) has made the
development and compilation of gems on Windows a real problem.

The goal of using MinGW is not beat VC6 speed (which is a desire) but
instead ease the integration path between platforms.

JRuby, like IronRuby adds another layer of compatibility concerns both
developers and users should take in consideration.

> I have barely used JRuby at all thus far, and it's not a perfect
> replacement for
> Ruby just yet. For example, JRuby can have a hard time presenting more
> friendly error messages which really tell what went wrong, but it's evolving,
> improving, and it "steals" the platform infrastructure from Java so
> they can focus
> on other issues. Also, when testing GUI applications (GTK+), Ruby runs
> instantly while JRuby with Swing can take a while longer, though they could
> improve it as well. JRuby generally starts slower with more complex
> applications,
> is that fair to say? :-)

Yes, JRuby was it's own nice looking attributes, neither me or anyone
can deny that some of those are good looking.

> I came to Ruby from Java and a disillusionment with the .NET surge and the
> splitting of the developers into worlds. Ruby was meant to be the third way,
> but now Java and .NET more than promise to support Ruby. Also, Java and .NET
> try to leave the C/C++ world behind for as much as most developers are
> concerned.
> As I currently see it, instead of having Ruby by itself, the future will bring
> Ruby + Java and Ruby + .NET and we will have to deal with that and it will
> be a nice problem to have. :-)

Don't forget to include Rubinius in the mix. :-D

Yet still, there will be flavors of Ruby implementations for all the
backgrounds, the ones coming form Java, and the ones coming from .NET

> See an example of IronRuby:
> http://www.valleyhighlands.com/ttc/post/IronRuby-for-the-Newbie.aspx
> What worries me is Ruby having its ass kicked by these other implementations
> mainly on Windows. I personally think it's just easier to run JRuby on Windows
> and in the name of reaching a consensus, JRuby could win as my preferred
> platform, at least until Microsoft adopts the GNU tools or .NET + Mono
> with IronRuby give Java and JRuby something to worry about.

In some way I agree with your statement, but I don't feel in that way.

As I mentioned previously, neither JRuby or IronRuby will be able to
work with a huge number of gems that require native extensions.

In case there is no binding for the library neither in Java or dotNet,
then the users should decide for other libraries or switch back to

The goal of One-Click Installer is ease the path, integrating GNU
tools and documenting the whole process which has been, until now,
close managed by the guys at garbagecollect for their "binary

Even more, I will not doubt on creating a One-Click JRuby/IronRuby
Installer in the future, only if people is interested.

> I guess Ruby on Windows will need to take advantage of the latest improvements
> on compilers and whatnot to keep it competitive. If Microsoft's C compiler
> builds faster executables it could be better to use it, though MinGW's GCC
> could be "fast enough" and even more compatible.

The VC8/9 path has been discussed previously in the list under which I
expressed both my points and concerns. As you said, MinGW will provide
more value to the equation.

> It's high-time something great happens to Ruby on Windows, other than
> Java and .NET. :-)
> I invite you to run some of the benchmarks found in the JRuby repository.
> JRuby can be run in different ways:

I'll as soon time allows, and maybe drop some post in my blog.

> # generally opts for a simpler JVM said to be the "client" one:
> jruby bench_colon.rb
> # found only in the JDK, this one can more aggressively try to optimize:
> jruby --server bench_colon.rb
> # disables the ruby to bytecode compiler because the interpreter is
> fast already:
> jruby --server -X-C bench_colon.rb
> And compare "stuff".
> I extended myself a lot in this post but I continue to be thoroughly thankful
> for the work of you guys.

Thanks to you man for putting together all this, exposing issues and
your point of view about One-Click Installer and current situation.

I believe that even JRuby or IronRuby became good candidates for usage
on Windows, there is still room for MRI (and maybe Rubinius?) :-D

> Cheers,
> Joao

Cheers and have a nice week!
Luis Lavena
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

More information about the Rubyinstaller-devel mailing list