This article describes in detail what to expect from Sun when it comes to the SPARC platform. The 8-core Niagara chip, now planned for early 2006, is the most impressive: "In practical terms, what Niagara delivers is a chip that consumes about 56 watts that has about the same performance on infrastructure workloads as a four-way SMP rig of Xeon processors or a two-way setup using dual-core Xeons. These Xeon setups will consume hundreds of watts per processor."
To read all comments associated with this story, please click here.
Member since:2005-07-06
You're right about that. Threads are not the appropriate abstraction for concurrency. They're just a hack to run multiple sequential processes. What you need is a language based on a concurrent calculus. Basically, your language needs to have some formal way of specifying concurrency, just like current languages have a formal way of specifying types or functions. Such languages aren't even prevalent in academia yet --- the mathematical underpinings (eg: Pi Calculus) are still being worked out.
Member since:2005-07-06
I think the best work around would be if there was some way for the operating system/API or something that can automatically syncronise threads so that the programmer doesn't need to manually do it - same goes for locking; remove the need to manually track everything that is finely grained - then it would be possible to go thread crazy without needing to worry about dead locks and so forth.
Member since:2005-07-07
Well you seem to confuse academics with practicality. Solaris' thread implementation works and scales really well and can make full utilization of Niagara. It probably does this better than any other commercial solution and that is the selling point.
You will find that in the "real world" often the inelegant solution wins. Academic research more often than not just remains that.
Member since:2005-07-06
Well you seem to confuse academics with practicality. Solaris' thread implementation works and scales really well and can make full utilization of Niagara.
The fact that the OS can handle it is great, but doesn't hit the point. The real bottleneck is not the hardware or the OS, but the programmer. Writing concurrent code is difficult, especially in C. Solaris apps can often take good advantage of 128-way Sun machines, because quite often they have a natural unit of concurrency --- a request. As long as their is little interaction between requests, the locking can be kept to a minimum. But that doesn't work for all apps. Consider something like an MMORPG server. Requests aren't independent. Theoretically, any particular connection can affect any other connection. Designing a codebase for something like that which can run on a 128-way Sun machine is much less easy. Multithreaded code, as all the bellyaching about the new multi-core consoles suggests, is not easy to write.
You will find that in the "real world" often the inelegant solution wins. Academic research more often than not just remains that.
Until its stolen by the commercial world 
If you took a (good) languages and translation program in the early 1990s, you can pretty safely predict what will be coming out of the Java and C# teams for the next decade...
Member since:
2005-07-06
There may be some things in the research lab, but today there is no language that handles multi-threading very well. Even simple things end up being very complex.
I have to wonder if "threads" are the appropriate abstraction for concurrency.