AA 3 executes edits more slowly on dual core then single core systems

Issue for which soliciting ideas, speculation is that in past week ran some (non rigorous) tests that suggest that AA 3, in edit mode, runs not only more slowly but significantly more slowly on some dual core systems then older slower single core ones.

Initial results were derived not from a speed test of from using AA 1.5 on an eight year old 1.6 gHz single core P M to split out tracks and create a CD master from a live 45+ min set (which I've been doing for several years) and using AA 3 on a two year old 3 gHz dual core to try to create CD master without having to divide set into individual tracks first .. . And see if this could save time.  AA 3 on the dual core took 85 min to execute a similar set of instructions where older machines running AA1.5 finish, consistently complete in 40-45 min.

Found results disturbing enough (in live setting AA3 becomes useless for me with that time frame) that duplicated the tests in the studio using four single core and two double core machines.  All the older single core used PATA dives, dual core used SATA.  Field single core laptops were limited to 1 gig of RAM, desktops (two single, one dual) and dual core laptop all have 2 gig of RAM, none of the RAM is stock 'value' RAM.  Side stepping the 1.5 vs. 3 issue I found was that AA 3 was consistently and significantly slower in executing batched clusters of edits on the dual core machines.  There were some process, notably (and as one might expect) noise reduction and full reverb, for which AA3 was significantly faster on dual core machines. Whether using individual files or a single large, whether executed individually or on a batch, whether executed individually or via a script AA 3 completed the sequence almost twice as rapidly on all single core 1.6 gHz machines then on either 3 gHz dual core (Intel chips on everything)

Using Rightmark I did not show any anomalous behavior on either dual core machine.  On CPU 0 right mark showed a fairly wide discrepancy between CPU load and OS load, both dual core machines but with AA running loads basically (with fluctuations) hit 100% on everything and stayed there until sequence was completed.

Over the past year I've noticed that AA 3 runs more slowly the longer it runs, the more it does, longer between reboots.  This impression was carried over to AA 3 getting (slightly) more slow on dual core then single core systems.

Primarily in trying to reason some explanation, trying to ferret an overlooked hardware variable, repeated tests, repeated variations far more times then makes sense.  Results were not absolutely the same, but when you examined averages and deviation from means the results were consistent. Except for a handful of very CPU intensive processes, overall, AA3 executed edits far more slowly (consisted with 1.5 vs. 3 times from the field test) with my dual core machines then on slower older single core machines.  The 'save' instruction showed the greatest discrepancy.

The gear was the usual Wintel hodgepodge different chips, different RAM, Hds, cache sizes, background processes, certainly not every variable was isolated . . . But on the surface the only thing I can think of is that AA3 was coded for coarse multithreading and I simply don't own  (or have any easy way of learning) a correct machine.

At this point just looking for any idea or speculation, more or less hoping I've overlooked something extremely obvious to everyone else.

thanks

Hmm... dunno without trying it. The one thing I do know though is that the code is optimised to run on Intel processors, and not AMDs. And since this all relates to the way SSE instructions are handled, it can make a very big difference to the resultant performance.

The other thing that's become apparent recently from some other, but entirely unrelated research is a 'perspective' thing, and in Audition's case it relates to FFT performance. Adobe have always said that the FFT performance improves quite dramatically with more cores in use, but it appears that this isn't quite the case. If you look at the timings for typical FFT algorithms, what you discover is that they perform pretty much according to the way they are predicted to if you use a quad-core machine, but get significantly less efficient than they should be on machines with less cores. This appears not to be an Adobe issue either... go figure!

But as to the overall performance - well, it might be interesting to set up some benchmarks and have people run them, I suppose. That would involve a degree of agreement about what they should be, though. Any suggestions?

For those curious   . . .

was not specifically an AA issue

it was hardware, OS issue of at least nodding serpentine complexity.  It pivoted on registry entry for 'Master Device Timing Mode Allowed'  (an entry that may or my not supposed to be created in XP sp2 . . . but then I was using sp3 (only machine on which that was installed)  and issues with how parallel ATA interacts with systems where system drive is Serial ATA.

2nd variable was OS reaction to CRC errors.   While a common cause for an IDE channel to revert to PIO mode is for an optical drive trying to read scratched or damaged media this was not a factor for me.  There is apparently, from XP sp3 (and on into Vista) some connection between DRM and CRC, or if not CRC directly then in registry rewrites that I've associated in the past with CRC errors.  In any case a mere half dozen CRC errors can permanently force an OS controlled shift from DMA to PIO.  This is OS only not drive firmware or BIOS but correcting it is a royal pain in the ass

Part of my specific issue was that I was working with a 2 spindle laptop, which had an optical drive installed but which I primarily used for a 2nd HDD.  I had difficulty with getting optical drive to work with my elderly software (in fact had difficulty getting it work with bundled software) and it is possible that my forced 'fixes' for these issues effected the registry rewrites for Device Timing Mode Allowed.

The optical drive functioned DMA, the HDD worked DMA in external enclosure on problem system, worked DMA in different carrier on different system .  . . but only worked PIO as internal HDD on problem system.  What is more irritating that is even with forced reinstall of drivers, manually resetting problem registry entries that 'Device Timing Mode Allowed' resets itself on the fly  (and this is the part that somehow seems to be connected with AA)

One of my tech guru's informed me that this type of problem does not show up with SATA systems . . . Since I had thought dual core laptop was SATA I had not pursued DMA issues particularly rigorously.  But apparently the 2nd spindle (even with SATA HD in the bay) functions as primary IDE (PATA) channel).  still not entirely clear on this . . . but if true it supports current diagnosis.

In any case my symptoms appear to be fairly species specific . . . perfect storm of things that have made MS systems useful to challenge performance in this instance.  Widow and orphan lingering code causing problems with legacy hardware, poorly implemented firmware by manufacturer (still think coarse vs. fine threading combined with poor southbridge DMA implementation is contributing factor) combined with efforts by MS to use existing code for  purposes for which it was not originally designed (in this case, error check sum for DRM) having unintended consequences. 

I never purchased the problem laptop for audio work.  It was intended to be a walk around spread sheet word processing internet machine but was surprised by poor performance when pressed into audio work . . . sorting out all the variables (fact that most CPU intensive processes always performed 'faster' on faster system . always pointed towards DMA issues but not necessarily drive issues . . . fact that I could get better performance in external enclosure seemed to remove AA as a culprit (except that it was with AA 3 that I saw the broadest discrepancies in performance) So I have a work around to force better performance, performance in line with what I would expect from hardware, but fact that, in AA 3, some combination of variables will reset 'Device Timing Mode Allowed' to PIO only (over write manual DWORD = 0xFFFFFFFF) so some scripted processes jump from 3 to 20 sec. means that this specific system won't be able to be used for generating impulse purchase night of show CD's

FWIW and from an entirely differen perspective my observation is this:-

I replaced a Q6600 (quad) with a faster E8500 (dual) thinking its gotta be better for AA as AA doesn't really fully utilise the quad.
Within the week I got rid of the E8500 and put the Q6600 back in.

While not carrying out specific timings it was obvious that the (faster) dual (with everything else equal) was noticeably slower on all counts.