Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOC: roadmap update #12008

Merged
merged 5 commits into from
May 17, 2020
Merged

DOC: roadmap update #12008

merged 5 commits into from
May 17, 2020

Commits on May 8, 2020

  1. Configuration menu
    Copy the full SHA
    1c83e45 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    f9782ef View commit details
    Browse the repository at this point in the history
  3. DOC: add "more hardware platforms" to main roadmap, reorder items.

    Also address a couple of review comments, delete things that were done.
    
    [ci skip]
    rgommers committed May 8, 2020
    Configuration menu
    Copy the full SHA
    83fa0ee View commit details
    Browse the repository at this point in the history
  4. DOC: add "performance improvements" to roadmap.

    Note that this was one of the big ticket items in the 2019 NSF proposal
    for the SciPy ecosystem:
    https://figshare.com/articles/Mid-Scale_Research_Infrastructure_-_The_Scientific_Python_Ecosystem/8009441
    
    For that proposal we got a lot of direct feedback from outreach to
    prominent users in domains like economics, physics, and biology.
    
    Example quotes:
    
    "... my top-level concern as a person who supports users is whether
    Python and the Scientific Python stack as a whole needs a rethink as
    architectures become more parallel and individual cores become less and
    less powerful. ... We don't have bright lines for Python users like we
    have for C, C++, Fortran for performance portability. If your code is in
    C++ we can talk about directive-based parallelism or specific libraries
    or compilers that will help you minimize the amount of code you have to
    rewrite to move across architectures (to be fair: it's rarely magic).
    But things seem to lag in Python."
    
    "Beyond individual features I think there's another issue worth thinking
    about. Using things like numba efficiently is becoming more and more
    useful to researchers, as special model types and solution methods may
    not be written in vectorized form very easily or "beautifully". However,
    since the whole chain has to be written using numpa for the JIT to fully
    materialize itself, it's kind of an issue that scipy does not generally
    support this way to solving problems in python (by that I mean something
    that's not just fast because you're using Numpy and vector operations).
    The leads to researchers writing their own optimizers, that are
    essentially duplicates of well-known methods such as brent and golden
    section search, multilinear interpolation and other methods, to speed up
    their code. SciPy should handle this part of the problem-solving (it
    does, but just not in a way that's efficient to the numba-users), but
    currently we risk a lot of code duplication and bugs. I'm not involved
    in scipy so I'm not fully aware of their stance of numba vs some of the
    other possibilities out there, but the issue of being unable to
    efficiently use @njit is a real issue in my opinion."
    
    [ci skip]
    rgommers committed May 8, 2020
    Configuration menu
    Copy the full SHA
    21d03db View commit details
    Browse the repository at this point in the history

Commits on May 17, 2020

  1. Configuration menu
    Copy the full SHA
    c5e6d09 View commit details
    Browse the repository at this point in the history