Re: [xml-dev] When parsing speed matters (was Re: [xml-dev] No XML Binar

[noah_mendelsohn@us.ibm.com]

Without commenting on the performance of particular products such as IBM's 
Datapower boxes, I think there are a few others factor that haven't been 
adequately mentioned:

* These boxes can be an attractive way to put more CPUs to work.  Yes, for 
embarrassingly parallel applications (sometimes web serving) you can get a 
fair amount of scaleout by adding general purpose computers or blades to 
your system, but there's overhead of various sorts for that.  You're 
running more copies of a general purpose operating system, tuned to 
multiprogram lots of general purpose applications, Java VMs, or whatever 
in parallel.  Furthermore, for many applications, adding computers does 
not scale your throughput linearly, for a variety of reasons.  If you've 
got enough XML work to justify it, using outboard processors for even 
basic XML parsing, validation and deserialization gives you a good way to 
put more computers to work.  Furthermore, because the work is specialized, 
the software overhead associated with the operating system, buffer 
management, context switching, etc. may mean you get more XML work done on 
those boxes than you would >using the same XML software< on your general 
purpose processsor.  The analogy I use is to the CPUs in your printer: for 
years there was debate whether to do rasterization in your main computer 
or in a chip in the printer.  Either will do the job, and as far as I know 
both solutions more or less work these days (though printer resolutions 
have gotten high enough and page feed speeds fast enough that you need a 
pretty fast link to send a full rasterization to a printer without slowing 
it down.)  Anyway, where the dust mostly settled was:  CPUs and their 
support chips are cheap, and there are easy ways to move the processing 
outboard, so lots of printers to the final rendering on an outboard CPU in 
the printer.  Sometimes that's because there are custom chips in there, 
but often not.  The same software would in principle run as fast in the 
main computer:  it's just a significant bit of work you can move outboard. 
 Regarding David Megginson's claim that low level XML overhead is perhaps 
a few % of overall application CPU time:  I think there are 
counterexamples in the high performance Web Services world, but I don't 
have the numbers here to back up my claim.

* Depending on your needs, there may be less management cost to a black 
box that "just does one thing", than to deploying extra general purpose 
computers that need to be backed up, secured, etc. in ways that more fixed 
function boxes may not require.

So, I don't think the justification for outboard boxes depends entirely on 
custom hardware, or claiming that they can do more XML work per CPU cycle 
than traditional software.  There are other factors involved too.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Anne Thomas Manes" <atmanes@gmail.com>
02/24/2007 07:53 AM
 
        To:     "Len Bullard" <cbullard@hiwaay.net>, "XML Dev" 
<xml-dev@lists.xml.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: [xml-dev] When parsing speed matters (was Re: 
[xml-dev] No XML Binaries? Buy Hardware)


Validation, transformation, and encryption/signature processing are
the primary functions for which people use XML gateways.

Anne

On 2/24/07, Len Bullard <cbullard@hiwaay.net> wrote:
> Finally, the prosaic answer:  the accelerators are not necessary for 
parsing
> but for inspection and routing. The 'otherwise process' is somewhat less
> prosaic.  It sounds like the applications that make the civil liberties
> lawyers nervous, but politics aside, wouldn't requirements to inspect, 
route
> and 'otherwise process' be there for any application that has to open 
the
> packets and 'look see' even if the bits weren't in XML?
>
> IOW, given that prose, this doesn't seem to be an XML issue although
> possibly XML makes it easier/convenient to do.
>
> len
>
>
> From: David Megginson [mailto:david.megginson@gmail.com]
>
> On the other hand consider a network carrier or major data centre that
> has to inspect, route, or otherwise process XML documents at wire
> speed as they fly past.  That *is* a situation where accelerated
> parsing of some kind might make a difference.
>
>
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php