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.