You said:
“This causes the spring system to have a net force imbalance in a particular direction (depending on the order of update). The solution here was very simple. I just split the loop up into two separate loops: one to gather the forces, and then one to apply them in the integration step. This ensured that all forces were symmetrical.”

I generally solved this kind of pertubation by inverting the processing order on each update loop (eg: frame n update points to 0 to max, frame n+1 update points max to 0). It is as cache-friendly but allow to avoid iterating the points more than one time for this kind of operation, and generally tends to stabilize the system.

The bubbles in Soul Bubbles are 32 verlet-integrated points to which are applied:
- A single layer of spring constraints ( point N to point N+1%32 ).
- Angle constraints to try to maintain an overall round shape. Applied by moving point N to tend to satisfy an ideal angle between N-1,N,N+1. I don’t recall the details but this proven to be different from applying strings between points N-1 and N+1.
- A slight scaling up of all points from their average center to cope with external pressure when the surface became too small.
- In cases where bubbles gets into thin/sharp objects collisions responses are biased to push points back toward blob center, and friction increased for those points to reduce penetration.

Add in some thresholds to optimize idle cases and various common-sense low level optimization. In the end other components (such as managing the membranes between 2 collides bubbles) were more heavy.

En la web de Mick West hay un interesante tutorial sobre cómo programar blobs (o "goterones viscosos", a falta de un mejor sinónimo) como los que aparecen en juegos como Roco Loco….

Yes, I suppose if I really wanted to I could also sacrifice a huge amount of readability to hyperoptimize the managed version. Experience tells me that there are better ways to spend my time though. The 90/10 rule applies even here :)

Better ways to spend 90% of your time, that’s for sure. But I just made my application 8% faster with 15 minutes work (it went from 134 to 123 fps, in non-simd, just with that one change!). Remember what Knuth said about similar optimization:

The conventional wisdom shared by many of today’s software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by penny-wise-and-pound-foolish programmers, who can’t debug or maintain their ‘optimized’ programs

Your point on “good” SIMD is well taken. I’m from console-land, and if you are doing anything intensive with vectors like this, then you want to be using SIMD (or preferably the vector units).

It’s a period of transition. Managed code is great, but there’s still an appropriate division between game code and engine code. It’s not a hard and fast division, and depends on the game (and several other factors), but it’s still there. As managed code gets better at targeting hardware, then it will get used more.

And here’s the comparison.

http://cowboyprogramming.com/code/ComparisonOfManagedOptimizations2.html

And really I should be using the MD part of SIMD, which should be able to halve it again.

So my original example was somewhat misleading. However, when you look at actual engine code, it WILL be optimized to take advantage of the processor architecture, and I suspect based on that then the speed comparisons will be similar to what I was getting.

Yes, I suppose if I really wanted to I could also sacrifice a huge amount of readability to hyperoptimize the managed version. Experience tells me that there are better ways to spend my time though. The 90/10 rule applies even here :)

What I do note is the lack of ‘good’ SIMD in most applications. For instance, the lack of usage of parallelizing of operations. Instead of performing 1 dot product at a time using SIMD, do 4…as in below (note that I do not claim that you should use the code below, just that its typically a better parallelization than single operations)

; Given that XMM0 - XMM7 contain R4 vectors V0 - V7, such that we wish to
; calculate the inner product of and return the results of
; all four inner products in a result vector.
mulps xmm0, xmm1
mulps xmm2, xmm3
haddps xmm0, xmm2

haddps xmm0, xmm4
movaps result, xmm0



Vector2 CSemiRigidConstraint::GetForce(CVerletPoint* p_verlet)
{ float v_x = p_verlet->GetPos().x;
float v_y = p_verlet->GetPos().y;
float o_x = mp_other_verlet->GetPos().x;
float o_y = mp_other_verlet->GetPos().y;
float t_x = (v_x - o_x);
float t_y = (v_y - o_y);
float t_len = sqrtf(t_x*t_x + t_y*t_y);
if (t_len <0.000001) // should be f, but leave it for comparison
{
t_x = 1.0f;
t_y = 0.0f;
t_len = 1.0f;
}
float mid = m_mid;
float m_x = o_x + t_x/t_len*mid;
float m_y = o_y + t_y/t_len*mid;
float tm_x = m_x - v_x;
float tm_y = m_y - v_y;
float force = m_force;
return Vector2(tm_x*force,tm_y*force);
}


And here's the comparison.

http://cowboyprogramming.com/code/ComparisonOfManagedOptimizations2.html

And really I should be using the MD part of SIMD, which should be able to halve it again.

So my original example was somewhat misleading. However, when you look at actual engine code, it WILL be optimized to take advantage of the processor architecture, and I suspect based on that then the speed comparisons will be similar to what I was getting.

And now I’ve seen your whole code (nice comparison BTW), it’s still 10% longer than the non-SIMD version, plus it calls functions for Magnitude, adding and subtracting. Whereas the C++ version just calls sqrtf, ect. I don’t know what’s in those functions, but I highly suspect at least another ten lines of asm per function, possibly more.

Indeed, there are ways to get around that too, ways that will generate better/faster code, ways that a professional application would use…such as ngen. Using that pre-JIT the program on the target machine during installation will allow it more time to optimize. How much better it will be, I can’t be sure.

But how fast does it run?

Faster, I don’t have the entire sample done, and probably am not going to complete it either (I have other commitments) but profiling suggests that it is about 5-10% slower than yours (without SIMD).

Which isn’t bad, it is not great, but overall that’s a significant performance boost of compiling with just /clr. Still won’t be able to write a HL2 killer in it, at least not yet. What is interesting are the future JIT compilers that are being invested in by Microsoft. JIT compilers that can optimize based on the machine configuration, something that current statically built applications cannot do. As an example, if you want to use SIMD, you typically have to build in several code-paths. Ones that can use SIMD, and ones that can’t. You then decide (at runtime) which path to take depending on the available features. The disadvantage here is a single level of indirection, and a whole hell of a lot of code on the developer’s part. A well written inner product can easily outperform the SSE generated by VSTS (Visual Studio Team System). Compilers just aren’t good at vectorization, even ones like the Intel compiler (which produces bugs when used, as translation of code to a vectorized format inherently changes the behavior of the application in unpredictable ways.

A more advanced JIT will be able to target the processor that the machine is running on, including hardware extensions, when the application is launched. This presents an opportunity for extreme runtime optimizations based on extended instruction sets. The JIT will still be constrained to a shorter running time than a static compiler, but using tricks like NGEN, you will be able to really optimize it to a great extent.

ValueType’s in .Net are a copy based mechanism, much like they are in other languages. Anything marked with the struct type in C# is considered to be a value type. Making it a class will not solve the problem though (actually, it makes it worse, but I’ll detail why in a bit). Since value-types are primarily a copy mechanism (the old immutable idea) then you’ve got to account for that in your code. Things like taking a reference to the value type (pass by-ref or as an out parameter) enable the CLR to realize how you are attempting to use these various objects, enabling it to eliminate redundant copies and the like. The JIT has very little time to run in, and so its not going to make the best decisions always (it does make a lot of smart ones though).

Classes don’t solve the problem because they hare heap only. You cannot allocate a non-heap based class, as such the allocation of a class type will lead to a GC eventually. Now, Gen0 collections are INSANELY fast, but if you’re pumping out a lot of short lived temporaries, what will happen is that some objects will live a bit longer, and get pushed into the Gen1 collection. Then when the Gen1 collection gets full, it will also be collected, and those short lived temps will be released, but any that live just a bit longer could end up being pushed up into gen2. Gen2 takes a long time to free up, especially with the LOH being up there in the Gen2 as well. So obviously short lived temporaries can cost you…if you’re not careful.

But, its not all horror stories, a gen0 collection is INSANELY fast, as I mentioned above, a wee bit of profiling on my part found it to be faster than a C++ allocation on a moderately fragmented heap. Since most C++ allocators use a heap walk to find a free chunk of memory to allocation (this is unspecified in the standard, as such not all implementations have to behave this way), that traversal can become quite expensive. With managed languages however, an allocation is a constant time operation. The GC will typically do a sweep and compact when a gen2 or gen1 collection happens, but in general, gen0 collections rarely have such actions. Plus, the GC typically doesn’t have to freeze your application[1].

You have to watch out for finalizers though, since destruction is not a deterministic action, finalizers can cause short lived elements to be pushed into the Gen1 heap, when they are really just waiting to be finalized.

[1] Using GC Efficiently – Part 1
Using GC Efficiently – Part 2
Using GC Efficiently – Part 3

[2] Clearing up some confusion over finalization and other areas in GC

But how fast does it run?