Re: [boost] [xint] Third release is ready, requesting preliminary review

Subject: Re: [boost] [xint] Third release is ready, requesting preliminary review
From: Marius Stoica (letto2_at_[hidden])
Date: 2010-05-02 09:49:52

On Saturday 01 May 2010 21:27:43 Chad Nelson wrote:
> On 05/01/2010 02:08 PM, Marius Stoica wrote:
> >> That would simplify things a great deal. I've never tried it
> >> though... an extra 130K of headers in every source code file that
> >> uses the library is a little much, isn't it?
> > 
> > I don't think that's an issue. Most(almost all) of that code is
> > conditionally compiled and the final size of what would end up in a
> > binnary will be very small.
> 
> It's still code that would have to be read and parsed for every
> compilation unit that includes it. Computers are a lot faster these days
> than when I learned to program, but that's still enough to make me think
> twice before doing something like that.
> 
> > Also let me check some of the other libraries in boost.
> > 
> > Here in alphabethic order (Afaict all of these are header only)
> > accumulators - 506k
> > algoritm - 305k
> > archive - 395k
> > asio - 1.5MiB
> > assign - 95k
> > bitmap - 488k
> > bind - 177k
> 
> I've used a few of those, and haven't noticed a major compile-speed
> problem, which is an argument in your favor.
> 

Dunno if you notticed but i was just checking the first boost libraries in 
alphabethic order. I guess what i was trying to say is that pretty much all 
the boost libraries are like this. It's ... tradition :)

Also i'm not certain the headers need to be parsed every time anyway. Most 
compiler support precompiled headers. If compilation speed becomes too much of 
an issue I'm sure they'll become more widely used.

> > Also because ubuntu screwed up their boost doesn't mean that all
> > distros will. The default compiled behaviour should be the one that
> > works in all cases not the one that's faster imho.
> 
> I'm sorry to say that my opinion differs. If someone is evaluating the
> library against several others to see which one he wants to use, he's
> not likely to dig into the documentation to figure out how to get the
> best speed out of it -- he's going to compare the default
> configurations. I'd like XInt to still be in the running when he does.
> 

That's certainly a good point since i've seen software getting a reputation 
for being slow and not being able to change that reputation despite seriously 
improving in performance.(postgresql)

> Also, multithreaded operation is still fairly uncommon. I'd hate to make
> everyone pay for something that only a few need, especially when the
> speed cost is so high (the single-threaded version is *twice* the speed
> of the multithreaded one).

How did you managed to get that difference anyway since threads are just 
processes without the memory protection.
C++11 will add several things related to this including thread local storage , 
move and others. Do you expect that with this the difference will dissapear?

If so i think it's best to support this with a compile flag since that can be 
easily deprecated.