Re: [jamboost] Re: Bjam in C++?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-06-28 02:02:08

David Abrahams wrote:

> > And here C++ might come handy. If say, I write "class Property_set", then
> > it will speed up current Boost.Build, but this class will be also usable
> > in the long run.
>
> Point taken. But can you avoid building in dependencies on Jam's
> dumb data structures?

Good question. I think they might still be necessary in some places, but most 
likely only in "some" places, not everywhere.

> > I think that strategically, we better implement core features in a
> > language which is fast -- C++. I suspect that converting not very
> > efficient code into yet another language might have dramatic effect
> > on performance.
>
> 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.

> > 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. 

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.

- Volodya