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

...

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

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.

I agree. Then it is important to provide the users with information regarding where btree_seq is most efficient, and where it is less efficient. Some library developers might wonder how btree_seq is different from std::list. What missing niche in the STL does btree_seq intend to fill?

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.

Yes. I can work out a test case.

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.

Yes. That's aood idea.

4) Benchmark - can you provide a link?

Yes.

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

OK. Give me a few days for cleanup. It's all at Github. Links will follow.

6) Warnings - fully accepted Some very high GCC Warning settings are shown below.

-Wall                          \ -Wextra                        \ -pedantic                      \ -Wmain                         \ -Wundef                        \ -Wsign-conversion              \ -Wunused-parameter             \ -Wuninitialized                \ -Wshadow                       \ -Wunreachable-code             \ -Wswitch-default               \ -Wswitch-enum                  \ -Wcast-align                   \ -Wmissing-include-dirs         \ -Winit-self                    \ -Wfloat-equal                  \ -Wdouble-promotion If you have -std=c++11, then you can also use: -Wzero-as-null-pointer-constant I also tested btree_seq on an 8-bit Atmel(R) AVR(R) microcontroller today. It was about 500 times slower than the ARM(R) core, but got the right results. So now btree_seq has seen some action on 8-bit, 32-bit. and 64-bit systems. ----------------------------------------------------------------- 8-bit Atmel(R) AVR(R) microcontroller Size analysis: * using neither     :  2240 byte * using std::vector :  4448 byte, delta =  2208 * using btree_seq   : 13504 byte, delta = 11264 Runtime analysis: * using std::vector : 1500 microseconds * using btree_seq   : 2200 microseconds ----------------------------------------------------------------- Cheers Chris On Wednesday, July 16, 2014 8:42 AM, Aleksandr Kupriianov wrote: Christopher Kormanyos 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 container_type; * typedef std::vector 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost