[Peabo]

My 8-core 3ghz config just shipped from Apple this morning and they say it will be delivered on or before the 20th of this month. Seems like a long time for shipping, but maybe it's coming from Shanghai again.
(I'm in the UK by the way)

[Leonard]

Originally Posted by schalliol 

Essentially if you want to bring your own monitor, you have to chose between the Mini and the Mac Pro. If you want more than one monitor or any internal expandability beyond swapping components out, you go to the Mac Pro. This is why my mother, who mainly uses email, MS Word and the Web has the base-level Mac Pro. She was able to get it for about $2k after rebates from Mac Mall using the 2.0 chips, so it wasn't so bad. I do think that a $1,200-$1,500 machine would be a sweet spot for many though.

Here's what I think would be nice, with all else as with the Mac Pro:

• Room for up to three hard drives (they don't take that much space)
• Single Optical Drive
• Single CPU (dual-core or quad-core)
• 4 FB-DIMM Slots (one card)
• Single Gigabit Ethernet

Take this to the headless Mac thread / Consumer Mac Tower thread, let's not start the headless Mac or Consumer Mac Tower thread here, Please.

A Mac Pro will always have dual CPUs, so you won't see a Mac Pro with one CPU.

[Xyrrus]

Originally Posted by hmurchison2001 

We're computer enthusiast here. If it was so easy to build a system why didn't you give us some specs and prices? Ahhh see below.

Ah yes and you had to use some "questionable" product as well. We all know you cannot get Mac Pro casing quality for $25. The "I can builld a PC for half the cost" is the early warning shriek of an idiot.

I know I can virtually ignore future posts from fmalone. There will be little actual content and much too much bluster.

Come on, that's not fair. This little subthread started out with the observation that you could build a better "Gaming PC" for about half the price, and then a post was made with quad Xeons and an outdated video card - not the best choices for gaming. Only people with money to burn are going to workstation/server chips into a "Gaming PC"

The 8 core mac pros are fantastic machines, and they are well suited to a lot of tasks. If you're doing the sort of processing that requires 8 cores, I'm sure they'll pay for themselves in a month. But they're not the be all and end all for all people.

-Xy

[hmurchison2001]

Originally Posted by Xyrrus 

Come on, that's not fair. This little subthread started out with the observation that you could build a better "Gaming PC" for about half the price, and then a post was made with quad Xeons and an outdated video card - not the best choices for gaming. Only people with money to burn are going to workstation/server chips into a "Gaming PC"

The 8 core mac pros are fantastic machines, and they are well suited to a lot of tasks. If you're doing the sort of processing that requires 8 cores, I'm sure they'll pay for themselves in a month. But they're not the be all and end all for all people.

-Xy

Yes I tend to be unfair when faced with extreme ignorance. I'm fully aware that the 7300 GPU isn't a gamers ideal solution which is why Apple has BTO for people that need to tailor their computer to their needs. But to come into a thread full of computer users and claim that an equivalent computer can be built for half the cost is assinine. Who do these people think they're talking to? I have 4 computers I know what stuff costs and I know that DIY computers can save money but you are NOT saving %50 and that was quickly disproven. Opinions are welcome and so are relatively civil opinions regarding opinions.

[Amdahl]

Early Performance Texting of the 8 Core Mac Pro

As I suspected, the OS 10.4 is not up to the task of handling 8-cores. The system can be completely pegged and barely beat a quad-core. Better luck with 10.5!

[Xyrrus]

Originally Posted by hmurchison2001 

Yes I tend to be unfair when faced with extreme ignorance. I'm fully aware that the 7300 GPU isn't a gamers ideal solution which is why Apple has BTO for people that need to tailor their computer to their needs. But to come into a thread full of computer users and claim that an equivalent computer can be built for half the cost is assinine. Who do these people think they're talking to? I have 4 computers I know what stuff costs and I know that DIY computers can save money but you are NOT saving %50 and that was quickly disproven. Opinions are welcome and so are relatively civil opinions regarding opinions.

The original statement was

Mac Pro for games? You can build a much better gaming PC for half the price.

That is true.

It is also true that is is effectively impossible to match the quality and performance of a Mac Pro for "work" tasks by going with a Windows OEM or by building it yourself.

These aren't contradictory statements in the least.

-Xy

[hmurchison2001]

This is true and a frying pan can cook eggs much better than the Mac Pro for 1/100th of the cost.

That's a gross example of taking a thread outside of the context but when everyone is discussion 8 core product it's a bit diversionary to chime in with what PC options are available when the topic of the thread is 8 Core. The Mac Pros make excellent gaming machines in addition to other workstation class features. If money was the issue then we'd just get an iMac with discrete graphics.

[Leonard]

Originally Posted by hmurchison2001 

The Mac Pros make excellent gaming machines in addition to other workstation class features. If money was the issue then we'd just get an iMac with discrete graphics.

That's what I plan oon using mine for half the time, when I buy it.

[Eug]

8-core box opening pix

3GHZ Dual Quad for a total of 8 cores - 4GB RAM - X1900 XT Graphics Card - Dual SuperDrives and twin 500GB hard drives...Bluetooth and Airport of course.

---

Originally Posted by Amdahl 

Early Performance Texting of the 8 Core Mac Pro

As I suspected, the OS 10.4 is not up to the task of handling 8-cores. The system can be completely pegged and barely beat a quad-core. Better luck with 10.5!

While OS X 10.5 may be better than 10.4 for multi-core on some tests, it really depends on the app. This is a pretty significant increase on 10.4 for the 8-core vs. the 4-core for Cinebench, and in line with what I expected:



For reference, my machines:

iMac C2D 2.33: 727
MacBook CD 2.0: 578
iMac G5 2.0: 268
Cube G4 1.7 7447A: 150 <--

BTW, a Quad G5 2.5 gets about 1100.

[Leonard]

Originally Posted by Amdahl 

Early Performance Texting of the 8 Core Mac Pro

As I suspected, the OS 10.4 is not up to the task of handling 8-cores. The system can be completely pegged and barely beat a quad-core. Better luck with 10.5!

The article hardly says that. If 10.4 didn't handle 8 cores you wouldn't see the improvements you see in Cinebench and Geekbench. These apps have to run UNDER 10.4 you know, they just don't magically run on their own. What their review does say, is that you'll see a speed increase depending on the apps you use.

Eug beat me to the puch it looks.

[Amdahl]

Originally Posted by Leonard 

The article hardly says that. If 10.4 didn't handle 8 cores you wouldn't see the improvements you see in Cinebench and Geekbench. These apps have to run UNDER 10.4 you know, they just don't magically run on their own. What their review does say, is that you'll see a speed increase depending on the apps you use.

Of course the article doesn't say that! I'm saying it!

Yes, the speed drag is dependent on the app; but they are all dependent on the OS. The apps that really need the cache and memory bandwidth suffer more than those that don't because the OS doesn't schedule threads on CPUs in an efficient manner.

How else do you explain a system that runs at 795% CPU load and hardly moves any faster than a quad-core?

[Eug]

Originally Posted by Amdahl 

Of course the article doesn't say that! I'm saying it!

Yes, the speed drag is dependent on the app; but they are all dependent on the OS. The apps that really need the cache and memory bandwidth suffer more than those that don't because the OS doesn't schedule threads on CPUs in an efficient manner.

How else do you explain a system that runs at 795% CPU load and hardly moves any faster than a quad-core?

Some of the apps in question don't scale well in the first place. Photoshop is a prime example. For many actions in Photoshop, performance scaling from even just 2 cores to 4 cores is virtually nil.

[hmurchison2001]

Hence we need an Apple created Photoshop competitor CS3 doesn't seem to be all htat much better on the multithreading front.

Developers better get savvy on this. I'm thinking that Nehalem will offer up to 16 threads a proc (via SMT) so it's likely we'll see systems capable of 32 threads.

[Amdahl]

Originally Posted by Eug 

Some of the apps in question don't scale well in the first place. Photoshop is a prime example. For many actions in Photoshop, performance scaling from even just 2 cores to 4 cores is virtually nil.

That's not the case in these benchmarks. If an app can't utilize more cores, it would have a lower % CPU load. These tests came just shy of 800%; that means they are making full use of all 8 cores.

The problem is in the OS.

[mduell]

Originally Posted by hmurchison2001 

Hence we need an Apple created Photoshop competitor CS3 doesn't seem to be all htat much better on the multithreading front.

Aperture doesn't scale well from 4 cores to 8 cores either.

[mitchell_pgh]

Originally Posted by Amdahl 

The problem is in the OS.

You are simplifying the issue... it's not just the OS, it's the applications as well. Developers need to aggressively multi-thread their applications to take advantage of additional CPUs. Without that, we aren't going to see the multi-cpu systems scream.

[Amdahl]

Originally Posted by mitchell_pgh 

You are simplifying the issue... it's not just the OS, it's the applications as well. Developers need to aggressively multi-thread their applications to take advantage of additional CPUs. Without that, we aren't going to see the multi-cpu systems scream.

No, you're simplifying the issue. It is not a problem of insufficient concurrency being provided by the application. The 8-core is screaming. It just isn't going anywhere.

[Eug]

I am not a developer, but it seems like an oversimplification to blame it all on the OS's granularity or whatever, especially when other apps do just fine over 8 cores.

[Amdahl]

Originally Posted by Eug 

I am not a developer, but it seems like an oversimplification to blame it all on the OS's granularity or whatever, especially when other apps do just fine over 8 cores.

No one ever said multiprocessing was easy, except the ones who don't understand it.

[Eug]

We'll have to see once 10.5 comes out, since it's supposedly finer-grained.

I suspect several of those apps still will not perform much better on 8-core vs. 4-core Macs.

[Amdahl]

Originally Posted by Eug 

We'll have to see once 10.5 comes out, since it's supposedly finer-grained.

I suspect several of those apps still will not perform much better on 8-core vs. 4-core Macs.

Yes, we'll see if 10.5 is better. (God help Apple if it isn't.)

But being finer-grained is not the problem. The problem is in the kernel scheduler. I believe 10.5 will be better, because I believe Apple had originally expected to have Leopard ship with the 8-core. They need the money now, so the 8-core had to go out the door without the proper software.

[Eug]

Originally Posted by Amdahl 

Yes, we'll see if 10.5 is better. (God help Apple if it isn't.)

But being finer-grained is not the problem. The problem is in the kernel scheduler. I believe 10.5 will be better, because I believe Apple had originally expected to have Leopard ship with the 8-core. They need the money now, so the 8-core had to go out the door without the proper software.

I have a different take on that.

Despite the fact that the 8-core is probably useless for most Photoshop jockeys for example, I betcha several will buy the 8-core anyway, just because they can. Apple will want to capture that market. So there I agree with you.

However, Apple WANTS the 8-core to ship before Leopard because that gives the pro users the option of using either OS. If their workflows demand Tiger, then they can use Tiger. If they can use Leopard, then great.

If the 8-core had shipped with Leopard, then Apple would have had to make an exception to their usual OS support rules to officially support Tiger running on them. Yeah, that's easy enough to do, but releasing Leopard before the 8-core is simpler.

P.S. For these reasons, I'm guessing it's possible that Leopard may actually come out in the next month instead of at WWDC. And then the new Santa Rosa iMac will quickly follow, shipping with Leopard (and not supporting Tiger at all).

[hmurchison2001]

Originally Posted by mduell 

Aperture doesn't scale well from 4 cores to 8 cores either.

I know. I trust that Aperture 2.0 though will be more threaded under Leopard than Adobe CS3. I believe non-destructive "recipe" editing is the future as GPU get faster and offer more complex programming it becomes a no brainer. Besides it's never good to have a monolithic way of computing. I'm tired of Office and Photoshop clones.

Originally Posted by mitchell_pgh 

You are simplifying the issue... it's not just the OS, it's the applications as well. Developers need to aggressively multi-thread their applications to take advantage of additional CPUs. Without that, we aren't going to see the multi-cpu systems scream.

You both are correct. Threading is already innate to OS X Tiger. Developers can can improve things be implicitely supporting threads in their applications and with Leopard Apple has added more support for dependencies. A classic Good/Better/Best scenario.

Eug - I hope that the next iMac moves to a dual core Conroe based system. The iMac needs to move off of laptop parts IMO.

Developers may as well begin to architect their applications for multi-core and threading. Nehalem's threading is going to make today's procs look prehistoric. Better get your threading chops down now if you want to keep up with the Jones'

[Amdahl]

Originally Posted by hmurchison2001 

Developers may as well begin to architect their applications for multi-core and threading. Nehalem's threading is going to make today's procs look prehistoric. Better get your threading chops down now if you want to keep up with the Jones'

Developers should only thread if it is easy for them to do so; if it isn't real easy, it would be better to look at alternatives such as OpenMP. I imagine that Apple will soon ship a version of gcc in Xcode that supports it.

The following paper by Berkeley's Chairman of the EE Dept. & Associate Chair of the CS department thinks that threads are a mistake for most application development because they are too hard to get right, or even to debug. He says only the most expert developers should use them, based on bugs that remained in software that had previously been determined by himself and other experts to be bug-free: http://www.eecs.berkeley.edu/Pubs/Te...ECS-2006-1.pdf

[hmurchison2001]

Apple's already moving forward. NSOperations and NSOperationsqueue prioritize your task. All you need do as a developer is figure out what you want to have priority and the API handles the dependencies and locking.

[Amdahl]

Originally Posted by hmurchison2001 

Apple's already moving forward. NSOperations and NSOperationsqueue prioritize your task. All you need do as a developer is figure out what you want to have priority and the API handles the dependencies and locking.

Never heard of it, and can't find any reference to it. Whatever it is, creating another API is not the answer. Concurrency is a language problem.

OpenMP is still the way to go for the average developer who just needs to get some multi-core support. You don't even have to figure anything out. It is similar to the compilers that automatically detect opportunities to provide Altivec or SSE support.

[hmurchison2001]

Originally Posted by Amdahl 

Never heard of it, and can't find any reference to it. Whatever it is, creating another API is not the answer. Concurrency is a language problem.

OpenMP is still the way to go for the average developer who just needs to get some multi-core support. You don't even have to figure anything out. It is similar to the compilers that automatically detect opportunities to provide Altivec or SSE support.

I can already see a bit of a problem with OpenMP. You have to have compiler support and it's C/C++ only I believe. If given the option to use OpenMP or NSOperation which is Cocoa I think you'll find Mac developers choosing NSOperation almost every time.

[Chuckit]

Originally Posted by Amdahl 

Never heard of it, and can't find any reference to it.

I think it's still technically NDA'd, though the info is freely available to all and sundry. Sign up for a free online ADC account and check out the Mac OS X State of the Union at Apple Developer Connection - ADC on iTunes.

Originally Posted by Amdahl 

Whatever it is, creating another API is not the answer. Concurrency is a language problem.

You don't even know what you're arguing against. If an API offers an easy and powerful way to fix the problem, it is an answer.

Originally Posted by Amdahl 

OpenMP is still the way to go for the average developer who just needs to get some multi-core support. You don't even have to figure anything out. It is similar to the compilers that automatically detect opportunities to provide Altivec or SSE support.

Who the **** "just needs to get some multi-core support"? Some marketing guy who wants to stick it on the product's box? I'd much rather have an easy way to actually optimize my app for SMP.

[Simon]

No matter if you blame the OS or the apps, the fact that if both MPs are using ~400% and ~800% CPU respectively yet the latter is only a few percent faster at finishing the task something is indeed wrong.


From BareFeats.

There's a nice post here which suggests there might well be a memory bottleneck. 350 MB/s memory copy speed per core sounds like a pretty low amount for a memory intensive app like PS. Core Swapping also seems to be a real issue with Tiger which indeed points toward a flaw that could likely be fixed by Leopard.



"It seems clear that Mac OS X 10.4 has not been adequately optimized for even 4 cores; perhaps Mac OS X 10.5 will improve matters."

[Amdahl]

Originally Posted by hmurchison2001 

I can already see a bit of a problem with OpenMP. You have to have compiler support and it's C/C++ only I believe. If given the option to use OpenMP or NSOperation which is Cocoa I think you'll find Mac developers choosing NSOperation almost every time.

OpenMP is not tied to C/C++; any language can use it. It does require compiler support. Solaris has it; newer versions of gcc has it; Microsoft C++ has it. It's already everywhere.

Now it is just a matter of developers getting off the threading kick and actually getting something done.

[Amdahl]

Originally Posted by Chuckit 

You don't even know what you're arguing against. If an API offers an easy and powerful way to fix the problem, it is an answer.

Yes I do. I'm arguing against an API. APIs can't fix the concurrency problem. It is a language problem.

Who the **** "just needs to get some multi-core support"? Some marketing guy who wants to stick it on the product's box? I'd much rather have an easy way to actually optimize my app for SMP.

Sounds like you want OpenMP.

[hmurchison2001]

Originally Posted by Amdahl 

OpenMP is not tied to C/C++; any language can use it. It does require compiler support. Solaris has it; newer versions of gcc has it; Microsoft C++ has it. It's already everywhere.
Now it is just a matter of developers getting off the threading kick and actually getting something done.

http://en.wikipedia.org/wiki/OpenMP

The OpenMP (Open Multi-Processing) is an application programming interface (API) that supports multi-platform shared memory multiprocessing programming in C/C++ and Fortran on many architectures, including Unix and Microsoft Windows platforms. It consists of a set of compiler directives, library routines, and environment variables that influence run-time behavior.
Jointly defined by a group of major computer hardware and software vendors, OpenMP is a portable, scalable model that gives programmers a simple and flexible interface for developing parallel applications for platforms ranging from the desktop to the supercomputer.
Often a so-called hybrid-model for parallel programming, programming in computer clusters can be done using both OpenMP and MPI (Message Passing Interface) simultaneously.

Apple using OpenMP would be redundant IMO. NSOperation does the heavy lifting regarding thread forking and concurrency and Apple controls it directly which means updates to it can be reflected in Xcode. My guess is it gets another big boost for 10.6 so that SMT is handled properly. OpenMP looks fantastic for HPC needs but a wee bit overkill for developers honestly.

[Chuckit]

Originally Posted by Amdahl 

Yes I do. I'm arguing against an API. APIs can't fix the concurrency problem. It is a language problem.

Mere assertion. I have seen NSOperation handle concurrency, so I'm going to go with my observations over your unfounded claims.

Originally Posted by Amdahl 

Sounds like you want OpenMP.

According to OpenMP's Web site, it's an API, so it's obviously incapable of solving the concurrency problem, right?

[Amdahl]

Originally Posted by Chuckit 

According to OpenMP's Web site, it's an API, so it's obviously incapable of solving the concurrency problem, right?

Whether something is a language feature or a library, it all ends up as binary machine code.

It's an API only in the sense that it isn't built in to the microprocessor. In any design sense, it is a compiler language extension.

[hmurchison2001]

OpenMP look fine but I don't think I'm seeing anything that it contains that I won't be able to do easily with NSOperation.

My suggestion is to go to developer.apple.com sign up for the free "Online" ADC account and download the "OS X State of the Union" address on iTunes. You'll see that OpenMP isn't going to happen in OS X and that it's redundant.

Intel is moving to a highly threaded architecture with Nehalem in late 2008. I'm not sure I'm buying into the argument that threading is too difficult when clearly Intel will have the proper tools to manage dealing with 8-core Nehalem procs with 2 threads per core. We could see 16-core Mac Pro with 32 threads. Apple will likely evolve NSOperation to handle dealing with more and more threading while keeping things simple for developers. That's their modus operandi.

[Amdahl]

Originally Posted by hmurchison2001 

You'll see that OpenMP isn't going to happen in OS X and that it's redundant.

Os X doesn't have to support it; it's a compiler feature. Gcc already has it; the only way Apple doesn't include it is if they actively decide to remove it.

Intel is moving to a highly threaded architecture with Nehalem in late 2008. I'm not sure I'm buying into the argument that threading is too difficult when clearly Intel will have the proper tools to manage dealing with 8-core Nehalem procs with 2 threads per core. We could see 16-core Mac Pro with 32 threads. Apple will likely evolve NSOperation to handle dealing with more and more threading while keeping things simple for developers. That's their modus operandi.

I'm sure they will do their best to provide a simple API; but there really is no such thing. Even Java failed at it. The reason OpenMP is the solution is that it is a compiler feature; the compiler knows things about the state of variables and data structures that a thread API can not know. It is these issues of state that are the heart of the threading problem. That means you have a better solution if you have the compiler assistance.

[Chuckit]

Originally Posted by Amdahl 

I'm sure they will do their best to provide a simple API; but there really is no such thing.

Since you are an expert on NSOperation, I'd be fascinated to see your detailed analysis of how it fails.

Originally Posted by Amdahl 

Even Java failed at it.

"Even" Java? Java's APIs are the most complicated and bloated creature imaginable.

Originally Posted by Amdahl 

The reason OpenMP is the solution is that it is a compiler feature; the compiler knows things about the state of variables and data structures that a thread API can not know. It is these issues of state that are the heart of the threading problem. That means you have a better solution if you have the compiler assistance.

Specifically what about "the state of variables and data structures" needs to be known at compile-time in order to make concurrency easy to program for?

[hmurchison2001]

After further perusal it's clear that OpenMP is aimed at scientific needs versus your typical desktop application. Most of the Fortran compiliers have support for OpenMP. When you start talking about MPI you're talking about a wholly different demographic than the developer that just wants to add a bit of dependencies and core affinity.

I do think Apple should support OpenMP for their Biotech and Science focus. If it's in GCC then it probably works but just doesn't have a Mac GUI.

Yup found out you can get GCC 4.3 with Auto-vectorizing and OpenMP support.
High Performance Computing for Mac OS X

Also as I expected Intel isn't sitting still either. Nehalem will require a new approach to threading and parallelization and here is what looks to be Intel's initiative for improvements.

Intel Threading Building Blocks
http://www.intel.com/cd/software/pro...eng/294797.htm

Originally Posted by Intel

Intel® Threading Building Blocks (Intel® TBB) 1.1 is an award-winning C++ runtime library that abstracts the low-level threading details necessary for optimal multi-core performance. It uses common C++ templates and coding style to eliminate tedious threading implementation work.

Now you can thread like an expert without being one. Intel® TBB requires fewer lines of code to achieve parallelism than other threading models. The applications you write are portable across platforms. Since the library is also inherently scalable, no code maintenance is required as more processor cores become available.

TBB is supposed to co-exist with other threading tools as well so if you wanted to use OpenMP along with it that should work. Apple will likely leverage more of these tools in future OS X versions. NSOperations is a nice start.

[Chuckit]

Originally Posted by hmurchison2001 

Apple will likely leverage more of these tools in future OS X versions. NSOperations is a nice start.

More to the point, with an abstract API like NSOperation to handle the details for you, you can get the benefit from new technology for free.

[Amdahl]

Originally Posted by Chuckit 

Specifically what about "the state of variables and data structures" needs to be known at compile-time in order to make concurrency easy to program for?

The compiler+linker knows whether a variable is being accessed from other modules in the program, and that can help it decide whether a variable can be stored in a register on the CPU, or needs to be written out to memory immediately. If the variable is being used in multiple threads, it knows it can't keep it in the CPU register.

There are a lot of things the compiler and linker can do to help ensure safety in multithread operation. No API can do it. That's why NSOperations fails. It's why Java failed; they built threading in to the API, they built it in to the VM, but they forgot to build it in to the essentials of the Java language itself.

[Amdahl]

Originally Posted by hmurchison2001 

After further perusal it's clear that OpenMP is aimed at scientific needs versus your typical desktop application.

That is the wrong conclusion to make. OpenMP is aimed at Computationally intense applications. This means all kinds of media apps that Macs are supposedly targeted at.

Intel Threading Building Blocks
http://www.intel.com/cd/software/pro...eng/294797.htm

Thread Building Blocks is a multi-threaded library, and it is a great idea too. It is like multi-threaded OpenGL. The programmer doesn't have to know about the threads, you just call the functions and they will run faster at sorting a list, or whatever it is. OpenMP is very similar, except it functions down to the code loop level; there doesn't have to be a pre-written function that does what you're trying to do.

[Chuckit]

Originally Posted by Amdahl 

The compiler+linker knows whether a variable is being accessed from other modules in the program, and that can help it decide whether a variable can be stored in a register on the CPU, or needs to be written out to memory immediately. If the variable is being used in multiple threads, it knows it can't keep it in the CPU register.

That sounds completely orthogonal to what NSOperation does. NSOperation could be implemented on top of that and the only difference would be a possible minor speed increase.

Originally Posted by Amdahl 

There are a lot of things the compiler and linker can do to help ensure safety in multithread operation. No API can do it. That's why NSOperations fails. It's why Java failed; they built threading in to the API, they built it in to the VM, but they forgot to build it in to the essentials of the Java language itself.

"Failure" is determined by whether or not something actually accomplishes a purpose. Your earlier quote makes me wonder whether you actually understand the purpose here. The purpose is not to make generated multithreading code more efficient — the purpose is to make it easy to write programs that can make good use of several processors. Having slightly less efficient generated code is not "failure" — it's room for optimization.

[Amdahl]

Originally Posted by Chuckit 

"Failure" is determined by whether or not something actually accomplishes a purpose. Your earlier quote makes me wonder whether you actually understand the purpose here. The purpose is not to make generated multithreading code more efficient — the purpose is to make it easy to write programs that can make good use of several processors. Having slightly less efficient generated code is not "failure" — it's room for optimization.

I haven't been concerned with efficiency at all; it is getting rid of threads that is the goal.

My perspective is that the goal is to make it easy to produce parallel code that doesn't have threading bugs. The ultimate way to manifest that is in the programming language. Directly using threads is like programming in assembly; capable of great speed, but demanding more of the programmer -- too much in the majority of cases. The majority of the software today is not written in assembly; and the majority is not going to directly use threads either. Any API which expects the programmer to be aware of and have to make locking decisions is a failure; if there are no threads exposed (like OpenMP or Intel thread builder), then success is achieved.

A good example in the real world would be SQL at the serializable transaction level: The SQL programmer doesn't have to get the locking right, because that was found to be too hard. Instead, the SQL programmer just needs to be ready for a do-over. The SQL engine will detect if any locking conflicts happen during the transaction and abort the transaction if one occurs. In this model, average programmers can get their work done safely, and expert SQL programmers can do the direct locking that would prevent conflicts in the first place if they need to.

[Chuckit]

Originally Posted by Amdahl 

Directly using threads is like programming in assembly; capable of great speed, but demanding more of the programmer -- too much in the majority of cases. The majority of the software today is not written in assembly; and the majority is not going to directly use threads either. Any API which expects the programmer to be aware of and have to make locking decisions is a failure; if there are no threads exposed (like OpenMP or Intel thread builder), then success is achieved.

I admit I don't have Leopard, but from what I have seen of NSOperation, it seems to fit the criteria you are describing. Have you seen evidence to the contrary?