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

Subject: Re: [boost] [container] New container: why is everybody silent?
From: Aleksandr Kupriianov (alexkupri_at_[hidden])
Date: 2014-07-16 02:42:28

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

> Hi Alex,
> 
> I tested the container with a floating-point benchmark
> that also performs numerous sequential operations on
> iterators ranging from [begin, end).
> 
> Here is my report and the interpretation of the report
> below the report:
> 
> ---------------------------------------------------------------
> 
> I found many warnings in both GCC as well as VC:
> 
> 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. 
> 
> 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.
> 
> I encourage you to keep going.
> 
> Cheers
> Chris
> 

Hi, Chris!

1) Thank you for spending some time to test my container.

2) Performance. Yes, for iterative and random-access the vector is slightly 
better (but only slightly, I'm also encouraged by 5.3 : 4.2 score). Vector 
is champion for these operations, and probably nobody can outperform it. But 
as soon as insertions/deletions are necessary, my container can outperform.

3) Real app. Are you writing the real app for microcontroller now? If you use 
insertions/deletions, especially random ones, my container can significantly 
outperform. Even if you just use push_back, my thing can slightly outperform. 
However, if you use iterative-access, vector wins, but not too much. I 
suggest you to try to use my thing in the real app.

4) Benchmark - can you provide a link?

5) C++11 - fully accepted. I'll deal with it soon.

6) Warnings - fully accepted. 

Best regards, and thank you again
Aleksandr