c++ version gives me 0.00027 sec for 100K mesh… but my machine is pretty old.
as i said the function doesn’t really do anything else than get and set values in memory.
def_visible_primitive(getMeshMapVerts, "getMeshMapVerts");
Value* getMeshMapVerts_cf(Value **arg_list, int count)
{
check_arg_count_with_keys(getMeshMapVerts, 1, count);
if (!is_mesh(arg_list[0])) return &undefined;
int vnum = 0;
Mesh* mesh = arg_list[0]->to_mesh();
int channel = key_arg_or_default(channel, Integer::intern(1))->to_int();
if (mesh->mapSupport(channel))
{
vnum = min(mesh->numVerts, mesh->getNumMapVerts(channel));
UVVert *mv = mesh->mapVerts(channel);
for (int k=0; k < vnum; k++)
{
if (mesh->verts[k].z) { }
float y = min(1.0f, max(0.0f, mv[k].y));
mv[k] = Point3(y,y,y);
}
}
return Integer::intern(vnum);
}
it’s not exactly the same but does do the same operations most native for c++ sdk way
Hmm I thought I would try to optimize it with SIMD for the fun of it, but I realize now it’s really not an ideal candidate due to the minimal amount of actions performed inside the loop and the AoS layout of the Point3’s.
Wouldn`t this an ideal candidate for parallelization through TPL?
http://msdn.microsoft.com/en-us/library/dd460717(v=vs.110).aspx
Probably only for meshes with huge amounts of vertices.
I would bet that the overhead of parallelization would be almost as high or higher than the runtime of the single-threaded function, though it’s easy enough to test.
With 40k verts using parallel.for I got ~23 seconds on 10k iterations, and ~37 seconds using the single threaded version. So that is pretty cool.
C#.
I replaced the for loop with just this:
Parallel.For(0, numMapVerts, i => ...
thank you for information