SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : All About Sun Microsystems -- Ignore unavailable to you. Want to Upgrade?


To: Prognosticator who wrote (44363)8/4/2001 3:02:46 PM
From: QwikSand  Read Replies (2) | Respond to of 64865
 
Ok...so the point remains that applications don't really have "inherent" thread-level parallelism in the sense that it happens without the programmer knowing or caring about it, as instruction-level parallelism does in Itanic. To take advantage of thread-level parallelism, an application has to be built that way. That means that, for example, the advantages of USV architecture would indeed extend to a C++ program that was coded using, e.g., pthreads. Java isn't the only language that can take advantage of this architecture, it's just easier to develop concurrent programs in Java.

And, as you point out, it will definitely accelerate Solaris itself, which long ago departed from the old Unix monolithic-kernel model and became a fully threaded kernel, which means it can take full advantage of SMP machines (which is what the USV really is on the micro level right...except I don't understand the memory architecture...how do you keep 1000 symmetric cores from saturating a single memory?). This is significant because many big applications spend most of their time in system calls, and the ones that don't are threaded.

Extrapolating recent performance, it will be remarkable if and when Sun and TI/ whoever get this device built and shipping. How do you get good yield on a single wafer with 1000 complex processor cores on it...put 2,000 cores on it and expect half of them to be bad??? Dat'sa some spicy interconnect! And I don't agree that they have until 2010, because 10 years in the computer business is beyond anyone's predictable event horizon. But if they actually manage to do it in some reasonable timeframe like five years, while Intel follows the risky Itanic route, I agree this USV thing could be a win of proportions that Wall Street analysts certainly don't comprehend (not that they comprehend much of anything).

It's GOOD to distribute the parallelism burden onto the programmers a little bit instead of trying to build a super complex chip and a super smart compiler. Let programmers work a little to decide which macro pieces of their programs should run at the same time, and then just run them at the same time. Simple and straightforward. Better than trying to get a super-compiler to line up 16 things for the CPU to do and then get it stalled out if one thing happens unexpectedly out of order. We shall see how big a disaster the Itanic is for Intel.

In the mean time, while that USV architecture is encouraging, I, and I think anybody, has to take the usual "believe it when I see it" stance. Thank you for the information. I have to read about this architecture. Are there any links?

--QS



To: Prognosticator who wrote (44363)8/5/2001 3:09:39 PM
From: Joseph Pareti  Respond to of 64865
 
Re C/C++ never managed to come up with a standardized threads API, and tools to debug multi-threaded C/C++ code are hampered by the code being executed directly by the CPU, not a virtual machine.

That's why C/C++ is ages faster :-)
re. lack of standard threads i/f, how about OpenMP or posix threads? Or how about the kap-pro tools of Kuck and associates for debugging and performance enhancement ? (now an Intel company)