Re: Developing Tool for Audio program
Re: Developing Tool for Audio program
- Subject: Re: Developing Tool for Audio program
- From: Brian Willoughby <email@hidden>
- Date: Mon, 29 Dec 2003 13:36:58 -0800
Hello all,
Sorry to continue this language discussion, but we're all developers here -
with a variety of language choices available for accessing CoreAudio - and I'd
like to at least follow up to any misleading or misguided statements. Enjoy:
on 12/25/03 3:55 PM, Brian Willoughby <email@hidden> wrote:
>
[ I'd certainly prefer to use Obj-C for AU internals --
>
[ though I would be concerned about method-lookup overhead.
>
>
The myth of method lookup overhead is what scares most people. Apple made it
>
clear at the 1997 WWDC that Objective-C method calls were on par with C++
>
calls.
Kurt Bigler <email@hidden> replied:
[ At the same time apple has since been doing this horrendously slow
[ "optimizing" step in all their installers to make up for the fact that the
[ method lookups are slow enough that it is worth doing this optimization when
[ possible. And I seem to remember how much faster applications got when
[ Apple first introduced that install-time optimization - but that was years
[ ago now. And I was never clear exactly why that was, and it is not
[ necessarily a proof of slow method dispatch, if in fact optimize-at-install
[ was just seen as a better alternative to optimize-at-launch for example. I
[ don't know that this whole scenario is clearly explained anywhere, but it
[ would be good to understand it.
The "optimizing" step performed by the installer has *nothing* to do with
Objective-C method dispatch. You are seeing a "linker/loader" stage
optimization, not any kind of code optimization, and especially not method
dispatch optimization. What is happening is that dynamically linked
"libraries" (we know them as Frameworks) may take a long time to load into an
application because their load addresses may overlap whenever more than one
Framework is used (which is almost always). The installer goes through every
framework loaded by the applications and decides which addresses to juggle so
that they will all load without conflict. These end up as hints for the
linker-loader. A program still must be dynamically linked when first run, but
this step is much faster when the hints point to a non-conflicting set of
addresses on the first attempt. Thus the performance boost you have observed.
If it were possible to speed up method dispatch in the way you were supposing,
then these optimizations would simply be built into the compiler, or at least
the linker/loader.
In "the old days," NeXT provided SharedLibs (.shlib). These were
statically-linked shared libraries which were loaded into a common address
space and shared via virtual memory among all programs which loaded the
library. Unfortunately, only NeXT could make these SharedLibs, because they
did not make it easy to coordinate the static address space. Basically, a
.shlib is pre-linked into a specified range of addresses, and if one shlib uses
another, then it must also know the range of addresses allocated to the other
shlib. If the address space for two static SharedLibs overlapped even
partially, then a given program could not load both of those libraries at the
same time. Even within the libraries provided by NeXT, there were some
conflicts. For example, it was not possible to create a program which used
both the ISDN networking kit and the IndexingKit. NeXT must have goofed and
one team forgot that another had already used a particular range. Either that,
or they were being conservative with address space to leave room for
third-party shlibs.
The dynamic shared libs were introduced in NeXTSTEP 4.0, otherwise known as
the first OPENSTEP release. This opened the door for frameworks which could be
developed by any third-party, but slowed down the step of loading of a program
into memory for execution. OPENSTEP still ran old staticically-linked
libraries, and it was easy to see the speed difference at load time. For this
reason, many OPENSTEP users never quit any of their applications, lest they
suffer the load-time penalty again.
I am not certain whether Mac OS X allows virtual memory sharing such that only
a single copy of a framework is loaded for all applications that use the
framework. Considering the fact that a large part of the CoreAudio API is
compiled into each application, it is actually impossible to share the code
memory, meaning that we're wasting RAM much faster with C++ than with ObjC.
[ > They went so far as to count instructions cycles. Plus, the proven
[ > track record of the DriverKit, with its 100% ObjC implementation, shows
[ > that critical code does not suffer because of the language.
[
[ But this does not explain the choice to abandon it, given its purportedly
[ good track record and clearly beneficial feature-set. Perhaps it was good
[ enough for what DriverKit did, but not good enough for more extreme
[ real-time needs, as in CoreAudio?
Not all programming decisions are technically motivated. The switch to C++
was largely, if not completely, political. ObjC frightened customers.
As far as comparing what the DriverKit did to what IOKit or CoreAudio does,
they are equivalent. All busses - PCI, PCMCIA, ISA, EISA, Plug&Play, etc. -
are scanned for devices, matching drivers are found and loaded, and the
operating system and applications are allowed access to the drivers for
timing-critical and protected access. In the area specific to CoreAudio,
DriverKit was able to provide high-bandwidth, real-time audio without
glitching, as well as access to DSP acceleration for audio effects. I don't
see that IOKit or CoreAudio does substantially more than that, at least not in
a way which would necessitate a language switch for technical reasons. IOKit
does improve on many things such as matching, but a modern DriverKit based on
ObjC would have been able to support the same improvements. Such improvements
are due to experience, not due to a language change.
That said, I reiterate my original statement: The language choice is up to the
developer. Each language has its unique advantages and disadvantages, but
none of C, C++, or ObjC are so lacking as to be incapable of solving our needs.
Pick the language, and seek help from the community if you seem to be coming
up against a barrier.
Brian Willoughby
Sound Consulting
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.