Plan for the merge of expr_dev

[Siirola, John D]

Following up on a phone call with several developers today, we decided that we needed a separate discussion to nail down the plan for the expr_dev merge.

 

To get the ball rolling, I am proposing the following:

• Fri 3/16:  Bill releases the expr_dev branch for review (no more major changes)
• Fri 3/22:  Pyomo 5.4.4 release, including
  • fixes from 5.4.3 (in particular GDP)
  • solver interface fixes (from Gabe)
  • some resolution of the glpk 4.65 issue
  • the “un-namespace-ization” of pyomo and pyutilib
• Wed 2/27: all reviews in
• On/before 3/31:  merge expr_dev!

 

Guiding principles:

• Reviewers will pay particular attention to expr_pyomo5, and the new canonical repn.
• Reviewers will divvy up the remainder of the codebase (e.g., JDS will look at GDP, BLN will look at DAE, etc)
• We are looking for major showstoppers:
  • Incorrect behavior
  • Catastrophic performance degradation
    • I propose that “catastrophic == >50% performance degradation for ‘go-to-solver-trace’”
  • Public API decisions that cause major heartburn / we do not want to commit to supporting
• All other issues:
  • Minor performance degradation
  • Stylistic changes
  • Private API decisions

Should be archived as issues, referenced in the review, and nominated for the 5.5 release (the first release including pyomo5 expressions)

 

Thoughts / stones / counter-proposals?

 

john

[Qi Chen]

What is the “un-namespace-ization” of pyomo and pyutilib?

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Qi Chen

PhD Candidate

Center for Advanced Process Decision-Making

qic...@andrew.cmu.edu

[Siirola, John D]

Pyomo, Pyutilib, and Pyutilib.component are all technically “namespace packages”.  We are proposing to remove that feature.

 

I also missed the dates…

                Fri 3/16

                Fri 3/23

                Wed 3/28

 

john

 

From: pyomo-de...@googlegroups.com [mailto:pyomo-de...@googlegroups.com] On Behalf Of Qi Chen
Sent: Thursday, March 15, 2018 10:05 AM
To: pyomo-de...@googlegroups.com
Subject: [EXTERNAL] Re: Plan for the merge of expr_dev

 

What is the “un-namespace-ization” of pyomo and pyutilib?

Siirola, John D <jds...@sandia.gov> schrieb am Do., 15. März 2018 um 12:02 Uhr:

Following up on a phone call with several developers today, we decided that we needed a separate discussion to nail down the plan for the expr_dev merge.

 

To get the ball rolling, I am proposing the following:

·         Fri 3/16:  Bill releases the expr_dev branch for review (no more major changes)

·         Fri 3/22:  Pyomo 5.4.4 release, including

o    fixes from 5.4.3 (in particular GDP)

o    solver interface fixes (from Gabe)

o    some resolution of the glpk 4.65 issue

o    the “un-namespace-ization” of pyomo and pyutilib

·         Wed 2/27: all reviews in

·         On/before 3/31:  merge expr_dev!

 

Guiding principles:

·         Reviewers will pay particular attention to expr_pyomo5, and the new canonical repn.

·         Reviewers will divvy up the remainder of the codebase (e.g., JDS will look at GDP, BLN will look at DAE, etc)

·         We are looking for major showstoppers:

o    Incorrect behavior

o    Catastrophic performance degradation

§  I propose that “catastrophic == >50% performance degradation for ‘go-to-solver-trace’”

o    Public API decisions that cause major heartburn / we do not want to commit to supporting

·         All other issues:

o    Minor performance degradation

o    Stylistic changes

o    Private API decisions

Should be archived as issues, referenced in the review, and nominated for the 5.5 release (the first release including pyomo5 expressions)

 

Thoughts / stones / counter-proposals?

 

john

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bill Hart]

This week, I did some performance tuning of Pyomo5 expressions, focusing on linear problems (and in particular pmedian8).  Attached is some performance data from my Mac laptop on the test problems we've been using this past year (a mixture of internal problems and the JuMP test problems).

Some comments:

1.  This is a single run, so there is some noise in the numbers here.

2.  The CPython runs were using the MacPorts python installations.  In preliminary runs, CPython using Anaconda was up to 25% faster than the MacPorts build.

3.   The relative #s were against the current Master branch of Pyomo, unless that code garfed.  In that case, the relative #s were against the expr_dev branch.

4.   The normalized numbers in the graphs include negative values, which indicate missing data (e.g. no quicksum() version of the model, Cython not being used, or test problem failures).

There were 5 versions of Pyomo compared:

1)  The current master branch

2)  The expr_dev branch (called 'default')

3)  The expr_def branch using the quicksum() function instead of sum()  (called 'quicksum')

4)  #2 installed with Cython

5)  #3 installed with Cython

Some general observations

1) There are no catastrophic failures.  The largest performance slowdown is 26%.

2) The large performance slowdowns are for nonlinear problems.  I know of ways to improve these, but there are some design trade-offs that I need to discuss with Pyomo developers regarding the expectation of canonical representations with nonlinear expression terms.

3) The Cython installs mitigate the large performance slowdowns in all cases.

4) Pyomo5 expressions are a big win for PyPy, both for runtime as well as reliability.  The current expression system fails in many cases.

5) There are some big performance wins for CPython, which appear to be related to elimination of cloning effects and incidental improvements in writers.

Given these results, I'm pretty comfortable recommending that we don't block the merge of the expr_dev branch based on performance considerations.  Although I have some ideas for improving the performance of nonlinear expressions, I plan to defer those changes until after the merge.

--Bill

P.S.  I've almost automated the generation of these results on our Jenkins test server, but several issues are likely to delay that until later next week.

[Nicholson, Bethany L.]

Bill,

 

A few of us (Dave, Gabe, Michael, and Bethany) talked about this at the developer’s meeting today and we agreed with you that the performance results should not block merging. We are going to start our reviews and ask that you limit new commits as much as possible. We expect that our reviews will include commits from each of us on the parts of the code base we are experts in and would like to minimize merge conflicts and complications through the review process. Both Michael and Gabe noticed commits/changes in master that were lost in the expr_dev branch likely due to messy merge conflicts when merging master into expr_dev. Checking the diff on each file during our reviews is going to be a time-consuming process and instituting a code freeze on expr_dev would make things a little easier for reviewers (assuming you’re ready for us to review).

 

Bethany

 

From: pyomo-de...@googlegroups.com [mailto:pyomo-de...@googlegroups.com] On Behalf Of Bill Hart
Sent: Saturday, March 17, 2018 4:29 AM
To: Pyomo Developers <pyomo-de...@googlegroups.com>
Subject: [EXTERNAL] Re: Plan for the merge of expr_dev

 

This week, I did some performance tuning of Pyomo5 expressions, focusing on linear problems (and in particular pmedian8).  Attached is some performance data from my Mac laptop on the test problems we've been using this past year (a mixture of internal problems and the JuMP test problems).

o   fixes from 5.4.3 (in particular GDP)

o   solver interface fixes (from Gabe)

o   some resolution of the glpk 4.65 issue

o   the “un-namespace-ization” of pyomo and pyutilib

·       Wed 2/27: all reviews in

·       On/before 3/31:  merge expr_dev!

 

Guiding principles:

·       Reviewers will pay particular attention to expr_pyomo5, and the new canonical repn.

·       Reviewers will divvy up the remainder of the codebase (e.g., JDS will look at GDP, BLN will look at DAE, etc)

·       We are looking for major showstoppers:

o   Incorrect behavior

o   Catastrophic performance degradation

§  I propose that “catastrophic == >50% performance degradation for ‘go-to-solver-trace’”

o   Public API decisions that cause major heartburn / we do not want to commit to supporting

·       All other issues:

o   Minor performance degradation

o   Stylistic changes

o   Private API decisions

Should be archived as issues, referenced in the review, and nominated for the 5.5 release (the first release including pyomo5 expressions)

 

Thoughts / stones / counter-proposals?

 

john

--

[William Hart]

Cool.  I'm not expecting to make any major commits at this point.

I'm in the process of fixing bugs, though.  Should I hold off on those until we have a complete set of reviews?

--Bill

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-developers+unsubscribe@googlegroups.com.

[William Hart]

I should have added that the bugs I'm fixing relate to test failures.  So they aren't pyomo.core or pyomo.repn, as far as I can tell.

--Bill

[Nicholson, Bethany L.]

My vote would be for you to finish squashing bugs that you know how to fix with a hard stop on Thursday 3/22. You should let us know if you are done before then and which tests you need help with.

 

Bethany

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.

[William Hart]

OK.  I'll try to fix all test failures tomorrow.  :)

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-developers+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-developers+unsubscribe@googlegroups.com.