CPU cycle tools

bootsy · 4 Mar 2008

Andrew J wrote: Like others, I've been having fun cutting my teeth on some ASM optimisations. I noticed with Sambean's CPU profiler that you could get highly variable results if you keep clicking on the input to get it to recalculate. This could obviously lead to some mistaken assumptions about how much something has been optimised.

I've observed similar and that tool was a little suspicious to me. I will test your tool and report back in the next days.

aliasant · 4 Mar 2008

Once again you have made exactly what I needed.

=)

Thanx Andrew. Will test it soon.

peterv · 4 Mar 2008

Andrew,

Thanks very much! This is a tool that will be used many times...

sunsynth · 4 Mar 2008

Great tools, will check them out soon

Thanks Andrew

SUNsynth

sambean · 4 Mar 2008

Nice improvement, just added to the toolkit! 🙂

Thanks for sharing!

Sam

infuzion · 5 Mar 2008

Moved page to here, to shorten URL, sorry for inconvenience [old link]

edit: new update I added on/off switches, a bit of optimization inside the CPU Cycle Tools, & did some Kung-fu on the Peaking EQ, bringing CPU down to about 69% of the "fast" version, almost 90% of the SM Code version! Interesting how the different CPUs had different impact to my optimizations: AMD64 C2D 3000+ E2140 slo 439 358 fas 69.4 124 f00 60.6 121.9 f03 58.6 120.5 ASM 48.1 untested

edit2: I forgot to thank Andrew for the great tools 🙂

edit3: Warning: I did get 3 crashes while editing, sent reports. Also, the "fast" & my optimizations don't seem to output any real values when connected to an OSC, though the Peaking EQ from SM does...

Andrew J · 5 Mar 2008

Thanks infuzion, good idea to do the outputs only at label refresh - I must have been lazy to miss that one!

With your compressed EQ, you seem to not be storing the value of x1 any more. I agree there's no need to save y0, but x1 is a must isn't it?

-Andrew

infuzion · 5 Mar 2008

Andrew J wrote: With your compressed EQ, you seem to not be storing the value of x1 any more. I agree there's no need to save y0, but x1 is a must isn't it?

Yes, & more I think, thanks. I'm testing a newer version with test tones, updates later.

infuzion · 7 Mar 2008

Thanks to AJ's pointing out my bug, I updated my module, which is still the fastest 🙂 Also a few more additions & fixes.

Consider my new testing: 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 ? First thing you'll notice, is that the AJ was able to drop the CPU usage significantly from SM's version, while my ASM version only saved a few extra cycles. Normally, I wouldn't spend the extra hour saving a few tiny cycles by re-arranging some of the movaps, but considering that the SM graphic EQ has 4 of these running at once, and a VST could have multiple EQs, the savings will add up.

Second thing you'll notice is that my Core2Duo reads higher cycles in the optimized versions than my single-core Athlon64. This made me believe the Signal Analyser doesn’t consider if you have multiple cores! If you divide the C2D readings by 2, it makes more sense; C2D the will have fewer cycles always! Also the % of savings from movaps optimizations is still smaller than the AMD64 since all C2Ds can process more movaps ops at once per cycle.

So ensure accuracy, I added a drop-select to change number of cores in the GUI. I hope someday there will be a primitiveto do it automatically.

Andrew J · 7 Mar 2008

Thanks infuzion. I wonder if the number of cores also depends on whether hyperthreading is enabled?

Note that the SM EQ has a fast and slow params mode. I think the fast params mode is meant to be more responsive to automation changes, but does the coeff calculation every sample which is very CPU hungry. The slow params mode uses green data for the coeffs (like our optimisations) but missed some obvious tricks.

I guess the last remaining optimisation could be to rely on denorms elsewhere in the signal path and remove the denorm code - but that's perhaps a matter for individuals to address?

-Andrew

infuzion · 7 Mar 2008

Andrew J wrote: Thanks infuzion. I wonder if the number of cores also depends on whether hyperthreading is enabled?

Note that the SM EQ has a fast and slow params mode....

I guess the last remaining optimisation could be to rely on denorms elsewhere in the signal path and remove the denorm code - but that's perhaps a matter for individuals to address?

Welcome 🙂 The devs would have more insight @ cores/hyperthreading.

The denorm is a single simple add, so only few extra cycles (perhaps 1 more if 1e-010 is loaded into memory at every sample) is spent. Let them hack it out if they wish.

I would say the next phase would be to optimize the "slow" version for fast automation like you said. Just simple algebra-reduction of the SM Code would save a dozen+ cycles. Perhaps 2 versions for the slow is in order: accurate (using x86 sin1/cos1, regular div) & approximate (SSE ~sin/cos, reciprocal (rcpps) instead of 1/x).

aliasant · 7 Mar 2008

infuzion wrote: Thanks to AJ's pointing out my bug, I updated my module, which is still the fastest 🙂 Also a few more additions & fixes.

Consider my new testing: 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 ? First thing you'll notice, is that the AJ was able to drop the CPU usage significantly from SM's version, while my ASM version only saved a few extra cycles. Normally, I wouldn't spend the extra hour saving a few tiny cycles by re-arranging some of the movaps, but considering that the SM graphic EQ has 4 of these running at once, and a VST could have multiple EQs, the savings will add up.

Second thing you'll notice is that my Core2Duo reads higher cycles in the optimized versions than my single-core Athlon64. This made me believe the Signal Analyser doesn’t consider if you have multiple cores! If you divide the C2D readings by 2, it makes more sense; C2D the will have fewer cycles always! Also the % of savings from movaps optimizations is still smaller than the AMD64 since all C2Ds can process more movaps ops at once per cycle.

So ensure accuracy, I added a drop-select to change number of cores in the GUI. I hope someday there will be a primitiveto do it automatically.

Hmm.

Anyone knows how this would be on my MacPro?

Its 2 dual Xeon so its 4 cores. But are there other differences to C2Ds?

infuzion · 7 Mar 2008

aliasant wrote: infuzion wrote: ...I updated,...a few more additions & fixes.

Consider my new testing: 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 ? ...my Core2Duo reads higher cycles in the optimized versions than my single-core Athlon64. This made me believe the Signal Analyser doesn’t consider if you have multiple cores!

...how this would be on my MacPro? Its 2 dual Xeon so its 4 cores. But are there other differences to C2Ds?

Each generation of Intel CPUs have been more & more optimized in different ways. Here are the levels to worry about when ASM optimizing: P3 P4 P4 HyperThreading PM (PentiumM, Core Solo, Core Duo, Atom) C2D * Celerons & I think Xeons are ranked according to their "base" design. Sorry, looks like you have to research for yourself 🙁

edit: Forgot to mention that seems AMD hasn't changed the fundamentals on how the opcodes work in their CPUs since the Athlon64 days, so the newest 3-4 core AMD CPUs will likely run in the same amount of cycles as my old laptop. == Can someone else with 2 computers: 1 with a Intel Core Duo/C2D & wother with a single CPU verify with some cycle stats please, testing the dual core with "1" CPU Core selected? TIA -- Be careful with crashes if you edit this OSM; I had about 8 sudden crashes while working on various versions of the OSM, mostly after a paste.

infuzion · 9 Mar 2008

infuzion wrote: Can someone else with 2 computers: 1 with a Intel Core Duo/C2D & with other with a single CPU verify with some cycle stats please, testing the dual core with "1" CPU Core selected?

urrr... anyone please? thanks

Andrew J · 27 Mar 2008

New improved version now available - see the wiki.

- Integrated some of infuzion’s changes into my original version (except adjustment for multiple cores) - Adjusted sampling technique for more accurate reporting - Added Scale button to automatically scale y-axis according to current measurement

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.

CPU Cycle Tools v1.5 **Edit: now v1.5**

Regards, Andrew

infuzion · 27 Mar 2008

Thanks for the update! The Comparator does have issues; comparing 2 versions of an ASM had "A" faster by ~2, & when I swapped A & B, A was still faster!?! When I used the Analyser, one was solidly faster by 2.

Also, when I hit [Scale] the range went to +/-10, but the actual line was about -8..-12.

infuzion · 27 Mar 2008

(from other thread)

Andrew J wrote: infuzion wrote: Dang, now mine is slower! Back to the drawing board 😉

I spent hours and hours trying to see if I could match yours. Eventually I came up with something that actually seemed a little better - but I couldn't really tell until today with the new analyser. 🙂

Ah your ASM-fu is indeed better, what changes did you do?

Andrew J · 27 Mar 2008

infuzion wrote: Also, when I hit [Scale] the range went to +/-10, but the actual line was about -8..-12.

Oops - the comparator graph was completely wrong! I've also improved the logic so the scaling works if the number is negative (thanks for the pickup infz). We're now up to v1.3. **Edit: old download link removed**

-Andrew

Andrew J · 27 Mar 2008

infuzion wrote: Ah your ASM-fu is indeed better, what changes did you do?

It's a few days ago now, so it's a bit of a blur, but I think I used more xmm registers so I could ditch some floats and shuffle to avoid some movs. Then shuffled some more to decrease execution dependencies. Did I do well master? 😉

infuzion · 27 Mar 2008

Andrew J wrote: infuzion wrote: Ah your ASM-fu is indeed better, what changes did you do?

It's a few days ago now, so it's a bit of a blur, but I think I used more xmm registers so I could ditch some floats and shuffle to avoid some movs. Then shuffled some more to decrease execution dependencies. Did I do well master? 😉

hmmm, well I clocked it when I opened the OSM, & yours was faster (using the Analyser; the comparator 1.3 is too inaccurate for me). Then I by passed the Selector, directly connecting only the modules to the Analyser, & found mine is faster. Moved back the links to the Selector, & found the Selector added about 18 cycles... could you check that for me please?

I checked it in my C2D, using the Selector, & found both were the same speed. C2Ds are great at optimizing code, & sometimes hand-interleaving makes things worse, so you did better than I would there.

Bugs: Calibrate with no input you'll still get 5-12 cycles; I'd assume it would be 0.

Calibrating when it is off starts it. I put in logic in my hacked (perhaps I didn't post that version) that allowed no inputs, including GUI, to start anything. I also had it auto-calibrate when turned on, so you know it is always (more) accurate.

comparator v1.3 is not good at all if the 2 modules are with in 3-4 cycles of each other. the old one (the one I hacked) was accurate within 1-2 cycles.

The Analyser was left on in your file, causing the CPU to run expectantly, adding .0000000000000000000000000000000000000000000000000000000000000000000001 more global warming 😉

Andrew J · 28 Mar 2008

OK - to get rid of the inconsistencies, I'm going to start over. Rather than choke up the forum with this, I might just send the next draft to infuzion for a check over before I post here (if that's OK with you infuzion?).

-Andrew

Andrew J · 28 Mar 2008

Changed my mind (why keep everyone waiting until infuzion wakes up?). I've made some significant changes and I think it's much better now - so here are the CPU Cycle Tools v1.4. Check 'em out in the wiki.

-Andrew

Acrobat · 28 Mar 2008

thx very much andrewJ, your work is much appreciated here.. 😀

infuzion · 31 Mar 2008

Andrew J wrote: Changed my mind (why keep everyone waiting until infuzion wakes up?). I've made some significant changes and I think it's much better now - so here are the CPU Cycle Tools v1.4. Check 'em out in the wiki.

Thanks for the updates! I wanted to test on both systems before commenting.

The tools are much more accurate & easier to use. I tend to leave the Analyser on autorun because the output will bounce around when I'm doing hacking (sometimes the cycles will constantly vary by a cycle or 2). I liked the 2 A/B scopes, since one code may have a more varied output. A few other comments & ideas:

+ I had to add 1 decimal point for each one; sometimes moving a ops around will change the average by even a 0.1. I undo, checked, redo, & still the same .1 difference. I got up to 5 cycles improvement by 1 cycle here, .5 cycle there, .2 here there there... - Comparator is much better, but for fine-tuning (see above) I relied on the Analyser & undo/redo. - Hard to see if Autorun is on if I have glare/sunlight. Switches are better for old eyes 🙂

Ideas for hacking (I might do later if you don't): - I prefer to have the buttons & readouts to the left of the graphs, since I don't have much screen space. - All-in-one tool with both Comparator & Analyser merged into 1 module, & both A & B merged into 2 scope with 2 different colors for each.

Andrew J · 13 Apr 2008

OK all, I integrated infuzion's suggestions and made some other improvements. Now that we've gone through a couple of weeks of review, I'm ready to share the latest (and hopefully final) version of this with you all. Enjoy 🙂

Latest version: CPU Cycle Tools v1.5 & Wiki entry

Regards, Andrew J

infuzion · 17 Apr 2008

Thanks again AJ!

Usage tips: If the 2 codes are very very close, it is best to switch around the A & B to get a better picture.

Take out Code/ASM hop(), or reduce them down to 2.

To me, a well-optimized ASM will normally have a smoother readout (without hop()). You can see the difference in the picture above.

In my experience, this new version may show 1-2 big jumps in CPU; don't worry about them too much since there will always may be some, & said jumps were in previous versions, except they're easier to see in this version since 1.5 has a bigger window. If you see the spikes, manually switch A & B, re-test, & if they're still there just look at the average.

TomC · 9 Dec 2008

G'day,

I've slightly modified the tool so that it computes the average CPU cycles (ignoring those nasty spikes which happen too often).

At least for my kind of usage the results are much more accurate now.

You'll find it in the Wiki under "Update 5". Some usage documentation is included.

Enjoy,

Tom

Andrew J · 9 Dec 2008

TomC - how often do you get nasty spikes? If you run DPC Latency Checker, do the spikes correlate betwen dpclat and what you see in SM?

infuzion · 10 Dec 2008

AJ: I get those spikes very frequently, more frequently with hop(), & more frequently with SM's Code output, but less frequently with hand-reduced ASM.

TomC: The Reset button has to be pressed twice, & the Tests per Sec seems reversed & has an odd ratio: left-most goes from 100 to 74 to 39 to 16 to 9,8,7,6, & 1 has a huge range. Sometimes I use v1.5 with a larger Sampling window (1000 msec) to smooth out the peaks, & yours seems to do a better job sometimes. Side A doesn't want to calibrate sometimes, but v1.5 has the same issue also. v1.5 seems to be more accurate with smaller cycles (like connecting a single Stream Mult).

Andrew J · 10 Dec 2008

My earlier versions used averaging, but I found it was more trouble than it was worth. That's why I ended up with the design I did in v1.5. I usually just sample again if there's a spike, or just run it continuously. Besides, it's interesting to see the spikes, it can let you know there's something else going on that you might have to pay some attention to (hops are a good example).

Infz: thanks for the observations, I'm inferring that many of the spikes are due to what's in your schematic rather than things external to SM. Would you agree?

infuzion · 7 Aug 2010

v1.7 for the CPU Cycle Analyzer available here. Changes: Fixed on/off switch to actually work when you start up the OSM. Some primitive reduction to reduce file size.

A mini-version which is a separate fork of 1.5 with only 1 imput is here.