Skip to content

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented Jun 17, 2025

This version uses manually supported stack instead of the C stack. It has less C stack consumption for very large number of arguments. But for not such large number of arguments (thousands or millions) it may actually have larger C stack consumption.

@serhiy-storchaka serhiy-storchaka changed the title gh-102221: Optimize math.lcm() for multiple arguments gh-102221: Optimize math.lcm() for multiple arguments (nonrecursive) Aug 12, 2025
@serhiy-storchaka serhiy-storchaka changed the title gh-102221: Optimize math.lcm() for multiple arguments (nonrecursive) gh-102221: Optimize math.lcm() for multiple arguments (non-recursive) Aug 12, 2025
@skirpichev
Copy link
Contributor

very large number of arguments

How common it is? Where the cutoff when this version will payoff us it's complexity over #135554?

@serhiy-storchaka
Copy link
Member Author

I did not measure it. But estimation for #135554 on abstract machine is 6 words/level (return address, two parameters and three local variables), so this is 6 and 11 on 32- and 64-bit platforms. Or 64 and 2048 arguments correspondingly. It may be less if recursion needs more than just a return address or larger if the compiler is extra clever in reusing stack variable.

The maximal stack consumption of this version is 8*64=512 bytes for the stack variable, plus up to 64 byte for other variables/parameters (but registers can be used for many of them). In #135554 it can be about 3KB in worst case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants