One-Click Installer: MinGW? or VC2005?

stu wrote:

10% is a LOT! I’d like to see these numbers that proove 10%. I’d be
sure there is a difference but 10% is ridiculous.
It wouldn’t surprise me, but I’d still like to see numbers.

Optimisation is completely tangential to the current issue, anyway -
Ruby’s currently (if I remember correctly) broken with -O any higher
than 2, and it’s the toolchain integration that’s important here.

> Doesnt microsofts license forbid redistribution of VC Express anyway? > From the EULA:
  1. TRANSFER TO A THIRD PARTY. The first user of the software may
    transfer it, and this agreement, directly to a third party. Before
    the transfer, that party must agree that this agreement applies to
    the transfer and use of the software. The first user must uninstall
    the software before transferring it separately from the device. The
    first user may not retain any copies.

That’d be a no. That being said, if there’s already a dialogue open
with Microsoft, it might be possible to talk them into allowing a
distribution of only the command-line tools Ruby needs, and not the
whole IDE kit and kaboodle. Might.

From: stu [mailto:[email protected]]
Sent: Friday, July 21, 2006 1:40 PM

VC has still a much better optimizer then gcc, if you use
it with care
about 10% faster, which today where CPU’s are not getting faster as
fast is still important.

10% is a LOT! I’d like to see these numbers that proove 10%.
I’d be sure there is a difference but 10% is ridiculous.

I know this does not say much, but without fiddling with optimizer
flags I got the following numbers (again, for a very small set
of tests - does someone suggested a performance-test-suit?)


D:\simon\ruby-snapshot>ruby-vc6\ruby.exe -v sudoku-solver.rb
ruby 1.8.5 (2006-07-20) [i386-mswin32]
time elapsed: 26.969 sec.

D:\simon\ruby-snapshot>ruby-vc2005\ruby.exe -v sudoku-solver.rb
ruby 1.8.5 (2006-07-20) [i386-mswin32_80]
time elapsed: 19.766 sec.

D:\simon\ruby-snapshot>ruby-mingw\ruby.exe -v sudoku-solver.rb
ruby 1.8.5 (2006-07-20) [i386-mingw32]
time elapsed: 19.812 sec.

I don’t dare to say anything about vc2005 and gcc 3.4.5 (which
was used in the mingw build) but obviously we would benefit from
loosing the old vc6.

cheers

Simon

The test code was striped from ruby-talk: (shall I try anything else?)

$count = 0

def valid?(state, x, y)

check in col and row

0.upto(8) do |i|
return false if i != y and state[x][i] == state[x][y]
return false if i != x and state[i][y] == state[x][y]
end

check in box

x_from = (x / 3) * 3
y_from = (y / 3) * 3
x_from.upto(x_from + 2) do |xx|
y_from.upto(y_from + 2) do |yy|
return false if (xx != x or yy != y) and state[xx][yy] ==
state[x][y]
end
end

true
end

def next_state(state, x, y)
$count = $count + 1
y = 0 and x = x + 1 if y == 9
return true if x == 9

unless state[x][y].zero?
return false unless valid?(state, x, y)
return next_state(state, x, y + 1)
else
1.upto(9) do |i|
state[x][y] = i
return true if valid?(state, x, y) and next_state(state, x, y + 1)
end
end

state[x][y] = 0
false
end

MAIN

start =
[
[ 0, 0, 0, 4, 0, 5, 0, 0, 1 ],
[ 0, 7, 0, 0, 0, 0, 0, 3, 0 ],
[ 0, 0, 4, 0, 0, 0, 9, 0, 0 ],
[ 0, 0, 3, 5, 0, 4, 1, 0, 0 ],
[ 0, 0, 7, 0, 0, 0, 4, 0, 0 ],
[ 0, 0, 8, 9, 0, 1, 0, 0, 0 ],
[ 0, 0, 9, 0, 0, 0, 6, 0, 0 ],
[ 0, 8, 0, 0, 0, 0, 0, 2, 0 ],
[ 4, 0, 0, 2, 0, 0, 0, 0, 0 ]
]

start_time = Time.new

if next_state(start, 0, 0)
puts “time elapsed: #{Time.new - start_time} sec.”
puts “count: #{$count}”
start.each do |val|
puts val.join(" ")
end
else
puts “Not solveable!”
end

Hello stu,

s> 10% is a LOT! I’d like to see these numbers that proove 10%.
s> I’d be sure there is a difference but 10% is ridiculous.

I measured this with my machine. I only did a -O3 with gcc so maybe i
missed something but i wont out of box optimization.

s> And how close to the C++ spec was vc6? it was ABYSMAL! Its better in
s> vc2005.

gcc broke plain C, not C++.

And i don’t care about spec’s but i care about the millions of lines of
code that are out there in the world and the dozens of millions of money
it
needs to convert them. My conclusion since this day is and still is
never trust the GCC team.

s> The VC++2005 Express is 474mb download

Hmm, i must say i hadn’t looked at it, the VC6++ free download was
something like 10 MB but i think Express does no contain the whole
IDE.

To cut a long story short: I don’t trust MinGW.

s> I smell a rat. Most of your complaints are bogus.
No. Most of the projects that run in great trouble by choosing wrong
tools didn’t had these problems for technical reasons.

s> Doesnt microsofts license forbid redistribution of VC Express anyway?
Maybe. But because i think the one click installer shouldn’t include the
compiler this is not a valid argument for me.

At 77MB, it would have to be an optional add-on.

I agree, this might be better.

Nevertheless you don’t need to download 77MB.

My msys1.0.7z is 8.265.183 Bytes
(including MinGW, debug libs and so on)

There is a lot of unnecessary stuff left, but some libs are also
missing. (zlib etc.) My guess would be 10MB not more.

cheers

Simon

On Fri, 21 Jul 2006, Lothar S. wrote:

Some here

-1 for MingGW
+1 for VC

VC has still a much better optimizer then gcc, if you use it with care
about 10% faster, which today where CPU’s are not getting faster as
fast is still important.

didn’t someone further up this thread show that the mingw compiler was
better?
in any case i’m going to say that ruby’s speed isn’t in the category of
needing compiler optimizations - of course i’m one that always compiles
with
‘-g’ so as to ‘optimize’ my sunday after noon brash recovery :wink:

MS it is keeping better capatibility. How many thousands of programms
were brocken by the (technically unnecessary) changes from 3.3 to 3.4.

MinGW always had problems with Windows specific new technology because
in the past - don’t know how the situation is now - they were not
allowed to use the windows header files directly.

A 77MB toolchain is extremely heavy.

seriously? it’s only a few mp3s :wink:

Then look at the update frequency of MingW and components, i can use
MSVC for years without problems, but the release-often/release-too-early
sympthom of open source is a different beast.

And finally, it is always a good decision to use the compiler from the
system vendor. Unix guys should remember this. Even if it is a totally
strange HP PA-RISC compiler. This simply gives the best compatibility.

wow. that’s strange - i’ve worked on hp-ux, vax, solaris, sunos, and
linux
over the last 8 years and have found, without exception, that gcc
produces the
fastest code. additionally, the compiler is much (read that MUCH)
more
standards compiant. just getting variardic c functions working across
those
platforms was a chore - unless one uses gcc/glib…

To cut a long story short: I don’t trust MinGW.

that’s something i won’t argue with - but is there anything specific you
don’t
trust? because certainly many people don’t trust microsoft either - but
it’s
a bit of a relgious topic for most.

cheers.

-a

On 7/21/06, Lothar S. [email protected] wrote:

s> 10% is a LOT! I’d like to see these numbers that proove 10%.
s> I’d be sure there is a difference but 10% is ridiculous.

I measured this with my machine. I only did a -O3 with gcc so maybe i
missed something but i wont out of box optimization.

Umm. This is not really a sensible argument. What does out of the box
optimization have to do with anything? Too lazy to type -O2 !? Not to
mention that you mention 10% difference in performance which doesn’t
match up with the sudoku example posted.

s> And how close to the C++ spec was vc6? it was ABYSMAL! Its better in
s> vc2005.

gcc broke plain C, not C++.

Great. So you want a broken compiler now? And again, what does this
have to do with the point being raised, which is totally ignored? C++
is borken enough between compilers and versions of compilers without
mainstream vendors making it worse by shipping crappy implementations.

And i don’t care about spec’s but i care about the millions of lines of
code that are out there in the world and the dozens of millions of money it
needs to convert them. My conclusion since this day is and still is
never trust the GCC team.

Hell, I don’t trust you based on what you are saying here. You are
probably the type who doesn’t care about web standards either because
of the millions of Internet Explorer browsers out there in the world.
Right up until you discover you’re getting hacked through the buggy
implementation and can’t switch away because others who think like you
have made it impossible to use the web without that particular
browser.

I call that busy work. Creating extra needless work and hassle for
yourself because you are too short sighted to follow standards.
Consider that if Microsoft had bothered to follow standards we
wouldn’t even need to be discussing this. Or is that what you call
‘innovation’?

s> The VC++2005 Express is 474mb download

Hmm, i must say i hadn’t looked at it, the VC6++ free download was
something like 10 MB but i think Express does no contain the whole
IDE.

And if Express doesn’t contain the whole IDE that’s a whole lot more
to download isn’t it?

To cut a long story short: I don’t trust MinGW.

s> I smell a rat. Most of your complaints are bogus.
No. Most of the projects that run in great trouble by choosing wrong
tools didn’t had these problems for technical reasons.

More projects fail from wrong people than from wrong tools. If the
tool is so hot and important, why is Vista so late if the VC2005
compiler is such hot stuff to avoid ‘great trouble’?

s> Doesnt microsofts license forbid redistribution of VC Express anyway?
Maybe. But because i think the one click installer shouldn’t include the
compiler this is not a valid argument for me.

Complete noise. No meaningful contribution except shilling for what
appears to be a dead end and inferior product. So because you don’t
want the compiler we all should go and dance on the moon?

– G.

Hello Simon,

KSe> I know this does not say much, but without fiddling with optimizer
KSe> flags I got the following numbers (again, for a very small set
KSe> of tests - does someone suggested a performance-test-suit?)

Maybe your numbers are correct. But you should use a ruby compiled
with a current version of MSVC. The VC6.0 compiler we use at the moment
has a copyright tag of 1998. So it is 8 years or even more old.

On 7/18/06, Curt H. [email protected] wrote:

Thanks for taking the time to post such a detailed account. Now that you
mention it, I have encountered the very same problem myself with OpenSSL. I
actually gave up trying to solve the compile problem when I found a
pre-built binary for OpenSSL.

I’m on vacation, so of necessity my post and details will be limited.

I have never had a problem compiling OpenSSL. (Well, almost. They
accepted some makefile patches that I gave them to shut up bogus
warnings/errors in VC2005. After that, though, I had no problems.)

MASM is now also available as a free download, so I expect that I
could do the assembly compile, too. I might have even already done it
with the netwide assembler.

OpenSSL and zlib are good libraries to compile, and I’ve never had a
problem with them. The extensions are a little harder, and a lot of
makefiles are written stupidly (e.g., they run install not $(INSTALL)
which should protect you against stupid things).

To the real question, though, we should be using the native
compiler for any given platform. I would never use gcc on HP-UX, for
example, if I wanted anything approaching performance or
compatibility.

If there is a problem in the toolkit that Ruby provides for
extensions, we need to find ways to make the toolkit for Ruby
extensions larger. Things like GSL, however, probably need to have
bugfixes and patches filed against the GSL project to make it work
well with non-Unix platforms. There’s never a problem with producing
your own Makefile … or Rakefile.

-austin

On 7/18/06, [email protected] [email protected] wrote:

the caveat, however, is whether mingw can cut the mustard. i’ve not heard any
reason why it couldn’t - but i am simply not experience enough on windoze to
know for sure.

It can’t. It uses an older Win32 API and still doesn’t use the most
recent GCC and appears to be very slow on updating. MinGW appears to
compile significantly slower code than VC++ does, as well.

-austin

On Wed, 19 Jul 2006, Curt H. wrote:

I also prefer VC6, and I would stick with it except that it is no longer
available.

Are MinGW binaries compatible with VC6 binaries?

no. though they are very close.

-a

On Wed, 19 Jul 2006, Charlie S. wrote:

From my experience using both tool chains on Windows (for the ruby-prof
extension and SWIG-based extensions for GEOS and GDAL).

  • You can build Ruby extensions using MingW that run against Ruby built
    with VC++. I’ve done this with Ruby 1.8.2/1.8.4, various MingW releases
    and VC++ 2003 and VC++ 2005. This used to require changing a small bug
    in ruby.h for Ruby 1.8.2, but that bug has been fixed with 1.8.4. For
    more info see
    http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2206&group_id=426.

try compiling an extension that uses isacii (narray is one such). it
will
fail at runtime due to imcompatible def in vc++ runtime vs. mingw
runtime.

My recommendation:

  • Use VC++ 2005 and get Microsoft to tell us how to properly use unmanaged
    assemblies so that we can avoid dll hell

  • Make sure that mkrf supports building Ruby extensions
    “out-of-the-box” on Windows using MingW if you have it installed.

this would be nice except that core dumps/link failures will result!
:wink:

-a

On 7/18/06, U.Nakamura [email protected] wrote:

Even if you choose either, you will have to compile all sources
by the compiler as which you chose.

Mmm. This may or may not be the case. This is why I have been trying
to collect information for an ongoing conversation with Microsoft.
They are … concerned that we are still using VC6 as our compiler and
want to see what can be helped to provide better support for moving
Ruby to VC8.

And, FYI:
After a while, a new port named x64-mswin64 is scheduled to be supported on 1.9.
It’s able to compile only by VS2005, and at present there is no plan to support x64
by MinGW. This information is offered only to perplex you, Curt :slight_smile:

This is an excellent point that should not be ignored, either. 64-bit
Windows support is currently only possible through VS2005.

-austin

On 7/18/06, Tanner B. [email protected] wrote:

I think this is a fairly valid point though, and plays a point in this
discussion. Which of the two compiler tool chains, (as that is as much what
we’re talking about as compilers themselves) will make it easiest for
extension and library providers to get binary installs on windows? My
feeling is that MinGW will make it easier for people that already provide
extensions/libs on *nix to provide the same in Windows. The tool chain is
the same or at least close enough to keep people sane.

Not quite. MinGW won’t give you 64-bit Windows support. At all.
Probably not for another year or more, given that no one seems to be
working on it at this point.

The better question is not “easier”; the better question is “which
will give me better” binary results? The answer to that nearly every
time will be the Microsoft toolchain.

-austin

On 7/18/06, Bill K. [email protected] wrote:

It’s not uncommon, at a minimum, to have to tweak the
extconf.rb, though. Often an extconf.rb specifies
gcc-specific compiler flags, or looks for the presence
of libraries that are named differently, etc.

Then this is a bug with that extension. Anyone who assumes GCC only on
their extensions is being a platform chauvinist and possibly making
unreasonable assumptions for you. File a bug.

I recently compiled the RMagick extension on Windows,
and it was a complete hack job to get it to compile
with microsoft’s tools.

First of all, RMagick uses ./configure to actually
build the extconf.rb from extconf.rb.in.
So there’s no extconf.rb to even work with initially.

IMO, RMagick should not be using a sh-based configure script. We
should be using a Ruby-based configure script. Perl has done this; so
should we.

So, yeah… If we could build ruby extensions AND the
libraries they rely on with ./configure && make, on
Windows… That sounds far nicer than the current hassles
I’ve had trying to build complex extensions and their
associated libraries with microsoft’s tools.

I understand that this would make your life easier, but it’s not the
right answer. There are better answers than this, and we should take
advantage of them. The “parent” libraries may be more difficult, but
we should bitch to the upstream authors, too.

MinGW is … not the best choice. It’s not as nearly as bad a choice
as cygwin, but it is definitely an inferior choice to VC2005. Here’s a
question: what if we tried to convince Microsoft to build a
gcc-wrapper? That is, something for VC2005 that can convert gcc
command-lines to VC2005 command-lines automatically? IIRC, the Mars
compiler had something similar (cl-to-mars converter).

-austin

On Sat, 22 Jul 2006, Austin Z. wrote:

On 7/18/06, U.Nakamura [email protected] wrote:

Even if you choose either, you will have to compile all sources
by the compiler as which you chose.

Mmm. This may or may not be the case. This is why I have been trying
to collect information for an ongoing conversation with Microsoft.
They are … concerned that we are still using VC6 as our compiler and
want to see what can be helped to provide better support for moving
Ruby to VC8.

here’s an example showing the abis of the c libs are not compatible:

Ara@windozer C:/msys/1.0/home/Ara/build/narray-0.5.8
$ /c/ruby/bin/ruby -r ./narray.so -e’ p NArray ’
./narray.so: 127: The specified procedure (isacii) could not be
found. - ./narray.so (LoadError)

Ara@windozer C:/msys/1.0/home/Ara/build/narray-0.5.8
$ /c/usr/local/bin/ruby -r ./narray.so -e’ p NArray ’
NArray

to reproduce

  • install msys

  • build an msys ruby:

    • export LD_LIBRARY_PATH=/c/usr/local/lib
    • export LD_RUN_PATH=/c/usr/local/lib
    • download ruby
    • unpack
    • ./configure --prefix=/c/usr/local && make && make install
  • download and build narray using msys ruby:

    ruby extconf.rb && make && make install

if you’ve managed to install both the one-click and an msys ruby this
script
will demonstrate the issue (obviously run it from msys command line):

 #! /bin/bash

 msys_ruby="/c/usr/local/bin/ruby"
 one_click_ruby="/c/ruby/bin/ruby"

 unset RUBYOPT

 cd ~
 mkdir build 2>/dev/null
 cd build

 curl http://rubyforge.org/frs/download.php/7658/narray-0.5.8.tar.gz 

narray-0.5.8.tar.gz

 tar xvfz narray-0.5.8.tar.gz
 cd narray-0.5.8
 $msys_ruby extconf.rb && make && make install
 $msys_ruby -r narray -e'  puts "you just installed #{ NArray }"  '

 $msys_ruby -r ./narray.so -e'  p "msys narray success!"  '
 $one_click_ruby -r ./narray.so -e'  p "one_click_ruby narray 

success!" ’

 cd ~

i’ll be out of town all weekend, hopefully this is valuable info.

-a

On 7/18/06, M. Edward (Ed) Borasky [email protected] wrote:

Is cross-compiling/linking with GCC on a GNU platform a viable third
option? MinGW tends to lag “real” GCC. Given that you plan a Linux
release of the One-Click Ruby Installer, could you save yourself some
hassles with a cross-builder?

No. I would stop using the One-Click Ruby Installer if that were the
direction chosen and start offering my own based on something more
useful. Cross-compiling should be used only if that’s the only way
to get a good build for a platform (e.g., PalmOS).

-austin

On Sat, 22 Jul 2006, Austin Z. wrote:

On 7/18/06, [email protected] [email protected] wrote:

the caveat, however, is whether mingw can cut the mustard. i’ve not heard
any
reason why it couldn’t - but i am simply not experience enough on windoze
to
know for sure.

It can’t. It uses an older Win32 API and still doesn’t use the most
recent GCC and appears to be very slow on updating. MinGW appears to
compile significantly slower code than VC++ does, as well.

can you show some numbers?

-a

On 7/19/06, M. Edward (Ed) Borasky [email protected] wrote:

Can you freely distribute VS2005 Express, or must a user who wants to
build extensions with it acquire it themselves?
Can you freely distribute MinGW, or must a user who wants to build
extensions with it acquire it themselves?

This is a non-issue, IMO. Good links to say “here are the
prerequisites you need for (a), (b), and (c)” are IMO better. To put
it another way, I don’t want to add MinGW or any other compiler to the
already heavy RubyForge download stream.

-austin

On 7/19/06, Simon Kröger [email protected] wrote:

I would love a one click installer that would include a
minimal own compiler tool chain and ruby + all standard
extensions as source code. It could build them (optimized
for the actual hardware) during the installation process.

How big would such a packet be?

Big. Big enough to not be worth considering, IMO. (~80Mb is the
current MSYS dl, I thought I saw. I may be misremembering.)

-austin

On 7/19/06, Curt H. [email protected] wrote:

This is a very good point (both Mauricio’s and yours). Its an angle that I
had not thought of and could be a major plus.

I do not believe it offers sufficient benefit to consider it.

-austin