'Re: [boost] [container] New container: why is everybody silent?'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [container] New container: why is everybody silent?
From:       Christopher Kormanyos <e_float () yahoo ! com>
Date:       2014-07-15 19:38:23
Message-ID: 1405453103.46875.YahooMailNeo () web172401 ! mail ! ir2 ! yahoo ! com
[Download RAW message or body]

>>> Please tell me something about my container, don't be silent.
>>> I firmly intend to offer it to boost, because it's much faster than
>>> competitors (by a constant factor).

>> I am interested in using the container on a microcontroller,
>> for which performance is crucial. I intend to use your container
>> in combination with a custom allocator.
>>
>> Cheers
>> Chris

> Hi Chris!
> Thank you for your answer. If you have any questions regarding
> the container, feel free to ask me.

Hi Alex,

I can provide you with my benchmark results below. Please do
not be discouraged by the potentially disappointing report, as
I suspect my benchmark might be stressing the node-linked
list in the wrong areas --- and with the wrong competition
(std::vector).

I tested the container with a floating-point benchmark
that also performs numerous sequential operations on
iterators ranging from [begin, end).

I used a desktop PC with Microsoft Visual Studio 2013
and an ARM(R) A8 microcontroller with GCC 4.8.2.
I used the container with a custom allocator having
a memory pool of 512 bytes.

Here is my report and the interpretation of the report
below the report:

---------------------------------------------------------------

I found many warnings in both GCC as well as VC:
- redundant semicolons (empty statements)
- local variables shadowing class members.
- non-explicit conversion to/from signed/unsigned
- signed / unsigned comparison
- unary minus applied to unsigned type
- unreferenced local variables

I stripped the implementation:
* I removed all exception handling and asserts.

I identified the container uses in the benchmark:
* Create two containers.
* One container has 4 floats, the other has 5 floats.

Do in a loop about 10 times the following:
* On each container apply std::accumulate with std::multiplies.
* On each container apply std::for_each with element incrementation.
* Do the normal floating-point operations and loop management.

I use a custom allocator with 512 byte pool:
* typedef util::ring_allocator<T> allocator_type;

I use either btree_seq or std::vector:
* typedef btree_seq<T, 12, 24, allocator_type> container_type;
* typedef std::vector<T, allocator_type> container_type;

I perform the numerical correctness analysis:
* Run on PC with VS2012.  Result OK.
* Run on ARM A8 with GCC. Result OK.

I perform the size analysis on the ARM(R):
* using neither     :  7344 byte
* using std::vector :  8928 byte, delta = 1584
* using btree_seq   : 15968 byte, delta = 8624

I perform the runtime analysis on the ARM(R):
* using std::vector : 4.4 microseconds
* using btree_seq   : 5.3 microseconds

-----------------------------------------------------------------------------

Interpretation:

The btree_seq obtains the correct result and can be used on
a PC as well as microcontroller with a custom allocator.
This is very positive!

The btree_seq creates much more code than the corresponding
use of std::vector. In addition, btree_seq runs significantly
slower than std::vector in this particular benchmark. One possible
explanation for this might be due to the large overhead of creating
a linked list in the constructor. This is not consistent with
your expected result and deserves further investigation.

The code could be potentially cleaned up significantly.
For this, build at very high warning levels and eliminate
all warnings.

As mentioned earlier, some C++11 awareness might be
mandatory. An awareness of move construction, nullptr
where appropriate, and construction / equating with
std::initializer_list. Boost has C++11 compiler switches for
these and more C++11 features.

If you would like to see the code of the benchmark, it
is available in the public domain.

If you would like me to provide more measurement data,
I might have time to compare with std::deque. I could
also potentially provide you with a greater granularity
regarding where the cycles and the bytes get lost with
btree_seq.

Please do not be discouraged by this report. It is only
stressing a few use-cases, and certainly does not test
btree_seq in its entirety.

I encourage you to keep going.

Cheers
Chris

On Tuesday, July 15, 2014 2:20 PM, Aleksandr Kupriianov <alexkupri@gmail.com> wrote:

Christopher Kormanyos <e_float <at> yahoo.com> writes:

> 
> 
> > Please tell me something about my container, don't be silent.
> > I firmly intend to offer it to boost, because it's much faster than 
> > competitors (by a constant factor).
> 
> I am interested in using the container on a microcontroller,
> for which performance is crucial. I intend to use your container
> in combination with a custom allocator.
> 
> I think folks are still working very hard on the release.
> I am also very busy with normal work and the GSoC 2014
> program. So could you please grant us maybe a bit
> more time?
> 
> Cheers
> Chris

Hi Chris!
Thank you for your answer. If you have any questions regarding the container, 
feel free to ask me.
By the way, if you are going to use it on microcontroller, other template 
parameters L,M might be better (smaller, I think), also default are good 
enough, I believe. I mean: btree_seq<Your_Class,15,30>.

Everybody! If you are going to use it, just tell me: Alex, I'm using it, 
it's cool (or not so cool).
Best regards,
Aleksandr Kupriianov

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread] 