Statalist


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: re: building a 'dream' stata desktop setup


From   David Airey <david.airey@Vanderbilt.Edu>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: re: building a 'dream' stata desktop setup
Date   Tue, 8 Jul 2008 14:38:55 -0500

.

Thank you for the very interesting edification. I did not realize the difference in performance between the recently released software and roadmap of Intel and what it really means to take advantage of multiple cores efficiently. Just for the record, I happily paid for Stata/MP for 2 cores, and I will have the same attitude if more cores land in front of me. One more question: will you be taking advantage of graphics processors? I've read this is another source to increase computations in most computers these days.

-Dave


On Jul 8, 2008, at 1:41 PM, William Gould, StataCorp LP wrote:


David Airey <david.airey@Vanderbilt.Edu> wrote,

[...] Intel has now recommended programmers prepare their code for more
cores than currently on the market or imaginable (i.e., 100s to 1000s). What
are we going to pay for Stata then? Clearly, Stata is charging more because
they can and those who buy 8 core machines have money in their pockets. When
it is the norm to have a larger number of cores, prices will not be by the
core, or no one will buy Stata.
I suspect David is imagining that all that was required to produce Stata/MP
was recompiling Stata by specifying a compiler option and then selling the
product. If that were the case, I would agree with David.

That is not what we did. Stata/MP was a major rewrite of Stata, the purpose
of which was to work directly with the multiple cores. This involved not just
parallelizing code, but deciding where and how deeply to parallelize, and
rewriting computation algorithms to be amenable to parallelization.

Stata/MP was a major effort and it still is. Multiple developers work full
time parallelizing more and more of Stata.

In fact, nowadays one could produce a multiprocessor product simply by
compiling single-processor code using a sophisticated compilers just released
in the last few months. The latest Intel compiler has just such a feature,
and as a result, we may be about to see programs, including statistical
packages, that run on "all the cores".

The problem is, such automatic techniques for producing parallel software does
not work nearly as well as custom coding efforts such as those performed
for Stata/MP.

Here's a table:

-------------------- run time -------------------
-- Stata/MP - Automatic method
Processors Perfect MP-A MP-E Alt. 1 Alt. 2
-------------------------------000----------------------------------
1 1.00 1.00 1.00 1.00 1.00
2 .50 .72 .57 . 94 .87
4 .25 .50 .35 . 90 .81
8 .125 .42 .24 . 89 .77
40 .025 .35 .15 . 87 .75
400 .003 .33 .13 . 87 .74
4,000 .0003 .33 .13 . 87 .74
--------------------------------------------------------------------
Note: Parallelizeable regions are 100% for Perfect, 66.6%
MP-A, 87% for MP-E, 13% for Alt. 1, and 26% for Alt. 2.

Numbers for Stata/MP based on actual measurement. MP-A
reports results for all Stata commands. MP-E reports
results for all estimation commands.

Alt. 1 is a generous estimates of what can be achieved by
automatic compiler methods today.

Alt. 2 is a generous estimate of what may be achievable by
automatic compiler methods in the future.


Alternatives 1 and 2 above are admittedly made up, but they have been made up
generously. Alternative 1, for instance, is supposed to be what is achievable
by today's compilers, yet using the current Intel compiler, we cannot achieve
such results. The results reported in the Alternative 2 column are about
twice as good as we think are theoretically possible with automated methods.

The numbers in the Stata/MP column are overall observed averages with
an extrapolation to 400 and 4,000 processors.

I admit I am in the process of setting up a straw man and knocking him
over. I am setting up the straw man because I suspect the "specify the
option and recompile" model is, unconciously, the underlying assumption in
everyone's mind when first thinking about this issue.

So let's understand the implications of the table. Stata/MP running
on two cores produces better performance than either automatic alternative
running even on 4,000 cores. Stata/MP on four cores does even better,
and indeed we are charging you for that.

David is right when he states, "Stata is charging more because they can and
those who buy 8 core machines have money in their pockets". I would say it
differently, of course. I would say that Stata with 4 cores produces a lot
more performance than Stata with 1 or 2 cores, and so the price is justified.

In part, the price is justified because making parallel algorithms work
efficiently on more than two cores requires a surprising amount of
extra work. The problem is, you don't necessarily want to run on all
of them because the setup costs could be too great. Instead, you must
develop a subsystem that decides problem-by-problem, based on current
conditions, exactly how many processors should be used for each little
piece of the calculation.

Nonetheless, David would be absolutely correct to say to that StataCorp chose
to charge more for 4-core Stata than 2-core than costs could justify. That's
always the case with software: the cost of development is an up- front cost
and afterwards, prices are set to spread those costs (and profits) in ways
that seem equitable.

-- 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/
*
*   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