This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients pitrou, r.david.murray, serhiy.storchaka, vstinner
Date 2013-04-22.22:00:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwbpmxOdy1PE0=0q-Ghn7cFDawKXWe1bq5hFUEHKByiDog@mail.gmail.com>
In-reply-to <1366509808.92.0.502616719861.issue17742@psf.upfronthosting.co.za>
Content
"I expect that replacing "*p++ = c;" with "*writer.str++ = c;" would
not add an important overhead, especially because writer is a local
variable, and str is the first attribute of the structure. I hope that
the machine code will be exactly the same."

I ran some benchmarks: performances are better in some cases, but
worse in other cases. Performances are worse for simple loop like:

                while (collstart++<collend)
                    *writer.str++ = '?';

For the "writer.str++" instruction, the new pointer value is written
immediatly in the structure. The pointer value is also read again at
each iteration. So we have 1 load and 1 store per iteration. I read
the assembler code on x86_64 using GCC 4.2.1 of Mac OS 10.6.

I compared with the original code:

                while (collstart++<collend)
                    *str++ = '?';

GCC emits better code: str is stored in a register and the new value
of str is only written once, at the end of loop (instead of writing it
at each iteration). The pointer value is read before the loop. So we
have 0 load and 0 store (related to the pointer value) in the body of
the loop.

It may be an aliasing issue, but I didn't find how to say to GCC that
the new value of writer.str can be written only once at the end of the
loop. I tried to add __restrict__ keyword: the load (get the pointer
value) is moved out of the loop. But the store is still in the body of
the loop.
History
Date User Action Args
2013-04-22 22:00:47vstinnersetrecipients: + vstinner, pitrou, r.david.murray, serhiy.storchaka
2013-04-22 22:00:47vstinnerlinkissue17742 messages
2013-04-22 22:00:47vstinnercreate