"Optimized in the source code, in a HLL is not the same thing as the claimed requirement to hand optimize the assembly. Surely you Can agree to that?" I'll grant you that it doesn't mean you have to optimize with assembler. But a compiler won't change source code. So any optimization in that source code has had to be done by a software engineer and therefore counts as hand optimized to me. Indeed AthlonXP doesn't yet support SSE2. (Next generation CPU will) But although the performance pack is called a P4 pack, the explanation about it only talks about SSE and talks about improving the P4 AND P3. If the modifications to the source code had been for SSE2 and would just have benefitted the P4, I'm convinced they would have mentioned SSE2 instead of just SSE. About the bottlenecks for Poser4. As you have also seen, the memory doesn't make much difference in this benchmark. You just have to have 256MB to make sure performance isn't degraded because of swapping. But if you have 1GB or 256MB doesn't matter at all in this test. When I render I see that during creation of the shadowmaps the CPU is at 100%. Shadowmaps aren't big here so that is just 6s of my 35s rendertime. After that my CPU usage is about 70% and I hear the harddisk. I assumed Poser writes the rendered image to a temporary file. I thought that may be the bottleneck. But I have done the test with performance monitor running and I don't see any bottlenecks at all. Pages/sec is low: 1.6 , so is avg disk write queue: 0.397 max Disk write Bytes/sec doesn't exceed 400Kb/s. So it's not the disk that is holding things back. It's not the CPU nor the amount of memory. What's left? I think there are more things like the dancing man holding things back. I didn't have him disabled this time, and I couldn't see that in the performance counters. There are probably more things like that, that slow it down without us being able to point to a specific bottleneck.