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 : Rambus (RMBS) - Eagle or Penguin -- Ignore unavailable to you. Want to Upgrade?

To: jim kelley who wrote (61655)	11/21/2000 3:56:43 PM
From: SBHX	Read Replies (1) \| Respond to of 93625

Jim, When these applications are recompiled the "sluggishness" in the legacy software will evaporate. This is going to be a big year for the software folks. I won't be so sure. Many of the spreadsheet and database and word processing s/w that runs in the business world are non-streaming and could potentially suffer the most with granularity loss. If the intention is to ignore all business s/w for benchmarking, then fine, there are video streaming and 3D applications [rewritten to change the ordering of the pre-geometry vertices (something called structure of arrays (proposed by intel) over array of structures (today in openGL and D3D)] that will benefit enormously from anything that uses more of the chunks of data being read in. Any app that addresses data sparsely will not like this. I doubt if many of the business world apps will benefit from a 'recompile' without rethinking their underlying data structures to solve the granularity loss problem. But I agree that what these machines need is a whole new set of benchmarks that run well on streaming data to make them look good. Or so my graphics and computer architecture guru friend tells me. (G) edit: actually, I take that back. There used to be certain mixes of instructions generated by a P54/P55C compiler to take advantages of the U-V pipes that caused horrible partial stalls on PentiumPros and PIIs. Perhaps something similar is there. Though I can't think anything off the top of my head about P6 style code generated by a C compiler that are order dependent --- the PII/PIII thing is superscalar out of order, so it shouldn't matter. But I could be wrong. SbH

To: jim kelley who wrote (61655)	11/21/2000 3:59:46 PM
From: Alex Fleming	Read Replies (1) \| Respond to of 93625

Hi Jim, There is no doubt that the P4 will improve with time but as far as steaming data applications, what are we talking about, 10mbs bandwidth on 'broadband connections' max on a best case. Thats the same as a regular ethernet connection. A PIII 500 will handle those tasks just as well. The bottleneck it still the connection not the CPU. As for legacy applications ie. any software sold up until yesterday...well thats what most people are using. If is takes half a year to have a recompiled application available then there is no rush. The P4 does show strength in encoding Mpeg2 streams which is fine. I am certain that a P4 would fair badly against any dual 800 in the same benchmark. The Ligos Mpeg2 encoding numbers are also very impressive on any dual cpu box. Remember that the P4 is not just competing against the Athlon but also against Intels 'legacy' workstation hardware which performs very well. It seems too early to make judgements about the benefits of the P4 as they are now. It seem that the best thing to do is wait and see. I am still waiting to be convinced. Regards, Alex

To: jim kelley who wrote (61655)	11/21/2000 4:11:04 PM
From: Sully-	Read Replies (1) \| Respond to of 93625

Jim, It appears that all RMBS/INTC detractors want any & all advancements in technology to come to a complete halt. Currently change is bad. Improvements to technology are no longer needed or necessary. Of course, their mantra will suddenly & dramatically change if/when AMD or Team DDR manage to upgrade their products to a more competitive level. Then they will be able to divine a future that demands more processing speed & software that is fully compatible. Funny how perceptions of reality can be based on where our emotional ties (& pocketbooks) are leaning..... regardless of long established historical trends or cold hard facts? Ö¿Ö

To: jim kelley who wrote (61655)	11/22/2000 12:55:13 AM
From: Ali Chen	Respond to of 93625

<Most of the "head cases" agree with me that the performance is likely to get much better when these applications are recompiled to run efficiently on the P4 architecture. I guess we are just going to be stuck with poorly performing legacy applications software.> You are showing a teenager's mentality, jim. The application software base is a given reality. There are hundreds of millions software packages in use, people invested billions $$ into it. What makes you think people will buy a totally new computer, new OS, throw away those investments and buy all new applications, all just to ripp-off CDs into MP3 files 30% faster? <When these applications are recompiled the "sluggishness" in the legacy software will evaporate. This is going to be a big year for the software folks.> "Sluggishness" of software is the last thing software folks a are concerned about. Software biggies prefer to think structurally, in objects, to get new features faster to market. The bloated software sluggishness comes from software layers that are soaring on theoretical abstractions of hidden data structures. These folks have no clue about all that crap of trace cache trashing and system latency penalties. More, they don't want to. They are above all that. No one would even try to "evaporate" the golden goose of working software. FYI, there are many s/w packages in $5k - $30k range whos DLLs were 90% compiled 5 years ago with 486 optimizations. Take a look at Microsoft VC++ kernel routines - they are still plain 8086 compatible and were written in primitive assembler 10-15 years ago. Now talk about "recompile"... The only chance to get some modern P4 code is maybe for some s/w startups.