Skip to content

Conversation

@JustCallMeRay
Copy link

Change set 1:

I had intended to make the function mc::mc_add_vertex branchless to improve performance but it was not more performant on quickbench. I then added "-ffast-math" and saw the performance decrease even more so there may be a flaw in my benchmark.

For documentation the code was:

double calculated_value = mc_isovalue_interpolation(isovalue, f1, f2,
        // Use maths instead of branches for quicker code
        // True -> 1,  False -> 0
          (x1 * (axis == 0))
        + (y1 * (axis == 1))
        + (z1 * (axis == 2)),
    c2);
    auto to_return = vertices->size()/3;
    // Write in correct order with maths as well
    vertices->push_back((calculated_value * (axis == 0)) + (x1 * (axis != 0)));
    vertices->push_back((calculated_value * (axis == 1)) + (y1 * (axis != 1)));
    vertices->push_back((calculated_value * (axis == 2)) + (z1 * (axis != 2))); 

And was later changed to use ternary operators instead of floating point maths.

Change set 2:

These changes relate to reserving the size of vectors before adding to them.
By default vectors have a small capacity, the standard does not specify but (cppreference)[https://en.cppreference.com/w/cpp/container/vector/capacity] suggests they start at 0. When an item would be added past the end of the buffer the internal buffer goes through a reallocation. Normally this reallocation adds half the size of the buffer again, (growing by 1.5x).

Reserving an initial estimate with .reserve() will heavily reduce the amount of allocations and increase the speed of the program. Overusing reserve (say reserving 3 in mc_add_vertex) can increase the amount of allocations, worsening performance.

Much better estimates may further increase performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant