Python-Dev

Download

python-dev@python.org

April 2018

103 participants
92 discussions

[Crosspost from python-committers] Announcing: signups are open for the 2018 Python Language Summit
by Larry Hastings 02 Apr '18

02 Apr '18

It’s that time again: time to start thinking about the Python Language Summit! The 2018 summit will be held on Wednesday, May 9, from 10am to 4pm, at the Huntington Convention Center in Cleveland, Ohio, USA. Your befezzled and befuddled hosts Barry and Larry will once more be behind the big desk in front. The summit’s purpose is to disseminate information and spark conversation among core Python developers. It’s our yearly opportunity to get together for an in-person discussion, to review interesting developments of the previous year and hash out where we’re going next. And we have lots to talk about! 3.7 is in beta, and we've all collectively started work on 3.8 too. As before, we’re using Google Forms to collect signups. Signups are open now; the deadline to sign up is Wednesday April 18th, 2018 (AoE). Please do us a favor and sign up sooner rather than later. The signup form is simpler this year--I bet most people can be done in less than two minutes! One difference from last year: there are now *two* forms. The first form is for signing up to attend (the "Request For Invitation" form), and the second form is for proposing a talk. Please note: if you want to present, you still need to fill out the Request For Invitation form too. (Yes, it's more complicated this way, sorry. But having both on the same form kind of enforced a one-to-one mapping, and it's really a many-to-many mapping: one person might propose multiple talks, and one talk might have multiple presenters. Overall this should be less complicated.) You can find links to *both* forms on the official Python Language Summit 2018 page: https://us.pycon.org/2018/events/language-summit/ A few notes: * There will be lightning talks! Signups will only be available during the Language Summit itself. * You don’t need to be registered for PyCon in order to attend the summit! * We’ll have badge ribbons for Language Summit participants, which we’ll hand out at the summit room in the morning. * We're inviting Jake Edge from Linux Weekly News to attend the summit and provide press coverage again. Jake’s done a phenomenal job of covering the last few summits, providing valuable information not just for summit attendees, but also for the Python community at large. Jake’s coverage goes a long way toward demystifying the summit, while remaining respectful of confidential information that’s deemed “off the record” ahead of time by participants. One big final note (please read this!): When using Google Forms, you /can/ edit your responses later! When you fill out the form and hit Submit, the submission complete page (the one that says "Thanks for playing!") will have a link on it labeled "Edit your response". BOOKMARK THIS LINK! You can use this link at /any time/ to edit your response, up to the point that signups close on April 18th. Keep in mind, you'll need to bookmark each response independently: once for signing up to attend ("Request For Invitation"), and once for each talk proposal you submit. Again, /please/ be sure to save this bookmark yourself--we don't know how to find the link for you later if you don't save it. We hope to see you at the summit! [BL]arry

1 0

How can we use 48bit pointer safely?
by INADA Naoki 02 Apr '18

02 Apr '18

Hi, As far as I know, most amd64 and arm64 systems use only 48bit address spaces. (except [1]) [1] https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging… It means there are some chance to compact some data structures. I point two examples below. My question is; can we use 48bit pointer safely? It depends on CPU architecture & OS memory map. Maybe, configure option which is available on only (amd64, amd64) * (Linux, Windows, macOS)? # Possible optimizations by 48bit pointer ## PyASCIIObject [snip] unsigned int ready:1; /* Padding to ensure that PyUnicode_DATA() is always aligned to 4 bytes (see issue #19537 on m68k). */ unsigned int :24; } state; wchar_t *wstr; /* wchar_t representation (null-terminated) */ } PyASCIIObject; Currently, state is 8bit + 24bit padding. I think we can pack state and wstr in 64bit. ## PyDictKeyEntry typedef struct { /* Cached hash code of me_key. */ Py_hash_t me_hash; PyObject *me_key; PyObject *me_value; /* This field is only meaningful for combined tables */ } PyDictKeyEntry; There are chance to compact it: Use only 32bit for hash and 48bit*2 for key and value. CompactEntry may be 16byte instead of 24byte. Regards, -- INADA Naoki <songofacandy(a)gmail.com>

3 7