Re: Bjam in C++?

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-28 09:43:09

Vladimir Prus <ghost_at_[hidden]> writes:

>> I don't know. Python's already pretty darned good at manipulating
>> lists of strings. Add to that the fact that it has real integers and
>> highly optimized mappings, and it starts to look pretty good to me.
>
> I don't really know how optimized mappings in Python are compared with Jam, 
> and Python's list handling optimizations. Real integers are surely good.
> So, maybe conversion to Python will increase performance, maybe not. 
> But C++ would still be faster.

In most places, probably. When's the last time you successfully
implemented fast general-purpose hashing in C++? Python dicts are
remarkably efficient.

>> > Really, it probably would be much better if we implemented more
>> > stuff in C++ from the start, rather then trying to put everything
>> > into jam language layer. After all, very few users, if any, will
>> > ever need to hack core modules like properties.jam. For tools/*
>> > interpreted language is fine, but for core parts it's probably not
>> > needed.
>>
>> I can see both sides of this argument. On one hand, it's very nice
>> to have rapid development in a scripting language, and since the
>> language is implemented in 'C', we don't have to worry about
>> portability. On the other hand, the lack of type declarations and
>> static type checking make it hard to keep Jam code understandable
>> and maintainable. I don't see speed as a major argument for C++,
>> at least not yet: Jam's fundamental data structures and operations
>> are so limited in power that it's very hard to conclude that we're
>> paying for time spent in the interpreter (as opposed to just doing
>> stuff inefficiently because there's no other way).
>
> Right. And since in C++ we're not limited in any way, we can do
> things efficiently. The only necessary thing is that interface with
> Jam be thin, so that we don't loose all performance gain on that
> boundary.

I don't think that's the only neccessary thing. If the interface is
too thin, then you're stuck dealing with unexpressive Jam data
structures in C++. You need to do enough work in C++ to justify
improving the data abstractions it works with. I don't think speed
should be the only goal here.

> For example, I'm pretty sure that toolset.set-target-variables can
> be very optimzied -- just bacause C++ version won't need hash
> lookups on every access to variable (including various mappings
> indexed by flag number, necessary because we can't have "struct
> flag" in Jam").
>
>> Ultimately, I remain convinced that authors of Jamfiles need the
>> power of a scripting language at their disposal, and that it should
>> be possible to add support for a new toolset or operating system
>> without using a compiler. I don't know what to conclude about all
>> of this, though.
>
> I agree with the above. It's good to add toolset in a scripting
> language -- and I don't ever intend to rewrite "tools" layer in C++
> -- especially since it's not performance critical. I guess one day
> we can allow writing tools in Python -- I don't see a problem with
> that.

Well, if we're going to consider a C++-based build system, I think we
ought to consider the whole architecture, rather than allowing a 3rd
language to creep into an already-messy system. Nasty "language
creep" was one of the reasons I didn't want to go with autotools.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com