llvm dev - Mar 2021 - [RFC] BOLT: A Framework for Binary Analysis, Transformation, and Optimization

On Wed, Mar 17, 2021 at 10:54 PM Mehdi AMINI <joker.eph at gmail.com>
wrote:
> Actually if I remember correctly flang went through multiple months of
preparatory upgrade that were asked for by some people in the community, and
they did so out-of-tree before getting ready to land in a single merge.
I have to admit that contrary to OpenMP, that I followed very closely,
I only superficially followed flang development. Thus, I stand
corrected by Mehdi and Eric here.
> We just have to make the expectation very clear and having a "moving
goalposts" situation and it should work fine. Any particular reason that
would put us in a "ad infinitum" situation?
I said "we may end up" -- or we may not. :-) No particular reason
apart of history of software engineering. As you said, clear
expectations from the very start are a key ingredient to avoid this
happening.

IMHO, it's infinitely better to start project development in a wide
and mature open source community ASAP -- at expense of some potential
refactoring work -- rather than delay until code is "good enough".
This says a man who spent most of his life working on proprietary
projects and used to argue with Chandler that "proprietary development
model is less expensive and leads to higher quality" (now I know
better). Just one man's opinion. It's fine to disagree.

Yours,
Andrey

On Thu, Mar 18, 2021 at 1:48 AM Andrey Bokhanko <andreybokhanko at
gmail.com>
wrote:
> On Wed, Mar 17, 2021 at 10:54 PM Mehdi AMINI <joker.eph at gmail.com>
wrote:
> > Actually if I remember correctly flang went through multiple months of
> preparatory upgrade that were asked for by some people in the community,
> and they did so out-of-tree before getting ready to land in a single merge.
>
> I have to admit that contrary to OpenMP, that I followed very closely,
> I only superficially followed flang development. Thus, I stand
> corrected by Mehdi and Eric here.
>
> > We just have to make the expectation very clear and having a
"moving
> goalposts" situation and it should work fine. Any particular reason
that
> would put us in a "ad infinitum" situation?
>
> I said "we may end up" -- or we may not. :-) No particular reason
> apart of history of software engineering. As you said, clear
> expectations from the very start are a key ingredient to avoid this
> happening.
>
> IMHO, it's infinitely better to start project development in a wide
> and mature open source community ASAP -- at expense of some potential
> refactoring work -- rather than delay until code is "good
enough".
> This says a man who spent most of his life working on proprietary
> projects and used to argue with Chandler that "proprietary development
> model is less expensive and leads to higher quality" (now I know
> better). Just one man's opinion. It's fine to disagree.
>
Not to disagree with what you said other than the 'infinitely' better
part
:) The situation here is different. BOLT has already gone through years of
development so it is not really a new project to start with.

Not saying it is actually the case, but it is very likely after years of
fast pace development, there are lots of tech debts piled up for this
project and it is now the *golden* opportunity to clean them up.  There
will be way less momentum to do this kind of work after it gets in --
especially when there are other new dependencies start to get in the way.

thanks,

David

> Yours,
> Andrey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210318/7d77699a/attachment.html>