Apple Freezes Snow Leopard APIs
DJRumpy writes in to alert us that Apple's new OS, Snow Leopard, is apparently nearing completion. "Apple this past weekend distributed a new beta of Mac OS X 10.6 Snow Leopard that altered the programming methods used to optimize code for multi-core Macs, telling developers they were the last programming-oriented changes planned ahead of the software's release. ...`Apple is said to have informed recipients of Mac OS X 10.6 Snow Leopard build 10A354 that it has simplified the`... APIs for working with Grand Central, a new architecture that makes it easier for developers to take advantage of Macs with multiple processing cores. This technology works by breaking complex tasks into smaller blocks, which are then`... dispatched efficiently to a Mac's available cores for faster processing."
Perhaps the editor doesn't know how to edit?
Oh wait, kdawson, never mind.
I almost threw up.
The problem is shared-memory, not multi-processor or core itself. Graphics card have dedicated memory or reserve a chunk of the main memory.
It is true, because they privilege immutable data structures which are safe to access concurrently.
Only partly true. Even in pure functional languages like Haskell, the functional-programming dream of automatic parallelization is nowhere near here yet; in theory the compiler could just run a bunch of thunks of code in parallel, or speculatively, or whatever it wants, but in practice the overhead of figuring out which are worth splitting up has doomed all the efforts so far. It does make some kinds of programmer-specific parallelism easier; probably the most interesting experiments in that direction, IMO, is Clojure's concurrency primitives (Clojure's a Lisp-derived language with immutable data types, targeting the JVM).
Lisp, FWIW, doesn't necessarily privilege immutable data structures, and isn't even necessarily used in a functional-programming style; "Lisp" without qualifiers often means Common Lisp, in which it's very common to use mutable data structures and imperative code.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I know it was partially true, I should remember not to be too lazy when posting on /. :).
Note that I was not talking about automatic parallelization which is indeed possible only with pure languages (and ghc is experimenting on it); but simply about the fact that is is easier to parallelize an application with immutable data structures since you need to care a lot less about synchronization. For instance, the Erlang actors model (also in other languages like Scala on the JVM) still requires the developer to define the tasks to be parallelized, yet immutable data structures make the developer's life a lot easier with respect to concurrent access and usually provide better performance.
My "It is true" was referring to "functional languages" which do usually privilege immutable data structures, not to Haskell or Lisp specifically (which as you said has many variants with mutable structures focused libraries). As you said, Clojure is itself a Lisp-1 and it does privilege immutable data structures and secure concurrent access with Refs/STM or agents. What is more interesting in the Clojure model (compared to Scala's, since they are often compared even though their differences, as functional languages and Java challengers on the JVM) is that it doesn't allow unsafe practices (all must be immutable except in variables local to a thread, etc).
Interesting times on the JVM indeed.
Yeah that's fair; I kind of quickly read your post (despite it being only one sentence; hey this is Slashdot!) so mistook it for the generic "FP means you get parallelization for free!" pipe dream. :)
Yeah, I agree that even if the programmer has to specify parallelism, having immutable data structures makes a lot of things easier to think about. The main trend that still seems to be in the process of being shaken out is to what extent STM will be the magic bullet some people are proposing it to be, and to what extent it can be "good enough" as a concurrency model even in non-functional languages (e.g. a lot of people are pushing STM in C/C++).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Not really, PCs had disk drives for many more years. It was only when DVD writers became standards did it stop appearing in models.
Also, what other PC manufacturers even use PPC?
Change is certain; progress is not obligatory.
Alright guys, I know the advantages (and challenges) of multi-threading. With almost all new processors coming with > 1 core, I can tell there's now a huge desire to start making apps that can take advantage of all cores. But my question is why? One thing I love about my quad-core Q6600 is the fact that I can be doing so many things at once. I can be streaming HD video to my TV while simultaneously playing DOOM, for example. However, when I fire up a multithreaded app that takes all 4 of my cores and I start doing something heavy, like video encoding for example, everything tends to slow down like it did back when I only had one core to play with. Yeah, my encoding gets done a lot faster, but honestly I'd rather it take longer than make my computer difficult to use for any period of time...
I realize I can throttle the video encoding to a single core, but I'm just using that as an example... if all apps start using all cores, aren't we right back where we started, just going a little faster? I love being able to do so much at once...
I always read it as "Slow Leopard"
My impression of most Apple users is that they want not to use Microsoft products and do hide inside an elitist little club where there is no need for most of them to be concerned about technical issues. That's fine if that is what they want but those same people should not try to argue with people who do know what they are talking about when it comes to OSes - at least, in my case, when it comes to UNIX, Linux or Windows.
Most Apple people I know are very knowledgeable about other operating systems and make informed choices to use Macs. What does drive us nuts are those who criticize our choices but also freely admit...
I don't use Apple.
and
I know nothing about OSX.