On Tuesday, 29 March 2016 at 21:27:15 UTC, ZombineDev wrote:
On Saturday, 26 March 2016 at 17:43:48 UTC, maik klein wrote:
On Saturday, 26 March 2016 at 17:06:39 UTC, ag0aep6g wrote:
On 26.03.2016 18:04, ag0aep6g wrote:
https://gist.github.com/aG0aep6G/a1b87df1ac5930870ffe/revisions
PS: Those enforces are for a size of 100_000 not 1_000_000,
because I'm impatient.
Thanks, okay that gives me more more reliable results.
for 1_000_000
benchmarking complete access
AoS: 1 sec, 87 ms, 266 μs, and 4 hnsecs
SoA: 1 sec, 491 ms, 186 μs, and 6 hnsecs
benchmarking partial access
AoS: 7 secs, 167 ms, 635 μs, and 8 hnsecs
SoA: 1 sec, 20 ms, 573 μs, and 1 hnsec
This is sort of what I expected. I will do a few more
benchmarks now. I probably also randomize the inputs.
Can you benchmark my implementation
(http://dpaste.dzfl.pl/3de1e18756f8) against yours? It should
have roughly the same API, except that mine doesn't support
pre-allocation (reserving capacity) - I wanted to keep it
minimalistic.
During access it should have the same performance, however the
insertion behavior should be noticeably different. I'm
interested to see if one larger allocation on insertion would
be faster than a number of small ones (or vice-versa). Though,
AoS should be the fastest in this regard (growth performance).
Yes I'll do it tomorrow, though I am not sure how much you can
rely on the data. I think it really depends on how fragmented the
heap currently is.
I will also benchmark memory access, just to see if there is any
difference. I recently asked a question about it on SO
https://stackoverflow.com/questions/36296960/pros-and-cons-of-one-big-buffer-vs-many-smaller-buffer?
Doesn't seem to be well received though.
