Intel compilers and libraries

C J Kenneth Tan -- Heuchera Technologies cjtan at
Thu Oct 9 09:34:56 EDT 2003


You covered some of the issues that we are addressing with our lawyers
right now.  It's a process which, as knowledgeable as you are, I am
sure you can understand we have to go through.

C. J. Kenneth Tan, Ph.D.
Heuchera Technologies Ltd.
E-mail: cjtan at      Telephone: +44 798 941 7838
Web:    Facsimile: +44 289 066 3015

On Thu, 9 Oct 2003, Robert G. Brown wrote:

> Date: Thu, 9 Oct 2003 09:16:43 -0400 (EDT)
> From: Robert G. Brown <rgb at>
> To: C J Kenneth Tan -- Heuchera Technologies <cjtan at>
> Cc: Greg Lindahl <lindahl at>, beowulf at
> Subject: Re: Intel compilers and libraries
> On Thu, 9 Oct 2003, C J Kenneth Tan -- Heuchera Technologies wrote:
> > > 4) Put your performance whitepapers on your website, or it looks
> > > fishy.
> >
> > Our white papers are not on the Web they contain performance data, and
> > particularly, performance data comparing against our competitors.  It
> > may expose us to libel legal issues.  Putting legitimacy of any legal
> Expose you to libel suits? Say what?
> Only if you lie about your competitor's numbers (or "cook" them so that
> they aren't an accurate reflection of their capabilities, as is often
> done in the industry) does it expose you to libel charges or more likely
> to the ridicule of the potential consumers (who tend to be quite
> knowledgeable, like Greg).
> One essential element to win those crafty consumers over is to compare
> apples to apples, not apples to apples that have been picked green,
> bruised, left on the ground for a while in the company of some handy
> worms, and then picked up so you can say "look how big and shiny and red
> and worm-free our apple is and how green and tiny and worm-ridden our
> competitor's apple is".  A wise consumer is going to eschew BOTH of your
> "display apples" (as your competitor will often have an equally shiny
> and red apple to parade about and curiously bruised and sour apples from
> YOUR orchard) and instead insist on wandering into the various orchards
> to pick REAL apples from your trees for their OWN comparison.
> What exactly prevents you from putting your own raw numbers up, without
> any listing of your competitor's numbers?  You can claim anything you
> like for your own product and it isn't libel.  False advertising,
> possibly, but not libel.  Or put the numbers up with your competitor's
> numbers up "anonymized" as A, B, C.  And nobody will sue you for beating
> ATLAS/GCC/GSL numbers -- ATLAS etc are open source tools and nobody
> "owns" them to sue you or cares in the slightest if you beat them. The
> most that might happen is that if you manipulate(d) ATLAS numbers so
> they aren't what real humans get on real systems, people might laugh at
> you or more likely just ignore you thereafter.
> What makes you any LESS liable to libel if you distribute the white
> papers to (potential) customers individually?  Libel is against the law
> no matter how, and to who, you distribute libelous material; it is
> against the law even if shrouded in NDA. It is against the law if you
> whisper it in your somebody's ears -- it is just harder to prove.
> Benchmark comparisons, by the way, are such a common marketing tool (and
> so easily bent to your own needs) that I honestly think that there is a
> tacit agreement among vendors not to challenge competitors' claims in
> court unless they are openly egregious, only to put up their own
> competing claims.  After all, no sane company WOULD actually lie, right
> -- they would have a testbed system on which they could run the
> comparisons listed right there in court and everybody knows it.  Whether
> the parameters, the compiler, the system architecture, the tests run
> etc. were carefully selected so your product wins is moot -- if it ain't
> a lie it ain't libel, and it is caveat emptor for the rest (and the rest
> is near universal practice -- show your best side, compare to their
> worst).
> > issues aside, it is not good for any business to be engulf in legal
> > squabbles.  We are in the process of clearing this with our legal
> > department at the moment.
> >
> > As I have noted in my previous e-mail, anyone who wants to get a hold
> > of the white papers are welcome to please send me an e-mail.
> As if your distributing them on a person by person basis is somehow less
> libelous?  Or so that you can ask me to sign an NDA so that your
> competitors never learn that you are libelling them?  I rather think
> that an NDA that was written to protect illegal activity be it libel or
> drug dealing or IP theft would not stand up in court.  Finally, product
> comparisons via publically available benchmarks of products that are
> openly for sale don't sound like trade secrets to me as I could easily
> duplicate the results at home (or not) and freely publish them.
> Your company's apparent desire to conceal this comes across remarkably
> poorly to the consumer.  It has the feel of "Hey, buddy, wanna buy a
> watch?  Come right down this alley so I can show you my watches where
> none of the bulls can see" compared to an open storefront with your
> watches on display to anyone, consumer or competitor.  This is simply my
> own viewpoint, of course.  I've simply never heard of a company
> shrinking away from making the statement "we are better than our
> competitors and here's why" as early and often as they possibly could.
> AMD routinely claims to be faster than Intel and vice versa, each has
> numbers that "prove" it -- for certain tests that just happen to be the
> tests that they tout in their claims, which they can easily back up.
> For all the rest of us humans, our mileage may vary and we know it, and
> so we mistrust BOTH claims and test the performance of our OWN programs
> on both platforms to see who wins.
> I'm certain that the same will prove true for your own product.  I don't
> care about your benchmarks except as a hook to "interest" me.  Perhaps
> they will convince me to get you to loan me access to your libraries etc
> to link them into my own code to see if MY code speeds up relative to
> the way I have it linked now, or relative to linking with a variety of
> libraries and compilers.  Then I can do a real price/performance
> comparison and decide if I'm better off buying your product (and buying
> fewer nodes) or using an open source solution that is free (and buying
> more nodes).  Which depends on the scaling properties of MY application,
> costs, and so forth, and cannot be predicted on the basis of ANY paper
> benchmark.
> Finally, don't assume that this audience is naive about benchmarking or
> algorithms, or at all gullible about performance numbers and vendor
> claims.  A lot of people on the list (such as Greg) almost certainly
> have far more experience with benchmarks than your development staff;
> some are likely involved in WRITING benchmarks.  If you want to be taken
> seriously, put up a full suite of benchmarks, by all means, and also
> carefully indicate how those benchmarks were run as people will be
> interested in duplicating them and irritated if they are unable to.
>    rgb
> --
> Robert G. Brown	             
> Duke University Dept. of Physics, Box 90305
> Durham, N.C. 27708-0305
> Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at
Beowulf mailing list, Beowulf at
To change your subscription (digest mode or unsubscribe) visit

More information about the Beowulf mailing list