[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: When parsing speed matters (was Re: No XML Binar

• From: "Len Bullard" <cbullard@h...>
• To: <noah_mendelsohn@u...>
• Date: Sat, 24 Feb 2007 16:45:18 -0600

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@u... [mailto:noah_mendelsohn@u...] 
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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

• References:
  • RE: When parsing speed matters (was Re: No XML Binaries? BuyHardware)
    • From: noah_mendelsohn@u...