[macports-ports] branch master updated: Add optimizations variant to python{27, 35, 36, 37}

Eitan Adler lists at eitanadler.com
Mon Jul 16 18:47:54 UTC 2018


On Mon, 16 Jul 2018 at 04:18, Perry E. Metzger <pmetzger at macports.org> wrote:
>
> On Sun, 15 Jul 2018 19:34:58 -0700 Eitan Adler <lists at eitanadler.com>
> wrote:
> > On Sun, 15 Jul 2018 at 17:00, Perry E. Metzger
> > <pmetzger at macports.org> wrote:
> > >
> > > I want to be clear about something. In theory, we could turn on
> > > runtime trace guided optimization for _every_ binary. Python isn't
> > > particularly special on this. It would also, in my opinion, be a
> > > horrible mistake -- the benefits are fairly small compared to the
> > > astonishing build times. There are people for whom this is
> > > important, but they're not normal users.
> >
> > Users that build that want shorter build times can turn off
> > optimizations. Those that use the defaults and use binary packages,
> > do not have that option.
> >
> > Remember, as a macports developer, or even contributor, you're in
> > the minority. The vast majority of people just stay with the
> > defaults.
>
> Which is why making it take a couple orders of magnitude longer
> to build seems like a bad idea. On an older machine this could be a
> very very long time indeed.

I think we're talking past each other. Lets put out our assumptions
and thus the difference of opinion.

There three groups of people:
   A. Users of the binary packages. This is the default type of user
(if you make no changes to the config, this is what you get)
   B. Those that build from source that would like to enable optimizations
   C. Those that build from source that *don't* want to enable optimizations

There are six ways to prioritize these groups of people:

ABC - clear win to enable optimizations
ACB - win to enable optimizations by default, as 'C' users can flip a switch
BAC - clear win to enable optimizations. This is essentially the same as ABC.
BCA - win to enable optimizations by default, as 'C' users can flip a switch
CAB - mostly a win to disable optimizations.  Even if it were enabled,
C could still flip a switch, but we're prioritizing their comfort.
CBA - mostly a win to disable optimizations. Even if it were enabled,
C could still flip a switch, but we're prioritizing their comfort.


I am very much optimizing for the case of ABC or ACB (don't care
which). The reason for this is that
1. Assumption based on data: it is shown consistently that the vast
majority of users do not change defaults. This is true for almost all
software, and for engineers and non-engineers alike. As such the
assumption is that most users are in group A.  [0]
2. The cost for users that want to build from source but disable
optimizations is trivial: adding a command line switch.

Which order are you proposing and why?




[0] If you believe this to not be the case for macports I'd like to
see the numbers. That would be putting macports into a rare an unusual
group of people/software.
[1] For the record, as you noted, this is not specific to python. This
is just the one I noticed.






-- 
Eitan Adler


More information about the macports-dev mailing list