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.

Sign up for GitHub

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

Jump to bottom

Performance regression in long division in 2.6 #48378

Closed
fredrikj mannequin opened this issue Oct 15, 2008 · 7 comments
Closed

Performance regression in long division in 2.6 #48378

fredrikj mannequin opened this issue Oct 15, 2008 · 7 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@fredrikj
Copy link
Mannequin

fredrikj mannequin commented Oct 15, 2008

BPO 4128
Nosy @loewis, @pitrou, @vstinner
Files
  • division_speed.txt
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2008-10-17.18:00:48.622>
created_at = <Date 2008-10-15.10:03:16.826>
labels = ['interpreter-core']
title = 'Performance regression in long division in 2.6'
updated_at = <Date 2008-10-17.18:00:48.621>
user = 'https://bugs.python.org/fredrikj'

    bugs.python.org fields:

    activity = <Date 2008-10-17.18:00:48.621>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = <Date 2008-10-17.18:00:48.622>
closer = 'loewis'
components = ['Interpreter Core']
creation = <Date 2008-10-15.10:03:16.826>
creator = 'fredrikj'
dependencies = []
files = ['11804']
hgrepos = []
issue_num = 4128
keywords = []
message_count = 7.0
messages = ['74798', '74799', '74800', '74906', '74909', '74915', '74927']
nosy_count = 4.0
nosy_names = ['loewis', 'pitrou', 'vstinner', 'fredrikj']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue4128'
versions = ['Python 2.6']
    @fredrikj
    Copy link
    Mannequin Author

    fredrikj mannequin commented Oct 15, 2008

    On my laptop (Windows XP, 32-bit), long division is about 15% slower in
    2.6 compared to 2.5. See the attached .txt for timings.

    I noticed this when comparing the unit tests for mpmath
    (http://code.google.com/p/mpmath/) under 2.5 and 2.6. It appears that
    most tests run 10-20% faster under 2.6 (good work all Python
    developers!), but the tests performing very high precision arithmetic
    run noticeably slower.

    From some quick benchmarking, addition and multiplication are not the
    culprits (they both actually seem to be quite a bit faster in 2.6).

    There could be other factors involved, but from what I've found out so
    far, it is only division that has become slower in 2.6.

    Division in Python 2.4 is also the same speed as 2.5.

    @fredrikj fredrikj mannequin added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Oct 15, 2008
    @vstinner
    Copy link
    Member

    The source code is unchanged except the format functions (binary and
    octal bases with the new prefixes: 0b, 0o). The speed difference comes
    from different compiler options.

    • (Ubuntu Gutsy) python2.5: 1010 ms
    • python trunk: 1010 ms
    • python trunk with -O0: 1800 ms

    I'm using -O0 to help gdb debug, but the default gcc optimization
    level for Python is -03.

    Did you recompiled your own Python or did you use the binary at
    python.org? Look at the compilater option for python 2.5 and python
    2.6.

    @fredrikj
    Copy link
    Mannequin Author

    fredrikj mannequin commented Oct 15, 2008

    The speed difference comes from different compiler options.

    I figured as much. I'm using the binaries from python.org (see the .txt
    file; it includes version headers).

    The question is why the compilation changes for 2.6 slowed down division
    but not e.g. multiplication, and if there is a workaround.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 17, 2008

    It may be that one of the builds was done with profile-guided
    optimization and the other was not.
    If you are interested in long division performance, you may also take a
    look at bpo-3451.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Oct 17, 2008

    The 2.5 build was done by VS 2003, with no PGO, and the 2.6 build was
    done with VS 2008, and it used profile-guided optimization.

    To understand why it behaves the way it behaves, you probably need to
    look at the respective machine code.

    I propose to close this as "won't fix"; I'm not interested in 150ms
    speed differences when dividing 100000 digit numbers.

    @vstinner
    Copy link
    Member

    I propose to close this as "won't fix"

    I agree.

    I'm not interested in 150ms speed differences when dividing 100000
    digit numbers.

    I'm ok to close the ticket, but I'm also interrested to optimize
    Python. But the compiler option is not the best choice to optimize a
    program. I prefer changes like using a O(n) algorithm instead of
    O(n^2) algorithm.

    @fredrikj
    Copy link
    Mannequin Author

    fredrikj mannequin commented Oct 17, 2008

    I propose to close this as "won't fix"; I'm not interested in 150ms
    speed differences when dividing 100000 digit numbers.

    Sure.

    (I care about differences like this, because they have a tendency to add
    up. But it's a minor issue, and a faster algorithm in Python 2.7 will
    indeed solve the problem.)

    @loewis loewis mannequin closed this as completed Oct 17, 2008
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @vstinner @pitrou