On Saturday, February 8, 2003, at 05:56 PM, Darcy James Argue wrote:
On Saturday, February 8, 2003, at 06:55 PM, Matthew Hindson Fastmail Account wrote:
I am interested to guess whether Finale OS X will automatically take advantage of double processors. Indeed, I have made my own requests to Coda that it should do so, as well as make use of the Altivec processor which is on every G4 processor. Perhaps a Mac OS X guru like Phillip Aker could fill us in as to whether this would make any difference within Finale. Certainly Mac Finale needs something to catch up to the speed of the PC version.
Matthew,
The Altivec vector instruction set seems to be most useful in hard number-crunching situations like ripping MP3s, applying certain types of Photoshop filters, or working in mathematics applications like MatLab. My impression -- and I'm sure Philip will correct me if I'm wrong -- is that typical Finale tasks are not good candidates for Altivec acceleration.That's correct because the _current_ Finale doesn't use floating point numbers that much. For instance in many dialogs you will see that you can enter unit values with a decimal point but in actual fact the APIs will translate those values into a storage type which packs those values into 32 bit integer (small EVPU = 1/64 EVPU). There's nothing faster than a 32 bit integer add on the PPC implementation we are all using and floating point calculation for IEEE doubles beats the pants off of an Intel at the same processor speed.
And I've heard conflicting reports about the extent to which multiple processors are automatically enabled by OS X, without requiring applications to be coded specifically for DP. The short answer is that if Finale 2004 is a well-written Carbon app, than it should see some benefit from having the dual processors. Just how much is unclear.The API names for these have the prefix MP (MultipleProcessor) and I know that Finale as of at least 2002 uses some of them. But to what extent I don't know. That's because as of about Mac OS 9.1.x or 9.2 the OS will automatically redirect some Toolbox calls to use MP calls and when you see them in MacsBug, it's kinda hard to tell who is actually generating the call. An example is the Delay() function which is used to make the OK or Cancel button blink when invoked by a keyboard command. Previously, it would completely block any background application processing but now it is mapped to MPDelayUntil() (which lets other processes continue while waiting).
Applications have to specifically implement multiple processor handling though. Finale could benefit from this because of it's use of disk files for temp files and undo chain is similar to Project Builder. PB itself only upgraded to multiple processor handling as of December 2002 Development Tools release.
(Anyone care to place bets whether the 970-based Macs will debut before an OS X version of Finale?)
Ha!
Count your blessings -- at least it's not like Sibelius, where Mac performance is unbelievably atrocious even on the simplest scores.Sibelius appears to write every damn setting it has each time one chooses a menu item or closes a dialog. Totally bizarre.
Philip Aker
http://www.aker.ca
_______________________________________________
Finale mailing list
[EMAIL PROTECTED]
http://mail.shsu.edu/mailman/listinfo/finale
