• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
G4/G5 performance question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

G4/G5 performance question


  • Subject: G4/G5 performance question
  • From: Glenn Zelniker <email@hidden>
  • Date: Fri, 25 Mar 2005 08:12:26 -0500

Coreaudio'ers...

While recently toying around and working on the real-time DSP part of a Mac audio app I'm writing, I was curious to see how much processing I could cram into the time-critical part of the app before I started to drop samples. Needless to say, even on a 1.5 GHz G4 PB, I could do a lot. But this got me thinking..

I'm a long-time DSP hardware designer and I'm used to writing in straight assembly for a processor that, for all intents and purposes, can execute a single assembly instruction per clock cycle. Therefore, when writing real-time audio apps that work in a sample-in/sample-out fashion (e.g., real time equalization), it a fairly meaningful question to ask how many processor cycles (i.e., assembly instructions) can I execute between each interrupt that signals the arrival of a new sample. This pretty much gives you an idea of how much EQ you can do or how long a convolution you can do or how many FFTs per second you can do.

Granted, we're working in a thoroughly different environment under OS X, with far more going on than in a purpose-built piece of DSP hardware, but I was wondering if anyone can cite any simple metrics for the G4/G5 under optimal conditions -- say, if one were to use it in a purpose-built piece of hardware and code for it in assembler. What is its actual execution speed (per GHz of rated processor speed) in terms of FP multiply/accumulates once the pipeline gets filled? Then, returning to the more ordinary case of doing DSP using the Core Audio API under OS X, how efficient is the assembly code generated by Xcode and how much processing can you cram in the real-time loop of your DSP app? I know that this is a far more difficult question to answer than the first one, but I was hoping some listers might be able to share some anecdotal information (e.g., "I was writing a digital EQ program and I was able to get more than 500 biquad sections to run in real-time with 44.1 kHz stereo data before the processor started to choke.")

Thanks,

Glenn Z

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: G4/G5 performance question
      • From: Wolfram Franke <email@hidden>
  • Prev by Date: (no subject)
  • Next by Date: Re: G4/G5 performance question
  • Previous by thread: (no subject)
  • Next by thread: Re: G4/G5 performance question
  • Index(es):
    • Date
    • Thread