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 <[email protected]>
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 <[email protected]>
is convinced. Vince Wiggins <[email protected]> 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
[email protected]
*
* 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/
