From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
Explanation & workaround here Not sure if the Float Array Clock Cycles output is doubled, or summed internally. cheers
edit: The new Cycle Tools is giving better readouts on different CPUs, & the Signal Analyser give a good approximation, but isn't 100% accurate. Good for now, bug report kept open in hopes a new, better solution will show up in the (distant) future.
infuzion ·
Seems SM's CPU gauge has the same issue.
malc ·
The signal analyser runs in a single thread on one core so it will only give you clock cycles for that core.
infuzion ·
Sorry malc, but I'm still not sure the readouts are correct. After about 20 hours studying how each CPU processes SSE opcodes (Like from ASM guru Agner Fog) I have to say with confidence that C2D are more per-cycle efficient then a ~5 year old Athlon64. C2D are simply faster per opcode, use a bigger buffer to help optimize opcode-reordering to combine more opcodes per cycle, etc. Consider the code found via my link above, & the results it gives: AMD64 C2D 3000+ E2140 /2? slo 470 398 199 SM 102 148 74 AJ 69.7 124 62 ASM 62.1 120 60 AJ - ASM Comarator: 5.7 ~2 ? I could be wrong, but please, explain to me how a Code segment (labeled "SM") would take 102 cycles on an AMD64 but almost 50% more on a C2D?!? If you divide the results by 2, then the chart make much more sense. "SM" Code segment is then 26% faster on the C2D since Code tends to produce more movaps, which C2D are better at than AMD64, so I'd expect that. When I optimize it in ASM the AMD64 vs C2D spread drops down to 3-4%, not too surprising since Andrew J & I had removed all redundant movaps and tightened up the opcode execution sequences by hand, rather than relying on the CPU to do it (which C2D are also better at).
So either my testing system was wrong, or SM is wrong. I would say SM needs to divide the cycles/CPU% output by the number of cores. Anyone else have thoughts on this?
aliasant ·
Sounds to me like Infuzion is on to something.
Another thing that would be nice to have on the SM CPU Gauge is a couple of decimals more.
Instead of
CPU=1.3%
Why not
CPU= 1.398%
That would make it much easier to spot smaller differences. Or ?
Andrew J ·
Martin, the way it jumps around all over the place, I think any extra precision could be misleading.
BTW, this thread has got me investigating a bit more about the signal analysis module and how to improve accuracy of the CPU cycle tools. Will post in that thread when I've got something...
aliasant ·
Andrew J wrote: Martin, the way it jumps around all over the place, I think any extra precision could be misleading.
BTW, this thread has got me investigating a bit more about the signal analysis module and how to improve accuracy of the CPU cycle tools. Will post in that thread when I've got something...
Of course your right. More decimals wouldnt work. And using average would also be very miss leading cause of the spikes... =(
Im trying to optimize one of Zynewaves new DeZippers/smoothers [old link] and since the actual difference in such a fast code is very small it is hard to see it. The only way to measure this might be to chain >30 of the DeZippers and same with the new code. Then the difference would be measurable I think. Anyone tried the green wasabi covered peanuts? Damn they tasty =)
infuzion ·
aliasant wrote: Im trying to optimize one of Zynewaves new DeZippers/smoothers and since the actual difference in such a fast code is very small it is hard to see it.
Off-Topic, but re reason why you can't speed up the code is because of the hop() (thanks dev team for adding hop in Code!). I pulled all my ASM ninja tricks on that very same de-zipper, & only got a fraction of a fraction difference. Even dropping the hop to 128 (incase the knob only moves a small fraction often) you could not see any improvement that was worth while. If you drop the hop to 2 you would, but then the hop is worthless. Then only time I saw any improvement ASMing a large hop was in the Multi Stage Envelope, & that included combining separate Codes.
= back on topic 🙂 = It would be great if people with both single & multi core computers could test modules/Codes with the Cycle Tools please. If you use my version DO NOT change the # of cores count, since my hack is the workaround for what I'm trying to prove. cheers!
infuzion ·
aliasant wrote: Im trying to optimize one of Zynewaves new DeZippers/smoothers and since the actual difference in such a fast code is very small it is hard to see it.
Off-Topic, but re reason why you can't speed up the code is because of the hop() (thanks dev team for adding hop in Code!). I pulled all my ASM ninja tricks on that very same de-zipper, & only got a fraction of a fraction difference. Even dropping the hop to 128 (incase the knob only moves a small fraction often) you could not see any improvement that was worth while. If you drop the hop to 2 you would, but then the hop is worthless. Then only time I saw any improvement ASMing a large hop was in the Multi Stage Envelope, & that included combining separate Codes.
= back on topic 🙂 = It would be great if people with both single & multi core computers could test modules/Codes with the Cycle Tools please. If you use my version DO NOT change the # of cores count, since my hack is the workaround for what I'm trying to prove. cheers!
Andrew J ·
Maybe hold off on the measurements for a tick, I'll try and post a more stable version of CPU cycle tools in the next couple of hours...
infuzion ·
Andrew J wrote: Maybe hold off on the measurements for a tick, I'll try and post a more stable version of CPU cycle tools in the next couple of hours...
OK, I'll check back in 7+ hours 🙂
aliasant ·
infuzion wrote: Andrew J wrote: Maybe hold off on the measurements for a tick, I'll try and post a more stable version of CPU cycle tools in the next couple of hours...
OK, I'll check back in 7+ hours 🙂
Gonna check back as soon as I can. Just gotta get some sleepy sleep first.
malc ·
Ok, after digging deeper I can see what the problem is (sorry I didn't do that sooner). We were using rdtsc which is apparently very unreliable for multi-core systems.
There are other options so I'll look into those.
Andrew J ·
OK, new version of the CPU Cycle Tools now available:
Forum post / Wiki page
Minimise your reading by taking it when the graph is flat (switch off to freeze it at a steady reading). Also, note that the comparator struggles when the two modules have similar cycle counts.
My results for the three peaking EQs...
Athlon X2 4400+
SM 102 AJ 57 Infz 59
Regards, Andrew
infuzion ·
Andrew J wrote: Also, note that the comparator struggles when the two modules have similar cycle counts.
Andrew J infuzion Athlon X2 4400+ Athlon64 3000+ SM 102 99 AJ 57 62 Infz 59 65
I've noticed the old cycle comparator wasn't good if both were within 1 or 2 cycles of each other.
Dang, now mine is slower! Back to the drawing board 😉
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker