Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Text.copy

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: stevel AT apache.org
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Text.copy
  • Date: Thu, 25 Nov 2004 15:16:27 -0800

I've seen that presentation some years ago, Steve.

There are many cases where cost/benefit and prize/performance do not pay off, no doubt. Gains tend to be high initially, then level off beyond some point, with little ROI. But there are no universal truths. Fruits often hang low, they accumulate and, quite possibly, multiply. Try running a throughput app with JDK 1.3 client VM and a normal parser, then try running with 1.5 server VM and a binary codec. With a little luck, there may well be 2 orders of magnitude speedup here.

Let me give you a funny thanksgiving example:

You have a Grid data center, your apps are grinding away on data-intensive problems. The primary measure of success is how much data you can process, and the better you are the more data the apps will throw at you: the desire is for ever higher frequencies of measurement, ever more accurate algorithms, ever more timely results - with hard work and little luck there might be a nobel prize around the corner.

You have 10000 CPUs, 3 Petabytes of disk caches and 20 Petabytes of robotic tape (the disks are just caches for the tapes), funky transatlantic links to similar folks (who are your collaborators but in a sense also your competitors). That translates to a large building with a substantial energy bill for power and cooling, regular hardware-failures because of a large N everywhere, quite a few technicians, and some challenges in scalable systems administration. Now suggest to high-level management "no particular need to try being efficient; just relax, everything will take care of itself soon", indirectly implying that we could just get away with standards based off-the-shelf commodity technology, or next year's version of it. It just happens to require another 90000 CPUs, plus disks, plus switches, plus staff, plus a new research project to figure out how we can actually keep the baby alive without imploding, etc.

For example, imagine the truck loads of spare parts arriving every day, with the technicians replacing failed disks pretty much all day long, every day, as a matter of routine. Each time those poor chaps walk back and forth between the truck and the hall they pass by a plastic sticker on the entrance door that proudly pronounces the "standards, off-the-shelf technology and next year's hardware are key to success" mantra. Then they look over to the office window of the mantra's inventor, and shake heads. :-)

Don't take it seriously, have a nice thanksgiving, and enjoy...
Wolfgang.

-----------------------------------------------------------------------
Wolfgang Hoschek | email: whoschek AT lbl.gov
Distributed Systems Department | phone: (415)-533-7610
Berkeley Laboratory | http://dsd.lbl.gov/~hoschek/
-----------------------------------------------------------------------

On Nov 25, 2004, at 1:55 PM, Steve Loughran wrote:

On Thu, 25 Nov 2004 12:50:55 -0800, Wolfgang Hoschek <whoschek AT lbl.gov> wrote:
Turns out it actually amounts to the same effect. No improvement there.
Maybe i'm just overworked...
Wolfgang.


Maybe you're just trying too hard

http://www.cs.umd.edu/~pugh/IsCodeOptimizationRelevant.pdf





Archive powered by MHonArc 2.6.24.

Top of Page