I am not qualified to comment on much of this, but one simple one:
1 million is a nice round easy to remember number.
But you can fit 2 million into 21 bits, and still fit three into 64 bits,
so why not?
Ialso noticed this:
> Reference Implementation
>
> None, as yet. T
On Thu, 12 Dec 2019 11:43:58 +
Rhodri James wrote:
> On 11/12/2019 21:35, Antoine Pitrou wrote:
> > In any case, this will have to be judged on benchmark numbers, once
> > Mark (or someone else) massages the interpreter to experiment with
> > those runtime memory footprint reductions.
>
>
On 11/12/2019 21:35, Antoine Pitrou wrote:
In any case, this will have to be judged on benchmark numbers, once
Mark (or someone else) massages the interpreter to experiment with
those runtime memory footprint reductions.
This I absolutely agree with. Without evidence we're just waving our
pre
On Fri, 6 Dec 2019 15:19:48 -0800
"Gregory P. Smith" wrote:
> I'd prefer it if we stayed on topic here...
+1. Please take rants about 30-year old CPU designs elsewhere (for
example Hacker News, Twitter, Facebook, etc.).
Regards
Antoine.
___
Python-D
On Fri, 6 Dec 2019 13:54:13 +
Rhodri James wrote:
> Apologies again for commenting in the wrong place.
>
> On 05/12/2019 16:38, Mark Shannon wrote:
>
> > Memory access is usually a limiting factor in the performance of
> > modern CPUs. Better packing of data structures enhances locality and
As PEP 611 reads to me, there is a lack of clarity as to whether you are
proposing a Python-the-language limit or a CPython-the-implementation limit. I
think your intent is the latter, but if so please be very clear about that in
the abstract, title, and motivation. The Other implementations s
On 12/06/2019 03:19 PM, Gregory P. Smith wrote:
I'd prefer it if we stayed on topic here...
I find discussion of other computing limits, and how and why they failed (and
the hassles of working around them), very relevant.
--
~Ethan~
___
Python-Dev
I'd prefer it if we stayed on topic here...
On Fri, Dec 6, 2019 at 3:15 PM Chris Angelico wrote:
> On Sat, Dec 7, 2019 at 9:58 AM Greg Ewing
> wrote:
> >
> > On 7/12/19 2:54 am, Rhodri James wrote:
> >
> > > You've talked some about not making the 640k mistake
> >
> > I think it's a bit unfair
On Thu, 2019-12-05 at 16:38 +, Mark Shannon wrote:
> Hi Everyone,
>
> Thanks for all your feedback on my proposed PEP. I've editing the PEP
> in
> light of all your comments and it is now hopefully more precise and
> with
> better justification.
>
> https://github.com/python/peps/pull/1249
On Sat, Dec 7, 2019 at 9:58 AM Greg Ewing wrote:
>
> On 7/12/19 2:54 am, Rhodri James wrote:
>
> > You've talked some about not making the 640k mistake
>
> I think it's a bit unfair to call it a "mistake". They had a 1MB
> address space limit to work with, and that was a reasonable place
> to put
On 7/12/19 2:54 am, Rhodri James wrote:
You've talked some about not making the 640k mistake
I think it's a bit unfair to call it a "mistake". They had a 1MB
address space limit to work with, and that was a reasonable place
to put the division between RAM and display/IO space. If anything
is t
Apologies again for commenting in the wrong place.
On 05/12/2019 16:38, Mark Shannon wrote:
Memory access is usually a limiting factor in the performance of
modern CPUs. Better packing of data structures enhances locality and>
reduces memory bandwith, at a modest increase in ALU usage (for
shi
12 matches
Mail list logo
