6 ms·
> So we need a code path that is specifically for calling the str() function on ints. I would argue that this is prohibitively specialized for an interpreter,
by acqq 6y ago
> So we need a code path that is specifically for calling the str() function on ints. I would argue that this is prohibitively specialized for an interpreter,
I would argue it isn't. It's actually less about the ints but about the tuple allocation:
"Now that we've removed enough code we can finally make another big optimization: no longer allocating the args tuple This cuts runtime down to 1.15s." (down from 1.40s)
It seems to me that having special case for one argument, avoiding the tuple allocation in each call is nothing "prohibitively expensive" and would benefit all the functions being called with one argument, and there are enough of such.
Regarding ints vs something else -- somewhere in the code there is anyway different code that does str of int vs str of something else. It's just about accessing that code for that type, it doesn't have to cost having today's speculative execution in the CPU's. The people who produce compiled code know about that and can use it.
- kmod 6y agoThere's a minor but important point: the amount of work str() has to do depends on its input type. In particular, if arg.__str__() returns a string or a subtype of string or not a string, str() will call different tp_init functions. So we can't get rid of the args tuple until after the optimization of knowing that arg.__str__() returns an string (which is why I did them in that order). So I guess the condition is a little bit weaker than str(int) but it's more than str() of one arg.
- burfog 6y agoI think you've proven that the language is a lost cause. It's never going to perform OK. With all the breakage of Python 3, it's a shame that the causes of slowness were not eliminated. The language could have been changed to allow full ahead-of-time compilation, without all the crazy object look-up. Performance might have been like that of Go.
- khc 6y agothen it will become perl6 which no one uses
- lizmat 6y agoPerl 6 is mostly not used because it has been renamed to Raku (https://raku.org https://raku.org using the #rakulang tag on social media). Raku is very much being used. If you want to stay up-to-date with Raku developments, you can check out the Rakudo Weekly News https://rakudoweekly.blog https://rakudoweekly.blog
- acqq 6y agoI'm still very sure that the Python's source code can be refactored to avoid the allocation completely in the case of a zero or one parameter for all the functions that now always have an expectation of the tuple. But I also understand that you can't achieve that in your case without changing the existing code base.