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 : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?

To: Elmer who wrote (136030)	5/25/2001 1:26:28 AM
From: Rob Young	Read Replies (1) \| Respond to of 186894

Elmer, First, the measurement is called tpmC. The TPC-C benchmark is "supposed" to mimic OLTP (i.e. typical transaction based environments). This metric has been greatly abused over the years as it allows officially sanctioned "cheating" to take place. This "cluster cheat" allows you to have multiple copies of the DB. What benchmarketers do is have multiple clustered nodes in a shared nothing fashion have a copy of the db hang off each node (simplification) providing great scaling. Real world, you wouldn't have multiple copies of your database around as most folks wouldn't be spending that kind of bucks on disks and management overhead. There are some tpc.org TPC-C benchmarks out there with 9000 disk drives in the config. For a much better and more thorough explanation of the "cluster cheat" pick up Greg Pfister's book, "In Search of Clusters": amazon.com Regarding "64 GBytes" being sufficient... shoot, 64 GBytes is way over kill for most situations. In OLTP , you typically boot up with a large SGA (Oracle) carved out of main memory and let the Oracle or SQL manage the blocks. With a largish DB (1, 2, or more Terabytes) only so much of that will be hot (indexes). Indexes beyond 30-40 Gig total size are rare except for large databases (large being relative, but the point here is this is a small segment of the marketplace compared to the total marketplace). If you hit cache when searching, you will have to hit disk to retrieve records, etc when DBs grow large. I'm not a DB but I have read enough and worked with them enough to be a bit dangerous. But reading the most recent articles you see the pundits proclaim that Itanium will be for high-end DB situations where you can "load the whole DB in memory and not hit the disk." Shoot, you can do that today. In fact, if your database is larger than 128 GBytes there is only one server on the market with enough memory to load up a DB that large in memory. The AlphaServer GS320 supports 256 GBytes of main memory. These writers/pundits/Inteldrones think as if Intel is about to release 64-bit computing on the world. Sheeeshhhh... But the market segments for large dbs and large memorys are small and growing. The bulk of the market (99%? ? ) is more than quite content with a server that supports 64 GBytes of memory. "Unfortunalely that link doesn't work." Go to page 7 here: realworldtech.com "Somethings beyond your expectations for Intel fans to crow about " We have known for over 3 years that Merced was going to disappoint at Integer (or many had supposed they knew and had been crowing about underwhelming Integer for quite some time): From: Henrik Klagges (henrik@strategypartners.com) Subject: Bottle of Champagne IA64 bet taken :-) Newsgroups: comp.arch Date: 1998/10/22 Hello, xyzzy wrote: > > On Thu, 22 Oct 1998 00:02:58 +0200, Henrik Klagges > <henrik@strategypartners.com> wrote: > > >I'm betting a regular bottle (fullsize) on IA32 code, and > >a small bottle on IA64 code :) > > I will take the second bet. Merced (running IA64 code) should trounce > the P6 in integer (and other) performance. It's not a contest unless > the P7 comes out before Merced. Bet taken! One small bottle of decent champagne that the fastest available Intel IA32-processor beats the first IA-64 Merced on SPECint when the first Merced ships. Bet includes normal freight to were you (or I) are. Cheers, Henrik -- Henrik Klagges - IT Analyst henrik@strategypartners.com PGPKey available on request ----- While compelling or very good Fp is a "good thing", the money is in commercial/business. Much better would have been the opposite. Decent fp and world beater integer and tpmC numbers. It would certainly speed adoption. It won't help if Foster is better commercially (speeding adoption that is). The obvious clue there is Intel's number one partner (Microsoft) spends most of its time doing business applications and is interested in great business performance. Microsoft's tepid (non-existent mostly) reactions about Itanium in the Wintel tradepress is not a good sign if you ask me. Will be fun to see how this all plays out after baking for 7 years. Rob

To: Elmer who wrote (136030)	5/25/2001 2:10:40 AM
From: Rob Young	Read Replies (1) \| Respond to of 186894

Elmer, Just for grins: linleygroup.com "We have increased our projections of the chip’s SPEC_base performance to 50 int and 80 fp. We expect it to achieve 45,000 tpmC on the TPC-C benchmark in a four-processor system based on Intel’s 460GX chip set and Lion motherboard. These scores should give Itanium performance leadership when it is released, but its performance could be surpassed by Compaq’s Alpha processors within a matter of months" To give you an idea what that translates to... our clever friends at Compaq stuck a 833 MHz ES40 score out there circa 3Q2000 using the since "retired" Spec95 numbers: Peak Base AlphaServer ES40 50.0 44.6 Integer 100.0 84.3 Fp Spec2000: 544 518 Integer 658 590 Fp Will be interesting to see how accurate Linley's predictions were/are. Rob