Re: [Boost-build] B2 C++ engine development.

Subject: Re: [Boost-build] B2 C++ engine development.
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2018-10-25 17:57:41

On Thu, Oct 25, 2018 at 12:55 PM Rene Rivera <grafikrobot_at_[hidden]> wrote:

> On Thu, Oct 25, 2018 at 12:41 PM Steven Watanabe via Boost-build <
> boost-build_at_[hidden]> wrote:
>
>> AMDG
>>
>> On 10/24/2018 09:58 PM, Rene Rivera via Boost-build wrote:
>> > One of my goals in the future of B2 is to move the engine to something
>> > easier to maintain and improve. As such it's my goal to incrementally
>> > rewrite the engine component of B2 in C++. Yesterday I completed an
>> initial
>> > step in that by having B2 compile as C++ instead of ANSI C. The code
>> > changes are in the "feature/cxx" branch and from outward appearances
>> it's
>> > exactly the same as before except that the build scripts now invoke the
>> C++
>> > compiler (only lightly tested for the compilers I have available). First
>> > con of this is that the executable is slightly fatter (about 20K on
>> OSX).
>> > But also the first pro, it's about 4% faster.
>> >
>>
>> Any explanation for this?  Are the build options
>> exactly the same other than -x c++?  The code
>> changes don't look significant, so is it just
>> that the stricter rules of C++ allow the optimizer
>> more freedom?  It looks like you're not linking
>> the C++ runtime (which was my first guess about
>> the binary size increase).
>>
>
> I think the speedup is from the stricter type rules of C++, probably
> constness and aliasing. But it would take way more investigation and
> looking at assembly to truly figure that out. And I'm not going to bother
> doing that :-) I don't prevent linking of the C++ runtime. But since it's
> not used yet I suspect it's just linked away anyway. My suspicion for size
> increase would be of the slightly different optimization behavior. In that
> it might prefer slightly larger code that performs better in many small
> instances.
>
>
>> > The idea is to merge this to develop, and eventually master, and
>> continue
>> > the C++ work based from those (as PRs).
>> >
>>
>> - Is there a reason that you eliminated the two stage
>>   bootstrap process?  Among other issues, you've made it
>>   impossible to create a debug build of b2.
>>
>
> I got tired of watching the double builds when it's just as easy to do it
> once. And I do intend to put in an option for a debug build (and the python
> build). Although technically you can still do it if you use the basic cxx
> toolset with CXX and CXXFLAGS. There's almost no benefit to having the
> build.jam as a large chunk of what it does is packaging. And we can do that
> many other ways that are less painful (like a python script). I.e. I'm
> trying to reduce complexity in the bootstrap building.
>
>
>> - While I support removing bjam, it's an entirely
>>   separate change.
>>
>
> I can easily add a copy in there again.
>
>
>> - Before this goes live, I'd like to see the files
>>   renamed to *.cpp.
>>
>
> Sure. I didn't want to rename things yet as I wanted to see the diffs
> clearly for verification.
>
>
>> - What language standard are we targeting?  filesystem
>>   is C++17.
>>
>
> C++11. As much as I would like to use the latest and greatest using the
> latest means we would have to immediately move to binary distribution.
> Maybe in the future we can move further, once we figure out what aspects of
> newer C++ are essential.
>

PS. One of the first items to think about is writing a new bjam language
parser. It's about time we stop relying on bison/yacc + the tokenizer :-)

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net