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
I'm not sure I understand your words "using neither", that's why I asked for a link. Yes, size for 8-bit Atmel is a little bit unexpected; normally it takes roughly 2 times more memory than vector.
The sizes refer to the actual size of constant program
code. This is something that most PC programmers
rarely consider in normal development.
When I write "neither", it means the size of the microcontroller
program code without the benchmark part active. In other
words, there is neither vector nor btree_seq being used
because noe of the benchmark code is active.
The benchmark is linked below. Actually it is a stronger
benchmark for floating-point portability rather than for containers.
But it is well-tested code, and i have it available. So I decided
to use it for a preliminary look at btree_seq.
The benchmark is called within ugly compiler switches
when these lines are un-commented.
//#define CFG_USE_APP_BENCHMARK_FPU
// #define CFG_APP_BENCHMARK_FPU_TYPE CFG_APP_BENCHMARK_FPU_TYPE_HYPERG
https://github.com/ckormanyos/real-time-cpp/blob/master/ref_app/src/app/benc...
The code for the mathematical hypergeometric function in
the actual benchmark run is here.
https://github.com/ckormanyos/real-time-cpp/blob/master/ref_app/src/app/benc...
The function hypergeometric_pfq is being called.
I can (and maybe should) work out some simpler test
cases that more clearly expose the functionality of
btree_seq.
Cheers, Chris
On Thursday, July 17, 2014 1:45 PM, Aleksandr Kupriianov
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.
Thank you so much for testing my thing. External testing is very important psychological thing, because my own tests can be too gentle. Random insertions and deletions are things where it's champion.
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?
Shortly speaking my thing is between list and vector. It sells everything for
O(log(N)) price. In the list you can insert something in the middle for a
constant time, only if you have an iterator, but going into the middle will
take O(N) time. If you insert in the middle using vector, it will require O
(N) anyway.
Another niche is possible porting string on its basis. I.e., something like
this:
typedef string_abstraction
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
I'm not sure I understand your words "using neither", that's why I asked for a link. Yes, size for 8-bit Atmel is a little bit unexpected; normally it takes roughly 2 times more memory than vector. Thank you 1e10 times for testing, Best regards, Aleksandr _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost