progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
this is a progress report on compiling python using entirely free software tools, no proprietary compilers or operating systems involved, yet still linking and successfully running with msvcr80 assemblies. manifests and rc files, which are compiled to internal resources, have been added. various sections which are uniquely identifed by _MSC_VER >= 1400 etc have had to be enabled with corresponding MSVCRT_VERSION >= 0x0800 - in particular, signal handling (PyOS_getsig()). currently, under wine with msvcr80, there looks like there is a bug with a common theme related to threads, but here's a short list: test_array.py is blocking, test_bz2.py is hanging and test_cmd_line.py causes a segfault; test_ctypes is _still_ a bundle of fun. for those people who use native win32 platforms who are compiling up this code, you should have better luck. significantly, the wine developers have been absolutely fantastic, and have fixed several bugs in wine, sometimes within hours, that were found as a result of running the extremely comprehensive python regression tests. the python regression tests are a credit to the collaborative incremental improvement process of free software development. i look forward to seeing the same incremental improvement applied to the development of python, evidence of which would be clearly seen by the acceptance of one of the following patches, one of which is dated 2003: http://bugs.python.org/issue3754 http://bugs.python.org/issue841454 http://bugs.python.org/issue3871 http://bugs.python.org/issue4954 http://bugs.python.org/issue5010 for those people wishing to track and contribute to the development of python for win32 using entirely free software tools, either under wine or native windows, there is a git repository, here, slightly illogically named pythonwine because that's where i started from (cross-compiling python under wine, so i could get at the wine registry from python). obviously, since then, things have... moved on :) http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine l.
correction: that's http://bugs.python.org/issue5026 apologies for the mix-up. also,for the msvcrt80 build, it is _essential_ that you use a patched version of mingw32-runtime, see: https://sourceforge.net/tracker/index.php?func=detail&aid=2134161&group_id=2435&atid=352435 libmsvcr80.a mistakenly thinks that _fstat exists (it doesn't - only _fstat32 does, and many more). it's quite straightforward to rebuild - just remember to run ./configure --prefix=/mingw and if you want to revert just reinstall mingw runtime .exe l.
Have you made some benchmarks like pystone? Cheers, Cesare On Wed, Jan 21, 2009 08:50PM, Luke Kenneth Casson Leighton wrote:
this is a progress report on compiling python using entirely free software tools, no proprietary compilers or operating systems involved, yet still linking and successfully running with msvcr80 assemblies. manifests and rc files, which are compiled to internal resources, have been added. various sections which are uniquely identifed by _MSC_VER >= 1400 etc have had to be enabled with corresponding MSVCRT_VERSION >= 0x0800 - in particular, signal handling (PyOS_getsig()).
currently, under wine with msvcr80, there looks like there is a bug with a common theme related to threads, but here's a short list: test_array.py is blocking, test_bz2.py is hanging and test_cmd_line.py causes a segfault; test_ctypes is _still_ a bundle of fun. for those people who use native win32 platforms who are compiling up this code, you should have better luck.
significantly, the wine developers have been absolutely fantastic, and have fixed several bugs in wine, sometimes within hours, that were found as a result of running the extremely comprehensive python regression tests.
the python regression tests are a credit to the collaborative incremental improvement process of free software development.
i look forward to seeing the same incremental improvement applied to the development of python, evidence of which would be clearly seen by the acceptance of one of the following patches, one of which is dated 2003: http://bugs.python.org/issue3754 http://bugs.python.org/issue841454 http://bugs.python.org/issue3871 http://bugs.python.org/issue4954 http://bugs.python.org/issue5010
for those people wishing to track and contribute to the development of python for win32 using entirely free software tools, either under wine or native windows, there is a git repository, here, slightly illogically named pythonwine because that's where i started from (cross-compiling python under wine, so i could get at the wine registry from python). obviously, since then, things have... moved on :)
http://github.com/lkcl/pythonwine/tree/python_2.5.2_wine
l. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/cesare.dimauro%40a-tono.co...
Cesare Di Mauro wrote:
Have you made some benchmarks like pystone?
There is result from pystone test test run an old PC (NT 5.1): - 2.6(official build): 42194,6; 42302,4; 41990,8; 42658,0; 42660,6; 42770,1 average=42429,4 deviation=311,6 - 2.6.1(official build): 35612,1; 35778,8; 35666,7; 35697,9; 35514,9; 35654,0 average=35654,1 deviation=88,1 - trunk(my mingw based build): 35256,7; 35272,5; 35247,2; 35270,7; 35225,6; 35233,5 average=35251,0 deviation=19,2 There is problem with python performance between 2.6 and 2.6.1 ~ 19% :(. Also the test for GCC-mingw is not with same source base. Roumen
Roumen Petrov wrote:
Cesare Di Mauro wrote:
Have you made some benchmarks like pystone?
Its seems to me version 2.6.1 is not optimized build so I remove(uninstall) it. I repeat the pystone tests with an optimized GCC(mingw32) build. - python-trunk-GCC(mingw32, local, native, optimized) -- shell=cmd.exe 35453,3; 35700,4; 35747,3; 35615,5; 35632,3; 35661,8; 35547,1 average=35622,5 deviation=98,0 -- shell=bash.exe(msys) 36002,1; 35884,4; 35961,7; 35859,5; 35997,3; 36062,9; 35747,1 average=35930,7 deviation=107,2 - python-2.6-MSVC -- shell=cmd.exe 35891,3; 35827,9; 35791,3; 35901,7; 35876,5; 36081,1; 36149,2 average=35931,3 deviation=132,7 -- shell=bash.exe(msys) 35532,9; 35621,1; 35526,8; 35639,4; 35671,2; 35702,4; 35633,0; average=35618,1 deviation=66,1 I don't have idea why performance of official python 2.6 goes down(see previous results below). It is same PC. Every tested program load own files. The result show unexpected behaviour: - the MSVC build is faster by ~0.9% if it is run under cmd.exe then msys bash; - the GCC build is faster by ~0.9% if it is run under msys bash. Otherwise results lock similar but note that builds use different source base and in this case we may can't compare. The old results:
There is result from pystone test test run an old PC (NT 5.1): - 2.6(official build): 42194,6; 42302,4; 41990,8; 42658,0; 42660,6; 42770,1 average=42429,4 deviation=311,6 - 2.6.1(official build): 35612,1; 35778,8; 35666,7; 35697,9; 35514,9; 35654,0 average=35654,1 deviation=88,1 - trunk(my mingw based build): 35256,7; 35272,5; 35247,2; 35270,7; 35225,6; 35233,5 average=35251,0 deviation=19,2
There is problem with python performance between 2.6 and 2.6.1 ~ 19% :(. Also the test for GCC-mingw is not with same source base.
Roumen
Roumen
Have you made some benchmarks like pystone?
Cheers, Cesare
Cesare, hi, thanks for responding: unfortunately, there's absolutely no point in making any benchmark figures under an emulated environment which does things like take 2 billion instruction cycles to start up a program named "c:/msys/bin/sh.exe", due to it inexplicably loading 200 GUI-only truetype fonts. and to do benchmarks on say windows would require that i install ... windows! so if somebody else would like to make some benchmarks, and publish them, they are most welcome to do so. l.
participants (3)
-
Cesare Di Mauro -
Luke Kenneth Casson Leighton -
Roumen Petrov