[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-bugs-list
Subject:    [issue33351] Support compiling with clang-cl on Windows
From:       Ethan Smith <report () bugs ! python ! org>
Date:       2018-04-30 2:16:02
Message-ID: 1525054562.6.0.682650639539.issue33351 () psf ! upfronthosting ! co ! za
[Download RAW message or body]


Ethan Smith <ethan@ethanhs.me> added the comment:

> Feel free to start creating patches so we can get an idea of what the changes would \
> look like. Hopefully it's not that dramatic.


Okay, will do. I have a few smaller patches to start with. Clang-cl tries to be as \
compatible as possible with cl, so I don't expect drastic changes. I'm currently \
trying to figure out an include issue with timeval, but so far the patches have been \
few and small.


> Be very careful making performance claims without benchmarks to back it up, and \
> ideally against multiple sets of hardware (MSVC is designed and tested to perform \
> well across a range of processors, often by engineers who work for the manufacturer \
> - intuition would suggest that an open source compiler is probably not 30% better \
> all the time). Don't focus on the number right now, but do try to collect the \
> justification before you expect or encourage others to do the work.


I did not mean to say it would make Python 30% faster in all cases, I meant "up to \
30% faster". This number is based on benchmarks of CPython with and without computed \
goto, and my own experiments of benchmarks comparing CPython in the WSL, and native \
Windows CPython releases on x86_64. But your point is well taken, and I will of \
course benchmark Python compiled with clang-cl once I have a complete working \
version.


> Since the ABI is compatible, there should be no problem enabling extensions to be \
> built using this compiler (assuming someone is willing to become a distutils \
> maintainer, as there are currently none). You don't need to ask here to create a \
> third-party library that enables this.


When you say "someone to become a distutils maintainer" you mean for clang-cl \
specifically? If that is the case, I'm happy to add support and commit to continuing \
to work on clang-cl support in distutils, as I expect to use it a fair amount.


> I haven't heard any complaints about access to the compilers being an issue \
> recently, so the only reasons to switch the interpreter itself would be source \
> compatibility (essentially, the clang clib is better than our custom Win32 code) or \
> performance. But we need a positive reason to switch support, not just the ability.


I agree there should be a good reason to move away from the MSVC compiler. The \
decision to move can be re-evaluated when there is a good argument to warrant it.

----------

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue33351>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-bugs-list%40marc.info



[prev in list] [next in list] [prev in thread] [next in thread]