30.03.18 02:16, Steven D'Aprano пише:
Is there a down-side to 2b? It sounds like something you might end up
doing at a later date regardless of what you do now.
This complicate the compiler and the eval loop, especially in the case
of nested substitutions in formats, like
f'{value:+{widt
30.03.18 09:28, INADA Naoki пише:
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_white_paper.pdf
It means there are some chance to compact some data structures.
I point t
On 30 March 2018 at 20:05, Serhiy Storchaka wrote:
> 30.03.18 02:16, Steven D'Aprano пише:
>>
>> Is there a down-side to 2b? It sounds like something you might end up
>> doing at a later date regardless of what you do now.
>
>
> This complicate the compiler and the eval loop, especially in the cas
29.03.18 18:06, Terry Reedy пише:
On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
The optimizer already changes semantic. Non-optimized "if a and True:"
would call bool(a) twice, but optimized code calls it only once.
Perhaps Ref 3.3.1 object.__bool__ entry, after " should return False or
True
On Fri, Mar 30, 2018 at 01:29:53PM +0300, Serhiy Storchaka wrote:
> 29.03.18 18:06, Terry Reedy пише:
> >On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
> >>The optimizer already changes semantic. Non-optimized "if a and True:"
> >>would call bool(a) twice, but optimized code calls it only once.
>
On Fri, Mar 30, 2018 at 3:29 AM, Serhiy Storchaka wrote:
> 29.03.18 18:06, Terry Reedy пише:
>>
>> On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
>>>
>>> The optimizer already changes semantic. Non-optimized "if a and True:"
>>> would call bool(a) twice, but optimized code calls it only once.
>>
>
On Fri, 30 Mar 2018 15:28:47 +0900
INADA Naoki wrote:
> 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_white_paper.pdf
>
> It means there are some chance
On 30 March 2018 at 21:16, Nathaniel Smith wrote:
> On Fri, Mar 30, 2018 at 3:29 AM, Serhiy Storchaka wrote:
>> 29.03.18 18:06, Terry Reedy пише:
>>>
>>> On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
The optimizer already changes semantic. Non-optimized "if a and True:"
would call
On Mar 30, 2018, at 08:31 AM, INADA Naoki wrote:
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_white_paper.pdf
It means there are some chance to compact some dat
Not only that, but afaik Linux could simply raise that 57bit virtual
to 64bit virtual without previous
warning on any version change.
On 30 March 2018 at 08:55, Ronald Oussoren wrote:
>
>
> On Mar 30, 2018, at 08:31 AM, INADA Naoki wrote:
>
> Hi,
>
> As far as I know, most amd64 and arm64 syste
On Mar 30, 2018, at 03:11 PM, "Joao S. O. Bueno" wrote:
Not only that, but afaik Linux could simply raise that 57bit virtual
to 64bit virtual without previous
warning on any version change.
The change from 48-bit to 57-bit virtual addresses was not done without any
warning because that would
On Mar 30, 2018, at 01:40 PM, Antoine Pitrou wrote:
A safer alternative is to use the *lower* bits of pointers. The bottom
3 bits are always available for storing ancillary information, since
typically all heap-allocated data will be at least 8-bytes aligned
(probably 16-bytes aligned on 64-b
On Fri, 30 Mar 2018 15:28:47 +0900
INADA Naoki wrote:
>
> # 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). */
>
On 3/30/2018 6:29 AM, Serhiy Storchaka wrote:
29.03.18 18:06, Terry Reedy пише:
On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
The optimizer already changes semantic. Non-optimized "if a and
True:" would call bool(a) twice, but optimized code calls it only once.
Perhaps Ref 3.3.1 object.__boo
ACTIVITY SUMMARY (2018-03-23 - 2018-03-30)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6543 (+14)
closed 38393 (+46)
total 44936 (+60)
Open issues wi
On Fri, Mar 30, 2018 at 4:41 AM, Nick Coghlan wrote:
> On 30 March 2018 at 21:16, Nathaniel Smith wrote:
>> And bool(obj) does always return True or False; if you define a
>> __bool__ method that returns something else then bool rejects it and
>> raises TypeError. So bool(bool(obj)) is already in
30.03.18 16:54, Antoine Pitrou пише:
We could also simply nuke wstr. I frankly don't think it's very
important. It's only used when calling system functions taking a
wchar_t argument, as an « optimization ». I'd be willing to
guess that modern workloads aren't bottlenecked by the cost overhead
[Steven D'Aprano ]
> ...
> Is there a down-side to 2b? It sounds like something you might end up
> doing at a later date regardless of what you do now.
There are always downsides ;-)
As Serhiy noted later, the idea that "it's faster" is an educated
guess - you can't know before it's implemented.
18 matches
Mail list logo
