Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Snow Leopard Cut ObjC Launch Time In Half

Soulskill posted more than 4 years ago | from the paring-down dept.

OS X 158

MBCook writes "Greg Parker has an excellent technical article on his blog about the changes to the dynamic linker (dyld) for Objective-C that Snow Leopard uses to cut launch time in half and cut about 1/2 MB of memory per application. 'In theory, a shared library could be different every time your program is run. In practice, you get the same version of the shared libraries almost every time you run, and so does every other process on the system. The system takes advantage of this by building the dyld shared cache. The shared cache contains a copy of many system libraries, with most of dyld's linking and loading work done in advance. Every process can then share that shared cache, saving memory and launch time.' He also has a post on the new thread-local garbage collection that Snow Leopard uses for Objective-C."

cancel ×

158 comments

Sorry! There are no comments related to the filter you selected.

I've heard that before.... (-1, Troll)

LO0G (606364) | more than 4 years ago | (#29331275)

In other words, Apple just re-invented Superfetch [wikipedia.org]

Photocopiers anyone?

Re:I've heard that before.... (0, Troll)

sa666_666 (924613) | more than 4 years ago | (#29331301)

Also sounds like the prelink [wikipedia.org] application in Linux.

Re:I've heard that before.... (5, Informative)

BorgDrone (64343) | more than 4 years ago | (#29331345)

Did you even read the article ? Suppose not... this is slashdot after all.

The article states that prebinding (similar to prelink) was used in previous versions of OS X and has been replaced by a much faster shared cache.

Re:I've heard that before.... (2, Informative)

Creepy (93888) | more than 4 years ago | (#29331809)

For reference, normally when a program is launched without prebinding, the program has to look into the symbol table for the shared library and "bind" it (basically, tell the program where it is). Prebinding basically does that in advance and saves the lookup table, but any time the library is changed, the bindings have to be regenerated.

    The article says prebinding is actually quite efficient for C/C++ code, but objective-C (used by macOS X and iPhone) is structured more like Smalltalk or Java, and uses selectors, which I believe can't be prebound (for you java programmers, these are equivalent to interfaces - C/C++ does not have this concept and instead allows direct access to the classes using protected or public) to interface into classes and these are instanced once for every application accessing that shared library. According to TFA, by keeping a single cached copy of the selector, they avoid the memory overhead of keeping individual copies. Since the OS itself has over 30000 selectors, you can imagine this cuts overhead by quite a bit, especially with commonly loaded libraries like Cocoa.

For people comparing this to superfetch, it's not really the same thing - superfetch was pre-loading heavily used libraries into memory to avoid the delay in loading them during start time, and this is caching the library lookups onto disk that may or may not be memory resident at any particular time.

Re:I've heard that before.... (4, Informative)

TheRaven64 (641858) | more than 4 years ago | (#29332517)

selectors, which I believe can't be prebound (for you java programmers, these are equivalent to interfaces - C/C++ does not have this concept and instead allows direct access to the classes using protected or public)

I'm sorry, but this and most of the rest of your description is completely wrong. Selectors are nothing like Java interfaces. Interfaces are Java's version of Objective-C Protocols. Selectors are abstract method names (Smalltalk calls them symbols). Each Objective-C class has some data structure mapping these to function pointers. When you send a message (call a method) you look up the function pointer corresponding to the selector in the receiving class. To make this fast, all selector comparisons are done as pointer comparisons. To make this work, the runtime needs to make sure that selectors are unique. This process involves building a large hash table and inserting every selector referenced by every compilation unit into it. By making the linker handle this uniquing, you have several advantages. The first is that the resulting table can be shared more easily between processes, resulting in a memory efficiency gain. The second is that the runtime can first try doing pointer comparison when registering a new selector, and only use the hash if the linker didn't unique the selector.

Re:I've heard that before.... (1)

ari_j (90255) | more than 4 years ago | (#29332825)

So, Objective-C requires selectors (such as for message names) to be interned [wikipedia.org] , and the old way was to intern all selectors at process startup time when the dynamic linker does its work; but the new way is to cache the interned selectors both on disk (faster startup) and in memory (even faster startup plus saved memory overhead). Is that correct?

Re:I've heard that before.... (1)

TheRaven64 (641858) | more than 4 years ago | (#29333453)

Almost. The old way was to do it at module load time, in the Objective-C runtime library (libobjc), the new way is to do it in the loader (dyld). The loader caches the result of everything it does, including uniquing symbols (two symbols with the same name are resolved to one or other instance), while the runtime library does no caching.

Re:I've heard that before.... (-1, Offtopic)

sa666_666 (924613) | more than 4 years ago | (#29331439)

Christ, the OSX fanbois are out in force today. This is the first time I've ever gotten a troll rating, basically for stating that it's similar to something that Linux has. It wasn't meant as a disparagement. I regularly use OSX and applaud any performance improvements. But I guess we can't even mention when similar features exist on other platforms. Note that I said SIMILAR; I recognize that it isn't exactly the same as prelink in Linux.

Re:I've heard that before.... (3, Informative)

lysergic.acid (845423) | more than 4 years ago | (#29331579)

Well, the FP is claiming that they're the same thing, and your post seemed to be agreeing with him. But yea, that troll rating probably should have gone to the post you replied to.

I don't know anything about prelink, but Superfetch sounds completely different from dyld. Superfetch keeps frequently launched applications in memory to make them launch faster (much like Winamp Agent does for Winamp). dyld, OTOH, shortens application launch times by not reloading a shared library each time an application is launched. Keeping the shared library loaded in a shared cache also reduces the number of copies of that library you need loaded in memory. It doesn't sound like Superfetch does that.

Both a turbocharger and a cold air intake can improve car performance, but that doesn't make them the same thing.

Re:I've heard that before.... (1)

pizzach (1011925) | more than 4 years ago | (#29331781)

You phrased things much better than I could fine sir. The link to the wikipedia article [wikipedia.org] that the original poster included read nothing like TFA [sealiesoftware.com] . Though because of the glaring placement of the post toward the top of the page and how straight forward it is written, I think most mods probably modded it without checking against either of the articles. That is how human nature is :). It's nice that slashdot moderation tends to correct itself over time thanks to insightful replies lower in the tree.

Re:I've heard that before.... (3, Insightful)

Simonics Zsolt (711668) | more than 4 years ago | (#29331645)

And maybe kdeinit does something similiar since 2003?

Re:I've heard that before.... (1)

good soldier svejk (571730) | more than 4 years ago | (#29332831)

Also sounds like the prelink [wikipedia.org] application in Linux.

No, OS X has always done that. Except they call it prebinding. [wikipedia.org]

Re:I've heard that before.... (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#29331311)

Isn't caching executables and shared libraries something Unix and variants have been doing for ages too? Way to stay ahead of the game, Slow Leopard :P

Re:I've heard that before.... (1, Informative)

Anonymous Coward | more than 4 years ago | (#29331327)

Or the GAC [wikipedia.org]

Re:I've heard that before.... (0, Troll)

pizzach (1011925) | more than 4 years ago | (#29331349)

I don't think so. From the article you linked:

The intent is to improve performance in situations where running an anti-virus scan or back-up utility would result in otherwise recently-used information being paged out to disk, or disposed from in-memory caches, resulting in lengthy delays when a user comes back to their computer after a period of non-use.

Everybody obviously knows that no viruses exist for the mac so your assertions are asymptotically false.

Re:I've heard that before.... (0)

pizzach (1011925) | more than 4 years ago | (#29331571)

I hoped my ridiculous words at the end would make people laugh, but I know most slashdotters lack a sense of humor. :) Tis life.

Re:I've heard that before.... (0, Troll)

pizzach (1011925) | more than 4 years ago | (#29331587)

Actually, it is interesting I was marked troll for quoting some text that the original poster linked. O.o A view into the minds of the moderators.

Re:I've heard that before.... (1)

osu-neko (2604) | more than 4 years ago | (#29332807)

Okay, whoever modded the above post as "Troll" is confused. Talking about the moderation system on a thread about some other topic (e.g. Snow Leopard) isn't a "Troll", it's "Off-topic".

Re:I've heard that before.... (0)

pizzach (1011925) | more than 4 years ago | (#29333701)

Depends on how you look at it. I was talking about how my post was rated troll which could and usually does turn into a talk about the content itself (which is on topic). A number of posts from other people on this article have been inaccurately moderated "Troll" for some reason though.

At his point, I do believe we may be both off topic (thanks to the mods). It will be interesting to see if you get rated off topic, and this post here gets rated troll, too. Here's hoping for helpful meta-moderation.

Re:I've heard that before.... (1)

TheGreenNuke (1612943) | more than 4 years ago | (#29333781)

Sir, I believe you are mistaken. There obviously must have been at least one virus at some point for a Mac otherwise why would Apple include virus and malware protection in Snow Leopard. Only now will none exist since Apple has deemed it so by not allowing the rogue virus to infect their hardware. :P

Re:I've heard that before.... (1)

leuk_he (194174) | more than 4 years ago | (#29331355)

And reintroduced dll hell as well?

Re:I've heard that before.... (1, Informative)

bhima (46039) | more than 4 years ago | (#29331471)

no. we've had a variant but lesser hell for years. Which has led to a series of cargo cult like maintenance procedures for Mac OS.

Re:I've heard that before.... (3, Funny)

mdwh2 (535323) | more than 4 years ago | (#29331375)

Well okay then, Apple were the ones who "popularised" it! ("Well I hadn't heard about Superfetch, but I heard about Apple doing it first, therefore, Apple did it first")

Or um ... they "integrated" it better. Yeah, that's it.

Re:I've heard that before.... (3, Interesting)

CharlyFoxtrot (1607527) | more than 4 years ago | (#29331479)

It's nothing like Superfetch. Superfetch preloads applications into system memory [microsoft.com] and this shared cache doesn't do that instead from what I understand it preforms some of the work the linker would do on load in advance.

Re:I've heard that before.... (-1, Offtopic)

sa666_666 (924613) | more than 4 years ago | (#29331525)

And this latter part is exactly what I referred to above when I compared it to prelink in Linux. And I was subsequently marked a troll for stating this similarity.

Re:I've heard that before.... (0)

Anonymous Coward | more than 4 years ago | (#29332185)

Dude, get over it. Sometimes mods are stupid. That's life. I'm sorry someone foolishly marked you as a troll, but you really need to move on.

Re:I've heard that before.... (0)

Anonymous Coward | more than 4 years ago | (#29333171)

Do you always throw a fit when you get modded down? I'm gonna bookmark this and give you the "overrated" treatment next time I get mod points, be sure to post crying about it.

Re:I've heard that before.... (2, Informative)

malevolentjelly (1057140) | more than 4 years ago | (#29331939)

It's nothing like Superfetch. Superfetch preloads applications into system memory [microsoft.com] and this shared cache doesn't do that instead from what I understand it preforms some of the work the linker would do on load in advance.

The whole dyld sounds a lot like some of the basic features of the .NET runtime...

Or maybe some of the features in this advanced futuristic os:

http://blogs.technet.com/askperf/archive/2008/02/06/ws2008-dynamic-link-library-loader-and-address-space-load-randomization.aspx [technet.com]

Re:I've heard that before.... (1)

guruevi (827432) | more than 4 years ago | (#29333687)

Dyld's (Dynamic Loader) have existed before Snow Leopard. They are extensively used in all Mac OS X versions since they are at the base of the system. They also appear in BSD and Linux under slightly different names. This just explains how they found out a way to do caching and preloading better than previously. It's like Microsoft finding out a way to automagically load all necessary dll's and correctly find out the dll amongst several different versions of the same dll for a program and preload them before the program even needs them. It does so correctly and consistently every time, they just sped it up now. I don't know if Windows DLL's even do versioning but from what I remember (latest experience was last week in XP) if one program writes over the other programs dll, you're shafted (I'm looking at you Aladdin USB/DRM Keys).

Re:I've heard that before.... (0)

malevolentjelly (1057140) | more than 4 years ago | (#29333735)

I understand, and Apple did a great job with it. It just really disturbs me when Apple (and their ilk) keep rehashing work previously completed on other platforms and claiming that they somehow invented it. I am yet to see a feature that's really *new* in Snow Leopard, yet I can't stop hearing about how many amazing new technologies Apple has created.

Apple did an intelligent new optimization of their dynamic loader on their platform. This is a good thing. They did not invent the concept of a dynamic loader.

Doesn't sound like this is loading apps. (2, Interesting)

Shag (3737) | more than 4 years ago | (#29331509)

Sounds like they've just updated their dynamic (shared) library loader to be able to handle Objective C (aka Cocoa) instead of just plain C, and to be a little smarter about keeping track of what it's already got going on, so it doesn't duplicate things.

As a long-time UNIX and Linux (and other more esoteric OSes) geek, this alone doesn't impress me too much. The idea that they went through the whole OS and worked to get little efficiency/performance gains like this all over the place impresses me a little more.

Re:Doesn't sound like this is loading apps. (4, Informative)

Ma8thew (861741) | more than 4 years ago | (#29331601)

Objective-C is not equivalent to Cocoa. Cocoa is a set of frameworks written in Obj-C and primarily used by Obj-C programs.

Re:Doesn't sound like this is loading apps. (1)

Shag (3737) | more than 4 years ago | (#29331775)

Good point. I should have said "as used in Cocoa" or something to be clearer. I'm not sure whether there are people out there writing Objective-C apps for the Mac without Cocoa, though. I guess there's always someone who won't use the nifty library and shortcuts and all that, because they're hardcore, efficiency nuts, or just masochists...

GNUstep Is Not Cocoa (1)

tepples (727027) | more than 4 years ago | (#29331899)

I'm not sure whether there are people out there writing Objective-C apps for the Mac without Cocoa, though. I guess there's always someone who won't use the nifty library and shortcuts and all that, because they're hardcore, efficiency nuts, or just masochists...

Or they use only a subset of Cocoa because they plan to port the app to GNU/Linux, *BSD, and Windows using GNUstep, an OpenStep-compatible toolkit that implements only some of Cocoa.

Re:GNUstep Is Not Cocoa (1)

Shag (3737) | more than 4 years ago | (#29333651)

GNUstep FTW indeed! And thanks, because I think you've just come up with an answer to something I was pondering the other day - what Adobe will do for Creative Suite 5, since they want to go 64-bit on the Mac, and that can't be done using the transitional Carbon library.

They're going to have to totally rewrite it in Cocoa (which I think is frankly a good thing, since the current codebase probably dates back to the early-to-mid 1990s, and has just had more and more crap glued onto it over the years), but I was thinking it'd be an awful pain to maintain both a Cocoa codebase for the Mac and the plain old codebase for Windows.

If they can do an Objective-C codebase, and keep the differences between the code for Mac (using Cocoa everything) and the code for Windows (using GNUstep) to a reasonably low level, they can still have a single codebase, which would make life easier going forward. (Plus, it'd be a modern OO codebase.)

Re:GNUstep Is Not Cocoa (1)

Jesus_666 (702802) | more than 4 years ago | (#29334179)

Nah, they'll probably write a wrapper that glues their C++/Carbon code to Cocoa and blame Apple for CS5 being slow.

Re:Doesn't sound like this is loading apps. (3, Interesting)

INT_QRK (1043164) | more than 4 years ago | (#29332133)

What impresses me significantly is that instead of concentrating on glitzy and often useless new "features," Apple actually implemented substantive performance enhancements. The import of this approach can't be praised enough in my view. Anecdotally, I recovered 6 GB of hard drive space, and immediately experienced noticeably zippier launches since yesterday's upgrade. My MacBook Air on Snow Leopard loaded on feels almost as nimble as my old IBM T-41 that operates on Ubuntu 9.04. Holy cow, this is no small thing. Just, good on them!

Re:I've heard that before.... (5, Informative)

plsuh (129598) | more than 4 years ago | (#29331795)

Moderators, please mod the parent down -- it completely misses the point.

Objective-C selector uniquing caching is NOT the same as Windows Superfetch.

Objective-C uses a two-phase dispatch for method calls. When you see a call in the Objective-C source code that looks like:

[myObject init];

the dispatch system:

  1. Looks up the function pointer for the method "init" in a table.
  2. Calls the "init" function via the function pointer.

The problem arises in the method dispatch table when you have multiple methods named "init" -- which is very common. When an application is loaded the dynamic loader ("dyld") needs to separately identify all of the methods named "init" (and any other methods with conflicting names) that apply to different classes. This is done by "tagging" each method in the dispatch table, a process called selector uniquing.

Now, this has to be not only for the application binary itself, but also for any Objective-C classes in shared libraries that are loaded. Almost all apps on Mac OS X load the libobjc.dylib library, which is cached to improve performance. As a part of the caching process, Snow Leopard now does the selector uniquing only once, and then stores the uniqued selectors in the cache. Thus, any application that links against libobjc.dylib (or any other library that is in the cache) only has to unique its own selectors, not those of the library as well. This significantly reduces the amount of overhead for launching an application compared to previous versions of Mac OS X.

This process does not attempt to retain application binary code in memory in the face of page-outs as Superfetch does. Selector uniquing caching speeds application launch times by reducing the amount of computation that has to happen at launch, not by pre-loading the application's binary.

Thread-local garbage collection is NOT the same as Windows Superfetch.

Thread-local garbage collection is a third phase of garbage collection added on top of the Objective-C 2.0 garbage collection system, which speeds up the garbage collection system even further. By concentrating GC to what has occurred in a single thread, the GC system can delay and reduce the cost of a slow global sweep even beyond the generational GC algorithm.

Windows Superfetch is a response to poorly written software.

To quote from the Wikipedia article:

The intent is to improve performance in situations where running an anti-virus scan or back-up utility would result in otherwise recently-used information being paged out to disk, or disposed from in-memory caches, resulting in lengthy delays when a user comes back to their computer after a period of non-use.

In my opinion as an experienced application developer the user should never run into the problem that Superfetch attempts to solve. Anti-malware scans or backups are generally limited by I/O transfer rates, not by CPU. In such situations, using lots of memory to pre-load data makes no sense. It is relatively easy to write a two-buffer, threaded, streaming system for situations that are constrained by disk transfer rates without consuming scads of memory.

In the bigger picture, Superfetch attempts to learn the times of day when apps are used and pre-loads their binaries. This is a nice concept, but I have serious doubts as to how useful it really is. The penalty for guessing wrong is fairly high, and users are more tolerant of consistent small slowdowns than they are of occasional long hangs (see the Mac literature on the spinning beach ball).

Mac OS X is less likely to need such anti-malware scans in the first place as the application binaries are now digitally signed by the developer. Any malware that attempts to insert itself into applications will run into problems. This is not to say that the Mac is immune -- I can think of a number of holes that could be exploited (such as the fact that unsigned binaries will still run and are still common; or that a malware author could attempt to insert his or her own root certificate into the trusted certificate store). However, these take more work and tend to limit the propagation rate of malware, making the platform a less-attractive target.

--Paul

Re:I've heard that before.... (2, Funny)

Spaham (634471) | more than 4 years ago | (#29331989)

mod parent : should be the article itself :D

Start working at 9 AM (1)

tepples (727027) | more than 4 years ago | (#29332061)

Objective-C uses a two-phase dispatch for method calls. When you see a call in the Objective-C source code that looks like:

[myObject init];

the dispatch system:

  1. Looks up the function pointer for the method "init" in a table.
  2. Calls the "init" function via the function pointer.

C++ follows the same steps. The big difference is that in Objective-C, the dispatch table is an associative array (C++ unordered_map, Java HashMap, Python dict) from strings to function pointers, not a plain array (C++ vector, Java ArrayList, Python list).

In my opinion as an experienced application developer the user should never run into the problem that Superfetch attempts to solve. Anti-malware scans or backups are generally limited by I/O transfer rates, not by CPU. In such situations, using lots of memory to pre-load data makes no sense. It is relatively easy to write a two-buffer, threaded, streaming system for situations that are constrained by disk transfer rates without consuming scads of memory.

But then you rely on the operating system to provide a method for applications to provide cache hints, and you rely on the antivirus software to provide such hints. SuperFetch tries to infer these even for applications developed prior to widespread knowledge of these hints or ported from systems that lack these hints.

In the bigger picture, Superfetch attempts to learn the times of day when apps are used and pre-loads their binaries. This is a nice concept, but I have serious doubts as to how useful it really is.

Having my applications ready to start at 08:57 when I'm about to grab the mouse at 08:58 improves my productivity. Consider that employees have sued their employers [technologyreview.com] for requiring that employees be present during application startup time but not paid until the application has fully started up.

Mac OS X is less likely to need such anti-malware scans in the first place as the application binaries are now digitally signed by the developer.

But who signs the developer's certificate? And what keeps malware publishers from signing their trojans?

Any malware that attempts to insert itself into applications will run into problems.

Unless an application tries to insert itself as, say, an assistive technology using the accessibility API.

Re:Start working at 9 AM (1)

larry bagina (561269) | more than 4 years ago | (#29332427)

c++ virtual functions go through the vtable (with an offset known at compile time). With Objective C, the selector/function pointer might not be in the associative array, so all the methods (stored as a linked list of arrays) need to be scanned (and inserted into the associative array if found) And if it's still not found, you send another message asking if it can respond, at which time it may add a new method on the fly.

Re:Start working at 9 AM (1)

TheRaven64 (641858) | more than 4 years ago | (#29332557)

This depends on the implementation. What you say is almost true for the Apple runtime, which has a small cache and then does a slow search along a list of arrays for cache misses. The GNU runtime uses a tree for dispatch, which is slower than Apple's cache (although not by much) and a lot faster in cases of a cache miss (by a lot). In 10.6 there are actually three fall-back methods if the selector is not found:
  1. If it's a fast proxy, then the object can provide a new receiver and the process starts again.
  2. The object can use the runtime functions to install a method, and then the process begins again.
  3. The message is wrapped up in an NSInvocation object and passed to the object to handle (forward over the network, or whatever).

Re:Start working at 9 AM (1)

rekoil (168689) | more than 4 years ago | (#29333469)

But who signs the developer's certificate? And what keeps malware publishers from signing their trojans??

IIRC the intent here is that any change in the binary - for example, an automatic updater - would have to be signed by the cert that's in the original package, and as such can validate that it's a "genuine" update, as opposed to the binary being changed by a remote exploit of any sort.

Re:Start working at 9 AM (1)

dkf (304284) | more than 4 years ago | (#29334055)

The big difference is that in Objective-C, the dispatch table is an associative array (C++ unordered_map, Java HashMap, Python dict) from strings to function pointers, not a plain array (C++ vector, Java ArrayList, Python list).

There are a whole bunch of tricks used (e.g., the map is actually from interned strings, which makes it far quicker to do the check) yet it has the flexibility to do things like dynamic dispatch and at a speed that isn't too horrible. Clever compromise (and has much in common with the way dynamic languages manage method invocations). And one of the cleverest things about it is that only method calls are routed through this: nobody even pretends that normal function calls need the overhead of fancy dispatch.

Re:I've heard that before.... (1)

BESTouff (531293) | more than 4 years ago | (#29333407)

The intent is to improve performance in situations where running an anti-virus scan or back-up utility would result in otherwise recently-used information being paged out to disk, or disposed from in-memory caches, resulting in lengthy delays when a user comes back to their computer after a period of non-use.

In my opinion as an experienced application developer the user should never run into the problem that Superfetch attempts to solve. Anti-malware scans or backups are generally limited by I/O transfer rates, not by CPU. In such situations, using lots of memory to pre-load data makes no sense. It is relatively easy to write a two-buffer, threaded, streaming system for situations that are constrained by disk transfer rates without consuming scads of memory.

I don't think you understood it right: the perf problem is not for the anti-malware programs, but once they have run they have thrown everything out of the cache and subsequent applications have to re-populate it again, thus slowing eveything down. There used to be the same kind of problem under linux after the 'locate' cronjob.

Re:I've heard that before.... (1)

Florian Weimer (88405) | more than 4 years ago | (#29333545)

Thread-local garbage collection is a third phase of garbage collection added on top of the Objective-C 2.0 garbage collection system, which speeds up the garbage collection system even further. By concentrating GC to what has occurred in a single thread, the GC system can delay and reduce the cost of a slow global sweep even beyond the generational GC algorithm.

Do you know how they detect that a pointer has escaped? Is there some sort of write barrier? How does this work with the somewhat unsafe base language?

Re:I've heard that before.... (0)

Anonymous Coward | more than 4 years ago | (#29332103)

Windows had this in 1995. The whole idea behind PE style DLLs is that you can just read in the module from disk and you can just use it as is. If the default loading address is available, which is normally almost always the case, you can use all the prebindings and you don't even have to patch your I/E tables. The only reason I won't mention the DLL cache is that that was only added in 2000 or so.

I heard of it, and USED IT, before that... apk (0)

Anonymous Coward | more than 4 years ago | (#29332263)

"In other words, Apple just re-invented Superfetch" - by LO0G (606364) on Sunday September 06, @10:36AM (#29331275)

On that note? Well, I could say that Microsoft only "ripped off" ideas I've been using since the early 1990's (first on software ramdisks, & later on SSD's too, per how I use them noted in this post here on /., today (& long before THAT, many times here & elsewhere online)):

http://hardware.slashdot.org/comments.pl?sid=1359547&cid=29332071 [slashdot.org]

Microsoft's only using a VARIATION OF MY IDEAS.

Ideas that took EEC Systems/SuperSpeed.com to a FINALIST position @ Microsoft's own Tech-Ed, 2 yrs. in a row, in its hardest category: SQLServer Performance Enhancement, albeit not for "home/end user oriented tasks" (which I list some of above & how I use it @ home @ least)...

That was for "back office app" perf. enhancement, & that url above shows proofs of that much for WebServers, File Servers, & DB Servers (from TechReport.com, in regards to Webserver, FileServer, & DB Server performance gains when using a TRUE SSD, like the IRAM).

E.G.-> AND? When that work showed improvements on SQLServer 6.5 & below, which used HDD space for various ops? Microsoft later "turned around", & made those ops take place in RAM...

(Which amounts to the SAME THING as doing it on a ramdisk in software really, & MUCH FASTER than HDD space could do it (MS uses a dedicated array/buffer in RAM now in SQLServer, because it works, for superior performance on DB work, bigtime)).

APK

P.S.=> More proof of my involvement here in this arena, goes back in WRITTEN PUBLICATION no less, as far back as 1996, here:

Windows NT Magazine (now Windows IT Pro) April 1997 "BACK OFFICE PERFORMANCE" issue, page 61

(&, for work done for EEC Systems/SuperSpeed.com on PAID CONTRACT (writing portions of their SuperCache program increasing its performance by up to 40% via my work) albeit, for their SuperDisk & HOW TO APPLY IT, took them to a finalist position @ MS Tech Ed, two years in a row)... apk

enough fucking (0, Troll)

Anonymous Coward | more than 4 years ago | (#29331285)

snow leopard stories!

Re:enough fucking (5, Funny)

Anonymous Coward | more than 4 years ago | (#29331343)

You've had enough of fucking, and would like more Snow Leopard stories? Each to his own, I guess.

Re:enough fucking (2, Funny)

igny (716218) | more than 4 years ago | (#29333543)

Apple's dyld comes in handy in both cases.

Re:enough fucking (4, Funny)

lysergic.acid (845423) | more than 4 years ago | (#29331385)

But I haven't even had a chance to submit these yet:

Re:enough fucking (1, Funny)

mdwh2 (535323) | more than 4 years ago | (#29331393)

Hey, it makes a refreshing change from the daily "Do XYZ On Your Iphone" stories! I'm love the variation today here on Apple- er Slashdot.

Re:enough fucking (0, Troll)

NoYob (1630681) | more than 4 years ago | (#29331413)

What?!?

Don't you understand that Snow Leopard is God's gift to operating systems?

Objective-C happens to be the greatest programming language EVAR!

Folks accuse Apple of re-inventing Superfetch. That is non-sense. Everything that Apple does is new and unique! It only seams as if Apple copies stuff because others come out with their own versions so fast that it sometimes seams as though they invented it first. But we all know that it was Apple who invented it first because their the ones who drive innovation in the PC world!

Anyway, this story came out just in time! I'm on my way to Sunday Apple services at the local Apple store. The pastor was blessed by Jobs himself once at a MacWorld show! To be touched by a hand that was once touched by His Appleness is just spiritually uplifting!

Praise Jobs - Glory Hallowed Be - Aaaaaaaaaamayyyen - Yaaaaeeeeeees!

Re:enough fucking (4, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#29332045)

Comparing this to Superfetch is ignorant beyond belief. Superfetch is part of the paging system on Windows and attempts to trigger page faults before the data is actually needed so that it's already cached when it is needed. This is quite a nice feature and one I am naturally prejudiced to like because my PhD was in this topic.

This is entirely different. Part of it is similar to the existing prebinding / prelinking stuff in Leopard / Linux, which generates the relocation tables in position-independent code. This is nothing like anything in Windows, because Windows doesn't use position-independent code for shared libraries (it uses a horribly ugly hack which performs better in the best case and much worse in the worst case). The article is a bit too light on details to understand exactly why the new version performs so much better.

The other half, however, is very clever. By caching the selector uniquing information, they are saving a lot of time when loading compilation units containing Objective-C code. Even better is the fact that, because these symbols are now not modified, they can be shared between processes without triggering copy-on-write faults. This isn't actually that hard to implement for the GNU runtime; just give the selector symbols mangled names and mark them as having common linkage (it's a bit harder on Darwin because Mach-O is weird), then you can use pointer comparison as a first step in the runtime and avoid the strcmp() call. Combining this with the prelinking support and you get the caching for free, which is very nice. I actually implemented this in Clang while writing this post, so expect to see it on non-Apple platforms soon too.

Re:enough fucking (1)

man_of_mr_e (217855) | more than 4 years ago | (#29333569)

Sounds like this "solution" is only a benefit because Apple chose to standardize on a language that generates very slow executables by default. Thus, the problem (and solution) are of their own making.

Re:enough fucking (1)

PhunkySchtuff (208108) | more than 4 years ago | (#29334649)

Yes, wouldn't it be terrible if Apple actually fixed issues with their OS...

Re:enough fucking (2, Funny)

hamburger lady (218108) | more than 4 years ago | (#29333775)

that sound you hear is NoYob's spirit being completely crushed.

bravo, sir.

Re:enough fucking (0)

Anonymous Coward | more than 4 years ago | (#29333905)

You are correct that this is nothing like Superfetch; however...

This is nothing like anything in Windows, because Windows doesn't use position-independent code for shared libraries (it uses a horribly ugly hack which performs better in the best case and much worse in the worst case).

Shows you have no idea what you are talking about with regard to Windows.

Your reply is a basic reciting of a couple of Wikipedia articles and you are not smart enough to realize that the 'hacks' the Wikipedia article that you are referencing is in regard to outdated DLL sharing technologies from Windows.

The article and your position is correct if you are stuck in Win32 and in the pre-Win2k/XP era of computing.

1) WIndows is NOT just WIn32, running the BSD subsystem on Vista, do you not have the exact same BSD form of linking and execution? So your blanket statement about Windows fails here, as BSD on NT is BSD on Windows, get it?

2) Windows XP changed how DLL sharing worked in the Win32 subsystem, and Vista and Win7 made massive changes to the DLL sharing mechanisms, as they are no longer fixed-position addressing.

3) You either don't realize there are several shared DLL/Asset technologies in Windows or you are just ignorning them. Here is a hint, take a look at something called .NET or even go further to core NT linking technologies

4) The way NT is designed, the core OS is not locked to any code execution or linking constructs, especially not something from an aged version of the Win32 subsystem. (This is one reason the VMS and UNIX designers of NT, chose not to use traditional kernel or UNIX constructs that are limited.)

*I use Win32 loosely, as there are technically two main NT OS subsystems, Win32 and Win64, with a legacy Win16 subsystem on the 32bit version of Vista/Win7.

You can beat up MS and Windows all you want, but if you want to pick on code linking, asset sharing, code caching or fundamental execution and compiler technologies, Microsoft is still one of the best companies in the world and continue to define technology progression in areas most SlashDot reader don't even realize exists.

Pull-Quoting a Wikipedia article doesn't help your position, especially if you do have a PhD in this area.

PS You might want to mention your actual doctorate, as the last time I was teaching there was no such thing as a doctorate on library sharing technology.

Re:enough fucking (1)

Hurricane78 (562437) | more than 4 years ago | (#29334235)

I still don't see what the point is. My solution to this: More RAM and *Autostart*. Really. I start everything I need at boot time. Which is quite rare. So I never felt the need to speed up the first start of any programs.

Re:enough fucking (2, Insightful)

644bd346996 (1012333) | more than 4 years ago | (#29331423)

Considering that the whole point of Snow Leopard was to refine the internal structure of the operating system and introduce new features for developers, it should come as no surprise that there are far more /. appropriate stories about it than the more eye-candy oriented releases.

Re:enough fucking (1)

shovas (1605685) | more than 4 years ago | (#29331469)

Maybe I've never realized before how bad slashdot is at beating a dead horse. But, really, this is going overboard with apple stories of the least bit of consequence or relevance (barring this story for once). I'm starting to think slashdot doesn't have pre-arranged deals with apple, and others, but that they get paid if a submission does happen to come through and is approved.

Re:enough fucking (0)

Anonymous Coward | more than 4 years ago | (#29332923)

No, this would be an decent enough story, assuming Slashdot actually was "news for nerds" and people were interested in the technical underpinnings. The handful of decent comments generated show that.

However, in reality, Slashdot is a gloryhole of non-technical luser fanboys who just want to piss on each other about who ripped off whom without understanding any of the details.

Re:enough fucking (2, Informative)

Jesus_666 (702802) | more than 4 years ago | (#29334155)

You are reading apple.slashdot.org. It might have occurred to you that at this subdomain you might find stories about Apple? You can filter it out, you know.

Re:enough fucking (0)

Anonymous Coward | more than 4 years ago | (#29332265)

Rather it strikes me that there are too few snow leopard stories. The gadget press goes crazy for almost every Apple launch, but somehow this OS is low key. Gizmodo isn't writing 100 posts a day about every nook and cranny of it, so on and so forth. A hypothetical tablet whereas seems to get a mention even in the new york times on a weekly basis. I simply don't get it.

Maybe it's due to the fact that this new version does not add shiny bells and whistles to a crumbling architecture. Rather it focuses on bringing some seriously good ideas together under one roof. That, to me, is a new standard compared to the mindless hype over pretty graphics.

Oh then again maybe the said "journalists" don't understand what they are seeing. Usually the core Apple fanatics orgasm by this time. Weird. Maybe the abscence of a RDF during launch had something to do with it.

What do you guys think about it?

If I ever switch from dual booting Ubuntu (buggy flash and video editing support will probably make me do it) and Win XP(for those windows only apps). OS X snow leopard is the thing I would buy.

I thought this was the shared libs always worked (3, Interesting)

noidentity (188756) | more than 4 years ago | (#29331333)

I thought one of the points of shared libraries was that the files could simply be mapped read-only into the memory of each process and executed directly. This would only require one physical copy in memory, even though it may exist at multiple logical addresses.

I take it since then shared library machine code has had to be patched in memory after it's loaded for a while now, thus preventing easy sharing among processes, and causing the page to need its own space in the swap file.

Sounds like this latest improvement effectively brings things back to the way they were, by effectively writing this patched version back to disk so that it can be mapped read-only as before, and not have to be patched every time the library is loaded into a process. It's odd, because I thought the OS already did this several versions ago when prebinding [wikipedia.org] .

Re:I thought this was the shared libs always worke (2, Informative)

Anonymous Coward | more than 4 years ago | (#29331637)

The shared libs are shared. What was not shared before is the linking table, that must be built for accessing that shared code. prelink precalculates that table, and this apple thing does more or less the same.

Re:I thought this was the shared libs always worke (0)

Anonymous Coward | more than 4 years ago | (#29332139)

A lot of people seem to be confused about operation of "shared" libraries.

Shared libraries on most platforms (mac,linux,windows..etc) are "shared" within a single processes memory space only. They are NOT "shared" between processes. Each separate process instantiates libraries separatly.

Apples change is to globally save some library state data to reduce each processes instantiation overhead when common libraries are used by multiple processes.

dyld (5, Funny)

DoofusOfDeath (636671) | more than 4 years ago | (#29331465)

dyld - noun. A reminder that regardless of age, you'll always have an adolescent sense of humor.

Re:dyld (0)

Anonymous Coward | more than 4 years ago | (#29331485)

Oh...

Re:dyld (0)

DoofusOfDeath (636671) | more than 4 years ago | (#29331493)

Oh...

That's what she said.

This is news... how? (-1, Troll)

Foredecker (161844) | more than 4 years ago | (#29331533)

So, Snow Leopard is now doing something Windows has always done... how is this news?

Sex wi*th a DOLL (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#29331535)

a sad world. at

Is this really something new? (0)

Anonymous Coward | more than 4 years ago | (#29331539)

What's the difference between this and sticky files?

Re:Is this really something new? (2, Funny)

AndGodSed (968378) | more than 4 years ago | (#29331603)

erm... these don't stick?

Re:Is this really something new? (1)

K. S. Kyosuke (729550) | more than 4 years ago | (#29333807)

erm... these don't stick?

Not even sticky files stick when applied to glue languages like Python. Must be glue incompatibility or something.

Commen Sense Sharded Library (0, Troll)

hackus (159037) | more than 4 years ago | (#29331625)

I do not wish to be a poo poo, but since dynamic libraries and shared libraries have been around for just about forever, when even a second year CS major would immediately notice this could be done, is such big news now?

The first thing I would have done is built a cache for the library system. LINUX has one, why not the Mac?

So certainly I congratulate the Mac community. But wow, DUH, a cache for the linkage editor. :-)

-Hack

Re:Commen Sense Sharded Library (3, Interesting)

Anonymous Coward | more than 4 years ago | (#29331763)

Me thinks you (and many other readers) are mistaking this feature for more traditional static dyld caching.

This enhancement is actually about caching a runtime computation for Objective-C purposes. In practice, as the linked article indicates, this computation is consistent most of the time. In some cases it is not. So to handle the general and most common case, these computations (selector uniquing) are cached and used across different processes.

So the fair question is does Linux cache selector-uniquing?

Re:Commen Sense Sharded Library (1)

keean (824435) | more than 4 years ago | (#29331937)

Does Linux need selector uniquing if it doesn't use Objective-C? To me this sounds like an inefficiency in Objective-C that made it less efficient than C++ (the other OO flavour of C) has been improved somewhat.

Re:Commen Sense Sharded Library (0)

Anonymous Coward | more than 4 years ago | (#29331969)

"Less efficient than C++" is a pretty pointless thing to say. They're different languages with different capabilities. It makes no more sense to say that one is more efficient than the other than it does to say a tree is more efficient than a cat.

What? (1)

gbutler69 (910166) | more than 4 years ago | (#29332299)

Hmm?? I think one could make a very meaningful comparison of the efficiency of Tree vs. Cat. Energy consumed vs. usefulness. Tree wins methinks!

Also, so what if they're "different languages"? If they were the "same language" there'd be nothing to compare. Do you go around comparing your right eye to your right eye?

Re:What? (0)

Anonymous Coward | more than 4 years ago | (#29334505)

Which one is more efficient at killing mice? Which one is more efficient at photosynthesis?

"Different languages" means that they have radically different capabilities, not just that they aren't identical. It makes sense to compare the efficiencies of, say, C and Pascal, or SmallTalk and Ruby, but little sense to compare, say, Prolog and FORTRAN or Lisp and BASIC.

People tend to think of Objective-C as being C++ with funny syntax, but they have radically different capabilities, so saying that Objective-C is less efficient makes no sense. It's more efficient at some stuff, and less efficient at others.

Re:Commen Sense Sharded Library (3, Insightful)

lurch_mojoff (867210) | more than 4 years ago | (#29332197)

Does Linux need selector uniquing if it doesn't use Objective-C?

No it doesn't. Since the average executable on linux is static code linked to dynamic libraries made up of static code, you get your "selector uniquing" at compile time - you don't get a method selector description, instead you get a pre-calculated and already unique address of the method or function.

To me this sounds like an inefficiency in Objective-C that made it less efficient than C++ (the other OO flavour of C) has been improved somewhat.

It is a tradeoff. You get to worry about the performance of shared library selector uniquing, but you get all the benefits of dynamic language and runtime. In practice such inefficiencies matter most in cases where you are very constrained for resources - e.g. on a phone, as hinted in TFA. I doubt in the context of the rest of the performance and efficiency improvements in Snow Leopard and on a reasonably modern computer, the 1/10 of a second or the few megabytes of memory saved matter all that much.

Re:Commen Sense Sharded Library (1)

keean (824435) | more than 4 years ago | (#29332325)

Makes sense... but I am not sold on the benefits of a dynamic language... how is this better than dynamically loaded shared libraries? If you really need a dynamic framework there is always XPCOM, which gives you the added benefit of being able to use it from many different languages, and of course the dynamic binding is built into Javascript which makes it ideal for linking together components written in C++.

Re:Commen Sense Sharded Library (1)

foniksonik (573572) | more than 4 years ago | (#29334103)

The article on Arstechnica about Snow Leopard goes into some detail about the advantages of Obj-C being a dynamic language... primarily due to the new inclusion of Closures aka functions assigned to variables so that you can pass a function to another function with dynamic arguments.

This makes for not necessarily a better performing language but an easier, more efficient and less buggy language.

It's still likely a personal coding preference of course.

Re:Commen Sense Sharded Library (0)

Anonymous Coward | more than 4 years ago | (#29334303)

The article on Arstechnica about Snow Leopard goes into some detail about the advantages of Obj-C being a dynamic language... primarily due to the new inclusion of Closures aka functions assigned to variables so that you can pass a function to another function with dynamic arguments.

Closures exist in several static languages too.

Re:Commen Sense Sharded Library (0)

Anonymous Coward | more than 4 years ago | (#29334585)

The fact that Apple's "blocks" (what they call closures/anonymous functions/etc.) are available in C/C++ should make it pretty damned obvious that they are completely unrelated to the advantages of using a dynamic language.

There are plenty of advantages to using a dynamic language, but blocks ain't one of them.

Re:Commen Sense Sharded Library (0)

Anonymous Coward | more than 4 years ago | (#29332203)

I don't think we'll get very far comparing an Objective-C (or Objective-C++) app against a C++ app. For better or worse, Apple has chosen to use Objective-C for Cocoa (GUI applications) and is simply making performance improvements for it.

Too bad I had to restore my computer to Leopard... (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#29331633)

Too bad I had to restore my computer to Leopard.....because with all this whiz-bang technology, many of my applications started to crash when saving files. I lost a days time updating and then restoring my two macs.

déjà vu (0)

Anonymous Coward | more than 4 years ago | (#29332043)

SGI did this linking trick in the early '90s - they called it Quickstart.

Apple made a rod for their own back with Obj-C (1, Insightful)

Viol8 (599362) | more than 4 years ago | (#29332253)

Perhaps Obj-C has a few nice features but personally I don't see it. If they'd stuck to C or C++ like every other version of Unix then this would never have been an issue in the first place. Plus a lot more people would have been able to cross-code for OS/X without having to learn an obscure OO version of C which never caught on in the wider IT world and is still used on practically no other system.

Re:Apple made a rod for their own back with Obj-C (1, Insightful)

Anonymous Coward | more than 4 years ago | (#29332663)

Objective-C simplifies many design patterns. Some have language level support at the core. Objective-C is a very simply, elegant language. It's not hard to learn at all. In fact, compared to C++ it's down right plain. Personally, I don't want to waste my time and brain cells learning all the intricate, ass chapping c++ quirks. I'd be better devoting those brain cells to Haskell.

Re:Apple made a rod for their own back with Obj-C (3, Insightful)

mgbastard (612419) | more than 4 years ago | (#29332677)

Right, because obviously the ultimate evolution of computer languages for all time is C and C++. There's never any need to further innovate that technology whatsoever.

Are you @#$@ kidding? It wasn't that funny.

I take issue with the assertion that nobody ever caught on with it. GNUStep? NeXT has been around for something like 15 years in industry now. EDS and others used it. Ross Perot was so impressed he invested in it and because a director at NeXT. It has a very feature rich set of frameworks associated with it, depending on your OS deployment. The only thing that sucks is Apple dropping OPENSTEP / Obj-C for Windows. But Steve didn't care about the enterprise market anymore at the time, and it might have eroded some mac hardware sales, and you couldn't very well charge a license for it. (I disagree, I think you could and can)

Re:Apple made a rod for their own back with Obj-C (1)

ari_j (90255) | more than 4 years ago | (#29332939)

Not just that, but the expense of rewriting Openstep in C++ would have been ridiculous and likely would have put Apple out of business. They did the right thing, both in business terms and in technological terms. Instead of wasting time reinventing the wheel, they just got on the cart and started rolling forward. Obj-C is also not a bad language, all things considered.

Re:Apple made a rod for their own back with Obj-C (0, Insightful)

Anonymous Coward | more than 4 years ago | (#29333097)

Right, because obviously the ultimate evolution of computer languages for all time is C and C++. There's never any need to further innovate that technology whatsoever.

Sure there is need for that. But does Objective-C do that? The GP said he doesn't think so. You should start there if you wan't to make a point.

Re:Apple made a rod for their own back with Obj-C (1)

am 2k (217885) | more than 4 years ago | (#29333237)

Considering what Apple did to WebObjects, my guess is that not even charging for it would have changed that decision.

Re:Apple made a rod for their own back with Obj-C (0)

Anonymous Coward | more than 4 years ago | (#29333673)

Actually, one of the nicer features of Obj-C is the fact that it is a strict superset of C. What this means for developers is that any code written in C (and usually C++, though for different reasons) can be treated as Obj-C code, which makes it pretty easy to port such code to OS X. All that usually needs to be done is write a wrapper in Obj-C to handle all your OS X specific code.

ObjC is a modern, rich platform (2, Interesting)

SuperKendall (25149) | more than 4 years ago | (#29333835)

Perhaps Obj-C has a few nice features but personally I don't see it. If they'd stuck to C or C++ like every other version of Unix then this would never have been an issue in the first place.

But you can use either of those perfectly well mixed with ObjC calls.

ObjC is a relatively small set of additions to standard-C, so it really doesn't take that long to pick up the syntax changes if you've encountered C before, while at the same time it allows for some very nice dynamic behavior and things like introspection. The language has evolved to support things like garbage collection (though that specific feature is not available on the iPhone due to performance constraints).

What you are really overlooking though is that Objective-C that Apple uses, has a very rich and diverse set of foundation classes (some inherited from the NeXT days) - just as wide in scope as Java. Any modern language simply has to have a giant toolbox to help get common tasks done, and that's going to be the thing that takes the most time to learn. Happily, Objective-C has a fairly consistent set of tools and conventions, that make learning new parts easier once you have learned a few others.

I don't get it. (1, Insightful)

Ant P. (974313) | more than 4 years ago | (#29333763)

Why don't they (any OS) just add something onto the generic filesystem caching layer to keep executable bits in RAM as long as the input files stay the same? If it was done that way you could theoretically reuse it for interpreted code as well.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>