WASM questions (JS in browser)

[stewartoallen]

I've managed to get Manifold working in my app fairly quickly. Love it. My experience with WASM has been limited to a couple of helper functions where I ditched auto-generated bindings in favor of direct access to shared memory. In those cases, I am also directly controlling the loading and unloading of WASM modules since it is a) a feature that is optionally turned on/off and b) the WASM gets loaded into a lot workers, which can end up sitting on a lot of memory.

For the Manifold bindings, is it possible to control (or have visibility into) the amount of memory reserved for each instance? Is it possible to control the url from which the WASM is loaded? In my use case, I would be loading the library into as many workers as the browser indicates for concurrency and then parallelizing operations on a shared buffer (which is ultimately use by a ThreeJS mesh).

[pca006132]

I don't think you can control the memory for each instance efficiently, iirc the heap can only grow but not shrink, and growing the heap seems quite slow. I think instead of parallelizing it by setting up many instances, we should look into using pthread for concurrency. I tried implementing a very simple OpenMP interface with pthread but it was very inefficient due to synchronization overhead, but we did many optimizations afterwards and it might be feasible for now.

[stewartoallen]

And if the performance is right (see other post about flattened array transfer) then it opens up an intriguing path to solving a 4+ axis CAM simulation problem.

[pca006132]

Note that we have some optimizations that can reorder operations and perform lazy operation for a series of boolean ops. If you do each operation, convert the result to a mesh, and pass it to another manifold instance and do other operations, it will lose the laziness and misses the optimization opportunity.

[stewartoallen]

The use case I am imaging above involves progressively passing a milling tool through a solid (subtractive) and extracting the updated mesh after each move to be visualized. It has to be relatively fast to be useful. The mesh will grow in size and complexity as the tool moves through it.

[pca006132]

For this case you may want to split the solid into a disjoint set of meshes first, and only do boolean for meshes that touch the milling tool. This can dramatically reduce the size of the mesh that needs to be passed between js and wasm.

Manifold will not perform operations in-place, so it will do quite a lot of copying, which might be slow in your case. The mesh after union should still be correct.

[stewartoallen]

This was the plan :) And if the tool passed through several mesh regions, it could be parallelized in workers. Being able to provide the buffer for a flattened output from Manifold can speed this up significantly. No need to union the final meshes since it is only for visualization.

[pca006132]

Also, regarding memory usage, you may want to check if you are freeing the memory after using the objects. We wrote a simple utility to free up the memory after use for our editor demo

manifold/bindings/wasm/examples/worker.js

Line 39 in 0fb4769

let manifoldRegistry = [];

You may want to do something similar but free the memory more often.

[elalish]

Yes, you can force the Boolean ops by calling anything that would require them like genus(), which has pretty much zero overhead.

[stewartoallen]

another failure mode. this is a lot harder to create a simple test for. adding genus() after each boolean seems to slow it down orders of magnitude. if I let it run for 5, 10, 50, 100 ops before running genus() it gets farther until the ops start generating large meshes. then it seems to fail with the sum of the size of the accumulated changes. and this is the error I get. remember, it happens sooner or later in the same cutting job depending on the number of accumulated changes I allow.

[elalish]

Well, if you're comparing calling genus() inside your loop to calling getMesh() once after the loop, then sure. The difference is in the first case you're actually performing the booleans during the loop. In the latter, you start to perform them only after the loop completes. I need to sit down and play with it and see if I can repro all this. Thanks for the manifoldcad example!

[stewartoallen]

putting timing around the loop + getMesh() call, a chain of deferred booleans with one getMesh() call at the end is far faster than doing them with a genus() call after each op and a getMesh() call at the end. does that sound right? it's doing the exact same ops in the same order.

[stewartoallen]

spent a bunch more time on this with a slightly altered torture test. the idea is that the complexity of the boolean grows progressively. batching should have no effect on timing. but it does at higher complexity which equates to memory pressure. it's not the recursion limit that gets you then. it's a little odd that smaller batches reduce memory pressure. iow, the test that fails with larger batches will succeed with smaller ones. I would not expect a modest queue size to induce that much pressure.

console.time('ball test');
let iter = 1; // increases final complexity (cpu + mem)
let maxBatch = 10; // increases memory pressure
let sphereDetail = 64; // higher # speeds up progression of complexity
let ball = Module.sphere(24, sphereDetail);
let box = Module.cube([500, 500, 100], true);
let deg2rad = Math.PI / 180;
let z = 50;
let rad = 250;
let last = Date.now();
let batch = 0;
for (let i=0; i<360*iter; i++) {
    let x = Math.cos(deg2rad * i) * rad;
    let y = Math.sin(deg2rad * i) * rad;
    let ball2 = ball.translate(x, y, z);
    let box2 = box.subtract(ball2);
    ball2.delete();
    box.delete();
    box = box2;
    if (batch++ > maxBatch) {
        batch = 0;
        let nv = box.numVert();
        let now = Date.now();
        console.log(
            (i / (iter * 360)).toFixed(2), // % complete
            nv, // num vertices in target block
            now - last, // elapsed time for maxBatch boolean ops
            ((now - last) / maxBatch).toFixed(4) // time per boolean op
        );
        last = now;
    }
    rad -= 0.04;
    z -= 0.08;
}
console.log(box.getMesh());
ball.delete();
box.delete();
console.timeEnd('ball test');