Linked by Thom Holwerda on Fri 11th Sep 2009 14:15 UTC
Mac OS X One of the main new features in Apple's new Snow Leopard operating system has been released as open source. Apple has released the code of the userland portion of its Grand Central Dispatch technology under the Apache License, version 2. Mac OS X also has kernel support for Grand Central Dispatch, which is also released as open source via the XNU project. While we're at it, let's take this opportunity to look into exactly what Grand Central Dispatch is.
Permalink for comment 383687
To read all comments associated with this story, please click here.
RE[4]: Compared to .Net ThreadPool
by CrLf on Sat 12th Sep 2009 13:49 UTC in reply to "RE[3]: Compared to .Net ThreadPool"
CrLf
Member since:
2006-01-03

Not unless it's over Richard Stallman's dead body. The whole reason for the existence of LLVM/Clang is that GCC was going nowhere Apple wanted and RMS was unwilling to add even trivial features any other modern-day compiler has.


This reminds me of EGCS*, which came to be exactly because the GCC project was stale and unwilling to evolve in any meaningful way. This is not the case with LLVM and Clang.

GCC and LLVM/Clang have fundamentally different objectives.

GCC is supposed to be the "all architectures/all-languages" compiler (which is why it changed from "GNU C Compiler" to "GNU Compiler Collection"), which places and extra burden in anyone who wishes to make significant changes in the way it operates and the features it has: making significant changes to GCC implies that those changes have to apply to all architectures (from multi-core multi-GHz CPUs to tiny microcontrollers) or, at least, not cause them any harm.

This is fantastically hard. Even so, GCC seems to be making steady progress over the last few years, but within its limitations and without a (probably disastrous for the project's goals) major rewrite.

LLVM/Clang is the way to work beyond those limitations without caring if it only works for x86. There is no war between LLVM and GCC (and if there is any significant rivalry between the two projects, there shouln't be).

The two projects actually help each other.

The knowledge within the GCC project about the different architectures it supports can help LLVM from falling into the x86-only pit, and the more production-oriented rate of change can help LLVM integrate the more relevant features sooner and more consistently into its design.

On the other hand, LLVM can eventually reach the level of quality and architecture/language support that GCC currently has, allowing it to adopt GCC's goals and effectively become a replacement for GCC.

I don't think RMS has anything to do with this (and with today's GCC, actually), nor I think he would come forward criticizing LLVM if this should happen.


As cynical as it is, I think it'll take some real convincing for GCC to accept Blocks. Maybe if it gets ratified into the standard, then there should be no reasonable reason for it to not be included.


I think you are wrong in both counts.

On one hand you imply that GCC is slow in adopting changes when, in fact, GCC is often criticized for implementing too many extensions to standards. Many changes to language standards have actually been implemented first in GCC, which is the complete opposite of what you're stating.

On the other hand, GCC doesn't have to implement blocks just because Apple provides them with the necessary code to do it and they are required by something that currently has no expression whatsoever outside of OS X.

The real problem, like others have mentioned, is that blocks/closures may not be a good fit for C, and C developers may not like them.

This may be confusing to the people that use the term "C/C++", but C is still a separate, and living, language from C++ because of its simplicity (a real understatement when comparing to a language so feature-bloated and baroque as C++). C programmers may not look favorably to C becoming a little more like C++.



* http://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fork

Reply Parent Score: 3