101–110 of 121 posts
http://www.apple.com/macosx/refinements/ for all those who claims it's just a service pack. But, as I said elsewhere, the major improvements are under the hood.
As a non Mac OS user, that link just reinforces to me that it looks like just a service pack. But at $29, I don't think it matters. If it were $129, that would be ridiculous.
Even in marketting copy, Apple's design taste is unrivaled: http://www.apple.com/macosx/ http://www.microsoft.com/windows/windows-7/ I mean seriously, how many levels of tabs are too many? http://www.microsoft.com/windows/windows-7/features/whats-ne...
I always wonder why Microsoft is so bad at advertising. They're not a stupid company. They create products that are nearly always good, if rarely (in my opinion) great. But they've never shown any sort of strength-of-focus and they make things that are ugly. I don't get it. In cases like this, it's easier to make something that's stark and simple than it is to make something cluttered and unappealing.
Even in marketting copy, Apple's design taste is unrivaled: http://www.apple.com/macosx/ http://www.microsoft.com/windows/windows-7/ I mean seriously, how many levels of tabs are too many? http://www.microsoft.com/windows/windows-7/features/whats-ne...
Apple's marketing is an added feature. I get a lot of joy looking through their ad copy, in a way that I get out of very few marketing departments'. I always wonder why Microsoft is so bad at advertising. They're not a stupid company. They create products that are nearly always good, if rarely (in my opinion) great. But they've never shown any sort of strength-of-focus and they make things that are ugly. I don't get…
Earlier quoted context omitted.
While I'm sure the scheduler had to be changed to accommodate it, it's not primarily a new scheduler. It's really a sophisticated thread pool system implemented in the kernel and exposed to programmers through language extensions. See http://en.wikipedia.org/wiki/Thread_pool_pattern for the basics on the idea - which has been around for a long time.
Thanks - this makes more sense. Just a scheduler wouldn't explain how "With GCD, threads are handled by the operating system, not by individual applications. GCD-enabled programs can automatically distribute their work across all available cores, resulting in the best possible performance whether they’re running on a dual-core Mac mini, an 8-core Mac Pro, or anything in between."
That sounds OK, if kinda unexciting. I'd like to see some benchmarks vs. traditional threading before I commit to liking it. History is littered with cute new IPC mechanisms that didn't turn out to have the benefits promised. This sounds a lot like a combination of sysv message queues and solaris doors, neither of which managed to drive much real innovation.
Earlier quoted context omitted.
Thanks - this makes more sense. Just a scheduler wouldn't explain how "With GCD, threads are handled by the operating system, not by individual applications. GCD-enabled programs can automatically distribute their work across all available cores, resulting in the best possible performance whether they’re running on a dual-core Mac mini, an 8-core Mac Pro, or anything in between."
Yeah, that sounds about right. It's a thread API that relies on applications providing "blocks" of work to the OS, and transferring their arguments and results around in message queues. So if you have five applications running, each of which has 8 threads to handle the needed parallelism on a Nehalem box, you don't need 40 separate threads and their stacks. The OS just spawns 8 threads. That sounds OK, if kinda unexc…
What a thread pool infrastructure buys us is the separation of tasks (the bundle of information passed around the queues) from their execution context (in this case, a kernel thread). It puts a level of abstraction between what is executed and how that's executed.
At the risk of belaboring a point, this is an old idea - this is traditional multithreading. Java has a library for doing it, as does C++ (in Boost). A library for this kind of parallelism was, in fact, the first C++ library, written by Stroustrup. Even the Linux kernel uses this technique internally (by which I mean it's not exposed to applications at the user level). Cilk (the MIT project that spawned the company Cilk Arts which was recently acquired by Intel) is probably the best known example of providing language-level abstractions for this technique. (I reccomend their paper "The Implemention of the Cilk-5 Multithreaded Language": http://supertech.csail.mit.edu/papers/cilk5.pdf)
By pointing out that this is an old idea, I don't mean to denigrate what Apple has done. Execution matters, and from the looks of it, they've executed this well - they've got something working at the language and kernel level, which is non-trivial.
I am quite surprised no other operating system has something like GCD. Is that MarketingSpeak or is it really something new?
Earlier quoted context omitted.
I think the point of GCD is that the concept is being brought down to the C, C++, and Objective-C layers, through the introduction of "blocks"... http://www.mikeash.com/?page=pyblog/friday-qa-2008-12-26.htm... http://www.mikeash.com/?page=pyblog/friday-qa-2009-08-14-pra... I agree there's too much marketing hype surrounding GCD, but neither the CLR nor the JVM can jump through that particular hoop.
It's interesting. For the little I have seen (and I was only able to give it a quick glance) it includes syntactic support for multi-threading being built into their Objective-C compiler. Are they forking the Objective-C compiler?
Earlier quoted context omitted.
I think the point of GCD is that the concept is being brought down to the C, C++, and Objective-C layers, through the introduction of "blocks"... http://www.mikeash.com/?page=pyblog/friday-qa-2008-12-26.htm... http://www.mikeash.com/?page=pyblog/friday-qa-2009-08-14-pra... I agree there's too much marketing hype surrounding GCD, but neither the CLR nor the JVM can jump through that particular hoop.
It's interesting. For the little I have seen (and I was only able to give it a quick glance) it includes syntactic support for multi-threading being built into their Objective-C compiler. Are they forking the Objective-C compiler?
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/00267...
Although, there's a comment by Johannes Fortmann here that says that the code has been available in an svn repository since at least September 5, 2008:
http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/
"If you check out the llvm-gcc svn trunk, you’ll find all the code there (you can even build your own llvm-gcc with working blocks)."
Earlier quoted context omitted.
I think the point of GCD is that the concept is being brought down to the C, C++, and Objective-C layers, through the introduction of "blocks"... http://www.mikeash.com/?page=pyblog/friday-qa-2008-12-26.htm... http://www.mikeash.com/?page=pyblog/friday-qa-2009-08-14-pra... I agree there's too much marketing hype surrounding GCD, but neither the CLR nor the JVM can jump through that particular hoop.
It's interesting. For the little I have seen (and I was only able to give it a quick glance) it includes syntactic support for multi-threading being built into their Objective-C compiler. Are they forking the Objective-C compiler?
Earlier quoted context omitted.
I'm still on Tiger and I'm probably not going to upgrade. I have a first-gen "lapburner" MBP which works just fine. Leopard didn't really offer anything ground breaking and it doesn't appear Snow Leopard will either. And I figure anything ground-breaking will require newer hardware, so I guess I'll stay on Tiger until the machine stops working. Which coincidentally is also why XP users don't upgrade either.
Time machine alone was worth the price of admission. There were also some good unix upgrades in there if that sort of thing carries any weight with you.
I'm hoping that a scorched-earth fresh install of 10.6 will either eliminate the amazing flakyness or alternatively point me to a hardware problem.