On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting <ha...@hannosch.eu> wrote: > I'm a relative outsider to core development (I'm just a Plone release > manager), but'll allow myself a couple of questions. Feel free to > ignore them, if you think they are not relevant at this point :-) I'd > note that I'm generally enthusiastic and supportive of the proposal :) > As a data point, I can add that all tests of Zope 2.12 / Plone 4.0 and > their dependency set run fine under Unladen Swallow.
Hi, thanks for checking that! > On Wed, Jan 20, 2010 at 11:27 PM, Collin Winter <collinwin...@google.com> > wrote: >> We have chosen to reuse a set of existing compiler libraries called LLVM >> [#llvm]_ for code generation and code optimization. > > Would it be prudent to ask for more information about the llvm > project? Especially in terms of its non-code related aspects. I can > try to hunt down this information myself, but as a complete outsider > to the llvm project this takes much longer, compared to someone who > has interacted with the project as closely as you have. > > Questions like: > > - Who holds the copyright, is there a foundation or is there a risk of > the project getting into trouble because of copyright issues? See http://llvm.org/docs/DeveloperPolicy.html#clp. The University of Illinois holds the copyright. > - What licence is the code and the tools under and what affect does > that have on the code generated by the JIT compiler? LLVM's under the University of Illinois/NCSA license, which is BSD-like: http://www.opensource.org/licenses/UoI-NCSA.php or http://llvm.org/releases/2.6/LICENSE.TXT. If I understand correctly, code transformed by a compiler isn't a work derived from that compiler, so the compiler's license has no bearing on the license of the output code. > - What's the bus factor of the project? Is it in practice dependent on > a single BDFL or a single company like Apple? I believe the project would survive either Chris Lattner or Apple getting bored. Even though Apple provides much of the development effort right now, LLVM has enough users (http://llvm.org/Users.html) to pick up the slack if they need to. Adobe, Cray, Google, NVidia, and Rapidmind all contribute patches back to LLVM. (And Unladen Swallow isn't the only reason Google cares.) > - What's the status of the documentation or web presence? Does the > project consist only of developers or has it been able to attract > people from other backgrounds? The documentation's quite good: http://llvm.org/docs/. What other backgrounds are you asking about? I don't think they have any sculptors on the project. ;) > On the code related side you described general enthusiasm and support > of the llvm community, but noted that some aspect of it aren't as > mature as others. You also noted that given Python's good test > coverage you have been able to find problems in llvm itself. This > raises some questions to me: > > - Does the llvm project employ automated test driven development, are > there functioning nightly test runs? Yep: http://google1.osuosl.org:8011/console. We've been adding tests as we fix bugs so they don't regress. They also have a larger "nightly" test suite that runs whole programs, http://llvm.org/docs/TestingGuide.html#quicktestsuite, but it isn't actually run every night. > - What do they do to ensure a good quality of their software, how many > critical regressions have their been in final releases? In addition to the unit tests and "nightly" tests, they have beta and release candidate phases during which they ask the community to test out the new release with our projects. Nick Lewycky (cc'ed) answered your second question with: "back in ... 1.7-ish? we had to do a 1.7.1 release within 24 hours due to an accidental release with a critical regression". Since LLVM's now on 2.6, I take that as "not very many". > - Is there a clearly distinguished core and stable part of the project > that is separate from more experimental ideas? Not really. > - What's the status of their known bugs? Do "important" issues get > resolved in a reasonable time? I'm not entirely sure how to answer that. The bugs database is at http://llvm.org/bugs, and they've tended to fix bugs I ran into pretty quickly, when those bugs affected the static compiler. JIT bugs get handled somewhat more slowly, but I've also been able to fix those bugs myself fairly easily. > - Did they have security problems related to their codebase, have > those been handled in a professional manner? I haven't been exposed to their resolution of any security problems, so I can't really answer that either. Inside of Python, LLVM will be pretty insulated from the outside world, so the risk exposure shouldn't be _too_ great, but I'm not really qualified to evaluate that. If a Python user could send arbitrary IR into LLVM, they could probably exploit the process, but Unladen doesn't give users a way to do that. Nick can talk more about this. > There's probably more of these questions you tend to ask yourself > somewhat implicitly when trying to assess how mature and stable a > given open-source project is. My feeling is that llvm is still a > slightly new and up and coming project and it would be good to get a > better idea about how mature they are. > >> Platform Support >> ================ >> >> Unladen Swallow is inherently limited by the platform support provided by >> LLVM, >> especially LLVM's JIT compilation system [#llvm-hardware]_. LLVM's JIT has >> the >> best support on x86 and x86-64 systems, and these are the platforms where >> Unladen Swallow has received the most testing. We are confident in >> LLVM/Unladen >> Swallow's support for x86 and x86-64 hardware. PPC and ARM support exists, >> but >> is not widely used and may be buggy. > > How does the platform support work with new versions of operating > systems? If for example a Windows 8 is released, is it likely that > llvm will need to be adjusted to support such a new version? They need to stay compatible with any ABI changes in a new OS, but most new OS versions try to stay compatible with the old ABI, so I don't think there are many issues there. We'd need a new LLVM version for new processors or 64-bit versions of old processors. They may not currently support Win64 for the JIT, so when that becomes required we might need to upgrade. > What kind > of effect does this have on how a Python release can add support for > such a new version? If nothing else, Python could disable LLVM on the new platform until a new LLVM is released. > Is there evidence from past releases that give an > indication on the time if costs the llvm team to support a new > version? Do they only add support for this to their latest release or > are such changes backported to older releases? They don't currently backport changes to old releases. > > The Windows support doesn't seem to be a specific focus of the > project. Are there core developers of llvm that run and support > Windows or is this left to outside contributors? There are at least 2 core LLVM developers that run primarily on Windows, covering both MSVC and mingw. > Is the feature set > the same across different operating systems, or are there areas in > which they differ in a significant manner? I don't know of areas where features "differ"; usually a feature will just be missing on a less-supported platform. >> Managing LLVM Releases, C++ API Changes >> --------------------------------------- >> >> LLVM is released regularly every six months. This means that LLVM may be >> released two or three times during the course of development of a CPython 3.x >> release. Each LLVM release brings newer and more powerful optimizations, >> improved platform support and more sophisticated code generation. > > How does the support and maintenance policy of llvm releases look > like? If a Python version is pegged to a specific llvm release, it > needs to be able to rely on critical bug fixes and security fixes to > be made for that release for a rather prolonged time. How does this > match the llvm policies given their frequent time based releases? LLVM doesn't currently do "dot" releases. So, once 2.7 is released, it's very unlikely there would be a 2.6.1. They do make release branches, and they've said they're open to dot releases if someone else does them, so if we need a patch release for some issue we could make it ourselves. I recognize that's not ideal, but I also expect that we'll be able to work around LLVM bugs with changes in Python, rather than needing to change LLVM. > Sorry if those questions aren't appropriate. It's what comes to my > mind when thinking about a new and quite heavy dependency :-) Those are great questions. Thanks for the opportunity to answer them. :) _______________________________________________ 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/archive%40mail-archive.com
