[Rubyinstaller-devel] Migrate to GCC as soon as possible?
rogerpack2005 at gmail.com
Sun Nov 30 00:47:18 EST 2008
I agree--the reason I stick with MRI (despite its shortcomings--GC,
speed, etc.) is that it is the "de facto standard" and, like it or
not, used by most rubyists.
On Wed, Nov 26, 2008 at 2:34 PM, Luis Lavena <luislavena at gmail.com> wrote:
> 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:
>> They have a bunch of other benchmarks though:
> 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
>> 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
>> 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:
>> 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 and have a nice week!
> Luis Lavena
> AREA 17
> 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
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
More information about the Rubyinstaller-devel