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: Richard M. Smith who wrote (5404)	11/8/1997 5:02:00 PM
From: gordon	Respond to of 64865

>>Sun has really shot themselves in the foot with the way have >choosen to handle the Benchmark Cheating Scandal so far. Too bad >they didn't say it is wrong for day one. Today's Boston Globe has >an article about the scandal on the front page of the business >section.It's all negative news for Sun: Yeh, it looks bad for sun, but I don't think it is big deal, technical speaking, there is nothing wrong with what SunSoft's claiming, solaris's JIT passed the CaffeineMark test and got the result of 50% faster, there is a big flaw in the CaffeineMark test system, Sun just used this flaw to get a better result. How can you run a=b to get 50 times faster result and when run b=a to get much slower result like what Pendragon Software claimed, a good test software should not let this happen. >Efforts by Sun Microsystems Inc. to make its Java computing system >a popular worldwide standard may have suffered serious damage >this week because of claims that Sun may have cheated on a test >designed to measure Java performance." Java already is a popular worldwide standard although it is still not something like ISO approved standard, There is no necessary for java becoming a offical standard(something like ISO approved) to guarantee the success of java(certainly a plus if it could become a offical standard). Java has been so successful right now, is java any offical standard now? the only reason Sun pushed java to become a ISO standard because some organizations on Europe wish to see java to get a offical standard approved to make their fully commitment on java, but no matter what happen, soon or later they will commit to java. Sun already made it clearly, if ISO do not approve the way Sun handled java to become a offical standard, Sun will go their own way anyway. Of course this way presents the best interests of SUNW's shareholders. >"Sun officials say they've done nothing wrong, but rival >software firm Microsoft Corp. and Java programmers alike say the >charge against Sun raises disturbing questions over whether the >company can be trusted." Disturbing questions from MSFT yes, but not from majority Java programmers. One thing should make it clear, SunSoft is only a JavaSoft's java licencee like other 119 java licencees and is treated like others, SunSoft also had some tough time to deal with JavaSoft. Sun controls java just like MSFT controls Windows, there are no such things like MSFT's java right now execpt MSFT's java products, the crucial point is the developer's world love java. Cheers Gordon Shen

To: Richard M. Smith who wrote (5404)	11/8/1997 7:15:00 PM
From: Charles Tutt	Read Replies (2) \| Respond to of 64865

There's nothing wrong with removing dead code as an optimization. It would be preferable, however, for the detection of the dead code to be more general than a comparison with known dead code in a benchmark! I think these events have shown the Pendragon benchmark is flawed, but Sun could have handled things better by disclosing that fact on its own. I'd like to know how they initially discovered the dead code -- was it found by an earlier version of the JVM (so that all the special test did was speed the detection of what would have been eliminated anyway) or did they do some analysis unavailable to the JVM? Would a decent (e.g., would Sun's) Java interpreter ever generate such dead code (or was the Pendragon code totally unrealistic of what could be expected in real code)? And how fast does the JVM run the code WITHOUT the benchmark-specific test (isn't that what we really want to know)? BTW, I don't think the use of benchmark-specific code is anything new to the industry. JMHO.