Slashdot Mirror
Jonathan Schwartz Shows 32-Way UltraSPARC Chip
Megaslow writes "The latest entry in Jonathan Schwartz's blog has pictures of Sun's Project Niagra chip, with 8 cores * 4 threads per core for a 32-way computer on single chip. He also shows what looks to be a test rig reportedly already up and running Solaris 10."
Schwartz's blog may not be representative of the general corporate attitude at Sun, but he comes across as bitter and even hostile. Perhaps he is just a passionate believer in his company's work, but his whiney tone smacks of unprofessionalism. I'm not particularly well versed on the continuing saga that is Sun, but should not product performance be speaking for itself? In any case, if they have achieved something noteworthy with this "32-way" chip, I hope they figure out a way to make it useful. This MPR Paper on the processor may be of interest to some.
Part of the hardcore faithful who believed in Apple long before it was cool again to do so
Doesn't mean a damn thing unless software is written to take advantage of it. Damn PC developers can't write software to take advantage of HT (with some exceptions, I know), but hopefully this chip's power can be realized fully.
Why is it that people keep stating that you have to write software that targets HT specifically? This is not true. Any multithreaded application will benefit from it. It is up to the OS to present you with the CPUs, real or virtual.
Yes, there are specific issues with handover during tight spinloops et.c., but only people writing locking or timing code should have to deal with those issues. Not your average application programmer.
Sun has never explained or shown what this Throughput computing is all about. More multi-processors. Yeah, so? You need concurrency mechanisms to exploit it. Pthreads by itself isn't going to hack it. They won't scale up. Even if Sun has "parallelized" Solaris, it's in user space where most of the processing is done and where most of the problems will occur.
Looking at processors like these, they're aimed at the server market. The people who can buy this hardware can afford the licenses. If one of these processors can compete with a 32 processor Sun Fire 12K in a functional sense, do you think Oracle is going to want less money? A count of "processors" presented to the system is as good a way of scaling licenses as any other in the server market.
Licensing probably won't change until everyone has multi core processors. Even then, licensing per "computer" without counting processors is still viable for desktop applications. Licensing is just income. Nobody cares how they do it, they just want to make sure they get as much of it as they can.
Because he must know that Sun is basically finished as a company
Nice to know you have such predictive abilities.
: their hardware is uninteresting and Solaris is uninteresting.
I would have thought that their SMP hardware would be interesting to geeks - unlike the compromised NUMA architecture that lesser Unix boxes run.
Solaris should definitely be of interest to anyone interested in UNIX or Linux - unless features such as partitioning and scalability are dull?
The most annoying and dangerous thing about Schwartz is that he keeps trying to redefine the meaning of "open" and "open source" in order to get Sun's highly proprietary platforms and prducts (e.g., Java) to be more widely accepted.
Java 'Highly proprietary'? Ah - I guess that is why the spec is published, and why GNU can implement Java; why Java is the most in-demand language for IT jobs, and why its so widely targetted on sourceforge.
There is nothing proprietary about Java, only the name, which you must pass compatibility tests to use. Without these compatibility tests, Java would have fragmented years ago.
(and, make no mistake: Sun has tighter legal ownership of Java than Microsoft has of any of their platforms)
Evidence?
Sun already extract a lot of revenue from Java - they use it as their language of preference when the provide software consultancy services (now a significant part of their revenue). There is also J2EE licencing, and J2ME services and partnering.
Most of Sun's application software vendors (CAD/CAM/animation) were busy porting their applications over to multithreaded mode back in the mid 1990's.
Even if an application isn't multithreaded, the window system may very well be. And you can always have all those background processes (clock, TCP/IP, X-server) running on different CPU's, leaving at least one CPU free to run your application without swapping/scheduling out memory.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
This is a SPARC processor. It runs Solaris. The Solaris kernel is fully pre-emptively muti-threaded. Most of the large applications that you buy a big Solaris box to run are also highly mutlithreaded.
The beauty of this design is that there is already a mature, stable and high-performance industry-standard OS for it (Solaris) along with thousands of applications.
You could even probably run Linux on it if you wanted.
Stick Men
Linux runs on Sparc, as does FreeBSD. There's no reason to think that these kernels will not be ported to take advantage of the Niagra architecture. If you don't like solaris, nobody is going to force you to use it (except maybe your customers, if that's what they like).
2. People not happy with big blue can migrate to another vendor without having to take an OS change into account. That means less lock in.
I call FUD on you. Doesn't "big blue" make the Z architecture, OS/390, System/36, etc., which are text-book examples of vendor lock-in? As in all other situations, you choose the system that works best for you. If vendor lock-in is fear for you, get Linux from IBM (or Sun, for that matter).
On the other hand, if you need something that only System/36 or Windows or MacOS or Solaris provides, then you bite the bullet and buy that.
Disclaimer: I work for a company, but I don't speak for them.
You are mistaken. Sun's SunFire systems are NUMA.
You are right in this case, but many Sun systems (including earlier SunFire machines) are SMP.
As far as scalability goes, Linux runs on "lesser" 512 CPU systems, with plans for 1024 and 2048. Solaris is at 144 CPUs. They're the cold, hard facts.
Scalability has nothing to do with the number of processors. Just because you can place a Linux system on that number of CPUs does not mean that it will efficiently make use of them for general purpose use. The large CPU count Linux systems are often for very specialised numerical work where a coder puts in a lot of effort (using specialised libraries) to distribute algorithms. You may be able to use kernel services (such as I/O) from all of those processors, but that doesn't mean it will scale within the kernel (although, in these applications, it doesn't need to).
On the other hand, high-processor count Solaris/Sparc systems are usually more general purpose business machines, running database engines, app servers, web services etc. These hammer the CPUs with unpredictable and varied requests.
The 'I put my OS on more processors that you' argument is very misleading.
I would have thought that their SMP hardware would be interesting to geeks - unlike the compromised NUMA architecture that lesser Unix boxes run.
As others have said, the current generation of big iron Suns (the Sun Fire) is NUMA. You can find details in
Alan E. Charlesworth: The sun fireplane system interconnect, Proceedings of SC2001 (available online if you have an ACM subscription).
While Suns combination of snooping and directory based cache coherency is neat, it nothing revolutionary or so, that other companies would somehow be unable to implement if they wanted to.
If Sun tanks, the world will go on just fine without them.
Solaris should definitely be of interest to anyone interested in UNIX or Linux - unless features such as partitioning and scalability are dull?
For the vast majority of users who have no need for partitioning nor extreme scalability, yes those features are pretty dull. And those who need those features know that Sun isn't the only game in town.
If Sun tanks, the world will go on just fine without them.
HyperThreading presents a virtual CPU - there are the same number of compuational units in the core. The speed advantage from HT is that with threaded code, there is additional silicon to save the state of each thread.
With the same number of execution units, however, you can't get better then optimal for a single non-HT CPU; once all the execution units are full, that's it, whether it's one thread or two.
HT is a great boost for a threaded app where it is not CPU bound in general.
On the other hand, a second CPU carries an aditional set of execution units; that means you can, in theory double the CPU output.
Neither helps with the memory - cpu bandwidth issues, which can limit performance. Dual CPU can mitigate that with dual memory controllers (see, e.g. Opteron), but that has it's own complications.
So, HT is a small step between dual CPU, and dual CPU.
However, even the most optimistic benchmarks from Intel that I have ever seen quote a 30ish% speed increase with HT. I have never, ever, seen anyone claim that HT can give a 100% speed boost - can you reference that claim?
I quote from
http://www.intel.com/business/bss/products/hype