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 <alexkupri@gmail.com> wrote: 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost