Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Stata (gllamm) benchmarks for different platforms?


From   wgould@stata.com (William Gould, Stata)
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: Stata (gllamm) benchmarks for different platforms?
Date   Mon, 26 Apr 2004 10:36:55 -0500

There has recently been a lengthy thread concerning speed of different
computers (and especially the Apple G5 64-bit computer), and a related thread
concerning GLLAMM, and finally Fred Wolfe <fwolfe@arthritis-research.org>
wrote,

> I wonder if it might be possible for Stata Corp to make available a few
> -standard- test files and do files that might be used for timing purposes by
> Stata users. The issue of comparative speed comes up often as computer
> systems change and Stata users try to figure out the various advantages and
> disadvantages of different hardware and OS.

Relationships between software vendors and hardware vendors is always tricky
because neither wants to hear that there is a problem with their offerings.
It is important, however, that software vendors and hardware vendors be able
to discuss issues between themselves honestly and forthrightly, and that is 
something that becomes more difficult if one or the other is on record as 
having identified a "problem" in the other's product.

The Apple G5 is a case in point:

    1.  As has been pointed out on Statalist, the Apple G5 runs GLLAMM 
        slower than Opteron, another 64-bit computer.  

    2.  We and Apple have privately discussed this matter and even traded 
        some software.  The bottom line is that we are doing something 
        inside Stata that Apple wishes that we were not, and Apple is 
        doing something inside the G5 that we wish they were not.  
        Right now, we think that those two design decisions have combined to
        produce the observed outcome.

    3.  The emphasis is on "we think".  Chinh Nguyen <cnguyen@stata.com> 
        is convinced.  Vince Wiggins <vwiggins@stata.com> is not so sure.
        There is no question, at a theoretical level, that the two 
        design decisions are at odds, but the question is how much of a 
        degradation they will combine to produce.

    4.  With work, we could figure that out.  We discussed (again) on Friday 
        doing that immediately, but decided to continue waiting.
        Right now, we do not yet have the 64-bit development tools that 
        we will ultimately be using, and they too can affect results.

    5.  I cannot predict the ultimate resolution of this problem, but 
        before anyone panics, let me point out that Stata design, chip 
        design, and compiler design all combine to produce observed outcomes.
        In previous cases of new, faster computers, it has occurred that 
        some parts of the Stata code ran more slowly while, overall, 
        results were better.  Indeed, at a theoretical level, this is bound to
        happen when RISC chips are compared with CISC chips.

I have already probably said too much, but I have tried to write this 
in way to emphasize that both parties are working to resolve the issue.

Fred Wolfe is correct is assuming that we do assemble timing scripts.
The timing scripts we usually assemble, however, are aimed at looking at 
one particular feature of a chip or subset of our code.  Putting together
a correctly weighted performance index for the average user -- or even 
the average statistical user -- is a difficult job we leave to others.

We of course, have no objection if members of Statalist wish to develop and 
trade such scripts, and we enjoy as much as anybody reading reported results.

-- Bill
wgould@stata.com
*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index