weird chrono time
borissmidt opened this issue · comments
When i run the benchmarks they sometimes give huge numbers that make no sence could these be overflows or so?
since the benchmark really didn't take soo long, the numbers are in us so that would be almost an hour per iteration.
Start fill_back___Trivial_128_
ptrvector:100000:20104828006
ptrvector:200000:20104846378
ptrvector:300000:20104874560
ptrvector:400000:20104911025
ptrvector:500000:20104995430
ptrvector:600000:20105101428
ptrvector:700000:20105224248
ptrvector:800000:20105364027
ptrvector:900000:20105521204
ptrvector:1000000:20105699188
vector:100000:10940
vector:200000:37706
vector:300000:91221
vector:400000:151032
vector:500000:217300
vector:600000:333053
vector:700000:454590
vector:800000:581747
vector:900000:714614
vector:1000000:853260
i now have divided the time before summing it and it hels but the list now give some weird results.
'list_inserter:100000:140723549969'
Also i do not think that implementing a custom container is easy since i need to implement a custom iterator as well then.
I have been able to implement some iterators for my custom pointer vector but i still have the chrono timing bug.
But if the time is correct then a vector of pointers is faster than a vector from array sizes of 128. But i cannot really compare it to the other errors because of the timing error.
I have solved it by explicitly setting the duration to 0 .
The benchmarks of my wrapped pointer vector show that it is faster than a vector at random insert from size 128. i will soon run all the tests.
But i think the pointer vector could be faster if i could somehow pre allocate reserved space. for example with a memory pool but i geuss this is too complex for me now.
Hi,
Sorry about that. I've slightly changed the timing function, it should not have these weird numbers anymore. Could you check again ?
Yes, it is likely that if you reserve the memory in a single block, it will be faster because of very good data locality of the pointers.
yea i used the same solution aswell to solve the chrono problem. i have the results in, the ptr vector seems faster than a linked list. But i guess the vector implementation is verry naive since it only allocated on an incert like a linked list and i am certain it could be made faster with a memory pool instead like a vector or deque. So then the performance would probably be between a deque and vector. except the fill back. the graph is html but github doesn't support it.
graph.txt
here is the naive ptr vector implementation. i quess i learned a thing or two from using you highly templated benchmark.
pointer_vector.txt
Maybe in the future when i'm better at programming C++ i could program my own pointer vector where which uses an allocator to pre allocate a memory block for the container. So the container becomes less naive and has some capacity reserved.
If you use vector as an underlying implementation, you at least have memory reserve for the pointers, but indeed it would probably be faster to have a memory pool for the objects themselves, but this is not trivial work.
I don't get the difference between const_iterator and iterator in your implementation. You use *a in iterator (which seems correct) for operator and &a in const_iterator. Otherwise, it seems quite good 👍
Yea i should come back later to it if i ever need it. But i guess a ponter vector + memory pool is almost like a deque in its structure but with more direct acces.
But the iterators do not implement enough for the c++ sort method. and thank for the complement.
I'm closing this issue, please reopen if there are still problems with this.