Subject: Re: IC's patent-pending technology
From: "Forrest J. Cavalier III" <mibsoft@mibsoftware.com>
Date: Mon, 25 Sep 2006 23:42:12 -0400

Jamie Lokier wrote:

in part,
> I'm sure that holds for anyone else with knowledge of modern code
> optimisation.

....Or anyone with knowlege of fast parallel MD5 algorithms, or
image processing algorithms.  The patent-pending methods seem to claim
some things that most C libraries have done inside strchr() and friends,
which work on aligned DWORDS, not bytes.  I trust they cited these in
prior art.

But Larry asked for impacts on FSB....

My take is thumbs down on getting wide adoption.  Let me
explain.

Most of the software I have written that uses XML uses it for
data interchange.  When it uses UTF-8, it uses it for I18N of the user 
interface, and doesn't care about validation: it just hands it to
the unicode syscalls in the OS.  (Also, typically I18 UTF-8 comes
from string tables, and that is already pre-validated.)

Computers are so fast now, that speeding up these operations 20x
would not appreciably affect the user experience in any software
that I can remember writing.

So, there aint no way I'm releasing anything with this patented code,
despite the liberal license.  When my customers care about licensing,
(and they do), the perception of risk counts as risk.

Since the benefits are very, very slight, the risk outweighs it.

YMMV. I'm sure that there are some apps that would really benefit here,
the way that the Fast Fourier Transform found niches where it offered
industry-changing improvement.  But if XML and I18N are ancilliary to your code, 
then I'd expect the risk-benefit analysis above to hold.

I'll even go further about this.  Because of blazing processor speeds, I'd say 
that "slight benefit, but perceived licensing risk" is going to be what free
software sees for almost every software patent that offers mere acceleration.

Amdahl's Law on optimization really clarifies things here: no single 
optimization can have that much affect on the overall app. It is quite 
acceptable to do without optmization in most every case.

IC's market is elsewhere, they already know.

BTW, the SIMD speedups in the overview claimed are overreaching I think.  SIMD 
is great if you can keep your processors filled with data.  If you have
large streams of data, disk I/O is the bottleneck, not CPU.  Lots of carefully
designed hardware architecture is needed to keep fast SIMD pipelines filled.

Also, RAM is cheap and a huge lookup table (rather than rule-based validation) 
is possible for those who have terabytes of XML and UTF-8 to process.