From: Andreas Dolfen (a.dolfen_at_[hidden])
Date: 2006-04-21 06:12:29
> A nother thing you could try is compiling test/placement_new.cpp and
> what the return value is. If this is -3 then you can enable
> which can make a major difference on some compilers.
It's sad. The error code is 0 so that is probably not causing the
> echo $?
Can you give a short comment on why this might have affected
performance? My understanding is that when you allocate more than one
element the system has to store how much actually was allocated. This
causes the offset of sizeof(std::size_t) (which btw is 4 on my system
and not 8)? Is this interpretation of what you do in the program right?
And why might it affect performance?
> A couple of things you could look at. uBLAS has bench1-4. If you are only
> using Dense matrices then it would be sufficient to just compile up bench1
> for both versions and compare results. This may give us a better idea of
> which operations are suffering.
I think it does not make sense anymore to develop a test case since
the problem occurs in the bench1 benchmark as well.
When you compare the results of the benchmark for boost1.33.1 to
boost1.30.2 you can see that every single timing is worse in the newer
version. Do you have any ideas what to try next? What might be the
Is it possible to use the old ublas of boost 1.30.2 with the rest of the