MinGW and Python

[Srijit Kumar Bhadra]

Is there any specific reason for not using MinGW to build the official
distribution of Python for Win32?
A quick Google search did not reveal the answer to my question. If a
link is available, please post it.

Best Regards,
Srijit

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Is there any specific reason for not using MinGW to build the official
distribution of Python for Win32?

What could be the reasons to use MinGW?

As for reasons not to do that:
- there is no build process available to do that
- people building extensions to Python must be able to do so with
Microsoft C++, since some of these extensions are written using MFC.
- developing Python itself in Visual Studio is quite convenient; in
particular, the debugger works "better" than gdb.

Regards,
Martin

 

[Josef Meile]

Is there any specific reason for not using MinGW to build the official

distribution of Python for Win32?
A quick Google search did not reveal the answer to my question. If a
link is available, please post it.

You may look at this thread:

* E02 - Support for MinGW Open Source Compiler
http://tinyurl.com/lxfsz

There was a big polemic and it is really long, but there are some useful
posts there.

Regards,
Josef

 

[Robert Kern]

What could be the reasons to use MinGW?

As for reasons not to do that:
- there is no build process available to do that
- people building extensions to Python must be able to do so with
Microsoft C++, since some of these extensions are written using MFC.
- developing Python itself in Visual Studio is quite convenient; in
particular, the debugger works "better" than gdb.

- gcc does not optimize particularly well.

--
Robert Kern
(e-mail address removed)

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Brian Elmegaard]

- gcc does not optimize particularly well.

But well enough for other platforms.

 

[Robert Kern]

But well enough for other platforms.

Well, it tends to optimize just as poorly for other platforms, too. It's just
frequently the only compiler widely available on those platforms. The goal of
the gcc project is to provide a portable compiler, not one that generates the
best code for any given platform. And in that goal, it succeeds remarkably well.

--
Robert Kern
(e-mail address removed)

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Brian Elmegaard]

the gcc project is to provide a portable compiler, not one that
generates the best code for any given platform. And in that goal, it
succeeds remarkably well.

Will a python program be slower on the same machine running windows
compared to linux?

What I don't understand is that it is not possible to distribute a
python compiled with gcc for windows. The main reason I saw in this
thread is that python uses mfc. So python requires api access, I
guess.

Once I asked about distutils here. The answer was that I had access to
the source so I could just extend it. After messing around I found I
couldn't because I don't have msvc.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

What I don't understand is that it is not possible to distribute a
python compiled with gcc for windows. The main reason I saw in this
thread is that python uses mfc. So python requires api access, I
guess.

You misunderstood. Python does not use MFC. PythonWin (for example)
does. That has a lot of implications which are hard to understand
if you are not familiar with Windows programming and the C library
mess on Windows.

It would certainly be possible to distribute a gcc-compiled python.
However, what is the point in doing so? Cygwin already includes
a gcc-compiled Python, for Windows:

http://cygwin.com/packages/python/

Once I asked about distutils here. The answer was that I had access to
the source so I could just extend it. After messing around I found I
couldn't because I don't have msvc.

That is simply not true. You can build the entire Python interpreter
with Cygwin (but you don't need to, because there is a precompiled
version), and you can build extensions for the python.org binary
using MingW.

Regards,
Martin

 

[Robert Kern]

Will a python program be slower on the same machine running windows
compared to linux?

Dunno. Depends on the machine. Depends on the program. Depends on how the
interpreter and any extension modules and underlying libraries were built.
Depends on which Linux and which Windows.

I'm sorry, but your question is a non sequitur. I don't understand its relevance
to this thread.

What I don't understand is that it is not possible to distribute a
python compiled with gcc for windows. The main reason I saw in this
thread is that python uses mfc. So python requires api access, I
guess.

It is possible. People have done it.

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

Once I asked about distutils here.

Okay. Again, what's the relevance here?

The answer was that I had access to
the source so I could just extend it. After messing around I found I
couldn't because I don't have msvc.

I'm not sure why this matters since distutils is pure Python.

If you meant writing extension modules for Python instead of extending
distutils, then you're in luck! You can indeed build extension modules with
mingw for the standard Python distribution. Please see my post in the thread "MS
VC++ Toolkit 2003, where?".

--
Robert Kern
(e-mail address removed)

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Fredrik Lundh]

Brian Elmegaard wrote

Will a python program be slower on the same machine running windows
compared to linux?

a better optimizer usually results in programs that run faster, not slower.

</F>

 

[Brian Elmegaard]

It would certainly be possible to distribute a gcc-compiled python.
However, what is the point in doing so? Cygwin already includes
a gcc-compiled Python, for Windows:
Interesting.

That is simply not true.

Actually, you answered me then too. I misunderstood after reading
http://sebsauvage.net/python/mingw.html.

Is the information on that page not correct? Has it never been?

You can build the entire Python interpreter with Cygwin (but you
don't need to, because there is a precompiled version), and you can
build extensions for the python.org binary using MingW.

Great, then I tend to agree that there is no reason for building it
with mingw.

 

[Brian Elmegaard]

If you meant writing extension modules for Python instead of extending
distutils,

I thought about extending distutils to make non-python installers. I
may have misunderstood the answers I got.
http://groups.google.com/group/comp...r:elmegaard+distutils&rnum=1#7af1aea19aa187b6

mingw for the standard Python distribution. Please see my post in the thread "MS
VC++ Toolkit 2003, where?".

Thanks, I will.

 

[Brian Elmegaard]

a better optimizer usually results in programs that run faster, not slower.

Got it the wrong after some editing ;-(

 

[sturlamolden]

- there is no build process available to do that

In MSYS:

$ ./configure --prefix=/c/mingw
$ make
$ make install

This should be obvious to any with Unix experience.

MinGW actually distribute precompiled Python binaries as well (in
MSYS-DTK).

- people building extensions to Python must be able to do so with
Microsoft C++, since some of these extensions are written using MFC.

MinGW can compile MFC. Download Windows Platform SDK and you get the
MFC source.

- developing Python itself in Visual Studio is quite convenient; in
particular, the debugger works "better" than gdb.

Eclipse is an excellent IDE that works with MinGW.

 

[sturlamolden]

- gcc does not optimize particularly well.

That is beyond BS. The more recent gcc releases optimize as well as any
commercial compiler. GCC 4 may even optimize better than MSVC.

GCC is the compiler used to build the Linux kernel and MacOSX. If it
can deal with this I say it can handle Python as well. My guess is you
will not notice any performance difference for the Python interpreter.
Doesn't Python run well on Linux? GCC is used to build Python on Linux.
MinGW is GCC. MinGW on Windows creates the same binary code as GCC on
Linux.

 

[sturlamolden]

Dunno. Depends on the machine. Depends on the program. Depends on how the
interpreter and any extension modules and underlying libraries were built.
Depends on which Linux and which Windows.

I'm sorry, but your question is a non sequitur. I don't understand its relevance
to this thread.

The relevance: Python is built with GCC on Linux. Do you or do you not
see a performance hit on Linux?

MinGW is GCC. Will you get a performance hit when building Python with
MinGW?

 

[sturlamolden]

I forgot to mention that C libraries built with Visual C++ and MinGW
are binary compatible. MinGW can link libararies and object files from
Visual C++. Although Python may be build with Visual C++, you can still
compile and link your C extensions with MinGW.

 

[Alex Martelli]

The relevance: Python is built with GCC on Linux. Do you or do you not
see a performance hit on Linux?

MinGW is GCC. Will you get a performance hit when building Python with
MinGW?

I cannot predict this, though it would be great if somebody who does
have both VS2003 and mingw could give it a try.

What I did just post on another thread over the last couple of days is
about MacOSX, which also uses gcc: 14% faster pybench using Python 2.4.3
under Win2000 under Parallels Workstation beta, compared to 2.4.3
Universal directly on MacOSX -- the standard build of 2.4.3 in either
cause, i.e., the one built with MS compilers on Windows, vs the one
built with Apple's gcc on MacOSX.


Alex

 

[Alex Martelli]

That is beyond BS. The more recent gcc releases optimize as well as any
commercial compiler. GCC 4 may even optimize better than MSVC.

GCC is the compiler used to build the Linux kernel and MacOSX. If it
can deal with this I say it can handle Python as well. My guess is you
will not notice any performance difference for the Python interpreter.

That is quite possible, of course: if, for example, the 14% speed
difference I measured with pybench is representative, then you might not
notice it because human beings have a hard time noticing time
differences of that magnitude. But it might still be there, easy to
measure, even though not to notice.

At the same time, if the 14% slowdown is representative, then it's not
true that the compiler responsible for it "optimizes as well" as the
other; indeed, "does not optimize particularly well", under such a
hypothesis, would be far from a "beyond BS" assertion.


Alex

 

[Scott David Daniels]

That is beyond BS.

The more recent gcc releases optimize as well as any
commercial compiler.

This is an outrageous claim. Having worked a bit doing
compilers, I no of no commercial compiler that would have
a leg to stand on if it claimed it optimized "as well as
any commercial compiler."

There are compilers and compiler experts out there in the
weeds that can (and regularly do) compile the hell out of code.
I took classes from one of these guys, and now he works in a
little company that does exactly that for particular customers
and problems.

Uncle Timmy, used to work for some of the places that employed
some of these experts. There is no "fully optimized state" for
compiled code (if the resultant instruction stream is greater
than a few hundred instructions); everyone approximates optimization.
It is almost inevitably a grey trade-off of compile time to speed
of resulting code over certain distributions of problems.

To say "gcc does a credible job of optimization" would not be
outrageous. To say "gcc optimization beats tool X on benchmark Y
on hardware Z by 1.237%" is a claim that could be made supportably,
but it would probably have to be accompanied with "using optimization
switches gcc-W for gcc and X-W for tool X."

I expect gcc does a reasonably good job of optimization, but the
best optimizers (as far as I know) are done by a relatively small
number of people who fully understand the workings of the optimizer
and its current workload, the workings of the hardware in question
as well, and have chosen a portion of that workload to become expert
in. Gcc does not have that expertise available to support people
to do things like that (nor does it need to). They don't need (or
want) to become wed to one architecture, but to do the best optimization
you must at some point get married.

The gcc team does a great job at what they do; blind defense of them
discredits the good work they do.

--Scott David Daniels
(e-mail address removed)