• 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
Re: Carbon is C++?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Carbon is C++?


  • Subject: Re: Carbon is C++?
  • From: Ariel Feinerman <email@hidden>
  • Date: Mon, 1 Mar 2010 13:32:56 +0200

Hi,
everyone say: "ObjC is slower then C++", but I/O Kit in the NextStep was
written in ObjC, I really don`t think Next`s engineers didn`t know that. Now
many crazy people write games in C# (managed language), but says that ObjC
is not appropriate because it dynamically. Your experience is greater then
mine, what do you think?

2010/3/1 Greg Parker <email@hidden>

> On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
> > I disagree.  I have written very low latency device drivers in
> Objective-C.  Why do you think Objective-C has too much "latency" for audio?
>  When properly used, Objective-C programs are no more likely to be preempted
> than any other kind of program.  Message dispatch generally has constant
> time and is only 2.5 times the cost of a C function call.  There aren't many
> function calls or messages sent in audio processing anyway.  Signal
> processing routines tend to be long loops.  Objective-C _IS_ C which means
> it is likely usable in any situation where C is usable.
>
> Message dispatch is generally fast. For many real-time-ish purposes that's
> good enough. But occasionally message dispatch (1) takes much longer, and
> (2) acquires locks. For some real-time-ish purposes, this sort of surprise
> is fatal when it occurs. Since there's no way for the program to control
> when dispatch is fast and when it is slow, clients with sufficiently tight
> "no surprises" requirements should avoid it altogether. If your requirements
> are demanding enough that you can't call malloc(), then you probably can't
> call objc_msgSend() either.
>
> It's the locks that kill. With care, a real-time-ish thread can pretty much
> solve problems of page faults and scheduling and the like. But the moment
> you take a lock, you're at the mercy of some other thread that may not be so
> careful.
>
> Audio clients tend to be the most paranoid about this on Mac OS X. They're
> the closest to truly-real-time requirements that I see, with good reason: if
> your audio playback skips, ever, you probably just lost a customer.
>
>
> --
> Greg Parker     email@hidden     Runtime Wrangler
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Re: Carbon is C++? (From: Greg Parker <email@hidden>)

  • Prev by Date: Re: Carbon is C++?
  • Next by Date: Re: UITextView as its own delegate - infinite loop on keyboard select
  • Previous by thread: Re: Carbon is C++?
  • Next by thread: Re: Carbon is C++?
  • Index(es):
    • Date
    • Thread