Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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: Charles Tutt who wrote (44355)	8/3/2001 4:49:53 AM
From: QwikSand	Read Replies (2) \| Respond to of 64865

Point A: That's all very nice if the real schedule falls in the same millenium as the roadmap. Point B: I've been out of things technical long enough that I don't have a sense of the burden a thread-parallel CPU imposes on programmers. We know about Itanic putting most of the burden on the compiler. That's bad for the compiler writer, but good for the programmer who doesn't have to care about processor-level parallelism (and couldn't if he had to). Now I know there are, or at least have been, compilers that try to parallelize ordinary C code or Java or whatever to create concurrency at the thread level (not the instruction level) even if the programmer doesn't explicitly multithread the program. So my question is: does this Ultra V architecture benefit ordinary monolithic programs, or only those that have been written as a set of explicitly concurrent tasks using thread API's? That is, does it place the onus on the programmer to re-code applications for threads, or does it require another set of supersmart compilers? Both of those alternatives sound like things that can get screwed up really bad, just by different people. --QS Edit: Or does it just mean the operating system can set up the processor to do zero-overhead "frictionless" context switches among processes?