Archive for May 12, 2014

Monday, May 12, 2014

The Untold Story of Larry Page’s Incredible Comeback

Nicholas Carlson:

The speech surprised the Google executives, particularly the company veterans. Since the days of Page and Brin calling every idea they didn’t like “stupid” — if not “evil” — fighting was the way things got done at Google.

Some of them remembered that day in July 2001 when Page had insulted and fired a handful of project managers in front of all their peers. But when the people in the Carneros Inn ballroom looked at Page that day, they saw someone who looked very different from the kid who built Google’s first server rack in his dorm room.

How to Efficiently Read Thousands of Small Files With GCD

Kenny Carruthers:

I’ve considered manually throttling the requests with an NSOperationQueue and a low value for the maxConcurrentOperationCount but that just seems wrong as the newer MacPros can clearly handle a ton more I/O compared to an older, non-SSD, MacBook.

Bill Bumgarner:

The reality is that a modern, multi-tasking, multi-user system that runs across many configurations of hardware, automatically throttling an I/O bound task is nigh impossible for the system to do.

You’re going to have to do the throttling yourself. This could be done with NSOperationQueue, with a semaphore, or with any of a number of other mechanisms.

Normally, I’d suggest you try to separate the I/O from any computation so you can serialize I/O (which is going to be the most generally reasonable performance across all systems), but that is pretty much impossible when using high level APIs. In fact, it isn’t clear how the CG* I/O APIs might interact with the dispatch_io_* advisory APIs.

I like GCD, but you have to take its promise with a huge grain of salt:

In the past, introducing concurrency to an application required the creation of one or more additional threads. Unfortunately, writing threaded code is challenging. Threads are a low-level tool that must be managed manually. Given that the optimal number of threads for an application can change dynamically based on the current system load and the underlying hardware, implementing a correct threading solution becomes extremely difficult, if not impossible to achieve.

[…]

Rather than creating threads directly, applications need only define specific tasks and then let the system perform them. By letting the system manage the threads, applications gain a level of scalability not possible with raw threads.

You still have to manage things manually unless you’re not doing I/O. It’s just that you’re dealing with queues rather than threads. And we don’t yet have good tools for adapting code to systems with different I/O capabilities.

Autoreleasing Core Foundation Objects With ARC

Mike Ash tries to use sel_getUid() to work around not being able to call -autorelease from ARC code and runs into some interesting issues:

I also said that this code is not harmless. The harm here is exactly that fast autorelease path. To ARC, an autorelease in a function or method followed by a retain in the caller is just a way to pass ownership around. However, that’s not what’s going on in this code. This code is attempting to actually put the object into the autorelease pool no matter what. ARC’s clever optimization ends up bypassing that attempt and as a result, the dictionary is immediately destroyed instead of being placed in the autorelease pool for later destruction.

[…]

References to external functions aren’t fully bound when a program is initially loaded. Instead, a stub is generated which has enough information to complete the binding the first time the call is made. On the first call to an external function, the address for that function is looked up, the stub is rewritten to point to it, and then the function call is made. Subsequent calls go directly to the function. By binding lazily, program startup time is improved and time isn’t wasted looking up functions that are never called.

Since CFAutorelease() requires Mac OS X 10.9, Daniel Jalkut suggests implementing your own function in a file that’s not compiled with ARC:

CFTypeRef MAAutorelease(CFTypeRef CF_RELEASES_ARGUMENT arg) 
{ 
    return [(id)arg autorelease]; 
}

This is probably the “right” solution, but it’s kind of a pain.

Tammo Freese suggests:

inline CFTypeRef MyAutorelease(CFTypeRef obj) { 
    id __autoreleasing result = CFBridgingRelease(obj); 
    return (__bridge CFTypeRef)result; 
}

The behavior of the __autoreleasing ownership qualifier is really subtle, though.

All of this illustrates the leakiness of the ARC abstraction. For simple cases, everything just works, without your having to know how. But at some point you not only have to understand the manual memory management rules that you were avoiding; you also have to understand the calls the compiler is inserting on your behalf and the crazy per-architecture optimizations. With manual memory management, we debugged using tools like ObjectAlloc and Instruments. With ARC, you occasionally need to drop into assembly.

What Happened at NewsGator

Brent Simmons:

Somewhere along the way the decision was made to shut down the consumer browser-based app and the syncing platform.

[…]

Last things to note: even Google Reader is gone. And AllThingsDigital.

Meanwhile, RSS is alive and well (from 2013), as always.

Dave Winer:

I always wondered what the VCs were thinking. They had a chance to work with the guy who was driving adoption, who had the relationships with the publishers, and had a roadmap already worked out. Instead they went with a nice guy who thought RSS was email.

How Apple Beats the Demise of Music Downloads

Jon Maples (via John Gruber):

The first number [13.3] is the percentage that music downloads have decreased in Q1 of this year compared with 2013. This is on the heels of a 5% decrease last year, so it’s looking like the decline is picking up speed.

[…]

It’s pretty clear when it comes to the choice between buying downloads or using a streaming service, customers are beginning to choose streaming. But so far, Apple has sat out of the subscription music trend. After all, the Book of Jobs says that customers wanted to own rather than rent music.

I thought Jobs was right about this. I don’t want to have to subscribe to anything. But clearly lots of people think otherwise. Maples suggests that Apple would keep the streaming service separate from iTunes, as a hedge.