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

[Rick Marshall <rjm@zenucom.com>]

I think the better use of these devices is something like a 'SOAP' 
processor. Rather than worrying about a general speed up, there is a 
real advantage in something like a message processor that accepts 
SOA/WS-*, does all the generic "are you allowed here?", "where should 
you go" etc and then passes the message payload on to machines in the 
DMZ that can do something with it.

While we're talking about this, my deja vu moment is the CDC PPU 
(peripheral processor unit) from the days when a super computer (the 
Cyber series in this case) still measured their performance in megaflops.

Nothing's new.

Rick

Len Bullard wrote:
> I've been interested because I was an early supporter of markup for
> graphics.  Then in VRML, it became apparent that the advantages were limited
> to tool reuse, the actual syntax being not attractive in that medium.
> Otherwise, with the growing use of real-time 3D and the development of
> XML-based messaging for these real-time worlds in XML, I've been wondering
> about the use of XML hardware accelerators on the server farms.
>
> XML in VRML was opposed bitterly based on the object model not being a match
> and that the syntax would slow down the application unacceptably.  The first
> objection is true but trivial.  The second turned out to be nonsense.  While
> I've not tested the high rate of exchange issues David and others mention, I
> have tested the loading time using the River of Life project files.  
>
> I've been building in VRML using the curly syntax for mostly legacy reasons,
> but I started converting pieces to X3D in the XML format using the Flux
> Studio 2.0 editor from Media Machines.  It imports and exports X3D (and KML)
> flawlessly.   Loading the X3D/XML into a viewer from a different vendor just
> to be sure there are no in-house tricks, there is NO noticeable difference
> to the end user.  Zero.  Nada.  That contradicts all my expectations and
> predictions from the graphics experts.   While I still think there is a case
> for a binary, it may be a lot more limited than predicted if my informal
> tests are any indicator, but I'm still holding out for the results from the
> working groups.
>
> <plugForTheGoodGuys>
> BTW, if real-time 3D in XML interests any reader, the Media Machines Flux
> Studio 2.0 3D editor is a prize-winning cherry.  The features included are
> mind boggling for a free-for-personal-use piece of liveware.
> </plugForTheGoodGuys>
>
> len
>
>
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: Saturday, February 24, 2007 3:41 PM
>  
> Len Bullard writes:
>
>   
>> Imagine a processor per language.  Gack!
>>     
>
> Yes, Gack, as you put it.  Now imagine a processor that's good at 
> character and string manipulation, table lookup scanning, buffer 
> manipulation, substitution, etc. and you might have something that would 
> do well on lots of languages, XML included.  A better investment than more 
> general purpose processing cores?  I have no clue at this point.
>
> I should say, I've personally never been a fan of special purpose 
> hardware, except when either its peak or average utilization is likely to 
> be very high (as seems to be the case with graphics chips, ethernet chips, 
> and the like).  It won't surprise me a bit if, even if XML processing is 
> offloaded, that the offload is to general purpose cores.  I'm just 
> pointing out that the equation is changing as the relative rate of change 
> in clock speed vs. transistor count starts to favor the latter.  There 
> will be increasing incentives to learn to do work in parallel as opposed 
> to sequentially.
>
> Anyway, this discussion has probably gone past the point of being of 
> interest to a crowd that gathers here mainly to discuss XML.  I'm happy to 
> wrap it up around now.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
> _______________________________________________________________________
>
> 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
>
>
>