James Carlson wrote: > "C. Bergstr?m" writes: > >> James Carlson wrote: >> >>> It sounds like an interesting project, but unless there's some buy-in >>> from the others who'd be affected, I think you might be talking about >>> a fork of the code. >>> >>> >>> >> I'm not sure I would call it a brand new compiler since open64 shares >> the same frontend as gcc and cw/aw would function the same, but the code >> generation on the backend certainly would change.. I've fairly >> optimistic experience with the PathScale backend and optimization tools >> for it, but that's another discussion. >> >> /we/ are not planning to fork the code, but will almost certainly be an >> external gate.. >> > > That sounds a little problematic to me on two fronts. > > First, I think it's a rough assumption to say that _no_ code changes > will ever be needed when switching compilers, now or in the future as > new (unrelated) projects go into ON. Maybe you'll get lucky, but it's > certainly been our experience that every minor change in the compiler > involves at least *some* small change in the existing code -- > sometimes it's as small as stamping out a new warning nit that shows > up, and sometimes it's as big as a kernel corruption showstopper -- > and often affects future projects as well. > > If you do need to make changes, then you'll have at least two choices > to keep current: > > A. Maintain a separate fork and merge and test as you feel > necessary. > > B. Contribute the changes back upstream to ON, where this now causes > us to ask the question: "so, how will we know we won't break your > fixes in the future?" That gets into the policy issue noted > before. > > That question aside, there's potentially a second front here. > Assuming that you have no changes at all in the code, how do you > propose testing your separate build to make sure that every integrated > project still works fine? How do you know that this new super- > optimizing compiler hasn't opened a timing hole somewhere, given that > direct comparison of the binaries won't answer the question? Or that > the new compiler has exactly zero bugs that are triggered by all of > the code in ON? > > My guess is that you wouldn't _really_ be in a position to test it, > which means that you'd run the risk of stability problems. > > That's obviously conjecture, but it's based on what I've seen with > compiler transitions in the past. They're hard ... much harder than I > think you're guessing. They usually take weeks. > > (I'm sure at least one of the folks who works in this area is lurking > right now on the list ... he can probably speak up and give some more > words of wisdom.) > > >> it will start as a slave and then if/when we get >> contributions which meet the level of engineering/licensing (be that >> patches/bug fixes or new implementations..) we'll merge it.. QA/auto >> build and other things are planned because frankly I trust a centralized >> approach in *addition* to developer check to add another layer. imho >> Sun should at the very least eat their own dog food and support whatever >> the latest SSX is available as well. I mean.. why release that if it >> can't even compile onnv-gate.. there's _SSNEXT variable in >> Makefile.master just for this.. why it's not used.. ? I appreciate the >> input.. if you want to elaborate on the political situation for any >> potentially soon to be open sourced bits that could benefit my/others >> efforts I'm all ears.. >> > > It's not political, in the sense that "politics" refers to > relationships between people. > > It's technical. Even minor changes to the CBE (common build > environment), such as applying a patch to the compilers, are > potentially quite disruptive and have to made cautiously. > Historically, they always involve substantial changes. These changes > must be made carefully *exactly* because we do in fact "eat our own > dog food" and/or "fly our own airplanes:" the kernel that gets built > today will be running on desktops and servers throughout the company > tomorrow morning. > > (Yes, I realize that you're referring to our non-use of the latest- > and-greatest from the DevPro chain. But this is the on-discuss list, > and we're charged with keeping ON sane, not the entire Universe.) > > Making random and untested changes in a large and complex system like > Solaris wouldn't just be irresponsible; it'd be completely untenable. > See the QDS: nothing would work again, and (to paraphrase Woody Allen) > nobody would care. > > The political aspect, if there is one, is the development process > around all of this, which includes the rules for gatelings: you must > test, you must do so on all affected platforms, and you must do so > thoroughly. The political aspect of adding a new compiler to the mix > is that you'd be forcing every ON contributor to compile three times > instead of the current two -- just to make sure that your "open64" > support doesn't itself suffer bit-rot in the gate. That's not > necessarily a bad thing, but it's a non-zero change, and would take > work. > > Hi James..
At the very least I appreciate your very insightful reply.. Just because it compiles. .does it mean it boots? I *highly* doubt gcc gets anywhere near the same level of testing that suncc does.. I've flippantly asked those who are more than gatelings if it does boot and I'm still waiting for someone to tell me a definitive yes.. and something more than "if it doesn't.. it's a bug" Yes.. others have worked hard at this, but still lets look at this /testing/ you're referring to.. kernel performance regressions.. You guys build and test the spec benchmarks.. you run them with SS12.. SSX, but do you use gcc? Is there an internal policy on this? Now.. lets switch focus away from a corporate mentality and not care about onnv-gate or me pushing one line of code change or policy to ON... Part of my work isn't just screwing things up by using another compiler.. my work is at a high level also explicitly trying to lower the threshold for people to test.. When something like crossbow drops. "what if" it was easy for people to install/test/cr.. would that mean more people do it.. Now say we have thousands of people doing this on more hw and sw variants than Sun does internally.. Who is going to get more testing? Not everyone is going to be interested in testing Andrew Morton's patchset, but slowly I work towards making things like this possible.. Right now people toss out cr and beg for review in some circumstances.. "what if" that whole process was easier... What if we have a fully open toolchain and a continuous build server so we *know* when who to blame when the bleeding edge commits a breaking change... This thread is completely off the original intent which is me asking about libCrun.so.. I have the answer to that now.. Thanks ./C
