4 ms·
Graphs are here: https://tse.gratis/aArray/#details https://tse.gratis/aArray/#details And you're completely right, benchmarking is hard Edit: To expand on th
by tsegratis 8y ago
Graphs are here: https://tse.gratis/aArray/#details https://tse.gratis/aArray/#details
And you're completely right, benchmarking is hard
Edit:
To expand on that: I use someone else's benchmark since they have put effort into it, and already received feedback
For std::vector and binary search I performed multiple runs on several architectures, and did things like randomizing the benchmark order (which can have a big impact)
Complex struct is a good question
- gus_massa 8y agoAdd a link to it in the main page next to the 1/3 faster claim, something like "see the details". (Moreover, I'd add the graph in the overview page with a link to the complete discussion. I like graphs :) .)
- tsegratis 8y agoThankyou for your questions. They made me go back and re-test Saving vectors between runs and comparing their contents, changes things -- to the much more believable result of aArray being slower Only comparing the array lengths, but not their contents probably let gcc optimize out assignmemnts for aArray, but not std::vector -- leading to an unfair test Interestingly yes, std::vector now wins by a larger margin for int8_t arrays, and int64_t becomes a tighter match ----- Note: I've updated the website to remove the 1/3 claim! But I can no-longer edit the title of this thread The remaining stool legs of aArray are safety, simplicity, and being generic -- hopefully they don't get kicked out from under it quite so quickly ;^)