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.”
Well I like the direction Niagara it is going in too, pervasive threading but I would go further in threading the memory system too and then even further after that.
Tidbit the architect of the NexGen686 and AMD Athlon later did a VC stint and helped get Afara (Niagara startup) off the ground. He then did the same thing again with the MIPs architecture. They both uses 8 cores 4 way threaded. He also has some inside comments on Athlon and Pentium in general, they both idle most of the time.
These 2 designs are designed not to idle or atleast to reduce that 4 fold or so.
http://www.razamicroelectronics.com/
I know they wanted to benefit from the economy of scale of using a mainstream cpu, but too bad Apple didn’t switch to THAT instead. My next Mac can also be used as a heater probably..
Visit South France – http://www.visitsouthfrance.com/
there is no operating system + language + tools that really works well with threads.
as usual the hardware is far beyond the software.
there is no operating system + language + tools that really works well with threads.
Ah, but that’s where you’re wrong. Solaris 10 along with SUN Studio provides an excellent set of tools. The OS itself scales with great efficiency to hundreds of processors. DTrace, dbx, mdb, are all available to help you when debugging and analyzing applications. Documentation is plentiful, and examples are numerous.
hybrid transactional memory addresses those issues
http://scholar.google.com/scholar?q=hybrid+transactional+memory&ie=…
Yeah, the SPARC lineup has been getting stale. Especially on the low end, where they still sell 550 and 650 MHz UltraSPARC IIis that were introduced in 2002, and even back then were slow.
would beos benefit from multhreaded cpu’s?
If each Xeon is well over 100 watts, Niagara is easily 8 times more power efficient. This is some seriously important technology for data centers and web farms!
Data centers always have had those gigantic air conditioning units, which themselves cost a pretty penny plus they suck lots of electricity.
It also shows how Intel has been leading the world in marketing fluff but ignoring other environmental concerns and secondary costs.
Sun is really poised to top Intel this round, especially when supplemented with Opteron. Kinda makes me nostalgic for the Sun of the early 1990s–their pizzaboxes are _still_ useful computers.
It also shows how Intel has been leading the world in marketing fluff but ignoring other environmental concerns and secondary costs.
Yeah when i design an application platform my first concern is will this polute the air? or will the BTU’s the server kickout contribute to the mankind impacted Global Warming Myth?
All the power usage saved from the processors with be used up with fans keeping the thing cool.
All the power usage saved from the processors with be used up with fans keeping the thing cool.
Hmmm…. If the thing consumed less power basic logic dicatates that it will run cooler… then why would you need that many fans???!!!
Yeah, the SPARC lineup has been getting stale. Especially on the low end, where they still sell 550 and 650 MHz UltraSPARC IIis that were introduced in 2002, and even back then were slow.
Have a look at Fujitsu’s SPARC64 line. Fujitsu’s PRIMEPOWER 2500 with 128 2.08GHz SPARC64 V CPUs, is the current recordholder on the SAP benchmark (http://www.sap.com/benchmark)
>Have a look at Fujitsu’s SPARC64 line. Fujitsu’s >PRIMEPOWER 2500 with 128 2.08GHz SPARC64 V CPUs, is the >current recordholder on the SAP benchmark >(http://www.sap.com/benchmark)
oh yeah – really impressive! especially since a 64way power5 box has a result just a few percent below.
“Fujitsu’s PRIMEPOWER 2500 with 128 2.08GHz SPARC64 V CPUs”
(looks in wallet) … uh, will you accept a personal check? Just don’t cash it until 2198…
What happened to the silicon germanium that was supposed to be the next new thing in chips ?
cool!! Wonder if they got anything new on the workstation side
“Yeah when i design an application platform my first concern is will this polute the air? or will the BTU’s the server kickout contribute to the mankind impacted Global Warming Myth?”
It should be, because electricity is not free. People have cited the vast numbers of computers and monitors running in California as a contributor to their power problems a few years back.
One thing Sun has always done is design CPUs with respectable power consumption. IIRC, the UltraSPARC II was generally under 20 watts, the UltraSPARC III is 60 to 70 watts or so, the UltraSPARC IV is about 100. I’ve seen mentions that Intel’s CPUs are 120 watts *typical* consumption and POWER 5 is even higher, while Sun posts *maximum* consumption, like AMD does. Niagara brings the top-end back under 60 watts, which is good.
I know Sun cites Niagara as useful for web servers, etc., but what about Sun Ray servers? Desktops use is mostly integer, anyway, so most people wouldn’t even notice that these CPUs aren’t strong in FP.
If Niagara is useful for Sun Ray, then that would be a server with a 56 watt CPU (plus other stuff like RAID and backup…say a kilowatt total in the server room) coupled with 15 watt thin clients. That puts running the office ceiling lights as a far greater expense than running the computers!
“People have cited the vast numbers of computers and monitors running in California as a contributor to their power problems a few years back.”
No, it turns out the “power problems” were due mostly to a bunch of a$$holes in Enron and their power gauging.
Electricity price is not the limiting factor to modern microprocessors… the problem is that at this point the power density of current silicon designs may approach a nuclear reactor (when heat output is compared). Hot silicon is not happy, that is the main problem. Nothing to do with the expense of running a computer….
Even if you were able to exponentially increase power in order to get even minor performance gains, it would still make the total wattage of systems impractical at some point. Not only would the cooling costs become exorbitant, the overall costs of power consumption for the servers would become a factor as well. The cost of system wattage is already a factor when considering that systems have become packed more and more densely within a given space.
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.
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.
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.
The thing is, there is no way for the operating system to automatically synchronize threads. The operating system doesn’t have enough information to know when two threads should be serialized. This is a job that has to be solved in the compiler. Unfortunately, the compiler (with existing languages) does’t know that either, since current languages don’t express anything about concurrency. For example, let’s pretend you changed C semantics so everything would run in parallel unless they needed to be serialized. Now, consider these two functions:
do_foo(int* buf) { for(int i = 0; i < 10; ++i) buf[i]++;}
do_foo2(int* buf) { for(int i = 0; i < 10; ++i) buf[i]+=2;}
do_foo(buf1);
do_foo2(buf2);
Now, both calls might be able to run in their own (lightweight) thread. The semantics could be very clear in the programmer mind — he could intend that the contents of buf1 are incremented by 1, and the contents of buf2 are incremented by 2. But the compiler has no way of knowing that? buf1 and buf2 could even point to the same array, and what the programmer really wants to do is increment its contents by 3!
That’s why new language constructs are necessary. API hacks aren’t going to cut it.
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.
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…
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.
Exactly. Handholding a programmer makes lazy programmers not better ones. Just like driving purists hate automatic driveraids.
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.
I thought the natural unit of concurrency in Solaris was a thread. There is no written rule that Apps on Solaris must be written in C. Any langauge even VM based ones that can enable concurrency implictly need the OS to schedule threads effectively.
Taking a naturally threaded language and serializing it is probably just as difficult or more difficult than the otherway around.
Considering that the platform that SUN has and will always push is Java, I wouldn’t be surprised to see heavily threaded J2EE screaming on these machines.
Another interesting side is what is going to happen with their SPARC based workstations; are they still going to be produced? concerntrate Opteron on the workstation, small to large servers, volume sales, and simple keep the SPARC64/Niagara for the enterprise servers?
It would be nice if SUN gave us (the unwashed masses) a nice road map as to where SPARC64, Niagara, Opteron and so forth fit into the grand scheme of things.
“… there is no language that handles multi-threading very well.”
Actually, all we need is Solaris. IIRC, Solaris allocates a thread to each process and schedules them, making no real distinction between processes and threads, other than that threads are lighter-weight. This means simply loading up a Niagara server with lots of jobs to do (e.g., fork-style Apache) should scale very nicely.
“oh yeah – really impressive! especially since a 64way power5 box has a result just a few percent below.”
If memory serves me right, the Fujitsu Sparc chip is a single-core processor while the Power5 is a dual core processor. That would mean that the 64way power5 box is basically an 128 cpu machine.
The current state of affairs in modern mainstream programming languages… is as Rayiner has stated, including that part about stealing 😉
The big thing about Java and .NET is the GC-centric memory programming model. Even more than the initial simplified OOP models (that today are no longer simple).
However, the next big thing for a language will be concurrency.
One could also make a case for XML or database being the next big thing, but there are many ways of doing XML and database today that basically get the job done. Not well, not elegantly, but done.
There is nothing good in a mainstream language for concurrency.
Maybe Bjarne should work on “C with Concurrency” next so that the concurrency toolkit gets done and then others can copy it and simplify it.
I really don’t think Bjarne or Anders or James are the right guys to do concurrency right, they all did it wrong before or ignored the issue. Bjarne has already done enough damage on the sequential model in that IMO C++ is already too big and does not mesh with concurrency. C++ lets you build walking dead programs.
A decent concurrent language will emerge that plays communicating sequential processes with object management, it will probably use C style syntax, what it will be called I can only guess at. Such a language also needs a better cpu organisation than even these threaded engines, its the memory system that actually matters more, where is the object in memory protection?
There have been conncurent systems before, my moniker is a clue to that, and there will be again.
The Niagara and other threaded cpus like Raza and Ubicom are currently aimed at applications areas (throughput andembedded) that already have some sort of concurrent solution in mind.
For these threaded cpus to offer 32 or even more disposable threads to to the wider software community will require a more formal approach to concurrency where it just works is the norm.
BTW, most all hardware description languages are fully concurrent “and just work” when used by EEs to design hardware. If hardware and software look the same in some domains, there’s a clue there.
To implement large scale “just works” concurrency, it will take more than just a new programming language.
I have some designs from CY2000 that are similar to what is now being done by Raza’s MIPS system and possibly Niagara.
However, the programming language for what I designed is like nothing (mainstream) that exists today. It is more a special kind of algebra.
Which reminds me. Patents, patents, patents. So when Microsoft steals, they will pay.
Links please on this language!
“If memory serves me right, the Fujitsu Sparc chip is a single-core processor while the Power5 is a dual core processor. That would mean that the 64way power5 box is basically an 128 cpu machine.”
Wrong! In IBM POWER4/5 speak, a core is a cpu. So if you compare core-for-core, the Fujitsu box isn’t that impressive, especially considering when each was released.
http://www.redbooks.ibm.com/redbooks/pdfs/sg249119.pdf