Exactly. In my actual real useage scenarios ( processing audio streams ) most of the time there will be more work going on inside the loops. Mostly this will involve just summing floats at the same "input buffer" "sample frame" location in several memoryblocks, having multiplied each float by a coefficient and then stuffing the result into one or more output "buffers". Basically its "mixing".
But like you I wasn't expecting mere looping to be so much slower ( 2X maybe - not 8-9X ) . I use a G4 Powerbook so I don't know if things are better on the Intel side. On 16/5/07 16:06, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > But, on another note, after my last message I saw your message where > you commented out the guts of the inner loop, and it was *still* 10X > slower than C. This surprises me, because in that case they really > should compile down to pretty much the same thing. This may be worth > digging into more deeply, but leave the method calls out of it until we > understand what's going on with the loop itself. Regards, Dan _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
